From stuart at terminus.co.uk Fri Jun 1 00:02:24 2007 From: stuart at terminus.co.uk (Stuart Children) Date: Fri, 01 Jun 2007 01:02:24 +0100 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180642169.9513.24.camel@localhost.localdomain> References: <1180639616.9513.4.camel@localhost.localdomain> <1180642169.9513.24.camel@localhost.localdomain> Message-ID: <465F6210.8000406@terminus.co.uk> If you're interested in my personal opinion on what the names in menus should look like, read the bits under the first quoted section. If you're interested in real development suggestions in how to make GNOME conform to the spec, skip to the second block. Matthias Clasen wrote: > On Thu, 2007-05-31 at 19:57 +0000, Kevin Kofler wrote: >> X-Chat has a meaning, it's the particular IRC client called X-Chat. There's >> several IRC clients in Fedora, including one called xchat-gnome which several >> people think should be the default (in fact, I'd LOVE for it to become the >> default, not because I actually use it, in fact I hate it, but because that >> could lead you to leave the regular X-Chat alone!), so "IRC" is very vague as a >> menu entry. > > Yes, IRC is not a very good menu item either, "IRC client" would be a > bit better, except you really don't want "clients" in the menus. But I > stand by my claim that X-Chat is totally meaningless to regular users. > >> And KDE actually displays "X-Chat (IRC client)" if the user preferences are set >> that way. FWIW: My 2p worth is that this is a very sensible default - people who know what X-Chat is can just click it. People who don't can read the bit in parenthesis and mentally make the association so when they see just "X-Chat" somewhere else (say, the window's titlebar in the launched application) they know what it is, and they know what to call it when they ask others for help. *Personally* I know what everything does, so just "X-Chat" is fine. The only time I'd want to see a totally generic name as a menu item is when it's actually a launcher that picks my current default "IRC client" (or "web broser" etc). I can appreciate arguments for just the generic name - chiefly total newbies who will only ever have one application per "task" installed... ... though I can think of several reasons why that might be bad. However, I'm not interested in arguing them. Choice is good. If the FDO spec [1] is followed when creating the .desktop files and GNOME follows KDE's example in being able to create the menu items in a configurable combination that covers all of the above, then everybody wins right? [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html >> Why does GNOME _still_ not support GenericName years after this >> specification has been supposedly agreed on? IMHO, the real technical problem >> lies there, mangling .desktop files like this is just papering over the >> problem. > > Because nobody implemented it ? Yes, that is not a great answer, but > just ignoring the fact in the name of blind guideline compliance is not > moving us forward. OK, I'll put up. I'm prepared to do the coding and try and get it submitted to GNOME. Assuming that was successful, Fedora could then pick that up the next release and choose a default that suited their policy (or just use whatever default GNOME goes with). Desktop files can be updated to be in-line with the spec. I can change my display default and live in silly-obscure-names-only-developers-could-come-up-with bliss. If anyone has already tried this I'd be interested to know how they got on. From a very quick search I couldn't see any recent discussion on this topic within GNOME. My curiosity got the better of me and I started digging. Traced the GNOME panel code through to gnome-menus gmenu_tree_entry_get_name() function. This just calls desktop_entry_get_name() which as you'd expect returns the appropriate value of Name. So, we extend desktop-entries.c to read and store GenericName, and present a getter method. After that, the question is should gmenu-tree.c (ie: gnome-menus) be making the decision on how to form the resulting string... or whatever is using it (gnome-panel in our case). In order to avoid duplicate code (or worse: code doing similar things with differing behaviour), I would say the former. Only issue is that would seem [2] to indicate that if we wish to make this configurable, gnome-menus needs to gain a dependency on gconf or whatever. Currently: $ ldd /usr/lib/libgnome-menu.so.2.1.3 linux-gate.so.1 => (0x0066b000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00c60000) libfam.so.0 => /usr/lib/libfam.so.0 (0x00ba0000) libc.so.6 => /lib/libc.so.6 (0x0074d000) /lib/ld-linux.so.2 (0x80000000) However: $ rpm -q --whatrequires gnome-menus gnome-panel-2.16.3-2.fc6 control-center-2.16.3-11.fc6 $ rpm -q --whatrequires /usr/lib/libgnome-menu.so.* no package requires /usr/lib/libgnome-menu.so.2 no package requires /usr/lib/libgnome-menu.so.2.1.3 (Is that second query necessary?) Based on that survey of one machine, it would seem adding a gconf dependency to libgnome-menu shouldn't be a big issue. Enough boring developer stuff. It's bedtime here, but I'll fire an email off to the gnome-menus maintainer tomorrow and get their opinion. If feedback is positive I'll get hacking on implementing that, along with exposing an interface for the configuration. [2] IANA GNOME configuration hacker. -- Stuart From blc at redhat.com Fri Jun 1 00:39:19 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 31 May 2007 18:39:19 -0600 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <20070530092348.GN4033@devserv.devel.redhat.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <7dd7ab490705291600x633a3452w85d9275ea662fbf9@mail.gmail.com> <1180516024.26803.87.camel@pmac.infradead.org> <20070530092348.GN4033@devserv.devel.redhat.com> Message-ID: <465F6AB7.8080604@redhat.com> Jakub Jelinek wrote: > but even 8way UltraII is horribly slow). So for secondary arches > we really need async builds instead of sync builds. Or cross builds. It would *really* make bootstrapping a new architecture easier if we had this ability. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From otaylor at redhat.com Fri Jun 1 01:15:01 2007 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 31 May 2007 21:15:01 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: References: <1180639616.9513.4.camel@localhost.localdomain> Message-ID: <1180660501.26450.49.camel@fresnel.dumbhippo.com> [ Cc: and Reply-To: fedora-desktop-list ] On Thu, 2007-05-31 at 19:57 +0000, Kevin Kofler wrote: > Matthias Clasen redhat.com> writes: > > So the two of you simply decided that it would be better for everybody > > if the menu item changed from the (somewhat cryptic, but informative) > > "IRC" to the totally meaningless "X-Chat" ? > > X-Chat has a meaning, it's the particular IRC client called X-Chat. There's > several IRC clients in Fedora, including one called xchat-gnome which several > people think should be the default (in fact, I'd LOVE for it to become the > default, not because I actually use it, in fact I hate it, but because that > could lead you to leave the regular X-Chat alone!), so "IRC" is very vague as a > menu entry. > > And KDE actually displays "X-Chat (IRC client)" if the user preferences are set > that way. Why does GNOME _still_ not support GenericName years after this > specification has been supposedly agreed on? IMHO, the real technical problem > lies there, mangling .desktop files like this is just papering over the > problem. I'm not sure how you think that the Fedora GNOME desktop should be using GenericName. The usage of a generic instead of a specific name in the Fedora menus is done for a small subset of applications: those considered to be "best of breed". Using a generic for everything would produce menus that looked like: IRC client IRC client Web Browser Web Browser Font editor Now, using a generic for *anything* is really a hold-over from a past era when our vision of the Fedora menus was that we'd select a small set of best-of-breed apps for our users, instead of making them deal with the chaos of the entire set of possible applications. This no longer fits with the Fedora philosophy, especially considering the merge of core and extras. The question is more "how to manage the chaos". Ideas that some of us have been working on for managing the chaos: - Collect statistics for the top applications in real use http://mugshot.org/applications - Concentrate on making it easy for the user to launch the applications they use most http://developer.mugshot.org/wiki/Image:Big_Board_and_Application_Browser.png - Bring together the installed applications and the available applications http://developer.mugshot.org/wiki/Image:Big_Board_Application_Browser_-_All_Internet.png Those mockups are a bit stale ... the real thing is better. (bigboard package in extras, but you might want to wait until tomorrow ... Colin has some neat stuff in the pipeline for setting everything up for online-desktop mode.) But you can see, sort of in the mockups, and more in the real thing, what we are using for applications is: X-Chat IRC Client With a tooltip of "Chat with your friends". (We get this from a merge of desktop files with the online Mugshot application database; neither GNOME nor KDE desktop files have all three of the above. GNOME desktop files miss the GenericName, KDE desktop files miss the tooltip.) OK, back to the present: My advise for the X-Chat is to make it match how we do a lot of other .desktop files now: do "X-Chat IRC Client" like "Firefox Web Browser" and so forth. Yes, that will screw over the KDE user who has chosen the Name (Generic Name) preference, but they already have Firefox Web Browser (Web Browser), so they can deal. Maybe we need X-Fedora-Name:, on the other hand, if we manage to make bigboard work, we don't need Fedora-customized menus at all, so we can (eventually, not right now, please), just use Name: X-Chat and get rid of having to munge desktop files as compared to upstream. - Owen From dwmw2 at infradead.org Fri Jun 1 01:15:10 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 01 Jun 2007 02:15:10 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <465F6AB7.8080604@redhat.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <7dd7ab490705291600x633a3452w85d9275ea662fbf9@mail.gmail.com> <1180516024.26803.87.camel@pmac.infradead.org> <20070530092348.GN4033@devserv.devel.redhat.com> <465F6AB7.8080604@redhat.com> Message-ID: <1180660510.26803.592.camel@pmac.infradead.org> On Thu, 2007-05-31 at 18:39 -0600, Brendan Conoboy wrote: > Jakub Jelinek wrote: > > but even 8way UltraII is horribly slow). So for secondary arches > > we really need async builds instead of sync builds. > > Or cross builds. It would *really* make bootstrapping a new > architecture easier if we had this ability. It's hard. When I tried cross-building for ARM and SH a long time ago, I ran into many problems, mostly with autotools. Something like scratchbox? might help, but I'm entirely unsure that I'd want to trust it to build the whole distribution for release. It doesn't help much that qemu's userspace emulation doesn't handle NPTL yet? (although I did get it sort of working a few months back to get the flash plugin running in nspluginwrapper in qemu-i386). The only really reliable solution I see would be full-system emulation. Which isn't always much faster than the real hardware, unfortunately. -- dwmw2 ? http://scratchbox.org/ ? Actually, do we support NPTL on ARM at all yet? From tibbs at math.uh.edu Fri Jun 1 01:59:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 May 2007 20:59:07 -0500 Subject: An idea for RPM -> License Agreement support In-Reply-To: <604aa7910705301454x3b7d1118td2ec111bf5021b6d@mail.gmail.com> References: <604aa7910705301454x3b7d1118td2ec111bf5021b6d@mail.gmail.com> Message-ID: >>>>> "JS" == Jeff Spaleta writes: JS> Older versions of the flash-plugin package provided by JS> macromedia.mplug.org had a technical solution to this using a post JS> install script which would open an EULA click-through window with JS> a timeout if X display was detected. Unattended package installs JS> and upgrades would still work, but the setup command would have to JS> be run later manually to run through the agreement to the license JS> before the plugin could be used. And of course, intelligent people just did "touch /etc/flash.license" at system build time, so users weren't bothered by useless crap. - J< From orion at cora.nwra.com Fri Jun 1 03:52:40 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Thu, 31 May 2007 21:52:40 -0600 (MDT) Subject: Mirroring tools Message-ID: <4890.71.208.204.173.1180669960.squirrel@www.cora.nwra.com> I'd like to try to reduce the amount of packages that I mirror locally, especially with the ever increasing amount of large game packages. Has anyone thought about a tool that could take a list of packages names generated by something like pungi and generate a include list suitable for rsync? Then you could do something like: rsync --include-from rpms_I_want --exclude \*.rpm Currently I periodically update an exclude list by hand, but this is getting tiresome. Just thought about using the output of 'yum groupinfo games' and the like to generate exclude lists. Maybe that will be easier and sufficient. - Orion From aalam at redhat.com Fri Jun 1 04:01:49 2007 From: aalam at redhat.com (A S Alam) Date: Fri, 01 Jun 2007 09:31:49 +0530 Subject: Pidgin problem In-Reply-To: <6bb886180705310435r75935c66yff92f25fb302a759@mail.gmail.com> References: <6bb886180704260433s39cf1c98v21212b8c3a07840@mail.gmail.com> <46309EA1.9020104@nigelj.com> <1177600852.22781.19.camel@metroid.rdu.redhat.com> <6bb886180705310435r75935c66yff92f25fb302a759@mail.gmail.com> Message-ID: <465F9A2D.6060309@redhat.com> David Hunter ?? ?????: > Pidgin crashing again. How to get a backtrace? > one bug for pidgin was filed for crash -- Bug 241580: Crash application during getting message from Buddy [BT attached] -- for bt with pidgin, http://live.gnome.org/GettingTraces/Details can help regards -- A S Alam #fedora-l10n (freenode) tz GMT+5:30 "Either find a way or Make one" From lightsolphoenix at gmail.com Fri Jun 1 04:36:34 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Fri, 1 Jun 2007 00:36:34 -0400 Subject: hwinfo? Message-ID: <200706010036.35017.lightsolphoenix@gmail.com> I was attempting to package up the GPL'ed version of the sysinfo:/ kioslave for Fedora, when I ran into a brick wall; sysinfo requires hwinfo. I don't seem to recall if hwinfo was ever in Fedora? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From dennis at ausil.us Fri Jun 1 04:44:07 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 31 May 2007 23:44:07 -0500 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706010003.11844.opensource@till.name> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706010003.11844.opensource@till.name> Message-ID: <200705312344.11171.dennis@ausil.us> Once upon a time Thursday 31 May 2007, Till Maas wrote: > On Do Mai 31 2007, Ralf Corsepius wrote: > > Can we please have http://buildsys.fedoraproject.org/buildgroups/7 > > And please with gpg signed rpms :-) > > Regards, > Till sorry I should have put these up a week or so ago. Unfortunately i cant sign them as im only in the epel signing group. i really dont know what key they should be signed if they were. It is up there now. please let me know if an arch needs adding Dennis From orion at cora.nwra.com Fri Jun 1 04:50:04 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Thu, 31 May 2007 22:50:04 -0600 (MDT) Subject: Multilib doc packages Message-ID: <1104.71.208.204.173.1180673404.squirrel@www.cora.nwra.com> There appears to be on the order of 340MB of -doc, -docs, and -javadoc i386 packages in the x86_64 development repository. Presumably these will be nearly identical to the x86_64 versions. Perhaps it might be worthwhile excluding them? Not worth the effort if we are just going to move to arch specific repositories... - Orion From notting at redhat.com Fri Jun 1 04:59:53 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 00:59:53 -0400 Subject: hwinfo? In-Reply-To: <200706010036.35017.lightsolphoenix@gmail.com> References: <200706010036.35017.lightsolphoenix@gmail.com> Message-ID: <20070601045953.GA32203@nostromo.devel.redhat.com> Kelly (lightsolphoenix at gmail.com) said: > I was attempting to package up the GPL'ed version of the sysinfo:/ kioslave > for Fedora, when I ran into a brick wall; sysinfo requires hwinfo. I don't > seem to recall if hwinfo was ever in Fedora? Don't thin it was, that's a SuSE/Novell thing. Looking at the web page, sysinfo really should be able to get everything it needs from HAL - what does it use hwinfo for? Bill From notting at redhat.com Fri Jun 1 05:00:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 01:00:43 -0400 Subject: Multilib doc packages In-Reply-To: <1104.71.208.204.173.1180673404.squirrel@www.cora.nwra.com> References: <1104.71.208.204.173.1180673404.squirrel@www.cora.nwra.com> Message-ID: <20070601050043.GB32203@nostromo.devel.redhat.com> orion at cora.nwra.com (orion at cora.nwra.com) said: > There appears to be on the order of 340MB of -doc, -docs, and -javadoc > i386 packages in the x86_64 development repository. Presumably these will > be nearly identical to the x86_64 versions. Perhaps it might be > worthwhile excluding them? Not worth the effort if we are just going to > move to arch specific repositories... multlib depsolving in rawhide went bang. It should sort itself out in a day or two. Bill From fedora at leemhuis.info Fri Jun 1 05:11:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 07:11:46 +0200 Subject: Upcoming FESCo Election In-Reply-To: <1180627394.5867.2.camel@lincoln> References: <1180627394.5867.2.camel@lincoln> Message-ID: <465FAA92.6050708@leemhuis.info> On 31.05.2007 18:03, Brian Pepple wrote: > > It's that time of year again. Everyone that wants to be in the next > FESCo needs to nominate him/herself for it by June 12, 2007 0:00 UTC; > that self-nomination should contain some information's like "Mission > Statement, Past work summary and Future plans". I think it's to early to have that election; the Board (together with FESCo) still didn't clarify what FESCo will be responsible for and where other groups (release engineering for example) are in the hierarchy of the whole game. That should be solved *before* a proper election is held IMHO, as that is highly relevant. To give a short example from a voters point of view: If FESCo is responsible for the distribution itself (features, schedule) and its packages I might vote for foo and bar, but not baz. But if FESCo just handles packaging in practice I might go for bar and baz, but not for foo. What FESCo will do in the future is also highly relevant for those people that might want to consider self-nominating for FESCo. Just my 2 cent. CU thl From kevin at scrye.com Fri Jun 1 05:31:43 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 31 May 2007 23:31:43 -0600 Subject: Koji - Trouble building for F-7 In-Reply-To: <20070531230054.GA7458@bludgeon.org> References: <20070531230054.GA7458@bludgeon.org> Message-ID: <20070531233143.430953c5@ghistelwchlohm.scrye.com> On Thu, 31 May 2007 16:00:54 -0700 rayvd at bludgeon.org (Ray Van Dolson) wrote: > This is my first package, so please bear with me. Welcome to the fun. ;) > I am trying to build remind: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235802 > > But am having some problems getting Koji to work. Had no issues > building for FC-6 and EL-[45] (I realize they do not use the Koji > build system). > ...snip... The problem was that you had a typo in your cvs request... Owners: rayvd at buldgeon.org (l and u swapped there) So things weren't updating right. ;) Should be all fixed now.. if you wait an hour or so and retry your builds they should all go through. :) > How about for Fedora Core 8 (devel)? Should also be fine on the next sync. > Thanks in advance! > Ray > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rayvd at bludgeon.org Fri Jun 1 05:43:34 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 31 May 2007 22:43:34 -0700 Subject: Koji - Trouble building for F-7 In-Reply-To: <20070531233143.430953c5@ghistelwchlohm.scrye.com> References: <20070531230054.GA7458@bludgeon.org> <20070531233143.430953c5@ghistelwchlohm.scrye.com> Message-ID: <20070601054334.GA15442@bludgeon.org> On Thu, May 31, 2007 at 11:31:43PM -0600, Kevin Fenzi wrote: > The problem was that you had a typo in your cvs request... > > Owners: rayvd at buldgeon.org > > (l and u swapped there) > > So things weren't updating right. ;) All I have to say is: argh. :) > Should be all fixed now.. if you wait an hour or so and retry your > builds they should all go through. > > :) Thanks kevin! From oliver at linux-kernel.at Fri Jun 1 06:18:21 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jun 2007 08:18:21 +0200 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1180635609.26803.471.camel@pmac.infradead.org> References: <1180473516.6254.454.camel@localhost.localdomain> <200705310826.55432.jkeating@redhat.com> <1180616481.26803.403.camel@pmac.infradead.org> <200705310908.01270.jkeating@redhat.com> <465ED1FF.8050704@linux-kernel.at> <1180622540.26803.457.camel@pmac.infradead.org> <465EE3D5.8010607@linux-kernel.at> <1180635609.26803.471.camel@pmac.infradead.org> Message-ID: <465FBA2D.2020403@linux-kernel.at> On 05/31/2007 08:20 PM, David Woodhouse wrote: > On Thu, 2007-05-31 at 17:03 +0200, Oliver Falk wrote: >>> 1. A spurious build or test failure which happens on all arches >>> but intermittently. >>> 2. A simple error introduced in the package update. >>> 3. Something 'hard' which the arch team need to look into. >>> 4. A compiler bug. >> OK, for is possible sure, but doesn't happen quite often hopefully. > > You mean that #4 is possible but shouldn't happen often? That's true at > the moment but once we start pulling in new architectures it could > happen more often. Yes, of course. You're totally right... There are enough bugs in the 'other archs'... > We should make sure that it's relatively easy for a package maintainer > to see a compiler failure, and just say "Don't Care" and leave it for > the arch maintainer to deal with (although the more conscientious > package maintainers would actually file the compiler bug with test case > for themselves). Being able to file a bug and then push a button for > 'release the build anyway' seems not to be too much of an imposition. > > In fact, _other_ than compiler bugs, I suspect that the _majority_ of > bugs which just happen to kill one build but not others may well be > generic bugs which are sensitive to timing or other criteria, and not > really arch-specific at all. Which is why it's so irresponsible to let > partially-failed builds make it through to the repo without _any_ > interaction from the maintainer at all. We will see. :-) -of From frank-buettner at gmx.net Fri Jun 1 07:54:00 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Fri, 01 Jun 2007 09:54:00 +0200 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree Message-ID: <465FD098.2060808@gmx.net> Here an list of packages that shut be fixed it dist tags. abcde-2.3.99.6-2.fc6.noarch.rpm abe-1.1-4.fc6.i386.rpm abuse-0.7.0-3.fc6.i386.rpm acpi-0.09-2.fc6.i386.rpm acpitool-0.4.6-2.fc6.i386.rpm adime-2.2.1-4.fc6.i386.rpm adime-devel-2.2.1-4.fc6.i386.rpm adns-1.2-5.fc6.i386.rpm adns-devel-1.2-5.fc6.i386.rpm adns-progs-1.2-5.fc6.i386.rpm AGReader-1.2-2.fc6.i386.rpm aiksaurus-1.2.1-15.fc6.i386.rpm aiksaurus-devel-1.2.1-15.fc6.i386.rpm aiksaurus-gtk-1.2.1-15.fc6.i386.rpm aiksaurus-gtk-devel-1.2.1-15.fc6.i386.rpm AllegroOGG-1.0.3-3.fc6.i386.rpm AllegroOGG-devel-1.0.3-3.fc6.i386.rpm alleyoop-0.9.3-2.fc6.i386.rpm alltray-0.69-2.fc6.i386.rpm alsamixergui-0.9.0-0.3.rc1.fc6.i386.rpm altermime-0.3.7-2.fc6.i386.rpm ant-contrib-1.0-0.4.b2.fc6.i386.rpm ant-contrib-javadoc-1.0-0.4.b2.fc6.i386.rpm apachetop-0.12.6-2.fc6.i386.rpm apel-10.6-9.fc6.noarch.rpm apg-2.3.0b-4.fc6.i386.rpm apollon-1.0.1-7.fc6.i386.rpm arc-5.21o-3.fc6.i386.rpm arj-3.10.22-1.fc6.i386.rpm artwiz-aleczapka-fonts-1.3-5.fc6.noarch.rpm asa-1.2-3.fc6.i386.rpm aspell-he-1.0-2.fc6.i386.rpm athcool-0.3.11-5.fc6.i386.rpm atlas-3.6.0-11.fc6.i386.rpm atlas-3dnow-3.6.0-11.fc6.i386.rpm atlas-3dnow-devel-3.6.0-11.fc6.i386.rpm atlascpp-0.6.0-3.fc6.i386.rpm atlascpp-devel-0.6.0-3.fc6.i386.rpm atlas-devel-3.6.0-11.fc6.i386.rpm atlas-sse2-3.6.0-11.fc6.i386.rpm atlas-sse2-devel-3.6.0-11.fc6.i386.rpm atlas-sse-3.6.0-11.fc6.i386.rpm atlas-sse-devel-3.6.0-11.fc6.i386.rpm atomix-2.14.0-2.fc6.i386.rpm auriferous-1.0.1-3.fc6.i386.rpm autossh-1.3-4.fc6.i386.rpm autotrace-0.31.1-14.fc6.i386.rpm autotrace-devel-0.31.1-14.fc6.i386.rpm BackupPC-2.1.2-7.fc6.noarch.rpm ballbuster-1.0-1.fc6.i386.rpm banner-1.3.1-4.fc6.i386.rpm barcode-0.98-10.fc6.i386.rpm barcode-devel-0.98-10.fc6.i386.rpm bazaar-1.4.2-8.fc6.i386.rpm bidiv-1.5-4.fc6.i386.rpm blktool-4-6.fc6.i386.rpm blt-2.4-14.z.fc6.i386.rpm boa-0.94.14-0.5.rc21.fc6.i386.rpm bonnie++-1.03a-6.fc6.i386.rpm brandy-1.0.19-4.fc6.i386.rpm bsdiff-4.3-2.fc6.i386.rpm bubblemon-1.46-6.fc6.i386.rpm bwidget-1.8.0-1.fc6.noarch.rpm bygfoot-2.0.1-1.fc6.i386.rpm byzanz-0.1.1-4.fc6.i386.rpm cabextract-1.1-5.fc6.i386.rpm CastPodder-5.0-8.fc6.noarch.rpm cd-discid-0.9-6.fc6.i386.rpm cdlabelgen-3.6.0-1.fc6.noarch.rpm cdo-1.0.1-2.fc6.i386.rpm cegui-0.4.1-11.fc6.i386.rpm cegui-devel-0.4.1-11.fc6.i386.rpm cegui-devel-doc-0.4.1-11.fc6.i386.rpm cfv-1.18.1-2.fc6.noarch.rpm cgoban-1.9.14-8.fc6.i386.rpm check-devel-0.9.3-5.fc6.i386.rpm chrpath-0.13-1.1.fc6.i386.rpm ClanLib06-0.6.5-7.fc6.i386.rpm ClanLib06-devel-0.6.5-7.fc6.i386.rpm cln-1.1.13-2.fc6.i386.rpm cln-devel-1.1.13-2.fc6.i386.rpm clusterssh-3.19.1-2.fc6.noarch.rpm coldet-1.1-4.fc6.i386.rpm coldet-devel-1.1-4.fc6.i386.rpm compat-wxGTK2-2.4.2-21.fc6.i386.rpm compat-wxGTK-2.4.2-21.fc6.i386.rpm compat-wxGTK2-devel-2.4.2-21.fc6.i386.rpm compat-wxGTK2-gl-2.4.2-21.fc6.i386.rpm compat-wxGTK2-stc-2.4.2-21.fc6.i386.rpm compat-wxGTK2-xrc-2.4.2-21.fc6.i386.rpm compat-wxGTK-common-2.4.2-21.fc6.i386.rpm compat-wxGTK-common-devel-2.4.2-21.fc6.i386.rpm compat-wxGTK-devel-2.4.2-21.fc6.i386.rpm compat-wxGTK-gl-2.4.2-21.fc6.i386.rpm compat-wxGTK-stc-2.4.2-21.fc6.i386.rpm compat-wxGTK-xrc-2.4.2-21.fc6.i386.rpm connect-proxy-1.95-5.fc6.i386.rpm convmv-1.10-2.fc6.noarch.rpm cook-2.26-3.fc6.i386.rpm cowbell-0.2.7.1-6.fc6.i386.rpm cpan2rpm-2.028-2.fc6.noarch.rpm cproto-4.7e-2.fc6.i386.rpm cpufreq-utils-002-1.1.41.fc6.i386.rpm crossfire-maps-1.9.1-2.fc6.noarch.rpm crystal-stacker-1.5-3.fc6.i386.rpm crystal-stacker-theme-editor-1.5-3.fc6.i386.rpm crystal-stacker-themes-1.0-2.fc6.noarch.rpm ctapi-common-1.0-4.fc6.i386.rpm ctrlproxy-2.6.2-7.fc6.i386.rpm curry-0.9.10-3.fc6.i386.rpm cvsgraph-1.6.1-3.fc6.i386.rpm cvsps-2.1-4.fc6.i386.rpm cvsweb-3.0.6-3.fc6.noarch.rpm daap-sharp-0.3.3-4.fc6.i386.rpm daap-sharp-devel-0.3.3-4.fc6.i386.rpm dbh-1.0.24-5.fc6.i386.rpm dbh-devel-1.0.24-5.fc6.i386.rpm dbus-sharp-0.63-6.fc6.i386.rpm dbus-sharp-devel-0.63-6.fc6.i386.rpm diction-1.10-0.1.1.rc4.fc6.i386.rpm dillo-0.8.6-3.fc6.i386.rpm dirvish-1.2.1-2.fc6.noarch.rpm dmidecode-2.7-1.26.1.fc6.i386.rpm docbook2X-0.8.7-2.fc6.i386.rpm dssi-0.9.1-10.fc6.i386.rpm dssi-devel-0.9.1-10.fc6.i386.rpm dssi-examples-0.9.1-10.fc6.i386.rpm dumb-0.9.3-5.fc6.i386.rpm dumb-devel-0.9.3-5.fc6.i386.rpm dx-4.4.4-2.fc6.i386.rpm dx-devel-4.4.4-2.fc6.i386.rpm dx-samples-4.4.0-3.fc6.noarch.rpm dynamite-0.1-6.fc6.i386.rpm dynamite-devel-0.1-6.fc6.i386.rpm echoping-5.2.0-2.fc6.i386.rpm ecl-0.9i-3.fc6.i386.rpm ed2k_hash-0.4.0-3.fc6.i386.rpm ed2k_hash-gui-0.4.0-3.fc6.i386.rpm efont-unicode-bdf-0.4.2-6.1.fc6.noarch.rpm emacs-gtypist-2.7-4.fc6.i386.rpm enca-1.9-3.fc6.i386.rpm enca-devel-1.9-3.fc6.i386.rpm enchant-1.3.0-1.fc6.i386.rpm enchant-devel-1.3.0-1.fc6.i386.rpm esmtp-0.5.1-13.fc6.i386.rpm ez-ipupdate-3.0.11-0.12.b8.fc6.i386.rpm fbdesk-1.4.0-2.fc6.i386.rpm fdupes-1.40-8.fc6.i386.rpm feh-1.3.4-4.fc6.i386.rpm fetchlog-1.0-8.fc6.i386.rpm fftw-3.1.2-3.fc6.i386.rpm fftw-devel-3.1.2-3.fc6.i386.rpm filelight-1.0-9.fc6.i386.rpm fillets-ng-0.7.3-5.fc6.i386.rpm firestarter-1.0.3-14.fc6.i386.rpm fish-1.21.12-1.fc6.i386.rpm flasm-1.61-3.fc6.i386.rpm flim-1.14.8-2.fc6.noarch.rpm flim-xemacs-1.14.8-2.fc6.noarch.rpm fluidsynth-1.0.7-8.a.fc6.i386.rpm fluidsynth-devel-1.0.7-8.a.fc6.i386.rpm fluidsynth-dssi-0.9.1-7.fc6.i386.rpm fluidsynth-libs-1.0.7-8.a.fc6.i386.rpm fluxconf-0.9.9-3.fc6.i386.rpm fnfx-0.3-8.fc6.i386.rpm foremost-1.3-0.1.20060826.fc6.i386.rpm fortune-firefly-2.1.1-2.fc6.noarch.rpm fpc-2.0.4-2.fc6.i386.rpm fpc-doc-2.0.4-2.fc6.i386.rpm fpc-src-2.0.4-2.fc6.i386.rpm fping-2.4b2-7.fc6.i386.rpm fRaBs-2.10-2.fc6.noarch.rpm freedroid-1.0.2-6.fc6.i386.rpm freeze-2.5.0-7.fc6.i386.rpm frotz-2.43-5.fc6.i386.rpm ftnchek-3.3.1-5.fc6.i386.rpm ftnchek-emacs-3.3.1-5.fc6.i386.rpm fuse-emulator-0.7.0-6.fc6.i386.rpm fuse-emulator-utils-0.7.0-5.fc6.i386.rpm fuse-sshfs-1.7-2.fc6.i386.rpm fwrestart-1.04-2.fc6.noarch.rpm fyre-1.0.1-1.fc6.i386.rpm galago-daemon-0.5.1-1.fc6.i386.rpm galculator-1.2.5-5.fc6.i386.rpm ganymed-ssh2-210-2.fc6.i386.rpm ganymed-ssh2-javadoc-210-2.fc6.i386.rpm gcdmaster-1.2.2-1.fc6.i386.rpm gcfilms-6.4-2.fc6.noarch.rpm gdmap-0.7.5-6.fc6.i386.rpm genchemlab-1.0-5.fc6.i386.rpm gentoo-0.11.56-2.fc6.i386.rpm ghasher-1.2.1-2.fc6.i386.rpm ghex-2.8.2-4.fc6.i386.rpm ghex-devel-2.8.2-4.fc6.i386.rpm giblib-1.2.4-7.fc6.i386.rpm giblib-devel-1.2.4-7.fc6.i386.rpm gif2png-2.5.1-3.fc6.i386.rpm gift-openft-0.2.1.6-3.fc6.i386.rpm gkrellm-aclock-0.3.4-1.fc6.i386.rpm gkrellm-freq-1.0-3.fc6.i386.rpm gkrellm-hddtemp-0.2-0.6.beta.fc6.i386.rpm gkrellm-volume-2.1.13-4.fc6.i386.rpm gkrellm-weather-2.0.7-3.fc6.i386.rpm glabels-2.0.4-5.fc6.i386.rpm glabels-devel-2.0.4-5.fc6.i386.rpm glade2-2.12.1-5.fc6.i386.rpm Glide3-20050815-5.fc6.i386.rpm Glide3-devel-20050815-5.fc6.i386.rpm Glide3-libGL-6.2.1-6.fc6.i386.rpm glunarclock-0.32.4-7.fc6.i386.rpm gnet2-2.0.7-9.fc6.i386.rpm gnet2-devel-2.0.7-9.fc6.i386.rpm gnome-applet-netspeed-0.13-7.fc6.i386.rpm gnome-applet-sensors-1.7.8-3.fc6.i386.rpm gnome-ppp-0.3.23-3.fc6.i386.rpm gnomeradio-1.6-3.fc6.i386.rpm gnome-sharp-2.16.0-1.fc6.i386.rpm gnome-sharp-devel-2.16.0-1.fc6.i386.rpm gnotime-2.2.2-7.fc6.i386.rpm gnuchess-5.07-10.fc6.i386.rpm gnugo-3.6-5.fc6.i386.rpm gnustep-make-1.12.0-5.fc6.i386.rpm gphpedit-0.9.91-3.fc6.i386.rpm gpp-0.6.6-3.fc6.i386.rpm gputils-0.13.4-2.fc6.i386.rpm grisbi-0.5.9-1.fc6.i386.rpm gsf-sharp-0.8.1-2.fc6.i386.rpm gsf-sharp-devel-0.8.1-2.fc6.i386.rpm gtkglarea2-1.99.0-7.fc6.i386.rpm gtkglarea2-devel-1.99.0-7.fc6.i386.rpm gtkglext-1.2.0-4.fc6.i386.rpm gtkglext-devel-1.2.0-4.fc6.i386.rpm gtkglextmm-1.2.0-5.fc6.i386.rpm gtkglextmm-devel-1.2.0-5.fc6.i386.rpm gtkmathview-0.7.6-5.fc6.i386.rpm gtkmathview-devel-0.7.6-5.fc6.i386.rpm gtkterm-0.99.5-3.fc6.i386.rpm gts-0.7.6-6.fc6.i386.rpm gts-devel-0.7.6-6.fc6.i386.rpm gtweakui-0.4.0-3.fc6.i386.rpm gtypist-2.7-4.fc6.i386.rpm harminv-1.3.1-8.fc6.i386.rpm harminv-devel-1.3.1-8.fc6.i386.rpm help2man-1.36.4-1.fc6.noarch.rpm hercules-3.04.1-4.fc6.i386.rpm Hermes-1.3.3-12.fc6.i386.rpm Hermes-devel-1.3.3-12.fc6.i386.rpm hevea-1.08-6.fc6.i386.rpm hfsplusutils-1.0.4-8.fc6.i386.rpm hmmer-2.3.2-6.fc6.i386.rpm hnb-1.9.18-3.fc6.i386.rpm hpic-0.52.2-2.fc6.i386.rpm hpic-devel-0.52.2-2.fc6.i386.rpm ht2html-2.0-5.fc6.noarch.rpm html401-dtds-4.01-19991224.3.fc6.noarch.rpm html-xml-utils-3.7-4.fc6.i386.rpm http_ping-20050629-4.fc6.i386.rpm hunky-fonts-0.3.1-4.fc6.noarch.rpm hunt-1.5-6.fc6.i386.rpm i810switch-0.6.5-5.fc6.i386.rpm i8kutils-1.25-11.fc6.i386.rpm id3v2-0.1.11-4.fc6.i386.rpm ifm-5.1-5.fc6.i386.rpm ikvm-0.22-10.fc6.i386.rpm ikvm-devel-0.22-10.fc6.i386.rpm inadyn-1.96-3.fc6.i386.rpm inews-2.4.3-6.fc6.i386.rpm inn-2.4.3-6.fc6.i386.rpm inn-devel-2.4.3-6.fc6.i386.rpm iozone-3-3.fc6.i386.rpm ipxripd-0.8-4.fc6.i386.rpm itext-1.3-3.fc6.i386.rpm itext-javadoc-1.3-3.fc6.i386.rpm itext-manual-1.3-3.fc6.i386.rpm iwidgets-4.0.1-4.fc6.noarch.rpm jakarta-commons-cli-1.0-6jpp_10.fc6.i386.rpm jakarta-commons-cli-javadoc-1.0-6jpp_10.fc6.i386.rpm jam-2.5-4.fc6.i386.rpm javasvn-1.1.0-0.3.beta4.fc6.i386.rpm javasvn-javadoc-1.1.0-0.3.beta4.fc6.i386.rpm jed-0.99.18-5.fc6.i386.rpm jogl-1.0.0-5.7.beta5.fc6.i386.rpm jogl-javadoc-1.0.0-5.7.beta5.fc6.i386.rpm jthread-1.2.1-2.fc6.i386.rpm jthread-devel-1.2.1-2.fc6.i386.rpm kadu-theme-crystal16-0.5.0-2.fc6.noarch.rpm kadu-theme-crystal22-0.5.0-2.fc6.noarch.rpm kadu-theme-glass16-0.5.0-2.fc6.noarch.rpm kadu-theme-glass22-0.5.0-2.fc6.noarch.rpm kadu-theme-nuvola16-0.5.0-2.fc6.noarch.rpm kadu-theme-nuvola22-0.5.0-2.fc6.noarch.rpm kakasi-2.3.4-22.fc6.i386.rpm kakasi-devel-2.3.4-22.fc6.i386.rpm kakasi-dict-2.3.4-22.fc6.i386.rpm kanatest-0.3.6-6.fc6.i386.rpm kannel-1.4.1-2.fc6.i386.rpm kannel-devel-1.4.1-2.fc6.i386.rpm kasablanca-0.4.0.2-9.fc6.i386.rpm kbackup-0.5.1-2.fc6.i386.rpm kdetv-0.8.9-4.fc6.i386.rpm kdiff3-0.9.90-7.fc6.i386.rpm kdirstat-2.5.3-5.fc6.i386.rpm kdnssd-avahi-0.1.3-0.1.20060713svn.fc6.i386.rpm kdnssd-avahi-devel-0.1.3-0.1.20060713svn.fc6.i386.rpm kdocker-1.3-8.fc6.i386.rpm keyutils-1.2-2.fc6.i386.rpm keyutils-libs-1.2-2.fc6.i386.rpm keyutils-libs-devel-1.2-2.fc6.i386.rpm kickpim-0.5.3-10.fc6.i386.rpm kiosktool-1.0-6.fc6.i386.rpm kmobiletools-0.4.3.3-3.fc6.i386.rpm konversation-1.0.1-2.fc6.i386.rpm kphone-4.2-11.fc6.i386.rpm krecipes-0.9.1-5.fc6.i386.rpm ksensors-0.7.3-7.fc6.i386.rpm ksynaptics-0.3.1-3.fc6.i386.rpm ktrack-0.3.0-15.rc1.fc6.i386.rpm kyum-0.7.5-4.fc6.i386.rpm lacewing-1.10-7.fc6.i386.rpm lagan-1.21-3.fc6.i386.rpm lasi-1.0.6-1.fc6.i386.rpm lasi-devel-1.0.6-1.fc6.i386.rpm lcov-1.4-2.fc6.noarch.rpm ldns-1.0.1-4.fc6.i386.rpm ldns-devel-1.0.1-4.fc6.i386.rpm lib765-0.3.4-2.fc6.i386.rpm lib765-devel-0.3.4-2.fc6.i386.rpm libAfterImage-1.07-8.fc6.i386.rpm libAfterImage-devel-1.07-8.fc6.i386.rpm libavc1394-0.5.3-1.fc6.i386.rpm libavc1394-devel-0.5.3-1.fc6.i386.rpm libbinio-1.4-6.fc6.i386.rpm libbinio-devel-1.4-6.fc6.i386.rpm libcdio-0.77-3.fc6.i386.rpm libcdio-devel-0.77-3.fc6.i386.rpm libchmxx-0.1-5.fc6.i386.rpm libchmxx-devel-0.1-5.fc6.i386.rpm libcmml-0.9.1-3.fc6.i386.rpm libcmml-devel-0.9.1-3.fc6.i386.rpm libconfuse-2.5-3.fc6.i386.rpm libconfuse-devel-2.5-3.fc6.i386.rpm libctl-3.0.2-4.fc6.i386.rpm libctl-devel-3.0.2-4.fc6.i386.rpm libdsk-1.1.9-2.fc6.i386.rpm libdsk-devel-1.1.9-2.fc6.i386.rpm libdsk-tools-1.1.9-2.fc6.i386.rpm libebml-0.7.7-2.fc6.i386.rpm libebml-devel-0.7.7-2.fc6.i386.rpm libesmtp-1.0.4-2.fc6.i386.rpm libesmtp-devel-1.0.4-2.fc6.i386.rpm libFoundation-1.1.3-10.fc6.i386.rpm libFoundation-devel-1.1.3-10.fc6.i386.rpm libgalago-0.5.2-3.fc6.i386.rpm libgalago-devel-0.5.2-3.fc6.i386.rpm libgalago-gtk-0.5.0-4.fc6.i386.rpm libgalago-gtk-devel-0.5.0-4.fc6.i386.rpm libgdamm-1.3.7-4.fc6.i386.rpm libgdamm-devel-1.3.7-4.fc6.i386.rpm libglade-0.17-19.fc6.i386.rpm libglade-devel-0.17-19.fc6.i386.rpm libglademm24-2.6.3-2.fc6.i386.rpm libglademm24-devel-2.6.3-2.fc6.i386.rpm libid3tag-0.15.1b-3.fc6.i386.rpm libid3tag-devel-0.15.1b-3.fc6.i386.rpm libifp-1.0.0.2-4.fc6.i386.rpm libifp-devel-1.0.0.2-4.fc6.i386.rpm libjingle-0.3.10-1.fc6.i386.rpm libjingle-devel-0.3.10-1.fc6.i386.rpm liblrdf-0.4.0-10.fc6.i386.rpm liblrdf-devel-0.4.0-10.fc6.i386.rpm libmcrypt-2.5.7-5.fc6.i386.rpm libmcrypt-devel-2.5.7-5.fc6.i386.rpm libmodelfile-0.1.92-4.fc6.i386.rpm libmodelfile-devel-0.1.92-4.fc6.i386.rpm libmpcdec-1.2.2-4.fc6.i386.rpm libmpcdec-devel-1.2.2-4.fc6.i386.rpm libnjb-2.2.5-3.fc6.i386.rpm libnjb-devel-2.2.5-3.fc6.i386.rpm libnjb-examples-2.2.5-3.fc6.i386.rpm libofa-0.9.3-8.fc6.i386.rpm libofa-devel-0.9.3-8.fc6.i386.rpm liboggz-0.9.4-3.fc6.i386.rpm liboggz-devel-0.9.4-3.fc6.i386.rpm libosip-0.9.7-10.fc6.i386.rpm libosip-devel-0.9.7-10.fc6.i386.rpm libotr-3.0.0-2.fc6.i386.rpm libotr-devel-3.0.0-2.fc6.i386.rpm libpano12-2.8.4-7.fc6.i386.rpm libpano12-devel-2.8.4-7.fc6.i386.rpm libpano12-tools-2.8.4-7.fc6.i386.rpm libpaper-1.1.20-5.fc6.i386.rpm libpaper-devel-1.1.20-5.fc6.i386.rpm libresample-devel-0.1.3-3.fc6.i386.rpm librx-1.5-8.fc6.i386.rpm librx-devel-1.5-8.fc6.i386.rpm libsamplerate-0.1.2-6.fc6.i386.rpm libsamplerate-devel-0.1.2-6.fc6.i386.rpm libshout-2.2.2-1.fc6.i386.rpm libshout-devel-2.2.2-1.fc6.i386.rpm libsigc++-1.2.7-4.fc6.i386.rpm libsigc++-devel-1.2.7-4.fc6.i386.rpm libsigsegv-2.4-2.fc6.i386.rpm libsigsegv-devel-2.4-2.fc6.i386.rpm libsilc-1.0.2-2.fc6.i386.rpm libsilc-devel-1.0.2-2.fc6.i386.rpm libsmi-0.4.5-2.fc6.i386.rpm libsmi-devel-0.4.5-2.fc6.i386.rpm libsndfile-1.0.17-1.fc6.i386.rpm libsndfile-devel-1.0.17-1.fc6.i386.rpm libspectrum-0.2.2-4.fc6.i386.rpm libspectrum-devel-0.2.2-4.fc6.i386.rpm libsynaptics-0.14.6b-4.fc6.i386.rpm libsynaptics-devel-0.14.6b-4.fc6.i386.rpm libtar-1.2.11-8.fc6.i386.rpm libtar-devel-1.2.11-8.fc6.i386.rpm libtlen-0-0.5.20060309.fc6.i386.rpm libtlen-devel-0-0.5.20060309.fc6.i386.rpm libtranslate-0.99-9.fc6.i386.rpm libtranslate-devel-0.99-9.fc6.i386.rpm libutempter-1.1.4-3.fc6.i386.rpm libutempter-devel-1.1.4-3.fc6.i386.rpm libvisual-0.4.0-3.fc6.i386.rpm libvisual-devel-0.4.0-3.fc6.i386.rpm libxml-1.8.17-15.fc6.i386.rpm libxml++-2.14.0-1.1.fc6.i386.rpm libxml-devel-1.8.17-15.fc6.i386.rpm libxml++-devel-2.14.0-1.1.fc6.i386.rpm lightning-1.2-4.fc6.i386.rpm lineakd-0.9-5.fc6.i386.rpm lineakd-devel-0.9-5.fc6.i386.rpm lineak-defaultplugin-0.9-2.fc6.i386.rpm lineak-kdeplugins-0.9-2.fc6.i386.rpm lineak-xosdplugin-0.9-2.fc6.i386.rpm link-grammar-4.2.2-2.fc6.i386.rpm link-grammar-devel-4.2.2-2.fc6.i386.rpm lmarbles-1.0.7-6.fc6.i386.rpm lock-keys-applet-1.0-11.fc6.i386.rpm lout-3.30-6.fc6.i386.rpm lrmi-0.10-2.fc6.i386.rpm lrmi-devel-0.10-2.fc6.i386.rpm ltrace-0.5-6.45svn.fc6.i386.rpm ltsp-utils-0.25-4.fc6.noarch.rpm lzo-2.02-2.fc6.i386.rpm lzo-devel-2.02-2.fc6.i386.rpm lzop-1.02-0.4.rc1.fc6.i386.rpm mailcap-2.1.23-1.fc6.noarch.rpm makebootfat-1.4-5.fc6.i386.rpm manaworld-music-0.0.20-1.fc6.noarch.rpm man-pages-uk-0.1-0.4.20060830.fc6.noarch.rpm mathml-fonts-1.0-21.fc6.noarch.rpm mcrypt-2.6.4-3.fc6.i386.rpm mercator-0.2.5-1.fc6.i386.rpm mercator-devel-0.2.5-1.fc6.i386.rpm metamonitor-0.4.5-3.fc6.i386.rpm metapixel-1.0.1-5.fc6.i386.rpm mfstools-2.0-11.snapshot050221.fc6.i386.rpm mgopen-fonts-0.20050515-5.fc6.noarch.rpm mimetex-1.60-3.fc6.i386.rpm mm-1.4.2-2.fc6.i386.rpm mm-devel-1.4.2-2.fc6.i386.rpm mmv-1.01b-8.fc6.i386.rpm MochiKit-1.3.1-1.fc6.noarch.rpm mod_annodex-0.2.2-6.fc6.i386.rpm mod_extract_forwarded-2.0.2-2.fc6.i386.rpm mod_geoip-1.1.8-2.fc6.i386.rpm moin-latex-0-0.20051126.3.fc6.noarch.rpm monsterz-0.7.0-7.fc6.i386.rpm monsterz-data-0.7.0-7.fc6.i386.rpm most-4.10.2-5.fc6.i386.rpm mtd-utils-1.0.1-2.fc6.i386.rpm multitail-4.2.0-2.fc6.i386.rpm musicbox-0.2.3-5.fc6.i386.rpm mxml-2.2.2-7.fc6.i386.rpm mxml-devel-2.2.2-7.fc6.i386.rpm mysql-connector-java-3.1.12-3.fc6.i386.rpm naim-0.11.8.3-1.fc6.i386.rpm nautilus-actions-1.4-4.fc6.i386.rpm nautilus-flac-converter-0.0.2-7.fc6.i386.rpm nautilus-open-terminal-0.7-3.fc6.i386.rpm nautilus-search-tool-0.2-2.fc6.i386.rpm nc6-1.0-4.fc6.i386.rpm ncmpc-0.11.1-7.fc6.i386.rpm nco-3.1.5-3.fc6.i386.rpm nco-devel-3.1.5-3.fc6.i386.rpm netgo-0.5-6.fc6.i386.rpm nethack-3.4.3-12.fc6.i386.rpm netlabel_tools-0.17-5.fc6.i386.rpm NetworkManager-openvpn-0.3.2-7.fc6.i386.rpm newscache-1.2-0.4.rc6.fc6.i386.rpm newsx-1.6-6.fc6.i386.rpm neXtaw-0.15.1-10.fc6.i386.rpm neXtaw-devel-0.15.1-10.fc6.i386.rpm nip2-7.10.21-1.fc6.i386.rpm njam-1.25-4.fc6.i386.rpm nkf-2.07-1.1.fc6.i386.rpm nomarch-1.4-2.fc6.i386.rpm ntfsprogs-1.13.1-3.fc6.i386.rpm ntfsprogs-devel-1.13.1-3.fc6.i386.rpm ntfsprogs-gnomevfs-1.13.1-3.fc6.i386.rpm numlockx-1.0-11.fc6.i386.rpm obconf-1.6-3.fc6.i386.rpm oidentd-2.0.8-2.fc6.i386.rpm oki4linux-2.1gst-1.fc6.i386.rpm oneko-1.2-4.fc6.i386.rpm oooqs2-1.0-3.fc6.i386.rpm OpenEXR-1.4.0a-3.fc6.i386.rpm OpenEXR-devel-1.4.0a-3.fc6.i386.rpm openslp-1.2.1-6.fc6.i386.rpm openslp-server-1.2.1-6.fc6.i386.rpm orpie-1.4.3-5.fc6.i386.rpm osiv-0.1.1-5.fc6.i386.rpm overgod-1.0-5.fc6.i386.rpm padevchooser-0.9.3-2.fc6.i386.rpm paman-0.9.3-2.fc6.i386.rpm pam_usb-hotplug-0.3.3-6.fc6.i386.rpm par2cmdline-0.4-11.fc6.i386.rpm pavucontrol-0.9.4-3.fc6.i386.rpm pavumeter-0.9.2-2.fc6.i386.rpm pbstop-4.14-3.fc6.i386.rpm pdsh-2.11-5.fc6.i386.rpm pdsh-mod-dshgroup-2.11-5.fc6.i386.rpm pdsh-mod-netgroup-2.11-5.fc6.i386.rpm pdsh-rcmd-rsh-2.11-5.fc6.i386.rpm pdsh-rcmd-ssh-2.11-5.fc6.i386.rpm perl-BSD-Resource-1.28-1.fc6.1.i386.rpm perl-Cache-Cache-1.05-1.fc6.noarch.rpm perl-Cflow-1.053-5.fc6.i386.rpm perl-Class-MethodMaker-2.08-4.fc6.i386.rpm perl-Compress-Bzip2-2.09-4.fc6.i386.rpm perl-Compress-Zlib-1.42-1.fc6.i386.rpm perl-Crypt-Blowfish-2.10-2.fc6.i386.rpm perl-Curses-1.15-1.fc6.i386.rpm perl-DBD-SQLite-1.12-2.fc6.i386.rpm perl-DBD-SQLite2-0.33-6.fc6.i386.rpm perl-Device-SerialPort-1.002-3.fc6.i386.rpm perl-Digest-MD4-1.5-3.fc6.i386.rpm perl-Digest-Nilsimsa-0.06-7.fc6.i386.rpm perl-File-MMagic-XS-0.08-2.fc6.i386.rpm perl-File-RsyncP-0.62-3.fc6.i386.rpm perl-GD-2.35-2.fc6.i386.rpm perl-Gnome2-Canvas-1.002-6.fc6.i386.rpm perl-Gnome2-GConf-1.043-1.fc6.i386.rpm perl-Gtk2-GladeXML-1.006-1.fc6.i386.rpm perl-Gtk2-Sexy-0.02-5.fc6.i386.rpm perl-Gtk2-Spell-1.03-5.fc6.i386.rpm perl-Gtk2-TrayIcon-0.03-3.fc6.i386.rpm perl-IO-Socket-INET6-2.51-2.fc6.noarch.rpm perl-IO-Tty-1.07-2.fc6.i386.rpm perl-libintl-1.16-3.fc6.i386.rpm perl-List-MoreUtils-0.22-2.fc6.i386.rpm perl-Net-IP-CMatch-0.02-4.fc6.i386.rpm perl-Net-Patricia-1.014-3.fc6.i386.rpm perl-Net-SSLeay-1.30-4.fc6.i386.rpm perl-NKF-2.07-1.1.fc6.i386.rpm perl-PBS-0.31-3.fc6.i386.rpm perl-Pod-POM-0.17-6.fc6.noarch.rpm perl-Razor-Agent-2.82-1.fc6.i386.rpm perl-Readonly-XS-1.04-7.fc6.i386.rpm perl-SDL-2.1.3-3.fc6.i386.rpm perl-Socket6-0.19-3.fc6.i386.rpm perl-String-CRC32-1.4-2.fc6.i386.rpm perl-Sub-Name-0.02-2.fc6.i386.rpm perl-Taint-Runtime-0.02-2.fc6.i386.rpm perl-Test-Taint-1.04-3.fc6.i386.rpm perl-TeX-Hyphen-0.140-5.fc6.noarch.rpm perl-Text-CHM-0.01-2.fc6.i386.rpm perl-Text-CSV_XS-0.23-5.fc6.i386.rpm perl-Text-Kakasi-2.04-3.fc6.i386.rpm perl-Time-Piece-1.09-2.fc6.i386.rpm perl-udunits-1.12.4-11.fc6.i386.rpm perl-Unicode-Map-0.112-8.fc6.i386.rpm perl-Unicode-String-2.09-2.fc6.i386.rpm perl-XML-LibXSLT-1.58-3.fc6.i386.rpm phpldapadmin-1.0.1-1.fc6.noarch.rpm php-magickwand-0.1.8-3.fc6.i386.rpm php-pecl-apc-3.0.12-1.fc6.i386.rpm php-pecl-mailparse-2.1.1-5.fc6.i386.rpm picocom-1.4-3.fc6.i386.rpm pikdev-0.9.2-2.fc6.i386.rpm pikloops-0.2.1-6.fc6.i386.rpm pingus-0.7.0-0.4.20060721.fc6.i386.rpm pipenightdreams-0.10.0-5.fc6.i386.rpm plotmm-examples-0.1.2-5.fc6.i386.rpm polyxmass-bin-0.9.3-2.fc6.i386.rpm pork-0.99.8.1-6.fc6.i386.rpm powermanga-0.80-3.fc6.i386.rpm pptp-1.7.1-2.fc6.i386.rpm pscan-1.2-3.fc6.i386.rpm psi-0.10-5.fc6.i386.rpm psi-i18n-0.10-5.fc6.i386.rpm psi-icons-0.10-5.fc6.i386.rpm pvm-3.4.5-7.fc6.1.i386.rpm pvm-gui-3.4.5-7.fc6.1.i386.rpm pwgen-2.05-4.fc6.i386.rpm qcad-2.0.5.0-5.fc6.i386.rpm qca-tls-1.0-10.fc6.i386.rpm qgo-1.5.2-1.fc6.i386.rpm qjackctl-0.2.20-7.fc6.i386.rpm qof-doc-0.7.0-1.fc6.i386.rpm qsynth-0.2.5-6.fc6.i386.rpm quilt-0.46-1.fc6.i386.rpm radiusclient-ng-utils-0.5.2-4.fc6.i386.rpm rafkill-1.2.2-4.fc6.i386.rpm raidem-0.3.1-5.fc6.i386.rpm ratpoison-1.4.0-5.fc6.i386.rpm rblcheck-1.5-12.fc6.i386.rpm rbldnsd-0.996a-2.fc6.i386.rpm regionset-0.1-4.fc6.i386.rpm R-hdf5-1.6.4-2.fc6.i386.rpm rinetd-0.62-6.fc6.i386.rpm rng-utils-2.0-1.14.1.fc6.i386.rpm rootsh-1.5.2-4.fc6.i386.rpm root-tail-1.2-2.fc6.i386.rpm rpld-1.8-0.1.beta1.fc6.i386.rpm rsibreak-0.8.0-1.fc6.i386.rpm rss-glx-0.8.1.p-6.fc6.i386.rpm rss-glx-gnome-screensaver-0.8.1.p-6.fc6.i386.rpm rss-glx-kde-0.8.1.p-6.fc6.i386.rpm rss-glx-xscreensaver-0.8.1.p-6.fc6.i386.rpm ruby-mysql-2.7.1-2.fc6.i386.rpm ruby-sqlite3-1.1.0-6.fc6.i386.rpm rxvt-2.7.10-11.fc6.i386.rpm s3switch-0.0-9.20020912.fc6.i386.rpm scim-fcitx-3.1.1-6.fc6.i386.rpm scim-fcitx-tools-3.1.1-6.fc6.i386.rpm scim-sinhala-0.2.0-2.fc6.i386.rpm scim-skk-0.5.2-8.fc6.i386.rpm scite-1.71-1.fc6.i386.rpm scmxx-0.8.2-3.fc6.i386.rpm scponly-4.6-6.fc6.i386.rpm scrip-1.4-6.fc6.i386.rpm scrub-1.8-1.fc6.i386.rpm SDL_mixer-1.2.7-2.fc6.i386.rpm SDL_mixer-devel-1.2.7-2.fc6.i386.rpm SDL_net-1.2.6-2.fc6.i386.rpm SDL_net-devel-1.2.6-2.fc6.i386.rpm SDL_Pango-0.1.2-4.fc6.i386.rpm SDL_Pango-devel-0.1.2-4.fc6.i386.rpm SDL_ttf-2.0.8-2.fc6.i386.rpm SDL_ttf-devel-2.0.8-2.fc6.i386.rpm seq24-0.8.7-6.fc6.i386.rpm ser2net-2.3-3.fc6.i386.rpm sextractor-2.5.0-5.fc6.i386.rpm shippy-1.3.3.7-4.fc6.i386.rpm shippy-allegro-1.3.3.7-4.fc6.i386.rpm shippy-common-1.3.3.7-4.fc6.i386.rpm sipsak-0.9.6-1.fc6.i386.rpm sjasm-0.39-0.4.g1.fc6.i386.rpm smarteiffel-2.2-6.fc6.i386.rpm smarteiffel-doc-2.2-6.fc6.i386.rpm snownews-1.5.7-5.fc6.i386.rpm soundtracker-0.6.8-2.fc6.i386.rpm source-highlight-2.4-1.fc6.i386.rpm spamass-milter-0.3.1-4.fc6.i386.rpm splint-3.1.1-15.fc6.i386.rpm Sprog-0.14-12.fc6.noarch.rpm sqlite2-tcl-2.8.17-1.fc6.i386.rpm ssss-0.5-2.fc6.i386.rpm starfighter-1.1-8.fc6.i386.rpm stripesnoop-1.5-7.fc6.i386.rpm supertuxkart-0.2-3.fc6.i386.rpm synaptics-0.14.4-8.fc6.i386.rpm synce-gnomevfs-0.9.0-5.fc6.i386.rpm synce-software-manager-0.9.0-7.fc6.i386.rpm synce-trayicon-0.9.0-8.fc6.i386.rpm synergy-1.3.1-2.fc6.i386.rpm system-config-network-1.3.96-1.fc6.noarch.rpm system-config-network-tui-1.3.96-1.fc6.noarch.rpm t1utils-1.32-8.fc6.i386.rpm taarich-1.20051120-6.fc6.i386.rpm tclhttpd-3.5.1-13.fc6.i386.rpm tcltls-1.5.0-11.fc6.i386.rpm telepathy-feed-0.13-2.fc6.i386.rpm thewidgetfactory-0.2.1-2.fc6.i386.rpm thttpd-2.25b-12.fc6.i386.rpm tiger-3.2.1-6.fc6.i386.rpm tin-1.8.2-1.fc6.i386.rpm tkdnd-1.0a2-7.fc6.i386.rpm tktable-2.9-9.fc6.i386.rpm tla-1.3.4-5.fc6.i386.rpm torsmo-0.18-6.fc6.i386.rpm treecc-0.3.8-3.fc6.i386.rpm tremulous-1.1.0-2.fc6.i386.rpm ttywatch-0.14-7.fc6.i386.rpm tux-3.2.18-9.fc6.i386.rpm tuxtype2-1.5.3-2.fc6.i386.rpm udftools-1.0.0b3-7.fc6.i386.rpm udunits-1.12.4-11.fc6.i386.rpm unifdef-1.171-5.fc6.i386.rpm unison-2.13.16-3.fc6.i386.rpm up-imapproxy-1.2.4-7.fc6.i386.rpm utrac-0.3.0-8.fc6.i386.rpm vbetest-0.10-2.fc6.i386.rpm videodog-0.31-4.fc6.i386.rpm vips-doc-7.10.21-1.fc6.i386.rpm vips-tools-7.10.21-1.fc6.i386.rpm vorbisgain-0.36-1.fc6.i386.rpm w3c-libwww-apps-5.4.1-0.4.20060206cvs.fc6.i386.rpm wavbreaker-0.7-6.fc6.i386.rpm web2png-2.5.1-3.fc6.i386.rpm whatmask-1.2-4.fc6.i386.rpm wmapmload-0.3.4-5.fc6.i386.rpm wmCalClock-1.25-8.fc6.i386.rpm wmctrl-1.07-2.fc6.i386.rpm wmix-3.1-1.fc6.i386.rpm wmweather+-2.9-4.fc6.i386.rpm wmx-6pl1-14.fc6.i386.rpm worminator-3.0R2.1-5.fc6.i386.rpm x11-ssh-askpass-1.2.4.1-2.fc6.i386.rpm x3270-3.3.4p7-5.fc6.i386.rpm x3270-text-3.3.4p7-5.fc6.i386.rpm x3270-x11-3.3.4p7-5.fc6.i386.rpm x86info-1.20-1.26.fc6.i386.rpm xarchon-0.50-3.fc6.i386.rpm xboard-4.2.7-16.fc6.i386.rpm xcompmgr-1.1.3-6.fc6.i386.rpm xdaliclock-2.23-3.fc6.i386.rpm xdesktopwaves-1.3-8.fc6.i386.rpm xeuphoric-0.18.2-6.fc6.i386.rpm xeuphoric-roms-0.18.2-6.fc6.i386.rpm xfce4-taskmanager-0.4.0-0.2.rc2.fc6.i386.rpm xfsdump-2.2.42-2.fc6.i386.rpm xgalaxy-2.0.34-5.fc6.i386.rpm xkeyboard-config-0.8-7.fc6.noarch.rpm xlhtml-0.5-6.fc6.i386.rpm xmlindent-0.2.17-7.fc6.i386.rpm xmms-acme-0.4.3-6.fc6.i386.rpm xmms-arts-0.7.1-4.fc6.i386.rpm xmms-cdread-0.14-12.fc6.i386.rpm xmms-crossfade-0.3.11-1.fc6.i386.rpm xmms-lirc-1.4-9.fc6.i386.rpm xmms-musepack-1.2-3.fc6.i386.rpm xmms-sid-0.8.0-0.3.beta15.fc6.i386.rpm xorg-x11-filesystem-7.1-2.fc6.noarch.rpm xplanet-1.2.0-2.1.fc6.i386.rpm xscorch-0.2.0-8.fc6.i386.rpm xsri-2.1.0-10.fc6.i386.rpm xvattr-1.3-11.fc6.i386.rpm xwrits-2.24-2.fc6.i386.rpm yadex-1.7.0-6.fc6.i386.rpm ytalk-3.3.0-6.fc6.i386.rpm z88dk-1.6-10.fc6.i386.rpm zasx-1.30-3.fc6.i386.rpm zidrav-1.2.0-2.fc6.i386.rpm zile-2.2.19-1.fc6.i386.rpm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From oliver at linux-kernel.at Fri Jun 1 08:02:44 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jun 2007 10:02:44 +0200 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <465FD098.2060808@gmx.net> References: <465FD098.2060808@gmx.net> Message-ID: <465FD2A4.2010306@linux-kernel.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/01/2007 09:54 AM, Frank B?ttner wrote: > Here an list of packages that shut be fixed it dist tags. [ ... ] < list omitted > As the release notes state: 8.5. Packages with ".fc6" Tag There have not been any major changes in the toolchain in Fedora 7. Therefore, some packages in Fedora 7 might retain ".fc6" in the release tag if they have been inherited from the previous release without any changes. Fedora maintainers have not rebuilt these packages for Fedora 7 to avoid making end users download the packages for only a release tag change. This measure ensures that the robustness is not affected by any potential changes evoked by rebuilds. This naming of packages is merely cosmetic, and does not in any way affect the functionality of the software. - -of -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGX9KjxWN5Ge8lKUMRAuc/AJ48s3HyV3c54ziFlq8QBgzzWEYTXgCdHzkX pmngpUfJTt/k3O3Cw22OO8o= =9tnX -----END PGP SIGNATURE----- From pertusus at free.fr Fri Jun 1 08:12:58 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 1 Jun 2007 10:12:58 +0200 Subject: disagreement in a merge review about patches Message-ID: <20070601081258.GA9531@free.fr> Hello, I am in disagreement with Marcela in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226529 It is about the patches, and it begins here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226529#c15 My point is that the patches are unreviewable and cannot be given to upstream or shared among packagers when upstream is dead, because some patches touch the same code, leading to something that isn't readable. Marcela disagrees because then there won't be a one patch one bug relationship. My advice is to keep the patches to have this one patch one bug relationship, but don't apply tem and instead have a one patch one functionality instead. Advices? -- Pat From sundaram at fedoraproject.org Fri Jun 1 08:28:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 13:58:55 +0530 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <465FD098.2060808@gmx.net> References: <465FD098.2060808@gmx.net> Message-ID: <465FD8C7.6080309@fedoraproject.org> Frank B?ttner wrote: > Here an list of packages that shut be fixed it dist tags. > abcde-2.3.99.6-2.fc6.noarch.rpm This is already mentioned in the release notes. http://mirrors.kernel.org/fedora/releases/7/Fedora/i386/os/RELEASE-NOTES-en_US.html#sn-fc6-tag Rahul From oliver at linux-kernel.at Fri Jun 1 08:36:16 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jun 2007 10:36:16 +0200 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <465FD8C7.6080309@fedoraproject.org> References: <465FD098.2060808@gmx.net> <465FD8C7.6080309@fedoraproject.org> Message-ID: <465FDA80.9060604@linux-kernel.at> On 06/01/2007 10:28 AM, Rahul Sundaram wrote: > Frank B?ttner wrote: >> Here an list of packages that shut be fixed it dist tags. >> abcde-2.3.99.6-2.fc6.noarch.rpm > > This is already mentioned in the release notes. > > http://mirrors.kernel.org/fedora/releases/7/Fedora/i386/os/RELEASE-NOTES-en_US.html#sn-fc6-tag You told him, I told him. I guess he knows now :-) -of From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jun 1 08:52:41 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 1 Jun 2007 10:52:41 +0200 Subject: First impressions of a system update with yum In-Reply-To: <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> Message-ID: <20070601105241.35b741bc@python3.es.egwn.lan> Schlaegel wrote : > On 5/31/07, Matthias Saou > > wrote: > > Other current thought : To hell with it, format "/" and reinstall from > > DVD... > > This is my normal course of action. I don't want to deal with the > leftover packages and the missing new packages. I just let Anaconda do > its job. This is quite easily dealt with : Running "package-cleanup --orphans" (from yum-utils) will list you all the packages currently installed which aren't listed in any configured repository. Then "yum groupinstall Base" will show/install the base packages which you don't have installed, usually because they were added in the last Fedora release. Of course, this doesn't remove unused stuff, nor does it deal so gracefully with configuration changes or even low-level install changes, for instance if anaconda now chooses different defaults for LVM layouts, sizes or even ext3 formatting options. Right now I've gotten back to the office, where my workstation freshly updated to F7 was waiting at the (new!) gdm login screen. FWIW, here are the annoyances I've seen so far : - My gnome-panel didn't start - I was seeing many denies regarding /dev/nvidia* accesses (yeah..) -> I disabled selinux and rebooted :-( - My desktop came up with metacity, I had to manually switch back to Beryl (probably because of the previous errors) - My GNOME menu icon is gone. Even if I add a new main GNOME menu to my panel, it doesn't have any icon. The name probably changed and I'll need to get a newer theme. *sigh* - All my fonts look different, in firefox as well as claws-mail... Note that many of my "annoyances" aren't related to packages themselves, more to the fact that I kept my /home intact. As always, there is clearly room for upgrade improvements, but as always... it's not that easy to get right in all possible scenarios. Oh, the "yum update" finished OK on my x86_64 after the esound hack, and on my i386 laptop (Dell X1) it went absolutely fine. I just need to get S3 working again, as I wanted to start fresh and removed all the kernel boot options I had in case they weren't useful anymore... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.08 0.54 0.54 From oliver at linux-kernel.at Fri Jun 1 08:52:48 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jun 2007 10:52:48 +0200 Subject: disagreement in a merge review about patches In-Reply-To: <20070601081258.GA9531@free.fr> References: <20070601081258.GA9531@free.fr> Message-ID: <465FDE60.4030901@linux-kernel.at> Hi Pat! On 06/01/2007 10:12 AM, Patrice Dumas wrote: > I am in disagreement with Marcela in > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226529 > It is about the patches, and it begins here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226529#c15 > > My point is that the patches are unreviewable and cannot be given to > upstream or shared among packagers when upstream is dead, because some > patches touch the same code, leading to something that isn't readable. > Marcela disagrees because then there won't be a one patch one bug > relationship. My advice is to keep the patches to have this one patch > one bug relationship, but don't apply tem and instead have a one patch > one functionality instead. > > Advices? I think it was a good idea to involve -devel list... I've now read the bug... It's becoming a huge thread already. :-) The vixie-cron package contains so many patches and the release has been increased so many times now... Active development of cron is only done by distributions now. >From my point of view I would say it would be good to create a new 'upstream'. Maybe some trac project at fp.o or so... Let's say: vixie's dead, long live vixie :-) Or is there any good alternative for vixie-cron? I'm not 100 % sure, but I think I stumbled across some crond, that is under active development. Quick search on freshmeat or via google should be done. To bring it to a point: I don't think it's good to have Base OS packages in Fedora (and then in RHEL) that have no active upstream! If we want to stick with vixie, we should create a new upstream project - officially; And invite other distros to join. If we don't want to stick with it, we should find an alternative. -of From hughsient at gmail.com Fri Jun 1 08:58:38 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 01 Jun 2007 09:58:38 +0100 Subject: First impressions of a system update with yum In-Reply-To: <20070601105241.35b741bc@python3.es.egwn.lan> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <20070601105241.35b741bc@python3.es.egwn.lan> Message-ID: <1180688318.2556.11.camel@localhost.localdomain> On Fri, 2007-06-01 at 10:52 +0200, Matthias Saou wrote: > I just need to get S3 working again, as I wanted to start fresh and > removed all the kernel boot options I had in case they weren't useful > anymore... If you are talking about s3 (suspend), see http://people.freedesktop.org/~hughsient/quirk/ Richard. From buildsys at fedoraproject.org Fri Jun 1 09:09:37 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 1 Jun 2007 05:09:37 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-01 Message-ID: <20070601090937.99345152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 30 dwatch-0.1.1-3.fc6 em8300-kmod-0.16.2-2.2.6.20_1.2952.fc6 epiphany-extensions-2.16.1-5 NEW firewalk-5.0-1.fc6 : Active reconnaissance network security tool freenx-0.6.0-12.fc6 fuse-convmvfs-0.2.4-2.fc6 galeon-2.0.3-7.fc6 NEW gnome-vfs2-obexftp-0.2-6.fc6 : ObexFTP over Bluetooth support for GNOME initng-0.6.10.1-1.fc6 initng-ifiles-0.1.3-1.fc6 jasper-1.900.1-2.fc6 kazehakase-0.4.7-1.fc6.1 libpng10-1.0.26-1.fc6 liferea-1.0.26-4.fc6 nx-2.1.0-22.fc6 perl-Algorithm-C3-0.07-1.fc6 perl-CGI-Ex-2.13-1.fc6 perl-Class-C3-XS-0.06-1.fc6 perl-Class-Data-Accessor-0.04001-1.fc6 perl-Class-MOP-0.38-1.fc6 NEW perl-Crypt-OpenSSL-X509-0.4-3.fc6 : Perl interface to OpenSSL for X509 perl-Gtk2-Notify-0.03-1.fc6 perl-Moose-0.22-1.fc6 pulseaudio-0.9.6-2.fc6 referencer-1.0.4-1.fc6 NEW remind-03.00.24-3.fc6 : A sophisticated calendar and alarm program ruby-gnome2-0.16.0-6.fc6 seamonkey-1.0.9-1.fc6 sysprof-kmod-1.0.8-1.2.6.20_1.2952.fc6 util-vserver-0.30.213-1.fc6 Packages built and released for Fedora Extras 5: 13 dwatch-0.1.1-3.fc5 freenx-0.6.0-12.fc5 galeon-2.0.3-4.fc5 jasper-1.900.1-2.fc5 kazehakase-0.4.7-1.fc5.1 nx-2.1.0-22.fc5 perl-Algorithm-C3-0.07-1.fc5 perl-CGI-Ex-2.13-1.fc5 perl-Class-C3-XS-0.06-1.fc5 perl-Class-Data-Accessor-0.04001-1.fc5 perl-Class-MOP-0.38-1.fc5 perl-Moose-0.22-1.fc5 pulseaudio-0.9.6-2.fc5 Changes in Fedora Extras 6: dwatch-0.1.1-3.fc6 ------------------ * Thu May 31 2007 Bernard Johnson - 0.1.1-3 - take junk out of default config file and just reference man page - change man page from dwatch(5) to dwatch.conf(5) - give a more complex example in dwatch.conf(5) man page em8300-kmod-0.16.2-2.2.6.20_1.2952.fc6 -------------------------------------- * Thu May 31 2007 Ville Skytt? - 0.16.2-2 - Apply fugly, hopefully temporary workaround for #227533. * Wed May 30 2007 Ville Skytt? - Rebuild for kernel 2.6.20-1.2952.fc6. epiphany-extensions-2.16.1-5 ---------------------------- * Thu May 31 2007 Peter Gordon - 2.16.1-5 - Rebuild for newer Gecko release (Firefox 1.5.0.12) firewalk-5.0-1.fc6 ------------------ * Thu May 03 2007 Sindre Pedersen Bj?rdal - 5.0-1 - Initial build freenx-0.6.0-12.fc6 ------------------- * Mon Feb 19 2007 Axel Thimm - 0.6.0-9 - Update to 0.6.0. fuse-convmvfs-0.2.4-2.fc6 ------------------------- * Fri Jun 01 2007 ZC Miao - 0.2.4-2 - update tag * Fri Jun 01 2007 ZC Miao - 0.2.4-1 - update to 0.2.4 galeon-2.0.3-7.fc6 ------------------ * Thu May 31 2007 Denis Leroy - 2.0.3-7 - Rebuild for gecko-libs 1.8.0.12 gnome-vfs2-obexftp-0.2-6.fc6 ---------------------------- * Wed May 30 2007 - Bastien Nocera - 0.2-6 - Fix description, this package isn't split from gnome-vfs2 - Add the dist to the release - Use the "perl correct" build requires for intltool's dependencies - Add missing BRs for the autoreconf - Add TODO file * Wed May 30 2007 - Bastien Nocera - 0.2-5 - Use rfcomm sockets instead of the RFCOMM and/or Serial services (faster, cleaner, more robust), rmeove bluez-utils requirement - Assume an empty version in the obex FTP listing is still fine - Remove obsolete obex://rfcommX/path/to/file URI support - List all known devices in obex:/// not just bonded ones * Sun May 27 2007 - Bastien Nocera - 0.2-4 - And some other patches for the read retval fix, and a write retval fix * Sat May 26 2007 - Bastien Nocera - 0.2-3 - Apply an upstream patch to osso-gwobex, to avoid the build warnings - Add a licence file to clarify why the package is GPL - Use the new bluez-libs serial service, instead of the old RFCOMM interface initng-0.6.10.1-1.fc6 --------------------- * Thu May 31 2007 Daniel Malmgren 0.6.10.1-1 - New upstreams version - Removed macros from changelog to make rpmlint happy initng-ifiles-0.1.3-1.fc6 ------------------------- * Thu May 31 2007 Daniel Malmgren 0.1.3-1 - New upstreams version - Removed the no longer needed virtcheck patch * Tue Mar 27 2007 Daniel Malmgren 0.1.2-1 - New upstreams version - Fixed up genrunlevel calls in post - Patch to disable broken virtcheck stuff jasper-1.900.1-2.fc6 -------------------- * Wed May 23 2007 Rex Dieter 1.900.1-2 - CVE-2007-2721 (#240397) kazehakase-0.4.7-1.fc6.1 ------------------------ * Thu May 31 2007 Mamoru Tasaka - 0.4.7-1.dist.1 - gecko engine update libpng10-1.0.26-1.fc6 --------------------- * Sun May 20 2007 Paul Howarth 1.0.26-1 - update to 1.0.26 to address DoS issue (#240398, CVE-2007-2445) - update soname patch - libpng.txt now has a versioned filename * Sun Mar 25 2007 Paul Howarth 1.0.21-2 - Own directory %{_docdir}/%{name}-%{version} (#233869) - Describe license as "zlib/libpng" rather than just "zlib" liferea-1.0.26-4.fc6 -------------------- * Thu May 31 2007 Brian Pepple - 1.0.26-4 - Rebuild for new gecko. nx-2.1.0-22.fc6 --------------- * Fri Jun 01 2007 Axel Thimm - 2.1.0-22 - Sync with ATrpms' nxfindprovides helper. * Wed May 23 2007 Axel Thimm - 2.1.0-21.1 - Fix typo in nxwrapper.in (PKGEXECDIR -> PKGLIBEXECDIR). * Tue May 22 2007 Axel Thimm - 2.1.0-20 - readded Source11 to filter find-provides from showing libraries that should not be provided to the system. BZ#194652 & 240835. * Mon Feb 19 2007 Axel Thimm - 2.1.0-18 - Update to 2.1.0 (4th? maintenance release). perl-Algorithm-C3-0.07-1.fc6 ---------------------------- * Thu May 31 2007 Chris Weyl 0.07-1 - update to 0.07 - include t/ in doc - minor spec reworkage to deal with the once and future perl split perl-CGI-Ex-2.13-1.fc6 ---------------------- * Thu May 31 2007 Chris Weyl 2.13-1 - update to 2.13 perl-Class-C3-XS-0.06-1.fc6 --------------------------- * Thu May 31 2007 Chris Weyl 0.06-1 - update to 0.06-1 perl-Class-Data-Accessor-0.04001-1.fc6 -------------------------------------- * Thu May 31 2007 Chris Weyl 0.04001-1 - update -- 0.40001 clarifies conflicting license statements perl-Class-MOP-0.38-1.fc6 ------------------------- * Thu May 31 2007 Chris Weyl 0.38-1 - update to 0.38 - add t/ to doc - minor spec rework to deal with the once and future perl split perl-Crypt-OpenSSL-X509-0.4-3.fc6 --------------------------------- * Mon May 14 2007 Wes Hardaker - 0.4-3 - BuildRequire perl(Test::More) perl(Test::Pod) - Fixed source code URL * Tue May 08 2007 Wes Hardaker - 0.4-2 - Add BuildRequire openssl-devel - Don't manually require openssl - Use vendorarch instead of vendorlib perl-Gtk2-Notify-0.03-1.fc6 --------------------------- * Thu May 31 2007 Chris Weyl 0.03-1 - update to 0.03 - add t/ to doc - spec updates to deal with the once and future perl split perl-Moose-0.22-1.fc6 --------------------- * Thu May 31 2007 Chris Weyl 0.22-1 - update to 0.22 pulseaudio-0.9.6-2.fc6 ---------------------- * Tue May 29 2007 Pierre Ossman 0.9.6-2 - Add libatomic_ops-devel as a build requirement. * Tue May 29 2007 Pierre Ossman 0.9.6-1 - Upgrade to 0.9.6. * Fri Mar 02 2007 Pierre Ossman 0.9.5-5 - Fix merge problems with patch. * Fri Mar 02 2007 Pierre Ossman 0.9.5-4 - Add patch to handle ALSA changing the frame size (bug 230211). - Add patch for suspended ALSA devices (bug 228205). * Mon Feb 05 2007 Pierre Ossman 0.9.5-3 - Add esound-compat subpackage that allows PulseAudio to be a drop-in replacement for esd (based on patch by Matthias Clasen). - Backport patch allows startup to continue even when the users' config cannot be read. referencer-1.0.4-1.fc6 ---------------------- * Thu May 31 2007 Deji Akingunola - 1.0.4-1 - New release remind-03.00.24-3.fc6 --------------------- * Wed May 23 2007 Ray Van Dolson - 03.00.24-3 - Fixed permissions on www/* to be 0644. * Mon May 07 2007 Ray Van Dolson - 03.00.24-2 - Added www to documentation. A sample web application I do not feel is suitable for inclusion into the actual RPM. * Thu May 03 2007 Ray Van Dolson - 03.00.24-2 - Using integer only release numbers. - Preserve timestamps on manpages. - Added %check - Removed README from documentation and added ACKNOWLEDGEMENTS ruby-gnome2-0.16.0-6.fc6 ------------------------ * Thu May 31 2007 Allisson Azevedo 0.16.0-6 - New gecko engine seamonkey-1.0.9-1.fc6 --------------------- * Thu May 31 2007 Kai Engert 1.0.9-1 - Update to 1.0.9 sysprof-kmod-1.0.8-1.2.6.20_1.2952.fc6 -------------------------------------- * Tue Jan 02 2007 Gianluca Sforna - rebuild for kernel 2.6.18-1.2869 util-vserver-0.30.213-1.fc6 --------------------------- * Thu May 31 2007 Enrico Scholz - 0.30.213-1 - updated to 0.30.213 - disabled dietlibc build for PPC64 - enabled support for 'util-vserver' initscript * Fri Apr 20 2007 Enrico Scholz - 0.30.212-4 - BR some tools tested by ./configure Changes in Fedora Extras 5: dwatch-0.1.1-3.fc5 ------------------ * Thu May 31 2007 Bernard Johnson - 0.1.1-3 - take junk out of default config file and just reference man page - change man page from dwatch(5) to dwatch.conf(5) - give a more complex example in dwatch.conf(5) man page freenx-0.6.0-12.fc5 ------------------- * Mon Feb 19 2007 Axel Thimm - 0.6.0-9 - Update to 0.6.0. galeon-2.0.3-4.fc5 ------------------ * Thu May 31 2007 Denis Leroy - 2.0.3-4 - Rebuild for seamonkey 1.0.9 jasper-1.900.1-2.fc5 -------------------- * Wed May 23 2007 Rex Dieter 1.900.1-2 - CVE-2007-2721 (#240397) kazehakase-0.4.7-1.fc5.1 ------------------------ * Thu May 31 2007 Mamoru Tasaka - 0.4.7-1.dist.1 - gecko engine update nx-2.1.0-22.fc5 --------------- * Fri Jun 01 2007 Axel Thimm - 2.1.0-22 - Sync with ATrpms' nxfindprovides helper. * Wed May 23 2007 Axel Thimm - 2.1.0-21.1 - Fix typo in nxwrapper.in (PKGEXECDIR -> PKGLIBEXECDIR). * Tue May 22 2007 Axel Thimm - 2.1.0-20 - readded Source11 to filter find-provides from showing libraries that should not be provided to the system. BZ#194652 & 240835. * Mon Feb 19 2007 Axel Thimm - 2.1.0-18 - Update to 2.1.0 (4th? maintenance release). perl-Algorithm-C3-0.07-1.fc5 ---------------------------- * Thu May 31 2007 Chris Weyl 0.07-1 - update to 0.07 - include t/ in doc - minor spec reworkage to deal with the once and future perl split perl-CGI-Ex-2.13-1.fc5 ---------------------- * Thu May 31 2007 Chris Weyl 2.13-1 - update to 2.13 perl-Class-C3-XS-0.06-1.fc5 --------------------------- * Thu May 31 2007 Chris Weyl 0.06-1 - update to 0.06-1 perl-Class-Data-Accessor-0.04001-1.fc5 -------------------------------------- * Thu May 31 2007 Chris Weyl 0.04001-1 - update -- 0.40001 clarifies conflicting license statements perl-Class-MOP-0.38-1.fc5 ------------------------- * Thu May 31 2007 Chris Weyl 0.38-1 - update to 0.38 - add t/ to doc - minor spec rework to deal with the once and future perl split perl-Moose-0.22-1.fc5 --------------------- * Thu May 31 2007 Chris Weyl 0.22-1 - update to 0.22 pulseaudio-0.9.6-2.fc5 ---------------------- * Tue May 29 2007 Pierre Ossman 0.9.6-2 - Add libatomic_ops-devel as a build requirement. * Tue May 29 2007 Pierre Ossman 0.9.6-1 - Upgrade to 0.9.6. * Fri Mar 02 2007 Pierre Ossman 0.9.5-5 - Fix merge problems with patch. * Fri Mar 02 2007 Pierre Ossman 0.9.5-4 - Add patch to handle ALSA changing the frame size (bug 230211). - Add patch for suspended ALSA devices (bug 228205). * Mon Feb 05 2007 Pierre Ossman 0.9.5-3 - Add esound-compat subpackage that allows PulseAudio to be a drop-in replacement for esd (based on patch by Matthias Clasen). - Backport patch allows startup to continue even when the users' config cannot be read. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From oliver at linux-kernel.at Fri Jun 1 09:33:21 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jun 2007 11:33:21 +0200 Subject: Missing pkgs in F7!? In-Reply-To: <20070601105241.35b741bc@python3.es.egwn.lan> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <20070601105241.35b741bc@python3.es.egwn.lan> Message-ID: <465FE7E1.5040907@linux-kernel.at> - snort is missing in f7, but avail in -devel and fc6 - openldap-servers missing in f7, but avail in -devel and fc6 - bind-sdb missing in f7, but avail in -devel and fc6 - net-snmp-utils missing in f7, but avail in -devel and fc6 - stonith and heartbeat missing in f7, but avail in -devel and fc6 That's all I stumbled across at the moment... Maybe it's a fault on my side (corrupt ISOs? I don't think so sha1sum-ed it). I also checked download.fedora.redhat.com and didn't find the pkgs. -of From oliver at linux-kernel.at Fri Jun 1 09:56:30 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 01 Jun 2007 11:56:30 +0200 Subject: Missing pkgs in F7!? In-Reply-To: <465FE7E1.5040907@linux-kernel.at> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <20070601105241.35b741bc@python3.es.egwn.lan> <465FE7E1.5040907@linux-kernel.at> Message-ID: <465FED4E.8080604@linux-kernel.at> On 06/01/2007 11:33 AM, Oliver Falk wrote: > - snort is missing in f7, but avail in -devel and fc6 > - openldap-servers missing in f7, but avail in -devel and fc6 > - bind-sdb missing in f7, but avail in -devel and fc6 > - net-snmp-utils missing in f7, but avail in -devel and fc6 > - stonith and heartbeat missing in f7, but avail in -devel and fc6 > > That's all I stumbled across at the moment... > > Maybe it's a fault on my side (corrupt ISOs? I don't think so sha1sum-ed > it). I also checked download.fedora.redhat.com and didn't find the pkgs. kk. it was clarified in irc. those pkgs are not on the distribution dvd, they can be found in the 'Everything' 'tree'... -of From fedora at leemhuis.info Fri Jun 1 09:57:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 11:57:41 +0200 Subject: Missing pkgs in F7!? In-Reply-To: <465FE7E1.5040907@linux-kernel.at> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <20070601105241.35b741bc@python3.es.egwn.lan> <465FE7E1.5040907@linux-kernel.at> Message-ID: <465FED95.9020509@leemhuis.info> On 01.06.2007 11:33, Oliver Falk wrote: > - snort is missing in f7, but avail in -devel and fc6 > - openldap-servers missing in f7, but avail in -devel and fc6 > - bind-sdb missing in f7, but avail in -devel and fc6 > - net-snmp-utils missing in f7, but avail in -devel and fc6 > - stonith and heartbeat missing in f7, but avail in -devel and fc6 > > That's all I stumbled across at the moment... > > Maybe it's a fault on my side (corrupt ISOs? I don't think so sha1sum-ed > it). I also checked download.fedora.redhat.com and didn't find the pkgs. Did you look in releases/7/Everything/${arch}/os/Fedora/ ? See for example: http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/releases/7/Everything/i386/os/Fedora/openldap-servers-2.3.34-0.fc7.i386.rpm http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/releases/7/Everything/i386/os/Fedora/snort-2.6.1.3-1.fc7.i386.rpm (that's a German mirror, but should be there on download.fedoraproject.org as well) CU thl From nicolas.mailhot at laposte.net Fri Jun 1 10:01:52 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 1 Jun 2007 12:01:52 +0200 (CEST) Subject: [Suspend-devel] willing to contribute - so laptops suspend better - but how? In-Reply-To: <465F254B.8000903@fedoraproject.org> References: <64b14b300705240119w768f23f1h40c312432818c385@mail.gmail.com> <200705242225.50298.rjw@sisk.pl> <64b14b300705300627g47c1868due57f449aaf528901@mail.gmail.com> <200705302212.12042.rjw@sisk.pl> <64b14b300705310121q1ad9430ek64e848d02a4dfcb5@mail.gmail.com> <47300.192.54.193.51.1180600598.squirrel@rousalka.dyndns.org> <465F254B.8000903@fedoraproject.org> Message-ID: <16339.192.54.193.51.1180692112.squirrel@rousalka.dyndns.org> Le Jeu 31 mai 2007 21:43, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: >> Le Jeu 31 mai 2007 10:21, Valent Turkovic a ?crit : >> >>> How much time does it take to configure vanilla kernel to run with >>> fedora? Can you give me some guide or some general info. >> >> It would be *very* nice to have an official simplified spec file >> where >> one would just dump vanilla source & patch references and test the >> result. The Fedora kernel spec is so complex it can't really be >> reused >> standalone > > Already planned. See fedora-kernel list archives. Not really what I had in mind What's planned if I understand it correctly is some automation to have koji spill vanilla kernels in addition to fedora-patched ones What I'd like to see is a spec template where you can just list the upstream patches & config options you need, and mock-build locally a kernel package that integrates nicely in Fedora (all the debuginfo, devel, etc subpackage stuff) ie kill the multi-arch multi-flavour automation, just build a simple single version for the user system The use case is when you hit a bug, open an issue in upstream's bugzilla/mail LKML, and people ask you to try vanilla kernel X with patch Y and config option Z on. -- Nicolas Mailhot From fedora at camperquake.de Fri Jun 1 10:37:53 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 1 Jun 2007 12:37:53 +0200 Subject: Fedora 8 Schedule In-Reply-To: <20070531223421.GA9934@orient.maison.lan> References: <200705311355.29200.jkeating@redhat.com> <1180634839.3572.14.camel@dhollis-lnx.sunera.com> <465F159E.9080005@fedoraproject.org> <465F1645.2000005@fedoraproject.org> <465F16EA.3020902@fedoraproject.org> <20070531223421.GA9934@orient.maison.lan> Message-ID: <20070601123753.6b420b10@banea.int.addix.net> Hi. On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: > Then again, neither does Fedora 7's name. There was a full moon yesterday. From jdogalt at yahoo.com Fri Jun 1 11:00:53 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Fri, 1 Jun 2007 04:00:53 -0700 (PDT) Subject: RFE: use nasa worldwind for timezone selection (i.e. my first reaction to F7) Message-ID: <448387.4032.qm@web56902.mail.re3.yahoo.com> FWIW the first nuisance I'm running into with F7 is during installation at the timezone selection phase. The shiny new zoomable map was shaping up to be a nice improvement, but some bug with the right mouse drag input handling is causing it to suck. But a simple bug report asside- the following idea came to me- If you are going to go to that much effort for the thing, why not take it a notch further and just integrate nasa worldwind into the anaconda. You could even have a way (possibly easter egg) to play with worldwind while the install is going (i.e. another option in addition to reading the release notes) Anway, this isn't a project I'm likely to work on, but I think it would be pretty cool. I'll admit I haven't even used worldwind other than maybe once a few years ago. But if it works as advertised, it seems like it shouldn't be too hard to integrate it. -dmc/jdog ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ From limb at jcomserv.net Fri Jun 1 11:16:25 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 1 Jun 2007 06:16:25 -0500 (CDT) Subject: First impressions of a system update with yum In-Reply-To: <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> Message-ID: <38348.65.192.24.190.1180696585.squirrel@mail.jcomserv.net> My first 32-bit x86 yum upgrade is finished, with no major complications. So far. I'll let you know. . . > On 5/31/07, Matthias Saou > > wrote: >> Other current thought : To hell with it, format "/" and reinstall from >> DVD... > > This is my normal course of action. I don't want to deal with the > leftover packages and the missing new packages. I just let Anaconda do > its job. > > I have two partitions for root, the current release, and the new or > old release. That way my old root with a working system is available > if some hardware seems to not work. > > Also, I don't bother with a DVD or CD, I just use the grub hack. > > -Schlaegel > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From laurent.rineau__fedora_extras at normalesup.org Fri Jun 1 11:26:23 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 1 Jun 2007 13:26:23 +0200 Subject: How to request a new review for a package of mine? Message-ID: <200706011326.23569@rineau.tsetse> Hi, My package CGAL has a new upstream revision (3.3-RC1) and a lot of work has been done with upstream between 3.2.1 and 3.3 so that CGAL is more Fedora compliant (dynamic libraries, with sonames, renaming of several libraries). I would like to ask a new review, for the package that I have pushed to Rawhide. Should?I open a new Review Request, in BZ, or re-open bug #199168 (CGAL's RR)? Other question: CGAL-3.3 has different sonames than previous CGAL-3.2.1. If I want to push CGAL-3.3 to Fedora?Extras 5 and 6 and Fedora?7, should I create a compat-CGAL-3.2 package, knowing that no Fedora package depends on CGAL? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From martin.sourada at seznam.cz Fri Jun 1 11:35:02 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 01 Jun 2007 13:35:02 +0200 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <448387.4032.qm@web56902.mail.re3.yahoo.com> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> Message-ID: <1180697702.3637.6.camel@pc-notebook> On Fri, 2007-06-01 at 13:00 +0200, Jane Dogalt wrote: > FWIW the first nuisance I'm running into with F7 is during installation > at the timezone selection phase. The shiny new zoomable map was > shaping up to be a nice improvement, but some bug with the right mouse > drag input handling is causing it to suck. > > But a simple bug report asside- the following idea came to me- > > If you are going to go to that much effort for the thing, why not take > it a notch further and just integrate nasa worldwind into the anaconda. > > You could even have a way (possibly easter egg) to play with worldwind > while the install is going (i.e. another option in addition to reading > the release notes) > > Anway, this isn't a project I'm likely to work on, but I think it would > be pretty cool. I'll admit I haven't even used worldwind other than > maybe once a few years ago. But if it works as advertised, it seems > like it shouldn't be too hard to integrate it. > > -dmc/jdog > > > > > > ____________________________________________________________________________________ > Need a vacation? Get great deals > to amazing places on Yahoo! Travel. > http://travel.yahoo.com/ > Well, it would be cool, but I don't think it's worth implementing. The zoom-able map is there only to ease the process of selecting you home town... However, if you mentioned extensions to timezone, it came to my mind that Fedora 7 installer didn't set timezone to Europe/Prague even with Czech language selected as installation language. I think it would be useful to set the timezone by default relevant to selected language of installation, or if internet connection is available, to check the position of computer and adjust timezone to that. Also, I think this feature need not to be included only in anaconda. I think, for people with laptops it could be useful to adjust timezone automatically as they travel from one to another. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Fri Jun 1 11:58:36 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 11:58:36 +0000 (UTC) Subject: For your consideration: Secondary Architectures in Fedora References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <7dd7ab490705291600x633a3452w85d9275ea662fbf9@mail.gmail.com> <1180516024.26803.87.camel@pmac.infradead.org> <20070530092348.GN4033@devserv.devel.redhat.com> <465F6AB7.8080604@redhat.com> <1180660510.26803.592.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > The only really reliable solution I see would be full-system emulation. > Which isn't always much faster than the real hardware, unfortunately. It's usually much slower. I used that to build x86_64 RPMs for my repository, and this takes 8 hours to build a package which builds in 10 minutes on my native 32-bit hardware or 5 minutes on real 64-bit hardware. Building OO.o in there would take days or even weeks. So unless you're talking about really slow machines, which likely don't have the RAM to run Fedora properly anyway, QEMU full-system emulation is not a solution. Kevin Kofler From pertusus at free.fr Fri Jun 1 11:58:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 1 Jun 2007 13:58:52 +0200 Subject: How to request a new review for a package of mine? In-Reply-To: <200706011326.23569@rineau.tsetse> References: <200706011326.23569@rineau.tsetse> Message-ID: <20070601115852.GA2844@free.fr> On Fri, Jun 01, 2007 at 01:26:23PM +0200, Laurent Rineau wrote: > Hi, > > I would like to ask a new review, for the package that I have pushed to > Rawhide. Should?I open a new Review Request, in BZ, or re-open bug #199168 > (CGAL's RR)? There is no policy on that. You may have hard time finding a reviewer for an existing package, but you can chose whatever way you prefer (ask on the list, continue in the previous bug, add a new bug...). People can look at the cvs version now, so things should be simpler in any case. > Other question: CGAL-3.3 has different sonames than previous CGAL-3.2.1. If I > want to push CGAL-3.3 to Fedora?Extras 5 and 6 and Fedora?7, should I create > a compat-CGAL-3.2 package, knowing that no Fedora package depends on CGAL? As far as I know, there are no policies on this in fedora, so in my opinion this should be based on your knowledge of the package use and users and on your best judgement. I personally don't like soname changing during a fedora release, but I guess it depends on the maintainer. There has been some debates on that in the past, but my recalling is that there was no real agreement. -- Pat From kevin.kofler at chello.at Fri Jun 1 12:02:01 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 12:02:01 +0000 (UTC) Subject: For your consideration: Secondary Architectures in Fedora References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <7dd7ab490705291600x633a3452w85d9275ea662fbf9@mail.gmail.com> <1180516024.26803.87.camel@pmac.infradead.org> <20070530092348.GN4033@devserv.devel.redhat.com> <1180522890.26803.180.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > It would be nice if I could submit them both together, and let the build > system handle building one after the other. And that shouldn't be > impossible to achieve... > > $ make -C bluez-libs/devel build > job id = 54321 > $ make -C bluez-utils/devel DEPENDS_ON_JOB=54321 build > job id = 54322 I believe Koji already supports that feature (not with that exact interface though; AFAIK you have to submit the dependent jobs together, not add a DEPENDS_ON_JOB after the fact), it's called chain-building, but Makefile.common doesn't support it yet. Kevin Kofler From sundaram at fedoraproject.org Fri Jun 1 12:09:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 17:39:10 +0530 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <1180697702.3637.6.camel@pc-notebook> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> Message-ID: <46600C66.30708@fedoraproject.org> Martin Sourada wrote: > > However, if you mentioned extensions to timezone, it came to my mind > that Fedora 7 installer didn't set timezone to Europe/Prague even with > Czech language selected as installation language. I think it would be > useful to set the timezone by default relevant to selected language of > installation, My native language is spoken by a significant popular in alteast three countries. For some languages there might be a strong affiliation to specific regions but people do migrate. Rahul From emmanuel.seyman at club-internet.fr Fri Jun 1 12:17:38 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 1 Jun 2007 14:17:38 +0200 Subject: Fedora 8 Schedule In-Reply-To: <20070601123753.6b420b10@banea.int.addix.net> References: <200705311355.29200.jkeating@redhat.com> <1180634839.3572.14.camel@dhollis-lnx.sunera.com> <465F159E.9080005@fedoraproject.org> <465F1645.2000005@fedoraproject.org> <465F16EA.3020902@fedoraproject.org> <20070531223421.GA9934@orient.maison.lan> <20070601123753.6b420b10@banea.int.addix.net> Message-ID: <20070601121738.GA13905@orient.maison.lan> * Ralf Ertzinger [01/06/2007 14:06] : > > On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: > > > Then again, neither does Fedora 7's name. > > There was a full moon yesterday. Not the first explanation that sprang to my mind while reading the release announcement, to be honest. Emmanuel From jwboyer at jdub.homelinux.org Fri Jun 1 12:33:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 01 Jun 2007 07:33:19 -0500 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180649583.3475.2.camel@localhost.localdomain> References: <1180639616.9513.4.camel@localhost.localdomain> <1180642169.9513.24.camel@localhost.localdomain> <1180646159.5761.54.camel@vader.jdub.homelinux.org> <1180646779.10152.0.camel@localhost.localdomain> <1180648995.5761.59.camel@vader.jdub.homelinux.org> <1180649583.3475.2.camel@localhost.localdomain> Message-ID: <1180701199.5761.62.camel@vader.jdub.homelinux.org> On Thu, 2007-05-31 at 18:13 -0400, Matthias Clasen wrote: > On Thu, 2007-05-31 at 17:03 -0500, Josh Boyer wrote: > > > If you're referring to migrating Windows users, even they realize there > > is more than one program to accomplish the same task. Think of AIM, > > Trillian, ICQ, blah blah blah. Or McAfee vs. Symantec. Or IE vs. > > Firefox. Hell, even Microsoft doesn't label IE as "Web browser" (which > > is another bogosity we do but one thing at a time). > > How convenient that the desktop team can alternatively be slammed for > copying Windows or for failing to copy it... Wait a minute... I'm not slamming anyone. Nor did I alternate here.. (at least I don't think I did). I'm simply saying that including a program's name in the menu entry seems common sense to me. What I don't understand is your classification of "regular user" and why you think having the program's name in the menu entry is confusing to them. josh From linux_4ever at yahoo.com Fri Jun 1 12:39:16 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 1 Jun 2007 05:39:16 -0700 (PDT) Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <465FD2A4.2010306@linux-kernel.at> Message-ID: <45365.29376.qm@web51512.mail.re2.yahoo.com> >Fedora maintainers have not rebuilt these packages for Fedora 7 >to avoid making end users download the packages for only a release tag >change. This is bull. Most people download an iso which contains the old version. IOW, you download it *anyways*. The only people this might help is rawhide users and people updating via yum - which if I recall, is not officially supported. I'd like to see this policy changed in F8 so that admins/users can spot failed upgrades or orphaned packages. That is far greater value than saying its to save bandwidth when it doesn't. -Steve ____________________________________________________________________________________ Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 From opensource at till.name Fri Jun 1 12:37:57 2007 From: opensource at till.name (Till Maas) Date: Fri, 01 Jun 2007 14:37:57 +0200 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200705312344.11171.dennis@ausil.us> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706010003.11844.opensource@till.name> <200705312344.11171.dennis@ausil.us> Message-ID: <200706011437.59049.opensource@till.name> On Fr Juni 1 2007, Dennis Gilmore wrote: > sorry I should have put these up a week or so ago. Unfortunately i cant > sign them as im only in the epel signing group. i really dont know what > key they should be signed if they were. It is up there now. please let me The key that is used for Fedora Packages now is my favourite. Why are the rpms not in the normal repository anyway? Then this problem would not exist. Regards, Till From sundaram at fedoraproject.org Fri Jun 1 12:48:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 18:18:14 +0530 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <45365.29376.qm@web51512.mail.re2.yahoo.com> References: <45365.29376.qm@web51512.mail.re2.yahoo.com> Message-ID: <4660158E.5080603@fedoraproject.org> Steve G wrote: >> Fedora maintainers have not rebuilt these packages for Fedora 7 >> to avoid making end users download the packages for only a release tag >> change. > > This is bull. Most people download an iso which contains the old version. IOW, > you download it *anyways*. The only people this might help is rawhide users and > people updating via yum - which if I recall, is not officially supported. I'd > like to see this policy changed in F8 so that admins/users can spot failed > upgrades or orphaned packages. That is far greater value than saying its to save > bandwidth when it doesn't. I did request precisely this to FESCo but unfortunately that got denied with this explanation which I don't think is much of a advantage esp if yum-presto comes in by default. Rahul From ich at frank-schmitt.net Fri Jun 1 12:46:58 2007 From: ich at frank-schmitt.net (Frank Schmitt) Date: Fri, 01 Jun 2007 14:46:58 +0200 Subject: Fedora 8 Schedule References: <200705311355.29200.jkeating@redhat.com> <1180634839.3572.14.camel@dhollis-lnx.sunera.com> <465F159E.9080005@fedoraproject.org> <465F1645.2000005@fedoraproject.org> <465F16EA.3020902@fedoraproject.org> <20070531223421.GA9934@orient.maison.lan> <20070601123753.6b420b10@banea.int.addix.net> <20070601121738.GA13905@orient.maison.lan> Message-ID: Emmanuel Seyman writes: > * Ralf Ertzinger [01/06/2007 14:06] : >> >> On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: >> >> > Then again, neither does Fedora 7's name. >> >> There was a full moon yesterday. > > Not the first explanation that sprang to my mind while reading the release > announcement, to be honest. Could someone enlighten a stupid German? -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From mclasen at redhat.com Fri Jun 1 12:45:39 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 01 Jun 2007 08:45:39 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180701199.5761.62.camel@vader.jdub.homelinux.org> References: <1180639616.9513.4.camel@localhost.localdomain> <1180642169.9513.24.camel@localhost.localdomain> <1180646159.5761.54.camel@vader.jdub.homelinux.org> <1180646779.10152.0.camel@localhost.localdomain> <1180648995.5761.59.camel@vader.jdub.homelinux.org> <1180649583.3475.2.camel@localhost.localdomain> <1180701199.5761.62.camel@vader.jdub.homelinux.org> Message-ID: <1180701939.3553.17.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-06-01 at 07:33 -0500, Josh Boyer wrote: > On Thu, 2007-05-31 at 18:13 -0400, Matthias Clasen wrote: > > On Thu, 2007-05-31 at 17:03 -0500, Josh Boyer wrote: > > > > > If you're referring to migrating Windows users, even they realize there > > > is more than one program to accomplish the same task. Think of AIM, > > > Trillian, ICQ, blah blah blah. Or McAfee vs. Symantec. Or IE vs. > > > Firefox. Hell, even Microsoft doesn't label IE as "Web browser" (which > > > is another bogosity we do but one thing at a time). > > > > How convenient that the desktop team can alternatively be slammed for > > copying Windows or for failing to copy it... > > Wait a minute... I'm not slamming anyone. Nor did I alternate here.. > (at least I don't think I did). > > I'm simply saying that including a program's name in the menu entry > seems common sense to me. What I don't understand is your > classification of "regular user" and why you think having the program's > name in the menu entry is confusing to them. > The program name in the menu doesn't help you make a choice unless you know the programs by name. That was the argument for including "Firefox" in the menu item even though Firefox is the default browser, because the name is well-recognized even with people who don't spend a large percentage of their life in front of a computer. Since x-chat doesn't have the same "brand recognition" that firefox has, adding its name to the menu does not help. Anyway, as Owen said, after the merge, and with the packaging guidelines agitating for putting everything in the menus, organizing meaningful menus is largely a lost cause, and we should concentrate on making application browsing in bigboard work well instead. From kevin.kofler at chello.at Fri Jun 1 12:50:50 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 12:50:50 +0000 (UTC) Subject: Testing update announcements Message-ID: I've noticed Bodhi doesn't appear to send announcements about testing updates to fedora-test-list as the old system used to. Is that intentional? If a maintainer would really like some specific testing to be done on the packages (and results reported), should they send their own announcement? Kevin Kofler From hughsient at gmail.com Fri Jun 1 12:52:09 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 01 Jun 2007 13:52:09 +0100 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <45365.29376.qm@web51512.mail.re2.yahoo.com> References: <45365.29376.qm@web51512.mail.re2.yahoo.com> Message-ID: <1180702329.12971.23.camel@localhost.localdomain> On Fri, 2007-06-01 at 05:39 -0700, Steve G wrote: > >Fedora maintainers have not rebuilt these packages for Fedora 7 > >to avoid making end users download the packages for only a release tag > >change. > > This is bull. Most people download an iso which contains the old version. IOW, > you download it *anyways*. The only people this might help is rawhide users and > people updating via yum - which if I recall, is not officially supported. I'd > like to see this policy changed in F8 so that admins/users can spot failed > upgrades or orphaned packages. That is far greater value than saying its to save > bandwidth when it doesn't. I tend to agree. If I saw a fc6 package on my anaconda updated fc7 system, I would likely think something has failed to update. Richard. From linux_4ever at yahoo.com Fri Jun 1 12:53:20 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 1 Jun 2007 05:53:20 -0700 (PDT) Subject: disagreement in a merge review about patches In-Reply-To: <20070601081258.GA9531@free.fr> Message-ID: <790934.34674.qm@web51512.mail.re2.yahoo.com> >Marcela disagrees because then there won't be a one patch one bug >relationship. My advice is to keep the patches to have this one patch >one bug relationship, but don't apply tem and instead have a one patch >one functionality instead. I'd have to agree with Marcela. There's many times I need to research a fix and see exactly what was changed. If you want a unified patch that's simple to create and I do that too sometimes. Having 2 sets of the same patch, individual and unified will make the srpm get bigger. -Steve ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From sundaram at fedoraproject.org Fri Jun 1 12:54:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 18:24:08 +0530 Subject: Fedora 8 Schedule In-Reply-To: References: <200705311355.29200.jkeating@redhat.com> <1180634839.3572.14.camel@dhollis-lnx.sunera.com> <465F159E.9080005@fedoraproject.org> <465F1645.2000005@fedoraproject.org> <465F16EA.3020902@fedoraproject.org> <20070531223421.GA9934@orient.maison.lan> <20070601123753.6b420b10@banea.int.addix.net> <20070601121738.GA13905@orient.maison.lan> Message-ID: <466016F0.5010104@fedoraproject.org> Frank Schmitt wrote: > Emmanuel Seyman writes: > >> * Ralf Ertzinger [01/06/2007 14:06] : >>> On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: >>> >>>> Then again, neither does Fedora 7's name. >>> There was a full moon yesterday. >> Not the first explanation that sprang to my mind while reading the release >> announcement, to be honest. > > Could someone enlighten a stupid German? http://en.wikipedia.org/wiki/Moonshine Rahul From pemboa at gmail.com Fri Jun 1 12:53:58 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 1 Jun 2007 08:53:58 -0400 Subject: Fedora 8 Schedule In-Reply-To: References: <1180634839.3572.14.camel@dhollis-lnx.sunera.com> <465F159E.9080005@fedoraproject.org> <465F1645.2000005@fedoraproject.org> <465F16EA.3020902@fedoraproject.org> <20070531223421.GA9934@orient.maison.lan> <20070601123753.6b420b10@banea.int.addix.net> <20070601121738.GA13905@orient.maison.lan> Message-ID: <16de708d0706010553y31ad2d9are2fa95c04296639b@mail.gmail.com> On 6/1/07, Frank Schmitt wrote: > Emmanuel Seyman writes: > > > * Ralf Ertzinger [01/06/2007 14:06] : > >> > >> On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: > >> > >> > Then again, neither does Fedora 7's name. > >> > >> There was a full moon yesterday. > > > > Not the first explanation that sprang to my mind while reading the release > > announcement, to be honest. > > Could someone enlighten a stupid German? http://en.wikipedia.org/wiki/Moonshine -- Fedora Core 6 and proud From kevin.kofler at chello.at Fri Jun 1 12:54:11 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 12:54:11 +0000 (UTC) Subject: X-Chat in Fedora References: <464E0072.2070309@redhat.com> Message-ID: Warren Togami redhat.com> writes: > I took a look at upgrading xchat in rawhide to a more recent version, > but I gave up when newer versions broke IM (scim and XIM) input which > would be an unacceptable regression to ship in Fedora. Perhaps newer > versions have fixed that issue. Wasn't that the gtkspell issue, which is "fixed" by simply using the --enable-spell=static option (which statically includes spell-checking code dlopening enchant at runtime) instead? Or did you run into a separate issue there? In any case, there's a 2.8.2-7.fc7 currently in F7 updates-testing, does this work with input methods? Kevin Kofler From ben.lewis at benl.co.uk Fri Jun 1 12:56:44 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Fri, 01 Jun 2007 13:56:44 +0100 Subject: First impressions of a system update with yum In-Reply-To: <38348.65.192.24.190.1180696585.squirrel@mail.jcomserv.net> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <38348.65.192.24.190.1180696585.squirrel@mail.jcomserv.net> Message-ID: <4660178C.7020400@benl.co.uk> Same here, no problems - this is the first time its worked for me too! Jon Ciesla wrote: > My first 32-bit x86 yum upgrade is finished, with no major complications. > So far. I'll let you know. . . > > >> On 5/31/07, Matthias Saou >> >> wrote: >> >>> Other current thought : To hell with it, format "/" and reinstall from >>> DVD... >>> >> This is my normal course of action. I don't want to deal with the >> leftover packages and the missing new packages. I just let Anaconda do >> its job. >> >> I have two partitions for root, the current release, and the new or >> old release. That way my old root with a working system is available >> if some hardware seems to not work. >> >> Also, I don't bother with a DVD or CD, I just use the grub hack. >> >> -Schlaegel >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > > > -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From dtimms at iinet.net.au Fri Jun 1 13:18:56 2007 From: dtimms at iinet.net.au (David Timms) Date: Fri, 01 Jun 2007 23:18:56 +1000 Subject: Mirroring tools In-Reply-To: <4890.71.208.204.173.1180669960.squirrel@www.cora.nwra.com> References: <4890.71.208.204.173.1180669960.squirrel@www.cora.nwra.com> Message-ID: <46601CC0.1000808@iinet.net.au> orion at cora.nwra.com wrote: > I'd like to try to reduce the amount of packages that I mirror locally, > especially with the ever increasing amount of large game packages. Has > anyone thought about a tool that could take a list of packages names > generated by something like pungi and generate a include list suitable for > rsync? Then you could do something like: > > rsync --include-from rpms_I_want --exclude \*.rpm > > Currently I periodically update an exclude list by hand, but this is > getting tiresome. > > Just thought about using the output of 'yum groupinfo games' and the like > to generate exclude lists. Maybe that will be easier and sufficient. Would the rsync option for only updating existing files be useful, along with fuzzy ? DaveT. From j.w.r.degoede at hhs.nl Fri Jun 1 13:14:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 15:14:23 +0200 Subject: Don't put new packages through updates-testing Message-ID: <46601BAF.8000507@hhs.nl> Hi all, As already discussed on then maintainers list (using devel list for this as I see no reason to keep this on maintainers), the plan all of a sudden is to let new packages go through updates-testing. I'm very much against this, as it adds one more step to already long process of getting new packages in, the current wiki page describing the process divides it into 14 steps and it is lacking the add to comps step (and in my case the update SIG wiki pag, twice once to add it to the list of packages undergoing review, once more to remove). It removes much of the satisfaction of after completing the review having the package into the hands of the end users, the ones for which I do this. As it adds yet another delay. The arguments made in favor of this is that it will be good for QA, however relatively few users will have updates testing enabled and new packages will not automatically get installed let alone used by those users. Then the argument in favor becomes that once we have a QA team up and running, we could build QA infra which autamatically installs new packages from updates-testing for the QA team (running still would be a manual thing). However currently all that infra doesn't exist, so can we please short circuit updates-testing for new packages, and revisit this discussion once that infra actually is there? IOW first show that updates-testing actually is usefull (esp. for new packages) and then make new packages go through there. Last but most certainly not least new packages have already had lots of QA they have just been reviewed! To me this forcing new packages to go through updates-testing is a vote of no confidence into me as a packager and a reviewer, and since I sink a lot of time, effort and skill into Fedora that hurts! Yet another argument against making new-packages go through updates-testing is the fact that even if there were a QA team testing them, I wonder how they would test my latest batch of packages: avr-binutils avr-gcc avr-libc arm-gp2x-linux-kernel-headers arm-gp2x-linux-binutils arm-gp2x-linux-gcc arm-gp2x-linux-glibc Do they happen to have an avr microcontroller development kit handy for testing or a gp2x handheld? Any experience with programming those? Making package like these goto updates-testing is ridiculous. Regards, Hans From gianluca.cecchi at gmail.com Fri Jun 1 13:24:41 2007 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 1 Jun 2007 15:24:41 +0200 Subject: Automate time zone selection Message-ID: <561c252c0706010624v750b8382mb040ece029204961@mail.gmail.com> On Fri, 01 Jun 2007 13:35:02 +0200 Martin Sourada wrote: >I think it would be useful to set the timezone by default relevant to selected language of >installation, or if internet connection is available, to check the >position of computer and adjust timezone to that. I use Tele2 in Italy to connect to the Internet, but usually I get different countries IP 9don't know what is the routing of my provider), as I can see if I go to www.google.com. Sometimes I'm diverted to the Belgium goggle page, sometimes to Holland and more often to Italy.... gianluca From limb at jcomserv.net Fri Jun 1 13:21:55 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 1 Jun 2007 08:21:55 -0500 (CDT) Subject: First impressions of a system update with yum In-Reply-To: <4660178C.7020400@benl.co.uk> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <38348.65.192.24.190.1180696585.squirrel@mail.jcomserv.net> <4660178C.7020400@benl.co.uk> Message-ID: <46915.65.192.24.190.1180704115.squirrel@mail.jcomserv.net> Actually, I've done this several times, I have a server that began life as FC3, and another as RH8. I've been yum upgrading since FC3, and this was just my first for F7. I several more to do yet. :) > Same here, no problems - this is the first time its worked for me too! > > Jon Ciesla wrote: >> My first 32-bit x86 yum upgrade is finished, with no major >> complications. >> So far. I'll let you know. . . >> >> >>> On 5/31/07, Matthias Saou >>> >>> wrote: >>> >>>> Other current thought : To hell with it, format "/" and reinstall from >>>> DVD... >>>> >>> This is my normal course of action. I don't want to deal with the >>> leftover packages and the missing new packages. I just let Anaconda do >>> its job. >>> >>> I have two partitions for root, the current release, and the new or >>> old release. That way my old root with a working system is available >>> if some hardware seems to not work. >>> >>> Also, I don't bother with a DVD or CD, I just use the grub hack. >>> >>> -Schlaegel >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >>> >> >> >> > > -- > > Benjamin Lewis > Fedora Ambassador > ben.lewis at benl.co.uk > > ----------------------------------------------------------------------- > http://benl.co.uk./ PGP Key: 0x647E480C > > "In cases of major discrepancy, it is always reality that got it wrong" > -- RFC 1118 > > -- novus ordo absurdum From mclasen at redhat.com Fri Jun 1 13:22:21 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 01 Jun 2007 09:22:21 -0400 Subject: Fedora 8 Schedule In-Reply-To: References: Message-ID: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-05-31 at 17:52 +0000, Kevin Kofler wrote: > So this has popped up now: > http://fedoraproject.org/wiki/Releases/8/Schedule > > I don't like this in the least: not only is this only a 5 month schedule, not > the usual 6, but the final devel freeze is 6 days before the scheduled KDE 4.0 > release, which is pretty unfortunate. :-( > Some more notes about this draft: it puts feature freeze in bold letters at August 20, which is only a few days after gnome 2.20 beta1, and is the exact same date as the Google SoC deadline. Since we are hoping to integrate SoC results for some features (Bluetooth support comes to mind), I hope that there will be enough flexibility to make this possible. From jkeating at redhat.com Fri Jun 1 13:33:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 09:33:19 -0400 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: References: <1180473516.6254.454.camel@localhost.localdomain> <1180522890.26803.180.camel@pmac.infradead.org> Message-ID: <200706010933.19346.jkeating@redhat.com> On Friday 01 June 2007 08:02:01 Kevin Kofler wrote: > I believe Koji already supports that feature (not with that exact interface > though; AFAIK you have to submit the dependent jobs together, not add a > DEPENDS_ON_JOB after the fact), it's called chain-building, but > Makefile.common doesn't support it yet. Actually patches went in yesterday for chainbuild support in Makefile.common -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 1 13:35:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 09:35:01 -0400 Subject: Fedora 8 Schedule In-Reply-To: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> Message-ID: <200706010935.01695.jkeating@redhat.com> On Friday 01 June 2007 09:22:21 Matthias Clasen wrote: > Some more notes about this draft: it puts feature freeze in bold letters > at August 20, which is only a few days after gnome 2.20 beta1, and is > the exact same date as the Google SoC deadline. Since we are hoping to > integrate SoC results for some features (Bluetooth support comes to > mind), I hope that there will be enough flexibility to make this > possible. Surely there will be some GSoC RC releases prior to the deadline, with features mostly done and in bugfix mode right? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Fri Jun 1 13:35:31 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 01 Jun 2007 09:35:31 -0400 Subject: Fedora 8 Schedule In-Reply-To: <200706010935.01695.jkeating@redhat.com> References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> <200706010935.01695.jkeating@redhat.com> Message-ID: <1180704931.3553.31.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-06-01 at 09:35 -0400, Jesse Keating wrote: > On Friday 01 June 2007 09:22:21 Matthias Clasen wrote: > > Some more notes about this draft: it puts feature freeze in bold letters > > at August 20, which is only a few days after gnome 2.20 beta1, and is > > the exact same date as the Google SoC deadline. Since we are hoping to > > integrate SoC results for some features (Bluetooth support comes to > > mind), I hope that there will be enough flexibility to make this > > possible. > > Surely there will be some GSoC RC releases prior to the deadline, with > features mostly done and in bugfix mode right? > Thats what should be hoped for, certainly, but you never know...I just wanted to point out the tight deadline alignment there. From nphilipp at redhat.com Fri Jun 1 13:45:11 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 01 Jun 2007 15:45:11 +0200 Subject: RFE: use nasa worldwind for timezone selection (i.e. my first reaction to F7) In-Reply-To: <448387.4032.qm@web56902.mail.re3.yahoo.com> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> Message-ID: <1180705512.3828.6.camel@gibraltar.stuttgart.redhat.com> On Fri, 2007-06-01 at 04:00 -0700, Jane Dogalt wrote: > FWIW the first nuisance I'm running into with F7 is during installation > at the timezone selection phase. The shiny new zoomable map was > shaping up to be a nice improvement, but some bug with the right mouse > drag input handling is causing it to suck. I agree, but this seems to be a bug in the underlying gnomecanvas to me that causes it to behave nicely when dragged slowly enough, but go berzerk if dragged to fast. I'm open for suggestions how to work around this though. > But a simple bug report asside- the following idea came to me- > > If you are going to go to that much effort for the thing, why not take > it a notch further and just integrate nasa worldwind into the anaconda. Weeell. First, the thing is from s-c-date, anaconda isn't the culprit. Second, as Martin said, this is to ease selecting "your" city in the map (especially in regions with a high density of cities), not to show off. Interfacing with Java and requiring accelerated 3D is not what I have in mind for s-c-date ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From ben.lewis at benl.co.uk Fri Jun 1 13:45:24 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Fri, 01 Jun 2007 14:45:24 +0100 Subject: First impressions of a system update with yum In-Reply-To: <46915.65.192.24.190.1180704115.squirrel@mail.jcomserv.net> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <38348.65.192.24.190.1180696585.squirrel@mail.jcomserv.net> <4660178C.7020400@benl.co.uk> <46915.65.192.24.190.1180704115.squirrel@mail.jcomserv.net> Message-ID: <466022F4.6070206@benl.co.uk> Yeah, its just it usually explodes when I do it, so I'm happy - now to sort out my laptop... Jon Ciesla wrote: > Actually, I've done this several times, I have a server that began life as > FC3, and another as RH8. I've been yum upgrading since FC3, and this was > just my first for F7. I several more to do yet. :) > > >> Same here, no problems - this is the first time its worked for me too! >> >> Jon Ciesla wrote: >> >>> My first 32-bit x86 yum upgrade is finished, with no major >>> complications. >>> So far. I'll let you know. . . >>> >>> >>> >>>> On 5/31/07, Matthias Saou >>>> >>>> wrote: >>>> >>>> >>>>> Other current thought : To hell with it, format "/" and reinstall from >>>>> DVD... >>>>> >>>>> >>>> This is my normal course of action. I don't want to deal with the >>>> leftover packages and the missing new packages. I just let Anaconda do >>>> its job. >>>> >>>> I have two partitions for root, the current release, and the new or >>>> old release. That way my old root with a working system is available >>>> if some hardware seems to not work. >>>> >>>> Also, I don't bother with a DVD or CD, I just use the grub hack. >>>> >>>> -Schlaegel >>>> >>>> -- >>>> fedora-devel-list mailing list >>>> fedora-devel-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>> >>>> >>>> >>> >>> >> -- >> >> Benjamin Lewis >> Fedora Ambassador >> ben.lewis at benl.co.uk >> >> ----------------------------------------------------------------------- >> http://benl.co.uk./ PGP Key: 0x647E480C >> >> "In cases of major discrepancy, it is always reality that got it wrong" >> -- RFC 1118 >> >> >> > > > -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Fri Jun 1 13:47:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 09:47:31 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <46601BAF.8000507@hhs.nl> References: <46601BAF.8000507@hhs.nl> Message-ID: <200706010947.31608.jkeating@redhat.com> On Friday 01 June 2007 09:14:23 Hans de Goede wrote: > As already discussed on then maintainers list (using devel list for this as > I see no reason to keep this on maintainers), the plan all of a sudden is > to let new packages go through updates-testing. Not so much "all of a sudden". The "sudden" part is using bodhi at all for new packages to released platforms. I may not have been mentioned loudly but updates-testing for said new packages was the idea all along. In the past, the only way we had to "test" things with a wider audience was to use rawhide, but that isn't a good test as rawhide doesn't equal the released platforms, and there are issues on said platforms that will be different. > I'm very much against this, as it adds one more step to already long > process of getting new packages in, the current wiki page describing the > process divides it into 14 steps and it is lacking the add to comps step > (and in my case the update SIG wiki pag, twice once to add it to the list > of packages undergoing review, once more to remove). > > It removes much of the satisfaction of after completing the review having > the package into the hands of the end users, the ones for which I do this. > As it adds yet another delay. You can still get your new package into rawhide immediately (or rather with the next rawhide push). There is instant satisfaction there. Bringing a brand new package to a supposedly stable released platform should be done with some caution and thought, and with letting a wider audience poke at it first in updates-testing before letting it loose upon the masses. > > The arguments made in favor of this is that it will be good for QA, however > relatively few users will have updates testing enabled And your data set is where? Perhaps we should query Mike McGraths statistics stuff to see how many unique IPs are hitting the mirror list for updates-testing. It may be small, it may be large, but I'm not going to just pull an observation out of my posterior. > and new packages > will not automatically get installed let alone used by those users. There is no reason why a QA team couldn't specifically target new packages to the distribution as seen through updates-testing to ensure proper functionality on a disparate set of hardware/software configurations. To just blanket claim that it won't happen is laughable. We've never done this for Extras, and in Core it was very very difficult to get approval to introduce a new package. Lets give it a try and see what our growing QA team can come up with to make it worth while. > Then > the argument in favor becomes that once we have a QA team up and running, > we could build QA infra which autamatically installs new packages from > updates-testing for the QA team (running still would be a manual thing). > However currently all that infra doesn't exist, so can we please short > circuit updates-testing for new packages, and revisit this discussion once > that infra actually is there? Why would the infra be there if there is no new packages to test? It doesn't take much effort to enable updates-testing and target a new package. There doesn't need to be any infrastructure in place, things can be done manually right now, today, and you could get valuable feed back, right now, today. That is if you even care about trying to maintain a stable release for users. I know I do. > IOW first show that updates-testing actually is usefull (esp. for new > packages) and then make new packages go through there. > > Last but most certainly not least new packages have already had lots of QA > they have just been reviewed! To me this forcing new packages to go through > updates-testing is a vote of no confidence into me as a packager and a > reviewer, and since I sink a lot of time, effort and skill into Fedora that > hurts! *cough* The review is for rawhide, where the platform could be drastically different than that of a stable tree. Just saying something worked on rawhide and expecting it to work on previous release, or previous release -1 is obtuse. > Yet another argument against making new-packages go through updates-testing > is the fact that even if there were a QA team testing them, I wonder how > they would test my latest batch of packages: > avr-binutils > avr-gcc > avr-libc > arm-gp2x-linux-kernel-headers > arm-gp2x-linux-binutils > arm-gp2x-linux-gcc > arm-gp2x-linux-glibc > > Do they happen to have an avr microcontroller development kit handy for > testing or a gp2x handheld? Any experience with programming those? > > Making package like these goto updates-testing is ridiculous. So you're using one corner case package set with a limited user base to throw out the entire idea of getting some larger audience testing on new packages to a stable release. Sounds like a great argument to me... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 1 13:48:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 09:48:11 -0400 Subject: Fedora 8 Schedule In-Reply-To: <1180704931.3553.31.camel@dhcp83-186.boston.redhat.com> References: <200706010935.01695.jkeating@redhat.com> <1180704931.3553.31.camel@dhcp83-186.boston.redhat.com> Message-ID: <200706010948.11870.jkeating@redhat.com> On Friday 01 June 2007 09:35:31 Matthias Clasen wrote: > Thats what should be hoped for, certainly, but you never know...I just > wanted to point out the tight deadline alignment there. Noted. Do you have wiki edit rights to add this to the Fedora 8 schedule page? It's good to have all such considerations tracked in the wiki. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Fri Jun 1 13:57:08 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 01 Jun 2007 15:57:08 +0200 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <1180697702.3637.6.camel@pc-notebook> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> Message-ID: <1180706228.3828.17.camel@gibraltar.stuttgart.redhat.com> On Fri, 2007-06-01 at 13:35 +0200, Martin Sourada wrote: > However, if you mentioned extensions to timezone, it came to my mind > that Fedora 7 installer didn't set timezone to Europe/Prague even with > Czech language selected as installation language. Mapping languages to timezones wouldn't work in many cases, would it? Take the list of languages, remove all those that usually are spoken in more than one country or timezone -- I don't think that list would be very long. > I think it would be > useful to set the timezone by default relevant to selected language of > installation, or if internet connection is available, to check the > position of computer and adjust timezone to that. Also, I think this > feature need not to be included only in anaconda. I think, for people > with laptops it could be useful to adjust timezone automatically as they > travel from one to another. IMO, to make setting this automatically sensible and reliable, you'd have to have some things first: - a freely available mapping between "position on earth" and the corresponding timezone that's kept up to date - an attached GPS receiver that can be read from Linux Just the first one makes this a no-go, I haven't been able to dig up something like this. I couldn't even find a freely available, machine-readable coarse map of timezones. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From cra at WPI.EDU Fri Jun 1 13:58:37 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 1 Jun 2007 09:58:37 -0400 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <45365.29376.qm@web51512.mail.re2.yahoo.com> References: <465FD2A4.2010306@linux-kernel.at> <45365.29376.qm@web51512.mail.re2.yahoo.com> Message-ID: <20070601135837.GH23405@angus.ind.WPI.EDU> On Fri, Jun 01, 2007 at 05:39:16AM -0700, Steve G wrote: > > >Fedora maintainers have not rebuilt these packages for Fedora 7 > >to avoid making end users download the packages for only a release tag > >change. > > This is bull. Most people download an iso which contains the old version. IOW, > you download it *anyways*. The only people this might help is rawhide users and > people updating via yum - which if I recall, is not officially supported. I'd > like to see this policy changed in F8 so that admins/users can spot failed > upgrades or orphaned packages. That is far greater value than saying its to save > bandwidth when it doesn't. Use "rpm -qa --last" to show you if there are packages leftover from before the upgrade date/time. k From greno at verizon.net Fri Jun 1 13:59:05 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 01 Jun 2007 09:59:05 -0400 Subject: First impressions of a system update with yum In-Reply-To: <466022F4.6070206@benl.co.uk> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <38348.65.192.24.190.1180696585.squirrel@mail.jcomserv.net> <4660178C.7020400@benl.co.uk> <46915.65.192.24.190.1180704115.squirrel@mail.jcomserv.net> <466022F4.6070206@benl.co.uk> Message-ID: <46602629.4000608@verizon.net> I successfully upgraded from FC5 to FC6 by having only packages installed using yum. Before that I always has a lot of tarball installs on the system and then upgrading to a new release was just a disaster every time I had tried it. Of course the upgrade to FC6 wasn't without problems, like i586 kernel, and the upgrade breaking in the middle and leaving a huge number of duplicate packages installed. So there was a lot of cleanup to do. But I'm really encouraged to hear that it looks like a FC6 - FC7 upgrade is going good without major problems (at least on 32-bit). :-) Benjamin Lewis wrote: > Yeah, its just it usually explodes when I do it, so I'm happy - now to > sort out my laptop... > > Jon Ciesla wrote: > >> Actually, I've done this several times, I have a server that began life as >> FC3, and another as RH8. I've been yum upgrading since FC3, and this was >> just my first for F7. I several more to do yet. :) >> >> >> >>> Same here, no problems - this is the first time its worked for me too! >>> >>> Jon Ciesla wrote: >>> >>> >>>> My first 32-bit x86 yum upgrade is finished, with no major >>>> complications. >>>> So far. I'll let you know. . . >>>> >>>> >>>> >>>> From linux_4ever at yahoo.com Fri Jun 1 14:08:35 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 1 Jun 2007 07:08:35 -0700 (PDT) Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <20070601135837.GH23405@angus.ind.WPI.EDU> Message-ID: <260130.53154.qm@web51510.mail.re2.yahoo.com> >Use "rpm -qa --last" to show you if there are packages leftover from >before the upgrade date/time. [root ~]# rpm -qa --last | wc -l 390 [root ~]# rpm -qa | wc -l 390 It returns the same list. I'd much rather be able to type: rpm -qa | grep -vi fc7 far simpler and no magic. -Steve ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From valent.turkovic at gmail.com Fri Jun 1 14:13:10 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 1 Jun 2007 16:13:10 +0200 Subject: [Suspend-devel] willing to contribute - so laptops suspend better - but how? In-Reply-To: <16339.192.54.193.51.1180692112.squirrel@rousalka.dyndns.org> References: <64b14b300705240119w768f23f1h40c312432818c385@mail.gmail.com> <200705242225.50298.rjw@sisk.pl> <64b14b300705300627g47c1868due57f449aaf528901@mail.gmail.com> <200705302212.12042.rjw@sisk.pl> <64b14b300705310121q1ad9430ek64e848d02a4dfcb5@mail.gmail.com> <47300.192.54.193.51.1180600598.squirrel@rousalka.dyndns.org> <465F254B.8000903@fedoraproject.org> <16339.192.54.193.51.1180692112.squirrel@rousalka.dyndns.org> Message-ID: <64b14b300706010713l5b88e25t2093646eb62fec70@mail.gmail.com> On 6/1/07, Nicolas Mailhot wrote: > > Le Jeu 31 mai 2007 21:43, Rahul Sundaram a ?crit : If I understood you correctly this feature would enable fodorans with not so great kernel knowledge to contribute to faster bug tracking... I hail this endeavor, please make this work if it is possible... if you lover the bar for us, users of fedora, to contribute you will get much more help. Regards Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From kevin.kofler at chello.at Fri Jun 1 14:13:14 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 14:13:14 +0000 (UTC) Subject: Fedora 8 Schedule References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> Message-ID: Matthias Clasen redhat.com> writes: > Some more notes about this draft: it puts feature freeze in bold letters > at August 20, which is only a few days after gnome 2.20 beta1, and is It's good to know that some folks from the GNOME camp are also not happy with that schedule (see also David Nielsen's message about the test3 freeze date). One one hand, it makes me feel better because this means the schedule isn't favoring GNOME over KDE, on the other hand it makes the schedule look even worse, because this means it's misaligned with both the GNOME and KDE schedules, at least one of which is central to every desktop user's experience of Fedora. Kevin Kofler From jkeating at redhat.com Fri Jun 1 14:11:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 10:11:21 -0400 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <260130.53154.qm@web51510.mail.re2.yahoo.com> References: <260130.53154.qm@web51510.mail.re2.yahoo.com> Message-ID: <200706011011.22131.jkeating@redhat.com> On Friday 01 June 2007 10:08:35 Steve G wrote: > far simpler and no magic. 'yum list extras' should show you packages you have installed that are not available in any configured / enabled repo. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cra at WPI.EDU Fri Jun 1 14:14:46 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 1 Jun 2007 10:14:46 -0400 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <260130.53154.qm@web51510.mail.re2.yahoo.com> References: <20070601135837.GH23405@angus.ind.WPI.EDU> <260130.53154.qm@web51510.mail.re2.yahoo.com> Message-ID: <20070601141446.GI23405@angus.ind.WPI.EDU> On Fri, Jun 01, 2007 at 07:08:35AM -0700, Steve G wrote: > >Use "rpm -qa --last" to show you if there are packages leftover from > >before the upgrade date/time. > > [root ~]# rpm -qa --last | wc -l > 390 > [root ~]# rpm -qa | wc -l > 390 > > It returns the same list. I'd much rather be able to type: > > rpm -qa | grep -vi fc7 > > far simpler and no magic. How about: rpm -qa --last | grep -v "the date that I installed Fedora 7" From rc040203 at freenet.de Fri Jun 1 14:18:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 16:18:22 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <200706010947.31608.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> Message-ID: <1180707503.12595.290.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 09:47 -0400, Jesse Keating wrote: > On Friday 01 June 2007 09:14:23 Hans de Goede wrote: > > As already discussed on then maintainers list (using devel list for this as > > I see no reason to keep this on maintainers), the plan all of a sudden is > > to let new packages go through updates-testing. > > Yet another argument against making new-packages go through updates-testing > > is the fact that even if there were a QA team testing them, I wonder how > > they would test my latest batch of packages: > > avr-binutils > > avr-gcc > > avr-libc > > arm-gp2x-linux-kernel-headers > > arm-gp2x-linux-binutils > > arm-gp2x-linux-gcc > > arm-gp2x-linux-glibc > > > > Do they happen to have an avr microcontroller development kit handy for > > testing or a gp2x handheld? Any experience with programming those? > > > > Making package like these goto updates-testing is ridiculous. > > So you're using one corner case package set with a limited user base to throw > out the entire idea of getting some larger audience testing on new packages > to a stable release. Sounds like a great argument to me... It is, it demonstrates the flaw of your endeavor: 1. You and the testers don't have the faintest idea how to test these packages: Probably 90% of all FE packages are in a similar boat: Specialized, small userbase and no knowledge on then in the testers team nor at RH. 2. There is no "community testers base" for such specialized packages, because these package are _new_ (rsp. not yet) in Fedora. 3. These packages are hugh and technically complex. They will never be "perfect" - There will always be bugs, it's only a matter if someone considers them severe enough. Ralf From kevin.kofler at chello.at Fri Jun 1 14:16:17 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 14:16:17 +0000 (UTC) Subject: Fedora 8 Schedule References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> Message-ID: I wrote: > worse, because this means it's misaligned with both the GNOME and KDE > schedules, at least one of which is central to every desktop user's > experience of Fedora. Whoops, let's make this "most desktop users' experience", lest we anger the XFCE and lightweight WM users. Sorry for that. ;-) Kevin Kofler From wwoods at redhat.com Fri Jun 1 14:28:08 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 01 Jun 2007 10:28:08 -0400 Subject: Testing update announcements In-Reply-To: References: Message-ID: <1180708088.3946.1.camel@zebes.localdomain> On Fri, 2007-06-01 at 12:50 +0000, Kevin Kofler wrote: > I've noticed Bodhi doesn't appear to send announcements about testing updates > to fedora-test-list as the old system used to. Is that intentional? If a > maintainer would really like some specific testing to be done on the packages > (and results reported), should they send their own announcement? This was a mistake - AFAIK bodhi should be sending announcements for new packages in updates-testing from now on. lmacken also said he could resend the announcements for the already-pushed ones, when he gets around to it. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From twoerner at redhat.com Fri Jun 1 14:32:50 2007 From: twoerner at redhat.com (Thomas Woerner) Date: Fri, 01 Jun 2007 16:32:50 +0200 Subject: Firewall configuration tool: system-config-firewall Message-ID: <46602E12.7080008@redhat.com> Hello, system-config-firewall is a new firewall configuration tool, which is based on system-config-securitylevel and provides enhanced funtionality and better user guidance. Please have a look at: http://koji.fedoraproject.org/scratch/twoerner/task_22791/ You will need system-config-firewall and system-config-firewall-tui packages for your architecture. system-config-firewall will replace system-config-securitylevel in devel, soon. Changes against system-config-securitylevel: - lokkit is rewritten in python (compatible with old version, but additional options). - gtk user interface cleaned up. - gtk UI enhancements: trusted interfaces, masquerading, custom rules for all IPV4 tables and for IPv6 filter - /etc/sysconfig/system-config-securitylevel is used for compatibility, the new location for the configuration is /etc/sysconfig/system-config-firewall - The text user interface is fully functional, but in an early state - this will be fixed. - The selinux part is stripped out of the user interfaces, because there is a new configuration tool for selinux: system-config-selinux. - The lokkit command line tool still has the selinux options and has the same behaviour as the old command line tool. - There is a simple setup wizard for the gtk UI. If you want to install system-config-firewall, you have to manually uninstall system-config-securitylevel, because there is a file conflict for /usr/sbin/lokkit. This version of system-config-firewall is not working with system-config-kickstart and firstboot, because these tools are using internal structures of system-config-securitylevel, which are not available anymore. Therefore you have to uninstall these packages, too. Thanks, Thomas From jkeating at redhat.com Fri Jun 1 14:31:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 10:31:46 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <1180707503.12595.290.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> Message-ID: <200706011031.47164.jkeating@redhat.com> On Friday 01 June 2007 10:18:22 Ralf Corsepius wrote: > It is, it demonstrates the flaw of your endeavor: No, it demonstrates an exception to the rule, which is completely acceptable. What's not acceptable is to use an exception to discount the rule as a whole. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Fri Jun 1 14:36:25 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 01 Jun 2007 10:36:25 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <1180707503.12595.290.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> Message-ID: <1180708585.3946.6.camel@zebes.localdomain> On Fri, 2007-06-01 at 16:18 +0200, Ralf Corsepius wrote: > On Fri, 2007-06-01 at 09:47 -0400, Jesse Keating wrote: > > On Friday 01 June 2007 09:14:23 Hans de Goede wrote: > > > As already discussed on then maintainers list (using devel list for this as > > > I see no reason to keep this on maintainers), the plan all of a sudden is > > > to let new packages go through updates-testing. > > > > Yet another argument against making new-packages go through updates-testing > > > is the fact that even if there were a QA team testing them, I wonder how > > > they would test my latest batch of packages: > > > avr-binutils > > > avr-gcc > > > avr-libc > > > arm-gp2x-linux-kernel-headers > > > arm-gp2x-linux-binutils > > > arm-gp2x-linux-gcc > > > arm-gp2x-linux-glibc > > > > > > Do they happen to have an avr microcontroller development kit handy for > > > testing or a gp2x handheld? Any experience with programming those? > > > > > > Making package like these goto updates-testing is ridiculous. > > > > So you're using one corner case package set with a limited user base to throw > > out the entire idea of getting some larger audience testing on new packages > > to a stable release. Sounds like a great argument to me... > It is, it demonstrates the flaw of your endeavor: > > 1. You and the testers don't have the faintest idea how to test these > packages: Probably 90% of all FE packages are in a similar boat: > Specialized, small userbase and no knowledge on then in the testers team > nor at RH. > > 2. There is no "community testers base" for such specialized packages, > because these package are _new_ (rsp. not yet) in Fedora. > > 3. These packages are hugh and technically complex. They will never be > "perfect" - There will always be bugs, it's only a matter if someone > considers them severe enough. Let's be a little more clear here - what the QA team actually does for packages in updates-testing is *verification*. Check package sanity, make sure programs don't segfault on startup, etc. I'm not expecting all testers to understand the functions of the packages as well as their maintainers. But anyone can tell if you missed some deps or your package doesn't start on x86_64. For some extra background on this, you might like to read: http://fedoraproject.org/wiki/WillWoods/Drafts/WhyBodhi -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linux_4ever at yahoo.com Fri Jun 1 14:30:04 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 1 Jun 2007 07:30:04 -0700 (PDT) Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <200706011011.22131.jkeating@redhat.com> Message-ID: <408487.92084.qm@web51505.mail.re2.yahoo.com> >'yum list extras' should show you packages you have installed that are not >available in any configured / enabled repo. This command is closer to what you would want. The problem with that command is it compares what is on the machine with what the current package is in yum. I bet it requires a network connection to work, too. It does not tell me that a package that has been superceeded is valid for that repo. Example, it tells me 3 of my kernels are not in yum when they were in fact officially released kernels. I have to weed through the output and decide case by case if its superceeded or orphaned. But even if there were a command that correctly identified orphaned packages without needing a network connection, the logic that not building all packages each development cycle saves download time doesn't hold up. -Steve ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news From cra at WPI.EDU Fri Jun 1 14:48:12 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 1 Jun 2007 10:48:12 -0400 Subject: Firewall configuration tool: system-config-firewall In-Reply-To: <46602E12.7080008@redhat.com> References: <46602E12.7080008@redhat.com> Message-ID: <20070601144812.GJ23405@angus.ind.WPI.EDU> On Fri, Jun 01, 2007 at 04:32:50PM +0200, Thomas Woerner wrote: > Hello, > > system-config-firewall is a new firewall configuration tool, which is > based on system-config-securitylevel and provides enhanced funtionality > and better user guidance. Does this one remember what I selected in it last time so I don't have to remember to make the same selections again myself? From j.w.r.degoede at hhs.nl Fri Jun 1 14:49:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 16:49:39 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <200706010947.31608.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> Message-ID: <46603203.3090001@hhs.nl> Jesse Keating wrote: > On Friday 01 June 2007 09:14:23 Hans de Goede wrote: >> As already discussed on then maintainers list (using devel list for this as >> I see no reason to keep this on maintainers), the plan all of a sudden is >> to let new packages go through updates-testing. > > Not so much "all of a sudden". The "sudden" part is using bodhi at all for > new packages to released platforms. I may not have been mentioned loudly but > updates-testing for said new packages was the idea all along. It was never mentioned, I've been digging the archives because AFAIK the opisite has actually been promised, new packages would go out as updates, but would not need to go through updates-testing, unfortunately I cannot find the thread where this was promised, nor did I find any thread which says that: "updates-testing for said new packages was the idea all along" Also there is nothing about updates at all under: http://fedoraproject.org/wiki/ReleaseEngineering[/*] Don't get me wrong, I don't want to be bitching all the time, I think that the merge is great, that having updates-testing and good QA is great too, actually in the past I've done updates where I wished I had an testing area to put them first (before actually pushing them, sofar in retrospective they all were fine) But going through updates testing for each and every bugfix / update is just adding unnecessary burden and delays. Why can't this just be left to the packagers discretion? I think I've done enough for Fedora to deserve some discretion. >> I'm very much against this, as it adds one more step to already long >> process of getting new packages in, the current wiki page describing the >> process divides it into 14 steps and it is lacking the add to comps step >> (and in my case the update SIG wiki pag, twice once to add it to the list >> of packages undergoing review, once more to remove). >> Please respond to this very imporant point! >> It removes much of the satisfaction of after completing the review having >> the package into the hands of the end users, the ones for which I do this. >> As it adds yet another delay. > > You can still get your new package into rawhide immediately (or rather with > the next rawhide push). There is instant satisfaction there. Bringing a > brand new package to a supposedly stable released platform should be done > with some caution and thought, and with letting a wider audience poke at it > first in updates-testing before letting it loose upon the masses. > 1) There will be no wide audience, even if they have updates-testing enabled they will not automatically install the new packages let alone use it, the only way to get a wide audience is to put it in updates and in comps, so that people can install it through "add/remove software". For the majority of users, if it isn't in comps it doesn't exist, since updates-testing has no comps *, the package doesn't exist and thus will not get tested. * and if it will, that means yet more work to get a package out >> The arguments made in favor of this is that it will be good for QA, however >> relatively few users will have updates testing enabled > > And your data set is where? Perhaps we should query Mike McGraths statistics > stuff to see how many unique IPs are hitting the mirror list for > updates-testing. It may be small, it may be large, but I'm not going to just > pull an observation out of my posterior. > I said relatively small, as compared to the total of Fedora users. You still do not seem to be getting the point, that the problem is that even if the new package is in updates-testing, it won't get installed let alone used all of a sudden. For all but the top 100 popular new packages, being in updates-testing thus adss no additional testing as no-one will install it. >> and new packages >> will not automatically get installed let alone used by those users. > > There is no reason why a QA team couldn't specifically target new packages to > the distribution as seen through updates-testing to ensure proper > functionality on a disparate set of hardware/software configurations. To > just blanket claim that it won't happen is laughable. We've never done this > for Extras, and in Core it was very very difficult to get approval to > introduce a new package. Lets give it a try and see what our growing QA team > can come up with to make it worth while. > Repeating myself, then first get such a QA time organized up and running and then, and only then, make updates-testing mandatory, if I get usefull feedback from this, you've won me over. But formulations like: "There is no reason why ...." to me actually read like: "today this serves no purpose other then to hinder you, but maybe in a future far away this will be actually usefull" Which results in me saying, fine, then when that future is upon us, do thinks like that, but not now. > That is if you even care about trying to maintain a stable release for users. > I know I do. > There is no reason to suggest that I do not promote stability, see my many attempts to start a bug fixing squad (not triaging but actual fixing) and my many offers of help with bugs. > *cough* The review is for rawhide, where the platform could be drastically > different than that of a stable tree. Just saying something worked on > rawhide and expecting it to work on previous release, or previous release -1 > is obtuse. > Not true many reviewers review on the latest stable, it says nowhere that a review should be done on rawhide. >> Yet another argument against making new-packages go through updates-testing >> is the fact that even if there were a QA team testing them, I wonder how >> they would test my latest batch of packages: >> avr-binutils >> avr-gcc >> avr-libc >> arm-gp2x-linux-kernel-headers >> arm-gp2x-linux-binutils >> arm-gp2x-linux-gcc >> arm-gp2x-linux-glibc >> >> Do they happen to have an avr microcontroller development kit handy for >> testing or a gp2x handheld? Any experience with programming those? >> >> Making package like these goto updates-testing is ridiculous. > > So you're using one corner case package set with a limited user base to throw > out the entire idea of getting some larger audience testing on new packages > to a stable release. Sounds like a great argument to me... > A niche package which requires specific domain knowledge to test is not a corner case, there are many many niche packages in Fedora and more being added every day. Also there is this thing called libraries, which cannot be tested without apps using them, but which very well can be packaged and published without apps, be it for future use by planned apps, or for use by some non Fedora distributabe apps. --- All I'm asking for is to leaving this to the packagers discretion, isn't Fedora supposed to be all about freedom? Then why put me in a straight jacket. Regards, Hans From twoerner at redhat.com Fri Jun 1 14:56:48 2007 From: twoerner at redhat.com (Thomas Woerner) Date: Fri, 01 Jun 2007 16:56:48 +0200 Subject: Firewall configuration tool: system-config-firewall In-Reply-To: <20070601144812.GJ23405@angus.ind.WPI.EDU> References: <46602E12.7080008@redhat.com> <20070601144812.GJ23405@angus.ind.WPI.EDU> Message-ID: <466033B0.1020004@redhat.com> Chuck Anderson wrote: > On Fri, Jun 01, 2007 at 04:32:50PM +0200, Thomas Woerner wrote: >> Hello, >> >> system-config-firewall is a new firewall configuration tool, which is >> based on system-config-securitylevel and provides enhanced funtionality >> and better user guidance. > > Does this one remember what I selected in it last time so I don't have > to remember to make the same selections again myself? > Yes, it is reusing the old configuration at the first start from /etc/sysconfig/system-config-securitylevel. If you apply your changes, it will write a new config file /etc/sysconfig/system-config-firewall. The old config file will not get modified. From j.w.r.degoede at hhs.nl Fri Jun 1 14:55:29 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 16:55:29 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <1180708585.3946.6.camel@zebes.localdomain> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <1180708585.3946.6.camel@zebes.localdomain> Message-ID: <46603361.2070507@hhs.nl> Will Woods wrote: > Let's be a little more clear here - what the QA team actually does for > packages in updates-testing is *verification*. Check package sanity, > make sure programs don't segfault on startup, etc. > > I'm not expecting all testers to understand the functions of the > packages as well as their maintainers. But anyone can tell if you missed > some deps or your package doesn't start on x86_64. > 1) I already verify my packages on x86_64 myself 2) starting libs is kinda hard 3) Most missing deps are subtile and do not necesarry show when just running an app It would be more usefull to check build-logs for things like: -suspicious ./configure failures (due to missing BuildRequires) -64 bit suspecious compiler output like cast from different size integer to pointer (this could actually be automated) Checking for 64 bit suspicious compiler warnings in my experience finds far more 64 bit bugs then just a quick test run, unless those 64 bit bugs happen to be in the straight quick test run path. Regards, Hans From twoerner at redhat.com Fri Jun 1 15:00:10 2007 From: twoerner at redhat.com (Thomas Woerner) Date: Fri, 01 Jun 2007 17:00:10 +0200 Subject: Firewall configuration tool: system-config-firewall In-Reply-To: <46602E12.7080008@redhat.com> References: <46602E12.7080008@redhat.com> Message-ID: <4660347A.7000808@redhat.com> There is one behaviour change in the gtk UI: If you disable the firewall and hit apply, the IPv4 and IPv6 firewall gets stopped. Then there is no firewall active anymore - your system is fully accessible. Thomas From sundaram at fedoraproject.org Fri Jun 1 15:02:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 20:32:06 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <46603203.3090001@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> Message-ID: <466034EE.3070004@fedoraproject.org> Hans de Goede wrote: >>> I'm very much against this, as it adds one more step to already long >>> process of getting new packages in, the current wiki page describing the >>> process divides it into 14 steps and it is lacking the add to comps step >>> (and in my case the update SIG wiki pag, twice once to add it to the >>> list >>> of packages undergoing review, once more to remove). >>> > > Please respond to this very imporant point! Adding that step in the wiki can be done by anyone and addition to help improve quality are a good thing. > 1) There will be no wide audience, even if they have updates-testing > enabled they will not automatically install the new packages let alone > use it, If the package has a small audience then surely it can wait for a limited timeout in updates-testing For all but the top 100 popular new > packages, being in updates-testing thus adss no additional testing as > no-one will install it. 100 is a purely arbitrary number. > Repeating myself, then first get such a QA time organized up and running > and then, and only then, make updates-testing mandatory, if I get > usefull feedback from this, you've won me over. If QA can be bypassed then that reduces the incentive to form the team in the first place. > > Not true many reviewers review on the latest stable, it says nowhere > that a review should be done on rawhide. Review is about guidelines and nowhere in the guideline does it even say that the fucntionality of the package should be tested. When I suggested that it be added I got back a knee jerk reaction to participate in reviews myself. > All I'm asking for is to leaving this to the packagers discretion, isn't > Fedora supposed to be all about freedom? Then why put me in a straight > jacket. It is not all about freedom though. There are several other factors that influence a decision. Rahul From nphilipp at redhat.com Fri Jun 1 15:02:56 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 01 Jun 2007 17:02:56 +0200 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180701939.3553.17.camel@dhcp83-186.boston.redhat.com> References: <1180639616.9513.4.camel@localhost.localdomain> <1180642169.9513.24.camel@localhost.localdomain> <1180646159.5761.54.camel@vader.jdub.homelinux.org> <1180646779.10152.0.camel@localhost.localdomain> <1180648995.5761.59.camel@vader.jdub.homelinux.org> <1180649583.3475.2.camel@localhost.localdomain> <1180701199.5761.62.camel@vader.jdub.homelinux.org> <1180701939.3553.17.camel@dhcp83-186.boston.redhat.com> Message-ID: <1180710176.3828.33.camel@gibraltar.stuttgart.redhat.com> On Fri, 2007-06-01 at 08:45 -0400, Matthias Clasen wrote: > On Fri, 2007-06-01 at 07:33 -0500, Josh Boyer wrote: > > On Thu, 2007-05-31 at 18:13 -0400, Matthias Clasen wrote: > > > On Thu, 2007-05-31 at 17:03 -0500, Josh Boyer wrote: > > > > > > > If you're referring to migrating Windows users, even they realize there > > > > is more than one program to accomplish the same task. Think of AIM, > > > > Trillian, ICQ, blah blah blah. Or McAfee vs. Symantec. Or IE vs. > > > > Firefox. Hell, even Microsoft doesn't label IE as "Web browser" (which > > > > is another bogosity we do but one thing at a time). > > > > > > How convenient that the desktop team can alternatively be slammed for > > > copying Windows or for failing to copy it... > > > > Wait a minute... I'm not slamming anyone. Nor did I alternate here.. > > (at least I don't think I did). > > > > I'm simply saying that including a program's name in the menu entry > > seems common sense to me. What I don't understand is your > > classification of "regular user" and why you think having the program's > > name in the menu entry is confusing to them. > > > > The program name in the menu doesn't help you make a choice unless you > know the programs by name. That was the argument for including "Firefox" > in the menu item even though Firefox is the default browser, because the > name is well-recognized even with people who don't spend a large > percentage of their life in front of a computer. Since x-chat doesn't > have the same "brand recognition" that firefox has, adding its name to > the menu does not help. > > Anyway, as Owen said, after the merge, and with the packaging guidelines > agitating for putting everything in the menus, organizing meaningful > menus is largely a lost cause, and we should concentrate on making > application browsing in bigboard work well instead. Perhaps the menu (whether gnome-panel or bigboard, I don't care) could do it like this: If there is only one type of $GenericName, display $GenericName, otherwise $Name and a set-off/smaller script/however distinguished $GenericName. Exceptions like e.g. Firefox, OOo could be flagged in the desktop file (e.g. "ShowNameOnly=true"). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From linux_4ever at yahoo.com Fri Jun 1 15:03:27 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 1 Jun 2007 08:03:27 -0700 (PDT) Subject: retiring gpg-pubkey packages Message-ID: <538877.88990.qm@web51501.mail.re2.yahoo.com> Hi, I was also looking over the "yum list extras" and noticed something. It ignores the gpg-pubkey packages. [root ~]# rpm -q gpg-pubkey gpg-pubkey-db42a60e-37ea5438 gpg-pubkey-731002fa-400b9109 gpg-pubkey-db42a60e-37ea5438 gpg-pubkey-4f2a6fd2-3f9d9d3b gpg-pubkey-1ac70ce6-41bebeef gpg-pubkey-db42a60e-37ea5438 Do we have any utility that identifies old keys that are no longer needed? Seems like you'd want to carry only the latest for security reasons. -Steve ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From jkeating at redhat.com Fri Jun 1 15:07:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 11:07:02 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <46603203.3090001@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> Message-ID: <200706011107.02464.jkeating@redhat.com> On Friday 01 June 2007 10:49:39 Hans de Goede wrote: > But going through updates testing for each and every bugfix / update is > just adding unnecessary burden and delays. Why can't this just be left to > the packagers discretion? I think I've done enough for Fedora to deserve > some discretion. This is a broader issue, but I don't think it's set in stone anywhere that every single update (or new package) has to go through updates-testing. We strongly encourage it and start throwing daggers if you don't do it and introduce issues on a stable platform, but I don't think there is anything physically stopping you from going straight to updates. > >> I'm very much against this, as it adds one more step to already long > >> process of getting new packages in, the current wiki page describing the > >> process divides it into 14 steps and it is lacking the add to comps step > >> (and in my case the update SIG wiki pag, twice once to add it to the > >> list of packages undergoing review, once more to remove). > > Please respond to this very imporant point! Um ok, yeah , adding software is a process. That sucks. Throwing out crap builds to users untested sucks too. > >> It removes much of the satisfaction of after completing the review > >> having the package into the hands of the end users, the ones for which I > >> do this. As it adds yet another delay. > > > > You can still get your new package into rawhide immediately (or rather > > with the next rawhide push). ?There is instant satisfaction there. > > ?Bringing a brand new package to a supposedly stable released platform > > should be done with some caution and thought, and with letting a wider > > audience poke at it first in updates-testing before letting it loose upon > > the masses. > > 1) There will be no wide audience, even if they have updates-testing > enabled they will not automatically install the new packages let alone use > it, the only way to get a wide audience is to put it in updates and in > comps, so that people can install it through "add/remove software". For the > majority of users, if it isn't in comps it doesn't exist, since > updates-testing has no comps *, the package doesn't exist and thus will not > get tested. That's just a simple matter of using the comps-f7.xml comps file when generating repodata for the Fedora 7 updates. Then suddenly you have entries in add/remove software for things in updates-testing. > * and if it will, that means yet more work to get a package out You should be adding the package to comps if it makes sense to have it in comps anyway, for each platform you'll build it for. > >> The arguments made in favor of this is that it will be good for QA, > >> however relatively few users will have updates testing enabled > > > > And your data set is where? ?Perhaps we should query Mike McGraths > > statistics stuff to see how many unique IPs are hitting the mirror list > > for updates-testing. ?It may be small, it may be large, but I'm not going > > to just pull an observation out of my posterior. > > I said relatively small, as compared to the total of Fedora users. You > still do not seem to be getting the point, that the problem is that even if > the new package is in updates-testing, it won't get installed let alone > used all of a sudden. For all but the top 100 popular new packages, being > in updates-testing thus adss no additional testing as no-one will install > it. That's simply a matter of gathering up a team of people or organizing 'new package frenzy' days to get sets of people to target NEW packages to existing releases for testing. > >> and new packages > >> will not automatically get installed let alone used by those users. > > > > There is no reason why a QA team couldn't specifically target new > > packages to the distribution as seen through updates-testing to ensure > > proper functionality on a disparate set of hardware/software > > configurations. ?To just blanket claim that it won't happen is laughable. > > ?We've never done this for Extras, and in Core it was very very difficult > > to get approval to introduce a new package. ?Lets give it a try and see > > what our growing QA team can come up with to make it worth while. > > Repeating myself, then first get such a QA time organized up and running > and then, and only then, make updates-testing mandatory, if I get usefull > feedback from this, you've won me over. But formulations like: "There is no > reason why ...." to me actually read like: "today this serves no purpose > other then to hinder you, but maybe in a future far away this will be > actually usefull" > > Which results in me saying, fine, then when that future is upon us, do > thinks like that, but not now. What do you think Will Woods is trying to do with his QA team? Only he's being met with vehement abuse and refusal to participate. > > > That is if you even care about trying to maintain a stable release for > > users. ? I know I do. > > There is no reason to suggest that I do not promote stability, see my many > attempts to start a bug fixing squad (not triaging but actual fixing) and > my many offers of help with bugs. > > > *cough* The review is for rawhide, where the platform could be > > drastically different than that of a stable tree. ?Just saying something > > worked on rawhide and expecting it to work on previous release, or > > previous release -1 is obtuse. > > Not true many reviewers review on the latest stable, it says nowhere that a > review should be done on rawhide. Yet the only place the package is allowed to go by default is rawhide, so it most certainly should be tested on rawhide. > > So you're using one corner case package set with a limited user base to > > throw out the entire idea of getting some larger audience testing on new > > packages to a stable release. ?Sounds like a great argument to me... > > A niche package which requires specific domain knowledge to test is not a > corner case, there are many many niche packages in Fedora and more being > added every day. Also there is this thing called libraries, which cannot be > tested without apps using them, but which very well can be packaged and > published without apps, be it for future use by planned apps, or for use by > some non Fedora distributabe apps. If you have a stack, the entire stack could be issued as an update at once (as soon as Luke gets that feature into Bodhi) so the entire stack can be tested at once. And there are going to be reasonable exceptions to the rule, I completely see this. However exceptions are not a reason to completely ignore the rule for every single package. > --- > > All I'm asking for is to leaving this to the packagers discretion, isn't > Fedora supposed to be all about freedom? Then why put me in a straight > jacket. Perhaps we have a communication issue. Can you show me where it is stated that every single new package absolutely must without any question go through updates-testing first, without exception? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Jun 1 15:06:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 17:06:44 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <466034EE.3070004@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> Message-ID: <46603604.6010706@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: > >>>> I'm very much against this, as it adds one more step to already long >>>> process of getting new packages in, the current wiki page describing >>>> the >>>> process divides it into 14 steps and it is lacking the add to comps >>>> step >>>> (and in my case the update SIG wiki pag, twice once to add it to the >>>> list >>>> of packages undergoing review, once more to remove). >>>> >> >> Please respond to this very imporant point! > > Adding that step in the wiki can be done by anyone and addition to help > improve quality are a good thing. > You know very well that I was not talking about the adding to the wiki, but about the to large number of steps needed to get a package in. >> 1) There will be no wide audience, even if they have updates-testing >> enabled they will not automatically install the new packages let alone >> use it, > > If the package has a small audience then surely it can wait for a > limited timeout in updates-testing > I'm not saying it has a small audience (it might) I'm saying that the cross-section of potential users and those with updates-testing enabled is most likely small. And for some reason nobody is responding to my point that when in updates-testing a package cannot be in comps and thus is invisible to those using the tools we advice them to use! >> Repeating myself, then first get such a QA time organized up and >> running and then, and only then, make updates-testing mandatory, if I >> get usefull feedback from this, you've won me over. > > If QA can be bypassed then that reduces the incentive to form the team > in the first place. I'm not saying QA should be bypassed, I'm saying that delaying packages for a week to allow testing by a non existent team is silly. >> >> Not true many reviewers review on the latest stable, it says nowhere >> that a review should be done on rawhide. > > Review is about guidelines and nowhere in the guideline does it even say > that the fucntionality of the package should be tested. When I suggested > that it be added I got back a knee jerk reaction to participate in > reviews myself. > Maybe that reaction was solicited because it seems that those making the rules seem to be disconnected from those doing the work? A typical case of manager syndrome. >> All I'm asking for is to leaving this to the packagers discretion, >> isn't Fedora supposed to be all about freedom? Then why put me in a >> straight jacket. > > It is not all about freedom though. There are several other factors that > influence a decision. > Factors such as? I thought freedom was the great good which we are all working for. Regards, Hans From wwoods at redhat.com Fri Jun 1 15:13:08 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 01 Jun 2007 11:13:08 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <46603361.2070507@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <1180708585.3946.6.camel@zebes.localdomain> <46603361.2070507@hhs.nl> Message-ID: <1180710788.3946.11.camel@zebes.localdomain> On Fri, 2007-06-01 at 16:55 +0200, Hans de Goede wrote: > Will Woods wrote: > > Let's be a little more clear here - what the QA team actually does for > > packages in updates-testing is *verification*. Check package sanity, > > make sure programs don't segfault on startup, etc. > > > > I'm not expecting all testers to understand the functions of the > > packages as well as their maintainers. But anyone can tell if you missed > > some deps or your package doesn't start on x86_64. > > > > 1) I already verify my packages on x86_64 myself Sure, and most maintainers do. And that's wonderful. It means that the QA process will be very fast: "Oh, look, one of Hans' packages! This will be easy!" [mere minutes pass, most of which is downloading the packages] "Yep, everything seems fine. That Hans is one great packager!" [QA approves package, rel-eng signs it, all is right with the world] So it really shouldn't slow *you* down much at all. But it should help catch packaging / build mistakes made by *others* before they make it into the repo. > 2) starting libs is kinda hard > 3) Most missing deps are subtile and do not necesarry show when just running an > app > > It would be more usefull to check build-logs for things like: > -suspicious ./configure failures (due to missing BuildRequires) > -64 bit suspecious compiler output like cast from different size integer to > pointer (this could actually be automated) > > Checking for 64 bit suspicious compiler warnings in my experience finds far > more 64 bit bugs then just a quick test run, unless those 64 bit bugs happen to > be in the straight quick test run path. These are excellent recommendations. I'll be sure to put 'em up on the QA pages when we start putting together our testing guidelines. Thanks! -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri Jun 1 15:16:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 20:46:42 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <46603604.6010706@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <46603604.6010706@hhs.nl> Message-ID: <4660385A.6040700@fedoraproject.org> Hans de Goede wrote: > > You know very well that I was not talking about the adding to the wiki, > but about the to large number of steps needed to get a package in. I honestly didnt know that very well. > And for some reason nobody is responding to my point that when in > updates-testing a package cannot be in comps and thus is invisible to > those using the tools we advice them to use! That's a problem that needs to fixed by adding packages to comps when necessary. > > I'm not saying QA should be bypassed, I'm saying that delaying packages > for a week to allow testing by a non existent team is silly. By calling the effort useless you making it come true. > Maybe that reaction was solicited because it seems that those making the > rules seem to be disconnected from those doing the work? A typical case > of manager syndrome. Testing for functionality is not desirable and shouldn't be in the review guidelines? > > Factors such as? I thought freedom was the great good which we are all > working for. http://fedoraproject.org/wiki/Objectives. There are factors like robustness in there. If freedom was the only factor we wouldn't have packaging guidelines which guide and therefore limit packagers freedom in many cases. Rahul From kevin.kofler at chello.at Fri Jun 1 15:19:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 15:19:35 +0000 (UTC) Subject: Don't put new packages through updates-testing References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <200706011107.02464.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > This is a broader issue, but I don't think it's set in stone anywhere that > every single update (or new package) has to go through updates-testing. We > strongly encourage it and start throwing daggers if you don't do it and > introduce issues on a stable platform, but I don't think there is anything > physically stopping you from going straight to updates. With the current Koji interface, that's a 2-step process, he'd have to request a push to updates-testing, wait for it to get committed by release engineering, and then request another push from updates-testing to updates. There isn't a way to bypass updates-testing entirely, except by abusing the "security" flag, which would certainly be frowned upon. ;-) > > Not true many reviewers review on the latest stable, it says nowhere that a > > review should be done on rawhide. > > Yet the only place the package is allowed to go by default is rawhide, so it > most certainly should be tested on rawhide. But the reality is that not all reviewers have a Rawhide system ready for testing. Moreover, the main part of reviewing is validating the guidelines, actually testing the package is only a "SHOULD" item (as is building in mock, only building in any way on any supported architecture is required: "- MUST: The package must successfully compile and build into binary rpms on at least one supported architecture."). Kevin Kofler From fedora at leemhuis.info Fri Jun 1 15:26:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 17:26:43 +0200 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <200706011011.22131.jkeating@redhat.com> References: <260130.53154.qm@web51510.mail.re2.yahoo.com> <200706011011.22131.jkeating@redhat.com> Message-ID: <46603AB3.1030507@leemhuis.info> On 01.06.2007 16:11, Jesse Keating wrote: > On Friday 01 June 2007 10:08:35 Steve G wrote: >> far simpler and no magic. > 'yum list extras' should show you packages you have installed that are not > available in any configured / enabled repo. $ package-cleanup --orphans does a better job afaics from looking at the output on my machine. package-cleanup is in yum-utils. Cu thl From dwmw2 at infradead.org Fri Jun 1 15:28:06 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 01 Jun 2007 16:28:06 +0100 Subject: Don't put new packages through updates-testing In-Reply-To: <46601BAF.8000507@hhs.nl> References: <46601BAF.8000507@hhs.nl> Message-ID: <1180711686.25232.17.camel@pmac.infradead.org> On Fri, 2007-06-01 at 15:14 +0200, Hans de Goede wrote: > arm-gp2x-linux-kernel-headers > arm-gp2x-linux-binutils > arm-gp2x-linux-gcc > arm-gp2x-linux-glibc How have you dealt with the dependencies between gcc, libgcc.a, glibc and libgcc.so to get gcc and glibc into separate packages? Please tell me you didn't throw them all into the same SRPM :) Are you using 'make headers_install' to get your kernel-headers? If not, please do. -- dwmw2 From rc040203 at freenet.de Fri Jun 1 14:35:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 16:35:42 +0200 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706011437.59049.opensource@till.name> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706010003.11844.opensource@till.name> <200705312344.11171.dennis@ausil.us> <200706011437.59049.opensource@till.name> Message-ID: <1180708542.12595.295.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 14:37 +0200, Till Maas wrote: > On Fr Juni 1 2007, Dennis Gilmore wrote: > > > sorry I should have put these up a week or so ago. Unfortunately i cant > > sign them as im only in the epel signing group. i really dont know what > > key they should be signed if they were. It is up there now. please let me > > The key that is used for Fedora Packages now is my favourite. Why are the rpms > not in the normal repository anyway? Then this problem would not exist. I had brought this topic up many months ago, but it was shot down by Jesse and Dennis. A real pity, IMO. I resorted to mirroring http://buildsys.fedoraproject.org/buildgroups into a local directory and use that instead for my local mock set ups. Ralf From rc040203 at freenet.de Fri Jun 1 14:38:01 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 16:38:01 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <200706011031.47164.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> Message-ID: <1180708682.12595.299.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 10:31 -0400, Jesse Keating wrote: > On Friday 01 June 2007 10:18:22 Ralf Corsepius wrote: > > It is, it demonstrates the flaw of your endeavor: > > No, it demonstrates an exception to the rule, which is completely acceptable. > What's not acceptable is to use an exception to discount the rule as a whole. You will never accept that "exceptions" always mean "lack of generality of the rules", i.e. brokenness. Ralf From jkeating at redhat.com Fri Jun 1 15:39:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 11:39:04 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <1180708542.12595.295.camel@mccallum.corsepiu.local> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706011437.59049.opensource@till.name> <1180708542.12595.295.camel@mccallum.corsepiu.local> Message-ID: <200706011139.04795.jkeating@redhat.com> On Friday 01 June 2007 10:35:42 Ralf Corsepius wrote: > I had brought this topic up many months ago, but it was shot down by > Jesse and Dennis. A real pity, IMO. We've obviated the need for buildsys-macros by having the definitions provided in it inside redhat-rpm-config. We could get rid of buildsys-build by making a perhaps 'hidden' group within comps that is the buildsys-build group, since mock can easily do a groupinstall instead of a package install to populate the buildroot. These two things together would obviate the need for a separate repo all together. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 1 15:47:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 21:17:09 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <1180708682.12595.299.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> Message-ID: <46603F7D.1050407@fedoraproject.org> Ralf Corsepius wrote: > On Fri, 2007-06-01 at 10:31 -0400, Jesse Keating wrote: >> On Friday 01 June 2007 10:18:22 Ralf Corsepius wrote: >>> It is, it demonstrates the flaw of your endeavor: >> No, it demonstrates an exception to the rule, which is completely acceptable. >> What's not acceptable is to use an exception to discount the rule as a whole. > You will never accept that "exceptions" always mean "lack of generality > of the rules", i.e. brokenness. Ironically, that might just be the worst generalization that I have ever heard. Rahul From jkeating at redhat.com Fri Jun 1 15:50:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 11:50:23 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <1180708682.12595.299.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> Message-ID: <200706011150.23233.jkeating@redhat.com> On Friday 01 June 2007 10:38:01 Ralf Corsepius wrote: > You will never accept that "exceptions" always mean "lack of generality > of the rules", i.e. brokenness. Man I wish I lived in a world where everything can be black/white. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Fri Jun 1 16:16:12 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 01 Jun 2007 12:16:12 -0400 Subject: Meaningless name In-Reply-To: <1180648995.5761.59.camel@vader.jdub.homelinux.org> References: <1180639616.9513.4.camel@localhost.localdomain> <1180642169.9513.24.camel@localhost.localdomain> <1180646159.5761.54.camel@vader.jdub.homelinux.org> <1180646779.10152.0.camel@localhost.localdomain> <1180648995.5761.59.camel@vader.jdub.homelinux.org> Message-ID: <4660464C.1090007@redhat.com> Josh Boyer wrote: > If you're referring to migrating Windows users, even they realize there > is more than one program to accomplish the same task. Think of AIM, > Trillian, ICQ, blah blah blah. Or McAfee vs. Symantec. Or IE vs. > Firefox. Hell, even Microsoft doesn't label IE as "Web browser" (which > is another bogosity we do but one thing at a time). But they chose "Internet Explorer" for the product name which is a very functional name, and IMO a much better name as it really does more than the web (FTP, etc). While the AIM product recently got renamed to AIM, it was initially AOL Instant Messenger. Instant Messenger, not Pigeon or some non-functional name that users wouldn't understand immediately. Norton Anti-Virus is another great example. McAfee VirusScan. The actual product names are all functional names. Don't confuse company branding with the product name. X-Chat is a product name and is not a functional name. From rc040203 at freenet.de Fri Jun 1 16:21:00 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 18:21:00 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46603F7D.1050407@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> <46603F7D.1050407@fedoraproject.org> Message-ID: <1180714860.12595.361.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 21:17 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Fri, 2007-06-01 at 10:31 -0400, Jesse Keating wrote: > >> On Friday 01 June 2007 10:18:22 Ralf Corsepius wrote: > >>> It is, it demonstrates the flaw of your endeavor: > >> No, it demonstrates an exception to the rule, which is completely acceptable. > >> What's not acceptable is to use an exception to discount the rule as a whole. > > You will never accept that "exceptions" always mean "lack of generality > > of the rules", i.e. brokenness. > > Ironically, that might just be the worst generalization that I have ever > heard. Nope, that's mathematics, get yourself a book on logic or similar ... Ralf From kevin.kofler at chello.at Fri Jun 1 16:20:55 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 16:20:55 +0000 (UTC) Subject: Meaningless name References: <1180639616.9513.4.camel@localhost.localdomain> <1180642169.9513.24.camel@localhost.localdomain> <1180646159.5761.54.camel@vader.jdub.homelinux.org> <1180646779.10152.0.camel@localhost.localdomain> <1180648995.5761.59.camel@vader.jdub.homelinux.org> <4660464C.1090007@redhat.com> Message-ID: Christopher Aillon redhat.com> writes: > X-Chat is a product name and is not a functional name. It contains "Chat", which is much more informative to an end user than the cryptic "IRC" abbreviation. :-) But even if it didn't, I'd still believe the actual name should go in the Name field. Kevin Kofler From caillon at redhat.com Fri Jun 1 16:21:24 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 01 Jun 2007 12:21:24 -0400 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <45365.29376.qm@web51512.mail.re2.yahoo.com> References: <45365.29376.qm@web51512.mail.re2.yahoo.com> Message-ID: <46604784.6080202@redhat.com> Steve G wrote: >>Fedora maintainers have not rebuilt these packages for Fedora 7 >>to avoid making end users download the packages for only a release tag >>change. > > This is bull. Most people download an iso which contains the old version. IOW, > you download it *anyways*. The only people this might help is rawhide users and > people updating via yum - which if I recall, is not officially supported. I'd > like to see this policy changed in F8 so that admins/users can spot failed > upgrades or orphaned packages. That is far greater value than saying its to save > bandwidth when it doesn't. Actually, many people do network installs. I have no DVD burner so the DVD ISO does me no good. So I downloaded the boot.iso to load up anaconda, and pointed the installer at the right places on the network. Much less downloading as you only update what you need. From blc at redhat.com Fri Jun 1 16:27:57 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 01 Jun 2007 10:27:57 -0600 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1180660510.26803.592.camel@pmac.infradead.org> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <7dd7ab490705291600x633a3452w85d9275ea662fbf9@mail.gmail.com> <1180516024.26803.87.camel@pmac.infradead.org> <20070530092348.GN4033@devserv.devel.redhat.com> <465F6AB7.8080604@redhat.com> <1180660510.26803.592.camel@pmac.infradead.org> Message-ID: <4660490D.9020902@redhat.com> David Woodhouse wrote: > On Thu, 2007-05-31 at 18:39 -0600, Brendan Conoboy wrote: >> Or cross builds. It would *really* make bootstrapping a new >> architecture easier if we had this ability. > > It's hard. When I tried cross-building for ARM and SH a long time ago, I > ran into many problems, mostly with autotools. It requires some small modifications to most packages. In a lot of cases, it's simply improper use of the autotools (Looking for files in absolute paths instead of using the compiler, or running an executable to test for functionality instead of trusting headers, etc). > The only really reliable solution I see would be full-system emulation. > Which isn't always much faster than the real hardware, unfortunately. Full system emulation is wrong for a number of reasons, performance is just one of them. It requires fully functional emulators as a pre-requisite to building for the architecture, which is uncertain and unlikely. What do you mean by reliable? Once a package is setup to work in a cross environment, it builds quite reliably. The main overhead is in getting the packages to be cross friendly in the first place. Most autotools programs already are and they just don't know it. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From sundaram at fedoraproject.org Fri Jun 1 16:43:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 22:13:54 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <1180714860.12595.361.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> <46603F7D.1050407@fedoraproject.org> <1180714860.12595.361.camel@mccallum.corsepiu.local> Message-ID: <46604CCA.8030907@fedoraproject.org> Ralf Corsepius wrote: > On Fri, 2007-06-01 at 21:17 +0530, Rahul Sundaram wrote: >> Ralf Corsepius wrote: >>> On Fri, 2007-06-01 at 10:31 -0400, Jesse Keating wrote: >>>> On Friday 01 June 2007 10:18:22 Ralf Corsepius wrote: >>>>> It is, it demonstrates the flaw of your endeavor: >>>> No, it demonstrates an exception to the rule, which is completely acceptable. >>>> What's not acceptable is to use an exception to discount the rule as a whole. >>> You will never accept that "exceptions" always mean "lack of generality >>> of the rules", i.e. brokenness. >> Ironically, that might just be the worst generalization that I have ever >> heard. > Nope, that's mathematics, get yourself a book on logic or similar ... Exceptions does not mean brokenness. Mathematics has nothing to do with your drama. Rahul From jspaleta at gmail.com Fri Jun 1 16:52:51 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 08:52:51 -0800 Subject: Don't put new packages through updates-testing In-Reply-To: <1180714860.12595.361.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> <46603F7D.1050407@fedoraproject.org> <1180714860.12595.361.camel@mccallum.corsepiu.local> Message-ID: <604aa7910706010952i6906466eo934d57c644bd714@mail.gmail.com> On 6/1/07, Ralf Corsepius wrote: > Nope, that's mathematics, get yourself a book on logic or similar ... Rigorous mathematical logic analysis is an extremely poor toolset to bring to bear on human designed policy structures.... my wife reaffirms that for me quite often when I attempt to use the strictures of logic to understand the decision making processes she is using. So in the context of this discussion, I think Rahul's reaction isn't so much out of place. So while the generalization is very much an important and fundamental concept that I'm sure Rahul is aware of, its not really applicable in this discussion. A discussion much more suited for application of statistical concepts and metrics than absolute rigor. -jef"A non-zero variance does not mean your mean is unmeaningful"spaleta From j.w.r.degoede at hhs.nl Fri Jun 1 16:57:03 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 18:57:03 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <1180711686.25232.17.camel@pmac.infradead.org> References: <46601BAF.8000507@hhs.nl> <1180711686.25232.17.camel@pmac.infradead.org> Message-ID: <46604FDF.7090700@hhs.nl> David Woodhouse wrote: > On Fri, 2007-06-01 at 15:14 +0200, Hans de Goede wrote: >> arm-gp2x-linux-kernel-headers >> arm-gp2x-linux-binutils >> arm-gp2x-linux-gcc >> arm-gp2x-linux-glibc > > How have you dealt with the dependencies between gcc, libgcc.a, glibc > and libgcc.so to get gcc and glibc into separate packages? Please tell > me you didn't throw them all into the same SRPM :) > Yes I have seperate packages, my gcc spec file has a bootstrap %define, which when true drags in glibc only todo a ./configure ....; make headers-install in the glibc dir, so that I have headers to build gcc against. When bootstrap == 0 an arm-gp2x-linux-glibc package is build-required and used (although as I type this I wonder if this is true, or if when compiling gcc it uses the native headers instead?? Hmm need to check). > Are you using 'make headers_install' to get your kernel-headers? If not, > please do. > Erm, I'm using a prebuild kernel-headers tarbal which is used by pld for cross compilers and which is used in the compile from source sdk's currently available from the gp2x community. Please see: http://people.atrpms.net/~hdegoede/ For the srpms and specs, any feedback much appreciated! arm-gp2x-linux-binutils has already been submitted for review (you want the 2.16.1 version, using 2.17 for gp2x was a bad idea), I'm planning on submitting the rest tonight (I'm all done, I just need to fill in the review form) I'm pretty new to all this cross compile stuff (sofar I've only used cross toolchains not build them myself) so I think those specs could really use a good look over, as said already any feedback is much appreciated! Regards, Hans From tonynelson at georgeanelson.com Fri Jun 1 17:08:35 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 1 Jun 2007 13:08:35 -0400 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <46603AB3.1030507@leemhuis.info> References: <260130.53154.qm@web51510.mail.re2.yahoo.com> <200706011011.22131.jkeating@redhat.com> <46603AB3.1030507@leemhuis.info> Message-ID: At 5:26 PM +0200 6/1/07, Thorsten Leemhuis wrote: >On 01.06.2007 16:11, Jesse Keating wrote: >> On Friday 01 June 2007 10:08:35 Steve G wrote: >>> far simpler and no magic. >> 'yum list extras' should show you packages you have installed that are not >> available in any configured / enabled repo. > >$ package-cleanup --orphans > >does a better job afaics from looking at the output on my machine. >package-cleanup is in yum-utils. Here I get the same items output, though the package-cleanup output is not sorted. -- ____________________________________________________________________ TonyN.:' ' From buildsys at fedoraproject.org Fri Jun 1 17:12:43 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 1 Jun 2007 13:12:43 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-01 Message-ID: <20070601171243.C25A3152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 5 Democracy-0.9.5.1-6.fc6 mod_nss-1.0.7-1.fc6 (!) perl-Crypt-OpenSSL-X509-0.4-3.fc6 : INVALID rebuild, not published! perl-JSON-XS-1.22-1.fc6 phpPgAdmin-4.1.2-1.fc6 Changes in Fedora Extras 6: Democracy-0.9.5.1-6.fc6 ----------------------- * Tue May 01 2007 Thorsten Scherf 0.9.5.1-6 - new firefox req mod_nss-1.0.7-1.fc6 ------------------- * Fri Jun 01 2007 Rob Crittenden 1.0.7-1 - Update to 1.0.7 - Remove Requires for nss and nspr since those are handled automatically by versioned libraries - Updated URL and Source to reference directory.fedoraproject.org * Mon Apr 09 2007 Rob Crittenden 1.0.6-2 - Patch to properly detect the Apache model and set up NSS appropriately - Patch to punt if a bad password is encountered - Patch to fix crash when password.conf is malformatted - Don't enable ECC support as NSS doesn't have it enabled (3.11.4-0.7) perl-Crypt-OpenSSL-X509-0.4-3.fc6 --------------------------------- * Mon May 14 2007 Wes Hardaker - 0.4-3 - BuildRequire perl(Test::More) perl(Test::Pod) - Fixed source code URL perl-JSON-XS-1.22-1.fc6 ----------------------- * Fri Jun 01 2007 Chris Weyl 1.22-1 - update to 1.22 phpPgAdmin-4.1.2-1.fc6 ---------------------- * Fri Jun 01 2007 Devrim Gunduz 4.1.2-1 - Update to 4.1.2 - Fix for Red Hat Bugzilla #241489 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jspaleta at gmail.com Fri Jun 1 17:22:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 09:22:48 -0800 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] Message-ID: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> On 6/1/07, Christopher Aillon wrote: > Actually, many people do network installs. I have no DVD burner so the > DVD ISO does me no good. So I downloaded the boot.iso to load up > anaconda, and pointed the installer at the right places on the network. > Much less downloading as you only update what you need. For people who do network based upgrades/re-installs...... would it be feasible, and appropriate to provide a package in the F7 repo which contained the F8 installer image as a grub entry for an F7 system at the time of F8 release. So people could install that and reboot into the installer via their grub menu and do an upgrade via the installer.. instead of being tempted to do a live upgrade just with yum. Clever monkeys can do this manually now with some effort to pull the installer image from the iso. The question is, does it make sense to make this easier for the general userbase and provide a package in a timely manner into F7 for the F8 release? -jef From ben.lewis at benl.co.uk Fri Jun 1 17:25:22 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Fri, 01 Jun 2007 18:25:22 +0100 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> Message-ID: <46605682.5000706@benl.co.uk> Jeff Spaleta wrote: > On 6/1/07, Christopher Aillon wrote: >> Actually, many people do network installs. I have no DVD burner so the >> DVD ISO does me no good. So I downloaded the boot.iso to load up >> anaconda, and pointed the installer at the right places on the network. >> Much less downloading as you only update what you need. > > For people who do network based upgrades/re-installs...... > would it be feasible, and appropriate to provide a package in the F7 > repo which contained the F8 installer image as a grub entry for an F7 > system at the time of F8 release. So people could install that and > reboot into the installer via their grub menu and do an upgrade via > the installer.. instead of being tempted to do a live upgrade just > with yum. Clever monkeys can do this manually now with some effort to > pull the installer image from the iso. The question is, does it make > sense to make this easier for the general userbase and provide a > package in a timely manner into F7 for the F8 release? > > -jef I kind of like this as an idea! My only concern is that people will use this to do ftp installs off the mirrors - which is a bad as yum really. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From jwboyer at jdub.homelinux.org Fri Jun 1 17:25:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 01 Jun 2007 12:25:48 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: <46603604.6010706@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <46603604.6010706@hhs.nl> Message-ID: <1180718749.5761.74.camel@vader.jdub.homelinux.org> On Fri, 2007-06-01 at 17:06 +0200, Hans de Goede wrote: > > If QA can be bypassed then that reduces the incentive to form the team > > in the first place. > > I'm not saying QA should be bypassed, I'm saying that delaying packages for a > week to allow testing by a non existent team is silly. I said this before, but it is _at most_ a week. Since we have no experience with this yet we can't say for sure, but the actual turn around time for things that _get comments_ on the updates-testing in bodhi will likely go much sooner than a week. > >> All I'm asking for is to leaving this to the packagers discretion, > >> isn't Fedora supposed to be all about freedom? Then why put me in a > >> straight jacket. > > > > It is not all about freedom though. There are several other factors that > > influence a decision. > > > > Factors such as? I thought freedom was the great good which we are all working for. Factors such as end user stability. Users don't exist to serve packagers. It's the other way around. josh From wwoods at redhat.com Fri Jun 1 17:37:20 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 01 Jun 2007 13:37:20 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <46605682.5000706@benl.co.uk> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> Message-ID: <1180719440.3946.39.camel@zebes.localdomain> On Fri, 2007-06-01 at 18:25 +0100, Benjamin Lewis wrote: > Jeff Spaleta wrote: > > On 6/1/07, Christopher Aillon wrote: > >> Actually, many people do network installs. I have no DVD burner so the > >> DVD ISO does me no good. So I downloaded the boot.iso to load up > >> anaconda, and pointed the installer at the right places on the network. > >> Much less downloading as you only update what you need. > > > > For people who do network based upgrades/re-installs...... > > would it be feasible, and appropriate to provide a package in the F7 > > repo which contained the F8 installer image as a grub entry for an F7 > > system at the time of F8 release. So people could install that and > > reboot into the installer via their grub menu and do an upgrade via > > the installer.. instead of being tempted to do a live upgrade just > > with yum. Clever monkeys can do this manually now with some effort to > > pull the installer image from the iso. The question is, does it make > > sense to make this easier for the general userbase and provide a > > package in a timely manner into F7 for the F8 release? > > > > -jef > I kind of like this as an idea! My only concern is that people will use > this to do ftp installs off the mirrors - which is a bad as yum really. "bad" in what sense? It's hard on mirror bandwidth, and that's bad, but it's not as likely to hose your system as a yum-upgrade would be. I've also been pondering what anaconda work would be needed to do system upgrades from the hard drive you're upgrading - assuming you have the free space on your drive, you could do something like: Start "live-updater" tool - Checks installed packages, as anaconda does - Downloads all updated packages - (Alternately: use a DVD iso and it would only download the packages you're missing.) - Grab kernel/initrd (from mirror or DVD iso) - update grub.conf, adding special flag(s) for anaconda Reboot into anaconda - Upgrade filesystems, perform other fixups that require unmounted fs - Mount target filesystem label - Upgrade using previously-downloaded packages / iso image The downside is that it requires a few gigs of free drive space, but on the plus side we don't need a separate partition for holding the updates. A sneaky thing we might do is: 1) download all packages 2) swapoff 3) mkfs.ext3 $SWAP_PARTITION 4) mount $SWAP_PARTITION /mnt/swap 5) copy all packages to /mnt/swap 6) get vmlinuz/initrd and update grubby 7) reboot into anaconda, upgrading from $SWAP_PARTITION Just a thought. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Fri Jun 1 17:44:26 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 01 Jun 2007 18:44:26 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <4660490D.9020902@redhat.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <7dd7ab490705291600x633a3452w85d9275ea662fbf9@mail.gmail.com> <1180516024.26803.87.camel@pmac.infradead.org> <20070530092348.GN4033@devserv.devel.redhat.com> <465F6AB7.8080604@redhat.com> <1180660510.26803.592.camel@pmac.infradead.org> <4660490D.9020902@redhat.com> Message-ID: <1180719866.25232.36.camel@pmac.infradead.org> On Fri, 2007-06-01 at 10:27 -0600, Brendan Conoboy wrote: > What do you mean by reliable? Once a package is setup to work in a > cross environment, it builds quite reliably. ...until the next time it gets broken by an uncaring upstream :) I just mean that I gave up on it, because I was seeing too many failures -- some of which didn't show up until you exercise some esoteric code path in the resulting binary. I wouldn't personally be happy to release cross-compiled stuff and call it 'Fedora'. -- dwmw2 From ben.lewis at benl.co.uk Fri Jun 1 17:45:57 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Fri, 01 Jun 2007 18:45:57 +0100 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180719440.3946.39.camel@zebes.localdomain> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> Message-ID: <46605B55.4020308@benl.co.uk> Will Woods wrote: > On Fri, 2007-06-01 at 18:25 +0100, Benjamin Lewis wrote: > >> Jeff Spaleta wrote: >> >>> On 6/1/07, Christopher Aillon wrote: >>> >>>> Actually, many people do network installs. I have no DVD burner so the >>>> DVD ISO does me no good. So I downloaded the boot.iso to load up >>>> anaconda, and pointed the installer at the right places on the network. >>>> Much less downloading as you only update what you need. >>>> >>> For people who do network based upgrades/re-installs...... >>> would it be feasible, and appropriate to provide a package in the F7 >>> repo which contained the F8 installer image as a grub entry for an F7 >>> system at the time of F8 release. So people could install that and >>> reboot into the installer via their grub menu and do an upgrade via >>> the installer.. instead of being tempted to do a live upgrade just >>> with yum. Clever monkeys can do this manually now with some effort to >>> pull the installer image from the iso. The question is, does it make >>> sense to make this easier for the general userbase and provide a >>> package in a timely manner into F7 for the F8 release? >>> >>> -jef >>> >> I kind of like this as an idea! My only concern is that people will use >> this to do ftp installs off the mirrors - which is a bad as yum really. >> > > "bad" in what sense? It's hard on mirror bandwidth, and that's bad, but > it's not as likely to hose your system as a yum-upgrade would be. > > I've also been pondering what anaconda work would be needed to do system > upgrades from the hard drive you're upgrading - assuming you have the > free space on your drive, you could do something like: > sorry, ambiguous - I meant bad as in bandwidth, not as in yum eating your system alive (which I've done at least twice) > Start "live-updater" tool > - Checks installed packages, as anaconda does > - Downloads all updated packages > - (Alternately: use a DVD iso and it would only > download the packages you're missing.) > - Grab kernel/initrd (from mirror or DVD iso) > - update grub.conf, adding special flag(s) for anaconda > Reboot into anaconda > - Upgrade filesystems, perform other fixups that require unmounted fs > - Mount target filesystem label > - Upgrade using previously-downloaded packages / iso image > > The downside is that it requires a few gigs of free drive space, but on > the plus side we don't need a separate partition for holding the > updates. > > A sneaky thing we might do is: > > 1) download all packages > 2) swapoff > 3) mkfs.ext3 $SWAP_PARTITION > 4) mount $SWAP_PARTITION /mnt/swap > 5) copy all packages to /mnt/swap > 6) get vmlinuz/initrd and update grubby > 7) reboot into anaconda, upgrading from $SWAP_PARTITION > > Just a thought. > > -w > I prefer the second option, provided the machine has the ram to run without swap. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From katzj at redhat.com Fri Jun 1 17:43:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 01 Jun 2007 13:43:32 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> Message-ID: <1180719812.14463.4.camel@aglarond.local> (I feel like I was just in the middle of a thread just like this within the past couple of days...) On Fri, 2007-06-01 at 09:22 -0800, Jeff Spaleta wrote: > On 6/1/07, Christopher Aillon wrote: > > Actually, many people do network installs. I have no DVD burner so the > > DVD ISO does me no good. So I downloaded the boot.iso to load up > > anaconda, and pointed the installer at the right places on the network. > > Much less downloading as you only update what you need. > > For people who do network based upgrades/re-installs...... > would it be feasible, and appropriate to provide a package in the F7 > repo which contained the F8 installer image as a grub entry for an F7 > system at the time of F8 release. So people could install that and > reboot into the installer via their grub menu and do an upgrade via > the installer.. Better even than having the installer image, just package up a script (or even simple pygtk app) that asks where you're wanting to upgrade from and then downloads the kernel + initrd from there and does the rest. This makes things far more general and more likely to work with, eg, Unity respins, custom distros, etc. Jeremy From jspaleta at gmail.com Fri Jun 1 17:55:08 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 09:55:08 -0800 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <46605682.5000706@benl.co.uk> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> Message-ID: <604aa7910706011055i3dbe3a45l97056bdd7172e9be@mail.gmail.com> On 6/1/07, Benjamin Lewis wrote: > I kind of like this as an idea! My only concern is that people will use > this to do ftp installs off the mirrors - which is a bad as yum really. Anyone who is going to prefer an ftp install from a public mirror already has the ability to pull the modest sized boot.iso or the rescuecd and go to town. The smart monkeys, like me, will make sure they have a local mirror to pull from (nfs installs rock!). All this does is make it easier for people who do not have a dvd writer to do something useful with as minimum of effort as necessary without resorting to attempting a live upgrade via yum. With additional options in the grub entry vnc can be enabled and this could even be a viable upgrade/re-install path for people with headless or remote installs... the people who currently reach for yum when they shouldn't. -jef"Never ever does a network install/upgrade from a mirror across the public network due to concerns over network reliability for the length of the install time"spaleta From walters at redhat.com Fri Jun 1 01:35:33 2007 From: walters at redhat.com (Colin Walters) Date: Thu, 31 May 2007 21:35:33 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180719440.3946.39.camel@zebes.localdomain> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> Message-ID: <1180661733.28298.15.camel@neutron> On Fri, 2007-06-01 at 13:37 -0400, Will Woods wrote: > Start "live-updater" tool > - Checks installed packages, as anaconda does > - Downloads all updated packages > - (Alternately: use a DVD iso and it would only I wouldn't even make it a tool you manually start - integrate into the pirut update mode so when the next version of Fedora comes out, you get a notification and it offers to start downloading it in the background. (I also think pirut should be downloading regular updates in the background instead of a window) > download the packages you're missing.) > - Grab kernel/initrd (from mirror or DVD iso) > - update grub.conf, adding special flag(s) for anaconda > Reboot into anaconda > - Upgrade filesystems, perform other fixups that require unmounted fs > - Mount target filesystem label > - Upgrade using previously-downloaded packages / iso image > > The downside is that it requires a few gigs of free drive space, A few gigs? Couldn't we download just a CD size image? I think it's kind of silly that Fedora makes DVD images so prominent in the download page - who actually wants to download *everything*? I know I sure don't want GNOME+KDE+XFCE for example. The live CD images are much nicer. Now, handing out DVDs works well at conferences or between friends, but I think these are a pretty small percentage of the way Fedora is distributed. Also if someone picks this up, I would try hard to make it something scriptable so a regression tester can try periodic upgrades during the development process and see how they go. (Recently become a fan of writing tests as early as possible again =)) From jspaleta at gmail.com Fri Jun 1 17:59:07 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 09:59:07 -0800 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180719812.14463.4.camel@aglarond.local> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180719812.14463.4.camel@aglarond.local> Message-ID: <604aa7910706011059s6076d0bfh19cb30702d0754a@mail.gmail.com> On 6/1/07, Jeremy Katz wrote: > Better even than having the installer image, just package up a script > (or even simple pygtk app) that asks where you're wanting to upgrade > from and then downloads the kernel + initrd from there and does the > rest. This makes things far more general and more likely to work with, > eg, Unity respins, custom distros, etc. whatever works. The goal here is to give people a better solution than just a live yum upgrade, when they feel they can't use the iso based images directly. People without dvd burners, remote/headless. In fact a UI'd script would be very useful, so you can give people a configuration dialog and ask them to turn on optional things like vnc support if they want it. -jef From wwoods at redhat.com Fri Jun 1 18:13:29 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 01 Jun 2007 14:13:29 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180661733.28298.15.camel@neutron> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> <1180661733.28298.15.camel@neutron> Message-ID: <1180721609.3946.51.camel@zebes.localdomain> On Thu, 2007-05-31 at 21:35 -0400, Colin Walters wrote: > On Fri, 2007-06-01 at 13:37 -0400, Will Woods wrote: > > > Start "live-updater" tool > > - Checks installed packages, as anaconda does > > - Downloads all updated packages > > - (Alternately: use a DVD iso and it would only > > I wouldn't even make it a tool you manually start - integrate into the > pirut update mode so when the next version of Fedora comes out, you get > a notification and it offers to start downloading it in the background. > (I also think pirut should be downloading regular updates in the > background instead of a window) I thought yum-updatesd had a flag to download updates in the background but I might be mistaken about that.. But yeah, having this integrated into puplet/pirut *would* be extra-cool. > > The downside is that it requires a few gigs of free drive space, > > A few gigs? Couldn't we download just a CD size image? I think it's > kind of silly that Fedora makes DVD images so prominent in the download > page - who actually wants to download *everything*? I know I sure don't > want GNOME+KDE+XFCE for example. Right, but assuming that you installed a fairly standard package set you'd still have to download upgrades for all those packages on your system. If you installed 2 CDs worth of packages initially you're gonna need to download 2 CDs worth of updates to your hard drive - that's 1-2GB of free space you'll need to hold the packages. Plus extra space for actually performing the updates. So.. a couple gigs of free drive space is needed for temporary storage of updates. > Also if someone picks this up, I would try hard to make it something > scriptable so a regression tester can try periodic upgrades during the > development process and see how they go. (Recently become a fan of > writing tests as early as possible again =)) Oh definitely. In fact, that's the main reason *I* care about this feature. Live-ish upgrades would be a cool feature and save our users some time, but making system upgrades easier to script is the icing on the cake for me. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Fri Jun 1 18:14:43 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 01 Jun 2007 12:14:43 -0600 Subject: Feature idea: network based livecd installer Message-ID: <46606213.5020505@cora.nwra.com> Inspired by Jeff's post - I'm really impressed with the install speed of the LiveCD installer. What I'd like to be able to do is to essentially do the same thing over the network - pxeboot into an environment that can pull the LiveCD image of the network and install onto the local harddrive. I really haven't had a chance to look closely at what's involved though. Seem possible? I'm really disappointed with the speed of installs lately and looking to speed things up. We do a lot of identical installs here and it would be nice to do the depsolving/filesystem creation on a fast server and then just dump it onto the client. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From nicolas.mailhot at laposte.net Fri Jun 1 17:36:54 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 01 Jun 2007 19:36:54 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <200706011150.23233.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> <200706011150.23233.jkeating@redhat.com> Message-ID: <1180719414.9688.1.camel@rousalka.dyndns.org> Le vendredi 01 juin 2007 ? 11:50 -0400, Jesse Keating a ?crit : > On Friday 01 June 2007 10:38:01 Ralf Corsepius wrote: > > You will never accept that "exceptions" always mean "lack of generality > > of the rules", i.e. brokenness. > > Man I wish I lived in a world where everything can be black/white. Looks dangerous ? do you think your shade of gray would end up on the white side every time? -- 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 jspaleta at gmail.com Fri Jun 1 18:18:35 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 10:18:35 -0800 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180710176.3828.33.camel@gibraltar.stuttgart.redhat.com> References: <1180642169.9513.24.camel@localhost.localdomain> <1180646159.5761.54.camel@vader.jdub.homelinux.org> <1180646779.10152.0.camel@localhost.localdomain> <1180648995.5761.59.camel@vader.jdub.homelinux.org> <1180649583.3475.2.camel@localhost.localdomain> <1180701199.5761.62.camel@vader.jdub.homelinux.org> <1180701939.3553.17.camel@dhcp83-186.boston.redhat.com> <1180710176.3828.33.camel@gibraltar.stuttgart.redhat.com> Message-ID: <604aa7910706011118y5f34a918n3c5d516ab6b053a2@mail.gmail.com> On 6/1/07, Nils Philippsen wrote: > Perhaps the menu (whether gnome-panel or bigboard, I don't care) could > do it like this: If there is only one type of $GenericName, display > $GenericName, otherwise $Name and a set-off/smaller script/however > distinguished $GenericName. Exceptions like e.g. Firefox, OOo could be > flagged in the desktop file (e.g. "ShowNameOnly=true"). +1 That would solve the usage cases within my own experience where this matters at all. -jef From bruno at wolff.to Fri Jun 1 15:32:36 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 1 Jun 2007 10:32:36 -0500 Subject: Fedora 8 Schedule In-Reply-To: References: <1180634839.3572.14.camel@dhollis-lnx.sunera.com> <465F159E.9080005@fedoraproject.org> <465F1645.2000005@fedoraproject.org> <465F16EA.3020902@fedoraproject.org> <20070531223421.GA9934@orient.maison.lan> <20070601123753.6b420b10@banea.int.addix.net> <20070601121738.GA13905@orient.maison.lan> Message-ID: <20070601153236.GA13601@wolff.to> On Fri, Jun 01, 2007 at 14:46:58 +0200, Frank Schmitt wrote: > Emmanuel Seyman writes: > > > * Ralf Ertzinger [01/06/2007 14:06] : > >> > >> On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: > >> > >> > Then again, neither does Fedora 7's name. > >> > >> There was a full moon yesterday. > > > > Not the first explanation that sprang to my mind while reading the release > > announcement, to be honest. > > Could someone enlighten a stupid German? Moonshine is distilled alcohol made without an OK from the government. From pemboa at gmail.com Fri Jun 1 18:28:57 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 1 Jun 2007 14:28:57 -0400 Subject: Fedora 8 Schedule In-Reply-To: <20070601153236.GA13601@wolff.to> References: <465F159E.9080005@fedoraproject.org> <465F1645.2000005@fedoraproject.org> <465F16EA.3020902@fedoraproject.org> <20070531223421.GA9934@orient.maison.lan> <20070601123753.6b420b10@banea.int.addix.net> <20070601121738.GA13905@orient.maison.lan> <20070601153236.GA13601@wolff.to> Message-ID: <16de708d0706011128g11a83232h90fc4be3e2001733@mail.gmail.com> On 6/1/07, Bruno Wolff III wrote: > On Fri, Jun 01, 2007 at 14:46:58 +0200, > Frank Schmitt wrote: > > Emmanuel Seyman writes: > > > > > * Ralf Ertzinger [01/06/2007 14:06] : > > >> > > >> On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: > > >> > > >> > Then again, neither does Fedora 7's name. > > >> > > >> There was a full moon yesterday. > > > > > > Not the first explanation that sprang to my mind while reading the release > > > announcement, to be honest. > > > > Could someone enlighten a stupid German? > > Moonshine is distilled alcohol made without an OK from the government. Think of moonshine as marijuana and "legal alcohol" as tobacco. -- Fedora Core 6 and proud From rrelyea at redhat.com Fri Jun 1 18:35:46 2007 From: rrelyea at redhat.com (Robert Relyea) Date: Fri, 01 Jun 2007 11:35:46 -0700 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <1180706228.3828.17.camel@gibraltar.stuttgart.redhat.com> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> <1180706228.3828.17.camel@gibraltar.stuttgart.redhat.com> Message-ID: <46606702.7050302@REDHAT.COM> Nils Philippsen wrote: > > IMO, to make setting this automatically sensible and reliable, you'd > have to have some things first: > > - a freely available mapping between "position on earth" and the > corresponding timezone that's kept up to date > - an attached GPS receiver that can be read from Linux > No need for a gps. If the network is configured... http://www.networldmap.com/TryIt.htm Google for 'ip location' for a whole slew of them (each varies in quality, none got my location, but most were accurate enough to get my time zone). If it's even 90% correct it will greatly reduce the number of people who have to manually adjust their timezone). The question is can we find/create an freely available database so we can put up our own server. bob > Just the first one makes this a no-go, I haven't been able to dig up > something like this. I couldn't even find a freely available, > machine-readable coarse map of timezones. > > Nils > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3420 bytes Desc: S/MIME Cryptographic Signature URL: From gunchev at gmail.com Fri Jun 1 18:54:13 2007 From: gunchev at gmail.com (Doncho N. Gunchev) Date: Fri, 1 Jun 2007 21:54:13 +0300 Subject: Fedora 8 Schedule In-Reply-To: <16de708d0706010553y31ad2d9are2fa95c04296639b@mail.gmail.com> References: <16de708d0706010553y31ad2d9are2fa95c04296639b@mail.gmail.com> Message-ID: <200706012154.13871.gunchev@gmail.com> On Friday 2007-06-01 15:53:58 Arthur Pemberton wrote: > On 6/1/07, Frank Schmitt wrote: > > Emmanuel Seyman writes: > > > > > * Ralf Ertzinger [01/06/2007 14:06] : > > >> > > >> On Fri, 1 Jun 2007 00:34:21 +0200, Emmanuel Seyman wrote: > > >> > > >> > Then again, neither does Fedora 7's name. > > >> > > >> There was a full moon yesterday. > > > > > > Not the first explanation that sprang to my mind while reading the release > > > announcement, to be honest. > > > > Could someone enlighten a stupid German? > > > http://en.wikipedia.org/wiki/Moonshine > Ha-ha, in this case can we translate it as '?????' (Rakia) in the release notes for our Bulgarian users? :-D (sorry, couldn't stop myself) -- Regards, Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu From j.w.r.degoede at hhs.nl Fri Jun 1 19:23:11 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 21:23:11 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <200706011107.02464.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <200706011107.02464.jkeating@redhat.com> Message-ID: <4660721F.9040102@hhs.nl> Jesse Keating wrote: > On Friday 01 June 2007 10:49:39 Hans de Goede wrote: >> But going through updates testing for each and every bugfix / update is >> just adding unnecessary burden and delays. Why can't this just be left to >> the packagers discretion? I think I've done enough for Fedora to deserve >> some discretion. > > This is a broader issue, but I don't think it's set in stone anywhere that > every single update (or new package) has to go through updates-testing. We > strongly encourage it and start throwing daggers if you don't do it and > introduce issues on a stable platform, but I don't think there is anything > physically stopping you from going straight to updates. > Currently bodhi doesn't have say a checkbox to skip updates-testing, so currently the only way is throuh updates testing (or abuse the I'm a security update feature, but that would be dead wrong). > And there are going to be reasonable exceptions to the rule, I completely see > this. However exceptions are not a reason to completely ignore the rule for > every single package. > I'm not asking to always ignore the rules what I'm asking for is: 1) not putting (all) new packages through updates-testing, for some it might make sense, for others less. 2) in case of regular updates allow updates-testing to be skipped for trivial fixes for serious bugs (think crashers, doa apps), AFAIK we already agreed on this some weeks ago. Preferably in both cases the choice to short circuit updates-testing would be left to the packager, iow leave some room for the packagers discretion. I'm fine with the default being go through updates-testing, I'm fine with an obnoxious javascript popup saying that short circuiting is a bad idea, etc. But please leave me the choice! >> All I'm asking for is to leaving this to the packagers discretion, isn't >> Fedora supposed to be all about freedom? Then why put me in a straight >> jacket. > > Perhaps we have a communication issue. Can you show me where it is stated > that every single new package absolutely must without any question go through > updates-testing first, without exception? > In the current bodhi describing documents, proposals and in the bodhi implementation as we have it now. If there is a way to make exceptions it sure isn't documented. Regards, Hans From martin.sourada at seznam.cz Fri Jun 1 19:09:12 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 01 Jun 2007 21:09:12 +0200 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <46606702.7050302@REDHAT.COM> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> <1180706228.3828.17.camel@gibraltar.stuttgart.redhat.com> <46606702.7050302@REDHAT.COM> Message-ID: <1180724952.7519.9.camel@pc-notebook> On Fri, 2007-06-01 at 20:35 +0200, Robert Relyea wrote: > Nils Philippsen wrote: > > > > IMO, to make setting this automatically sensible and reliable, you'd > > have to have some things first: > > > > - a freely available mapping between "position on earth" and the > > corresponding timezone that's kept up to date > > - an attached GPS receiver that can be read from Linux > > > No need for a gps. If the network is configured... > > http://www.networldmap.com/TryIt.htm don't find my location > > Google for 'ip location' for a whole slew of them (each varies in > quality, none got my location, but most were accurate enough to get my > time zone). If it's even 90% correct it will greatly reduce the number > of people who have to manually adjust their timezone). > > The question is can we find/create an freely available database so we > can put up our own server. > > bob > > > Just the first one makes this a no-go, I haven't been able to dig up > > something like this. I couldn't even find a freely available, > > machine-readable coarse map of timezones. > > > > Nils > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list but this on get it precisely and even adds latitude/longitude and map to it: http://www.ip-adress.com/ As you noted, if it worked for 90% of people it would make great difference, and maybe we would be first to implement it ;-) So the idea is: 1. from IP get your location on Earth (or somewhere else? :-D), no need for precision, if time zone is OK, than location is precise enough. Dunno, whether some server which is open source is providing this, but if not, one could be started if there is want and will ;-) 2. if you have location, than timezone is only matter of finding in which area are you in (say you have a ball divided into twenty four pieces and you select a point on the ball. Which piece it is on? This is IMHO simple process...) Well, and about languages... well, if you are English you probably won't need it, but if you are from Europe there are maybe tens of languages spoken only in one country - and Europe has only three timezones or so, so it would be very precise (excluding English )... Martin -------------- next part -------------- A non-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 Jun 1 19:26:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 21:26:53 +0200 Subject: updates, updates-testing and comps In-Reply-To: <200706011107.02464.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <200706011107.02464.jkeating@redhat.com> Message-ID: <466072FD.9080308@hhs.nl> Jesse Keating wrote: >> 1) There will be no wide audience, even if they have updates-testing >> enabled they will not automatically install the new packages let alone use >> it, the only way to get a wide audience is to put it in updates and in >> comps, so that people can install it through "add/remove software". For the >> majority of users, if it isn't in comps it doesn't exist, since >> updates-testing has no comps *, the package doesn't exist and thus will not >> get tested. > > That's just a simple matter of using the comps-f7.xml comps file when > generating repodata for the Fedora 7 updates. Then suddenly you have entries > in add/remove software for things in updates-testing. > >> * and if it will, that means yet more work to get a package out > > You should be adding the package to comps if it makes sense to have it in > comps anyway, for each platform you'll build it for. > So lets say I put blobAndConquer, a new package which I've submitted through bodhi today in comps-f7.xml.in, and that comps gets rebuild from this. Then yes, people with updates-testing enabled will be able to install it, but people without updates-testing enabled, will see it to and get an error that it isn't available when trying to install it. Not very pretty if you ask me. Regards. Hans From notting at redhat.com Fri Jun 1 19:15:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 15:15:33 -0400 Subject: disagreement in a merge review about patches In-Reply-To: <465FDE60.4030901@linux-kernel.at> References: <20070601081258.GA9531@free.fr> <465FDE60.4030901@linux-kernel.at> Message-ID: <20070601191533.GC7580@nostromo.devel.redhat.com> Oliver Falk (oliver at linux-kernel.at) said: > The vixie-cron package contains so many patches and the release has been > increased so many times now... Active development of cron is only done > by distributions now. Right. We (briefly) had a forked upstream for sysklogd; this would be similar. > Or is there any good alternative for vixie-cron? I'm not 100 % sure, but > I think I stumbled across some crond, that is under active development. > Quick search on freshmeat or via google should be done. fcron. Maybe it's worth switching. Bill From j.w.r.degoede at hhs.nl Fri Jun 1 19:32:17 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 21:32:17 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <1180710788.3946.11.camel@zebes.localdomain> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <1180708585.3946.6.camel@zebes.localdomain> <46603361.2070507@hhs.nl> <1180710788.3946.11.camel@zebes.localdomain> Message-ID: <46607441.9020703@hhs.nl> Will Woods wrote: > On Fri, 2007-06-01 at 16:55 +0200, Hans de Goede wrote: >> Will Woods wrote: >>> Let's be a little more clear here - what the QA team actually does for >>> packages in updates-testing is *verification*. Check package sanity, >>> make sure programs don't segfault on startup, etc. >>> >>> I'm not expecting all testers to understand the functions of the >>> packages as well as their maintainers. But anyone can tell if you missed >>> some deps or your package doesn't start on x86_64. >>> >> 1) I already verify my packages on x86_64 myself > > Sure, and most maintainers do. And that's wonderful. It means that the > QA process will be very fast: > > "Oh, look, one of Hans' packages! This will be easy!" > [mere minutes pass, most of which is downloading the packages] > "Yep, everything seems fine. That Hans is one great packager!" > [QA approves package, rel-eng signs it, all is right with the world] > > So it really shouldn't slow *you* down much at all. But it should help > catch packaging / build mistakes made by *others* before they make it > into the repo. > If things will actually work with that, iow if packages in updates-testing will get QA approved in 1-2 workdays in general and then move to updates, then I think updates-testing will be a good idea, and the additional QA will be worth the delay. What I'm against is the old updates-testing ways where a package would just linger for a week (esp if its a new package!) and the get moved to updates without having seen much testing if any at all. That way just adds a week delay without much benefits. >> 2) starting libs is kinda hard >> 3) Most missing deps are subtile and do not necesarry show when just running an >> app >> >> It would be more usefull to check build-logs for things like: >> -suspicious ./configure failures (due to missing BuildRequires) >> -64 bit suspecious compiler output like cast from different size integer to >> pointer (this could actually be automated) >> >> Checking for 64 bit suspicious compiler warnings in my experience finds far >> more 64 bit bugs then just a quick test run, unless those 64 bit bugs happen to >> be in the straight quick test run path. > > These are excellent recommendations. I'll be sure to put 'em up on the > QA pages when we start putting together our testing guidelines. > I'm glad you like them, also always a good idea is running rpmlint, and for small apps trying to run them with LD_PRELOAD=libefence.so (do not try this for big apps) Regards, Hans From notting at redhat.com Fri Jun 1 19:18:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 15:18:03 -0400 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <1180697702.3637.6.camel@pc-notebook> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> Message-ID: <20070601191803.GD7580@nostromo.devel.redhat.com> Martin Sourada (martin.sourada at seznam.cz) said: > However, if you mentioned extensions to timezone, it came to my mind > that Fedora 7 installer didn't set timezone to Europe/Prague even with > Czech language selected as installation language. That information is in the lang-table - can you file a bug? Bill From notting at redhat.com Fri Jun 1 19:18:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 15:18:40 -0400 Subject: RFE: use nasa worldwind for timezone selection (i.e. my first reaction to F7) In-Reply-To: <448387.4032.qm@web56902.mail.re3.yahoo.com> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> Message-ID: <20070601191839.GE7580@nostromo.devel.redhat.com> > If you are going to go to that much effort for the thing, why not take > it a notch further and just integrate nasa worldwind into the anaconda. That's 16MB more to put in the boot/install images... Bill From jkeating at redhat.com Fri Jun 1 19:19:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 15:19:22 -0400 Subject: updates, updates-testing and comps In-Reply-To: <466072FD.9080308@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706011107.02464.jkeating@redhat.com> <466072FD.9080308@hhs.nl> Message-ID: <200706011519.22246.jkeating@redhat.com> On Friday 01 June 2007 15:26:53 Hans de Goede wrote: > So lets say I put blobAndConquer, a new package which I've submitted > through bodhi today in comps-f7.xml.in, and that comps gets rebuild from > this. Then yes, people with updates-testing enabled will be able to install > it, but people without updates-testing enabled, will see it to and get an > error that it isn't available when trying to install it. Not very pretty if > you ask me. No they wont. Yum is smart enough to not display a comps item if it isn't in the repos. That's how we get away with listing say ppc only packages in comps and people on !ppc don't see a package they can't install. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Fri Jun 1 19:25:32 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 01 Jun 2007 15:25:32 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180721609.3946.51.camel@zebes.localdomain> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> <1180661733.28298.15.camel@neutron> <1180721609.3946.51.camel@zebes.localdomain> Message-ID: <1180725932.31759.9.camel@rivendell> On Fri, 2007-06-01 at 14:13 -0400, Will Woods wrote: > Oh definitely. In fact, that's the main reason *I* care about this > feature. Live-ish upgrades would be a cool feature and save our users > some time, but making system upgrades easier to script is the icing on > the cake for me. > But how do we get around all the mess? Items like: - ext3->ext4 conversion - lvm format changes - dev->udev - etc. etc. Those things can't be handled in a live update. You need to be outside of the system to do them or you risk losing data and badly upsetting the running system. -sv From notting at redhat.com Fri Jun 1 19:23:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 15:23:54 -0400 Subject: updates, updates-testing and comps In-Reply-To: <200706011519.22246.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706011107.02464.jkeating@redhat.com> <466072FD.9080308@hhs.nl> <200706011519.22246.jkeating@redhat.com> Message-ID: <20070601192354.GF7580@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > So lets say I put blobAndConquer, a new package which I've submitted > > through bodhi today in comps-f7.xml.in, and that comps gets rebuild from > > this. Then yes, people with updates-testing enabled will be able to install > > it, but people without updates-testing enabled, will see it to and get an > > error that it isn't available when trying to install it. Not very pretty if > > you ask me. > > No they wont. Yum is smart enough to not display a comps item if it isn't in > the repos. That's how we get away with listing say ppc only packages in > comps and people on !ppc don't see a package they can't install. ... however, bodhi doesn't update the comps file at the moment - we should fix this. Bill From j.w.r.degoede at hhs.nl Fri Jun 1 19:42:37 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 21:42:37 +0200 Subject: updates, updates-testing and comps In-Reply-To: <200706011519.22246.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706011107.02464.jkeating@redhat.com> <466072FD.9080308@hhs.nl> <200706011519.22246.jkeating@redhat.com> Message-ID: <466076AD.2030405@hhs.nl> Jesse Keating wrote: > On Friday 01 June 2007 15:26:53 Hans de Goede wrote: >> So lets say I put blobAndConquer, a new package which I've submitted >> through bodhi today in comps-f7.xml.in, and that comps gets rebuild from >> this. Then yes, people with updates-testing enabled will be able to install >> it, but people without updates-testing enabled, will see it to and get an >> error that it isn't available when trying to install it. Not very pretty if >> you ask me. > > No they wont. Yum is smart enough to not display a comps item if it isn't in > the repos. That's how we get away with listing say ppc only packages in > comps and people on !ppc don't see a package they can't install. > Ah, ok, and the same goes for pirut (I assume it uses yum)? Regards, Hans From david at fubar.dk Fri Jun 1 19:32:26 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 01 Jun 2007 15:32:26 -0400 Subject: Feature idea: network based livecd installer In-Reply-To: <46606213.5020505@cora.nwra.com> References: <46606213.5020505@cora.nwra.com> Message-ID: <1180726346.2642.14.camel@zelda.fubar.dk> On Fri, 2007-06-01 at 12:14 -0600, Orion Poplawski wrote: > Inspired by Jeff's post - > > I'm really impressed with the install speed of the LiveCD installer. > What I'd like to be able to do is to essentially do the same thing over > the network - pxeboot into an environment that can pull the LiveCD image > of the network and install onto the local harddrive. I really haven't > had a chance to look closely at what's involved though. Seem possible? That's indeed the plan; see my Live CD presentation I gave at the RH summit for some future features we want to add http://people.redhat.com/davidz/Summit07_livecd_davidz.pdf which includes this. Note I'm not working actively on the Live CD tools right now so Jeremy probably knows better when that feature is going to land; it shouldn't be more than a nights or two work to get something up and running; it's basically just adding some network drivers and user-mode bits (dhcp client etc.) to the (pretty flexible) initramfs that the live cd uses. David From a.badger at gmail.com Fri Jun 1 01:54:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 31 May 2007 18:54:12 -0700 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180660501.26450.49.camel@fresnel.dumbhippo.com> References: <1180639616.9513.4.camel@localhost.localdomain> <1180660501.26450.49.camel@fresnel.dumbhippo.com> Message-ID: <1180662852.19774.58.camel@localhost.localdomain> On Thu, 2007-05-31 at 21:15 -0400, Owen Taylor wrote: > [ Cc: and Reply-To: fedora-desktop-list ] > I think this will cause problems as I'm not on fedora-desktop-list but here goes :-) > On Thu, 2007-05-31 at 19:57 +0000, Kevin Kofler wrote: > > And KDE actually displays "X-Chat (IRC client)" if the user preferences are set > > that way. Why does GNOME _still_ not support GenericName years after this > > specification has been supposedly agreed on? IMHO, the real technical problem > > lies there, mangling .desktop files like this is just papering over the > > problem. > > I'm not sure how you think that the Fedora GNOME desktop should be using GenericName. > The usage of a generic instead of a specific name in the Fedora menus is done for > a small subset of applications: those considered to be "best of breed". I imagine he envisions it being used like KDE's Name (Generic Name) instead of "best of breed". Best of breed is similar to the big board concept of "program in this category most used by user" with an out of the box popularity determined by the distribution. It's information about ranking a program (as determined by the user or users in Big Board, by the distribution in the status quo) whereas name is information for identifying a program and generic name is information for categorizing. > Now, using a generic for *anything* is really a hold-over from a past era when > our vision of the Fedora menus was that we'd select a small set of best-of-breed apps > for our users, instead of making them deal with the chaos of the entire set of > possible applications. > > This no longer fits with the Fedora philosophy, especially considering the merge > of core and extras. The question is more "how to manage the chaos". > +1 In a world where we could potentially have every OSS application in the repository, menus are a losing proposition. Big Board and other alternatives to menu systems are the way forward. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri Jun 1 19:38:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 01 Jun 2007 12:38:41 -0700 Subject: Don't put new packages through updates-testing In-Reply-To: <466034EE.3070004@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> Message-ID: <1180726721.19774.62.camel@localhost.localdomain> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: > Hans de Goede wrote: > > > > Not true many reviewers review on the latest stable, it says nowhere > > that a review should be done on rawhide. > > Review is about guidelines and nowhere in the guideline does it even say > that the fucntionality of the package should be tested. When I suggested > that it be added I got back a knee jerk reaction to participate in > reviews myself. > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Fri Jun 1 18:45:15 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 1 Jun 2007 18:45:15 +0000 (UTC) Subject: Feature idea: package an installer image as a grub entry beforeF8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> <1180661733.28298.15.camel@neutron> Message-ID: Colin Walters redhat.com> writes: > A few gigs? Couldn't we download just a CD size image? I think it's > kind of silly that Fedora makes DVD images so prominent in the download > page - who actually wants to download *everything*? I know I sure don't > want GNOME+KDE+XFCE for example. The live CD images are much nicer. The DVD doesn't actually contain everything though. For example, out of the 3 desktop environments you cited, only 2 are actually on the DVD (GNOME and KDE, in alphabetical order), XFCE is in the Everything repository only. Kevin Kofler From jspaleta at gmail.com Fri Jun 1 19:40:49 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 11:40:49 -0800 Subject: Don't put new packages through updates-testing In-Reply-To: <46607441.9020703@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <1180708585.3946.6.camel@zebes.localdomain> <46603361.2070507@hhs.nl> <1180710788.3946.11.camel@zebes.localdomain> <46607441.9020703@hhs.nl> Message-ID: <604aa7910706011240i67ce12c8k3c0819bdaf4aff94@mail.gmail.com> On 6/1/07, Hans de Goede wrote: > If things will actually work with that, iow if packages in updates-testing will > get QA approved in 1-2 workdays in general and then move to updates, then I > think updates-testing will be a good idea, and the additional QA will be worth > the delay. Especially if we use the time that an initial package is in updates-testing to create package specific QA testing scripts to be used for later version of the package. I know there is a plan to hook something like beaker up into the update process. For new packages, that first time through updates-testing is the ideal time for QA people to focus on helping the maintainer create scripted tests that can be run automatically for later updates. We just don't have all the pieces in place yet, because we have to start somewhere. > What I'm against is the old updates-testing ways where a package would just > linger for a week (esp if its a new package!) and the get moved to updates > without having seen much testing if any at all. That way just adds a week delay > without much benefits. Here's the way I look at it... there is a larger plan to harness a testing framework into the update process exposed by bodhi. It's not all there yet granted, but I think its going to be easier to hook something like beaker up and make real headway with it if we make the decision right now to nominally send new packages into updates-testing and establish the process for beaker to tap into. We leave in place the flexibility for maintainers to argue with release-eng on a case by case basis to avoid updates-testing for new packages or updates, but we establish the expected process now, so that when something akin to beaker gets hooked in, its a smooth enhancement to an existing process. -jef From chasd at silveroaks.com Fri Jun 1 19:41:46 2007 From: chasd at silveroaks.com (chasd) Date: Fri, 1 Jun 2007 14:41:46 -0500 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <20070601190941.69A5B73B17@hormel.redhat.com> References: <20070601190941.69A5B73B17@hormel.redhat.com> Message-ID: <87DED87E-4CC4-4649-BC6D-B2A6E7EC115A@silveroaks.com> > Martin Sourada wrote: > 1. from IP get your location on Earth (or somewhere else? :-D), no > need > for precision, if time zone is OK, than location is precise enough. Where on Earth are these addresses : 10.0.0.1 172.16.0.1 192.168.0.1 127.0.0.1 and indeed fc00::/7 What about systems with more than one interface / address - which one do you pick ? Also realize not all computers may be on Earth ( ISS, etc. ) If you build it, don't build it so it only works only now and in only the simplest situations. Charles Dostale From fedora at leemhuis.info Fri Jun 1 19:47:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 21:47:43 +0200 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180725932.31759.9.camel@rivendell> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> <1180661733.28298.15.camel@neutron> <1180721609.3946.51.camel@zebes.localdomain> <1180725932.31759.9.camel@rivendell> Message-ID: <466077DF.50403@leemhuis.info> On 01.06.2007 21:25, seth vidal wrote: > On Fri, 2007-06-01 at 14:13 -0400, Will Woods wrote: >> Oh definitely. In fact, that's the main reason *I* care about this >> feature. Live-ish upgrades would be a cool feature and save our users >> some time, but making system upgrades easier to script is the icing on >> the cake for me. > > But how do we get around all the mess? Items like: > > - ext3->ext4 conversion > - lvm format changes > - dev->udev > - etc. etc. > > Those things can't be handled in a live update. You need to be outside > of the system to do them or you risk losing data and badly upsetting the > running system. +1, but I'm wondering: how complex are those? Could they be done from the initrd on first start? That has the additional benefit that the stuff works for rawhide users as well and actually gets tested there, too. Cu thl /me now quickly wanders to find a place to hide From martin.sourada at seznam.cz Fri Jun 1 19:56:29 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 01 Jun 2007 21:56:29 +0200 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <20070601191803.GD7580@nostromo.devel.redhat.com> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> <20070601191803.GD7580@nostromo.devel.redhat.com> Message-ID: <1180727789.7519.15.camel@pc-notebook> On Fri, 2007-06-01 at 21:18 +0200, Bill Nottingham wrote: > Martin Sourada (martin.sourada at seznam.cz) said: > > However, if you mentioned extensions to timezone, it came to my mind > > that Fedora 7 installer didn't set timezone to Europe/Prague even with > > Czech language selected as installation language. > > That information is in the lang-table - can you file a bug? > > Bill > Is it? Didn't know that. But, as the problem was in Test 4 (and I have too slow internet here to download final ISOs) and no one other mentioned it and in fact it was when I tested it in QEMU (when I installed it on my notebook I chose English, so it was set right) I think filling a bug is not worth it, at least until F8 Test 1 come out (for Fedora 7 its too late now and for F8 there is plenty of time to fix it if it is really broken). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Fri Jun 1 20:00:22 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 01 Jun 2007 16:00:22 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <466077DF.50403@leemhuis.info> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> <1180661733.28298.15.camel@neutron> <1180721609.3946.51.camel@zebes.localdomain> <1180725932.31759.9.camel@rivendell> <466077DF.50403@leemhuis.info> Message-ID: <1180728022.31759.13.camel@rivendell> On Fri, 2007-06-01 at 21:47 +0200, Thorsten Leemhuis wrote: > +1, but I'm wondering: how complex are those? Could they be done from > the initrd on first start? That has the additional benefit that the > stuff works for rawhide users as well and actually gets tested there, too. well, in a number of cases, the world changes need to happen BEFORE you put new bits on disk, not after. -sv From eric at brouhaha.com Fri Jun 1 20:03:53 2007 From: eric at brouhaha.com (Eric Smith) Date: Fri, 1 Jun 2007 13:03:53 -0700 (PDT) Subject: mock config files for Fedora 7? mock building on FC6 for F7 packages? Message-ID: <46833.71.129.198.222.1180728233.squirrel@ruckus.brouhaha.com> I upgraded one of my development machines to Fedora 7 last night, and was surprised to not find any mock configuration files for it. I'd expected something like /etc/mock/fedora-7-{i386,x86_64).cfg. Before I whip them up myself (which admittedly shouldn't be at all difficult), has anyone already done that? I don't plan to upgrade my main build machine to Fedora 7 for a while yet. Is using a suitable mock configuration on FC6 to build packages for F7 plausible? Thanks, Eric From dwmw2 at infradead.org Fri Jun 1 20:09:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 01 Jun 2007 21:09:33 +0100 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <87DED87E-4CC4-4649-BC6D-B2A6E7EC115A@silveroaks.com> References: <20070601190941.69A5B73B17@hormel.redhat.com> <87DED87E-4CC4-4649-BC6D-B2A6E7EC115A@silveroaks.com> Message-ID: <1180728573.25232.55.camel@pmac.infradead.org> On Fri, 2007-06-01 at 14:41 -0500, chasd wrote: > Where on Earth are these addresses : > > 10.0.0.1 > 172.16.0.1 > 192.168.0.1 > 127.0.0.1 > > and indeed > > fc00::/7 > > What about systems with more than one interface / address - which one > do you pick ? Does it matter? We pick a fairly arbitrary default at the moment; why not at least make an _attempt_ to get it better than that? -- dwmw2 From mschwendt.tmp0701.nospam at arcor.de Fri Jun 1 20:16:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 1 Jun 2007 22:16:01 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <1180726721.19774.62.camel@localhost.localdomain> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> Message-ID: <20070601221601.48d34cd2.mschwendt.tmp0701.nospam@arcor.de> On Fri, 01 Jun 2007 12:38:41 -0700, Toshio Kuratomi wrote: > On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: > > Hans de Goede wrote: > > > > > > Not true many reviewers review on the latest stable, it says nowhere > > > that a review should be done on rawhide. > > > > Review is about guidelines and nowhere in the guideline does it even say > > that the fucntionality of the package should be tested. When I suggested > > that it be added I got back a knee jerk reaction to participate in > > reviews myself. > > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > > - SHOULD: The reviewer should test that the package functions as > described. A package should not segfault instead of running, for > example. And it has been part of the guidelines for a *very* long time, simply to reduce the risk that something is built that refuses to work because of very obvious problems. It is easy to build packages that install fine, but which contain programs that don't even start without problems. A typical mistake with graphical applications is a "Help" menu item which doesn't work because of misplaced or missing documentation files. From martin.sourada at seznam.cz Fri Jun 1 20:14:57 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 01 Jun 2007 22:14:57 +0200 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <87DED87E-4CC4-4649-BC6D-B2A6E7EC115A@silveroaks.com> References: <20070601190941.69A5B73B17@hormel.redhat.com> <87DED87E-4CC4-4649-BC6D-B2A6E7EC115A@silveroaks.com> Message-ID: <1180728897.7519.31.camel@pc-notebook> On Fri, 2007-06-01 at 21:41 +0200, chasd wrote: > > Martin Sourada wrote: > > > 1. from IP get your location on Earth (or somewhere else? :-D), no > > need > > for precision, if time zone is OK, than location is precise enough. > > Where on Earth are these addresses : > > 10.0.0.1 > 172.16.0.1 > 192.168.0.1 > 127.0.0.1 > let's say it thus: these are not public addresses (AFAIK). Many of the computers actually have only local IPs only and are connected to internet via single public IP. And for timezone selection is public address enough. Of course there can be problems on the borders, but if system is unsure which timezone is the right one, user could be queued to check it (and even select one from much shorter list of timezones/cities). > and indeed > > fc00::/7 > Ugh? What is that? Never seen something similar to that, save IPv6 addresses which are however usually quite longer. IPv6s, IMHO, could be handled similar to classic IPs, only we would need bigger database... > What about systems with more than one interface / address - which one > do you pick ? > The public one. > Also realize not all computers may be on Earth ( ISS, etc. ) > Well, these are not likely to have Fedora on themselves and if they have, there will certainly not be a very big number IPs (at least not in near future). Don't know which timezone (if any) is used in space... > If you build it, don't build it so it only works only now and in only > the simplest situations. > > Hm... do you think we should think, from the beginning, about Mars timezones, for example? I think, better idea is start with standard IPs only and Earth only. When it works then wider it to IPv6 and then start to include time in Space (which is an issue all by itself, as e.g. Mars has longer days and years then Earth, and people want to colonise Mars in the future, don't they?)... > Charles Dostale > > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From caillon at redhat.com Fri Jun 1 20:17:28 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 01 Jun 2007 16:17:28 -0400 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <1180727789.7519.15.camel@pc-notebook> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> <20070601191803.GD7580@nostromo.devel.redhat.com> <1180727789.7519.15.camel@pc-notebook> Message-ID: <46607ED8.9020008@redhat.com> Martin Sourada wrote: > Is it? Didn't know that. But, as the problem was in Test 4 (and I have > too slow internet here to download final ISOs) and no one other > mentioned it and in fact it was when I tested it in QEMU (when I > installed it on my notebook I chose English, so it was set right) I > think filling a bug is not worth it, at least until F8 Test 1 come out > (for Fedora 7 its too late now and for F8 there is plenty of time to fix > it if it is really broken). Without filing a bug, the person responsible for fixing it might not know about it. So there's close to zero chance of it being fixed until you file a bug. From nicolas.mailhot at laposte.net Fri Jun 1 20:19:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 01 Jun 2007 22:19:25 +0200 Subject: mock config files for Fedora 7? mock building on FC6 for F7 packages? In-Reply-To: <46833.71.129.198.222.1180728233.squirrel@ruckus.brouhaha.com> References: <46833.71.129.198.222.1180728233.squirrel@ruckus.brouhaha.com> Message-ID: <1180729165.11490.25.camel@rousalka.dyndns.org> Le vendredi 01 juin 2007 ? 13:03 -0700, Eric Smith a ?crit : > I upgraded one of my development machines to Fedora 7 last night, > and was surprised to not find any mock configuration files for it. > I'd expected something like /etc/mock/fedora-7-{i386,x86_64).cfg. > > Before I whip them up myself (which admittedly shouldn't be at all > difficult), has anyone already done that? I've done this for the new rawhide, it's real evil?, don't use this unless you sit behind a proxy to limit infrastructure load config_opts['chroot_setup_cmd'] = 'groupinstall build' [fedora-devel] name=Fedora - Development baseurl=http://redhat.download.fedoraproject.org/pub/fedora/linux/development/x86_64/os/ enabled=1 gpgcheck=0 [fedora-7] name=Fedora 7 http://redhat.download.fedoraproject.org/pub/fedora/linux/releases/7/Everything/x86_64/os/ enabled=1 gpgcheck=1 [koji-f8-builds] name=Fedora - 8 - Koji builds baseurl=http://koji.fedoraproject.org/static-repos/dist-f8-build-current/x86_64/ enabled=1 gpgcheck=0 [koji-f7-builds] name=Fedora - 7 - Koji builds baseurl=http://koji.fedoraproject.org/static-repos/dist-fc7-build-current/x86_64/ enabled=1 gpgcheck=0 [koji-f7-final] name=Fedora - 7 - Koji baseurl=http://koji.fedoraproject.org/static-repos/f7-final-current/x86_64/ enabled=1 gpgcheck=0 -- 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 martin.sourada at seznam.cz Fri Jun 1 20:25:19 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 01 Jun 2007 22:25:19 +0200 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <46607ED8.9020008@redhat.com> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> <20070601191803.GD7580@nostromo.devel.redhat.com> <1180727789.7519.15.camel@pc-notebook> <46607ED8.9020008@redhat.com> Message-ID: <1180729519.7519.35.camel@pc-notebook> On Fri, 2007-06-01 at 22:17 +0200, Christopher Aillon wrote: > Martin Sourada wrote: > > Is it? Didn't know that. But, as the problem was in Test 4 (and I have > > too slow internet here to download final ISOs) and no one other > > mentioned it and in fact it was when I tested it in QEMU (when I > > installed it on my notebook I chose English, so it was set right) I > > think filling a bug is not worth it, at least until F8 Test 1 come out > > (for Fedora 7 its too late now and for F8 there is plenty of time to fix > > it if it is really broken). > > Without filing a bug, the person responsible for fixing it might not > know about it. So there's close to zero chance of it being fixed until > you file a bug. > I know, but also don't want to fill bugs when not necessary. I'll check it when F8 T1 is out. If it will work then it is OK, if not, I will file a bug. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Fri Jun 1 20:26:36 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 1 Jun 2007 16:26:36 -0400 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <87DED87E-4CC4-4649-BC6D-B2A6E7EC115A@silveroaks.com> References: <20070601190941.69A5B73B17@hormel.redhat.com> <87DED87E-4CC4-4649-BC6D-B2A6E7EC115A@silveroaks.com> Message-ID: <20070601202636.GA865@redhat.com> On Fri, Jun 01, 2007 at 02:41:46PM -0500, chasd wrote: > > Martin Sourada wrote: > > > 1. from IP get your location on Earth (or somewhere else? :-D), no > > need > > for precision, if time zone is OK, than location is precise enough. > > Where on Earth are these addresses : > > 10.0.0.1 > 172.16.0.1 > 192.168.0.1 > 127.0.0.1 > fc00::/7 If you can connect to the remote server that does the translation, it won't see these addresses, it'll see the address of the server you're masquerading/tunneling through. > What about systems with more than one interface / address - which one > do you pick ? Why does it matter, it's not like the different interfaces are going to be geographically different. > Also realize not all computers may be on Earth ( ISS, etc. ) > If you build it, don't build it so it only works only now and in only > the simplest situations. Perfect is the enemy of good enough. Dave From naheemzaffar at gmail.com Fri Jun 1 20:44:15 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 1 Jun 2007 21:44:15 +0100 Subject: Unsigned packages (ntfs-config) Message-ID: <3adc77210706011344h22eabe5et1bf71e8749594239@mail.gmail.com> It seems that atleast one package in the repo is unsigned: yum install ntfs-config Loading "installonlyn" plugin Loading "presto" plugin Setting up Presto Reading Presto metadata in from local files Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package ntfs-config.noarch 0:1.0-0.2.beta1.fc7 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: ntfs-config noarch 1.0-0.2.beta1.fc7 fedora 82 k Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 82 k Is this ok [y/N]: y Downloading Packages: Package ntfs-config-1.0-0.2.beta1.fc7.noarch.rpm is not signed Should I file a bug report, or are these teething problems for a new release? From david at lovesunix.net Fri Jun 1 20:58:07 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 01 Jun 2007 22:58:07 +0200 Subject: Fedora 8 Schedule In-Reply-To: References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> Message-ID: <1180731487.11951.37.camel@dawkins> fre, 01 06 2007 kl. 14:13 +0000, skrev Kevin Kofler: > Matthias Clasen redhat.com> writes: > > Some more notes about this draft: it puts feature freeze in bold letters > > at August 20, which is only a few days after gnome 2.20 beta1, and is > > It's good to know that some folks from the GNOME camp are also not happy with > that schedule (see also David Nielsen's message about the test3 freeze date). > One one hand, it makes me feel better because this means the schedule isn't > favoring GNOME over KDE, on the other hand it makes the schedule look even > worse, because this means it's misaligned with both the GNOME and KDE > schedules, at least one of which is central to every desktop user's experience > of Fedora. To be honest normally I wouldn't have a problem favoring GNOME over KDE, it has always been the default desktop but in this case I think it would be entirely foolish to forget just how major a release KDE 4.0 is. We have users waiting for it like crack addicts and it would look better if we were able to ship with the final release. Having the final version looks better to users not to mention it will do wonders for PR to both have KDE4 as one of the first stable distro releases and to show that we really do care about KDE in defiance of popular belief. I hear KDE 4.1 is aimed at being a 6 month release, this would then mean we align nicely for a F9 with KDE4 and GNOME 2.22. That would accomplice the goal of adjusting the schedule which was aimed for rather nicely.. provided neither projects slips their release date. For KDE4 to hit on the final devel freeze we are merely talking putting back the schedule by about a week which if we push Test3 devel freeze to the the 25th of September that would allow us to ship Test3 with KDE 4.0-rc1 and GNOME 2.20 - I'm hoping that will provide helpful for getting testers to start using the release and we can accommodate both major releases in the final release. Cut dates would then be: September 19th - GNOME 2.20 September 25th - KDE 4.0-rc1 September 25th - Test3 devel freeze October 1st - Test3 release October 23th - KDE 4.0 final October 23th - Final devel freeze. November 7th - Final release - Is this insanity? - If I'm to understand Rex KDE packagers get the tarballs in time to make this? - can we live with doing freezes on a Tuesday instead of a Monday? And we'd be roughly on schedule with GNOME and KDE for F9 following that considering a standard 6 month cycle. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jkeating at redhat.com Fri Jun 1 21:06:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 17:06:11 -0400 Subject: updates, updates-testing and comps In-Reply-To: <466076AD.2030405@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706011519.22246.jkeating@redhat.com> <466076AD.2030405@hhs.nl> Message-ID: <200706011706.11985.jkeating@redhat.com> On Friday 01 June 2007 15:42:37 Hans de Goede wrote: > Ah, ok, and the same goes for pirut (I assume it uses yum)? Yes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 1 21:06:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 17:06:25 -0400 Subject: updates, updates-testing and comps In-Reply-To: <20070601192354.GF7580@nostromo.devel.redhat.com> References: <46601BAF.8000507@hhs.nl> <200706011519.22246.jkeating@redhat.com> <20070601192354.GF7580@nostromo.devel.redhat.com> Message-ID: <200706011706.25330.jkeating@redhat.com> On Friday 01 June 2007 15:23:54 Bill Nottingham wrote: > ... however, bodhi doesn't update the comps file at the moment - we should > fix this. Yeah I meant to talk to you and Luke about that this afternoon. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 1 21:08:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 17:08:04 -0400 Subject: Unsigned packages (ntfs-config) In-Reply-To: <3adc77210706011344h22eabe5et1bf71e8749594239@mail.gmail.com> References: <3adc77210706011344h22eabe5et1bf71e8749594239@mail.gmail.com> Message-ID: <200706011708.04375.jkeating@redhat.com> On Friday 01 June 2007 16:44:15 Naheem Zaffar wrote: > Should I file a bug report, or are these teething problems for a new > release? There are a few known. We're going to fix them. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andy at andrewprice.me.uk Fri Jun 1 18:37:54 2007 From: andy at andrewprice.me.uk (Andrew Price) Date: Fri, 01 Jun 2007 19:37:54 +0100 Subject: Sponsorship request for pybackpack Message-ID: Hello, I'm the maintainer of a python/gnome backup tool called pybackpack which was originally started as a Fedora project for the Google summer of code in 2005 but I took over from the original maintainer (Dave Arter) some time ago. It still hasn't gotten into fedora but a review request bug (bug #221884) has been open for a while. could you let me know where to go from here? I'm led to believe that I need to request sponsorship, but I'm not entirely familiar with Fedora's processes. Regards, -- Andy Price http://andrewprice.me.uk From pertusus at free.fr Fri Jun 1 21:33:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 1 Jun 2007 23:33:51 +0200 Subject: koji can't find a newly build dependency Message-ID: <20070601213351.GA27920@free.fr> Hello, I have just rebuilt libdap: http://koji.fedoraproject.org/koji/buildinfo?buildID=7748 Now I am trying to build packages depending on libdap, but on x86_64 there are errors because libdap-devel isn't found. Isn't it supposed to be here? I am missing something, or maybe there is a bug somewhere? http://koji.fedoraproject.org/koji/taskinfo?taskID=23306 -- Pat From drago01 at gmail.com Fri Jun 1 21:08:47 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 1 Jun 2007 23:08:47 +0200 Subject: Fedora 8 Schedule In-Reply-To: <1180731487.11951.37.camel@dawkins> References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> <1180731487.11951.37.camel@dawkins> Message-ID: On 6/1/07, David Nielsen wrote: > > fre, 01 06 2007 kl. 14:13 +0000, skrev Kevin Kofler: > > Matthias Clasen redhat.com> writes: > > > Some more notes about this draft: it puts feature freeze in bold > letters > > > at August 20, which is only a few days after gnome 2.20 beta1, and is > > > > It's good to know that some folks from the GNOME camp are also not happy > with > > that schedule (see also David Nielsen's message about the test3 freeze > date). > > One one hand, it makes me feel better because this means the schedule > isn't > > favoring GNOME over KDE, on the other hand it makes the schedule look > even > > worse, because this means it's misaligned with both the GNOME and KDE > > schedules, at least one of which is central to every desktop user's > experience > > of Fedora. > > To be honest normally I wouldn't have a problem favoring GNOME over KDE, > it has always been the default desktop but in this case I think it would > be entirely foolish to forget just how major a release KDE 4.0 is. We > have users waiting for it like crack addicts and it would look better if > we were able to ship with the final release. > > Having the final version looks better to users not to mention it will do > wonders for PR to both have KDE4 as one of the first stable distro > releases and to show that we really do care about KDE in defiance of > popular belief. > > I hear KDE 4.1 is aimed at being a 6 month release, this would then mean > we align nicely for a F9 with KDE4 and GNOME 2.22. That would accomplice > the goal of adjusting the schedule which was aimed for rather nicely.. > provided neither projects slips their release date. > > For KDE4 to hit on the final devel freeze we are merely talking putting > back the schedule by about a week which if we push Test3 devel freeze to > the the 25th of September that would allow us to ship Test3 with KDE > 4.0-rc1 and GNOME 2.20 - I'm hoping that will provide helpful for > getting testers to start using the release and we can accommodate both > major releases in the final release. > > Cut dates would then be: > September 19th - GNOME 2.20 > September 25th - KDE 4.0-rc1 > September 25th - Test3 devel freeze > October 1st - Test3 release > October 23th - KDE 4.0 final > October 23th - Final devel freeze. > November 7th - Final release > > - Is this insanity? > - If I'm to understand Rex KDE packagers get the tarballs in time to > make this? > - can we live with doing freezes on a Tuesday instead of a Monday? > > And we'd be roughly on schedule with GNOME and KDE for F9 following that > considering a standard 6 month cycle. +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.lewis at benl.co.uk Fri Jun 1 21:46:11 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Fri, 01 Jun 2007 22:46:11 +0100 Subject: Fedora 8 Schedule In-Reply-To: References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> <1180731487.11951.37.camel@dawkins> Message-ID: <466093A3.2060008@benl.co.uk> dragoran wrote: > > > On 6/1/07, *David Nielsen* > wrote: > > fre, 01 06 2007 kl. 14:13 +0000, skrev Kevin Kofler: > > Matthias Clasen redhat.com > > writes: > > > Some more notes about this draft: it puts feature freeze in > bold letters > > > at August 20, which is only a few days after gnome 2.20 beta1, > and is > > > > It's good to know that some folks from the GNOME camp are also > not happy with > > that schedule (see also David Nielsen's message about the test3 > freeze date). > > One one hand, it makes me feel better because this means the > schedule isn't > > favoring GNOME over KDE, on the other hand it makes the schedule > look even > > worse, because this means it's misaligned with both the GNOME > and KDE > > schedules, at least one of which is central to every desktop > user's experience > > of Fedora. > > To be honest normally I wouldn't have a problem favoring GNOME > over KDE, > it has always been the default desktop but in this case I think it > would > be entirely foolish to forget just how major a release KDE 4.0 is. We > have users waiting for it like crack addicts and it would look > better if > we were able to ship with the final release. > > Having the final version looks better to users not to mention it > will do > wonders for PR to both have KDE4 as one of the first stable distro > releases and to show that we really do care about KDE in defiance of > popular belief. > > I hear KDE 4.1 is aimed at being a 6 month release, this would > then mean > we align nicely for a F9 with KDE4 and GNOME 2.22. That would > accomplice > the goal of adjusting the schedule which was aimed for rather nicely.. > provided neither projects slips their release date. > > For KDE4 to hit on the final devel freeze we are merely talking > putting > back the schedule by about a week which if we push Test3 devel > freeze to > the the 25th of September that would allow us to ship Test3 with KDE > 4.0-rc1 and GNOME 2.20 - I'm hoping that will provide helpful for > getting testers to start using the release and we can accommodate both > major releases in the final release. > > Cut dates would then be: > September 19th - GNOME 2.20 > September 25th - KDE 4.0-rc1 > September 25th - Test3 devel freeze > October 1st - Test3 release > October 23th - KDE 4.0 final > October 23th - Final devel freeze. > November 7th - Final release > > - Is this insanity? > - If I'm to understand Rex KDE packagers get the tarballs in time to > make this? > - can we live with doing freezes on a Tuesday instead of a Monday? > > And we'd be roughly on schedule with GNOME and KDE for F9 > following that > considering a standard 6 month cycle. > > > +1 +1 -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From orion at cora.nwra.com Fri Jun 1 21:49:00 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 01 Jun 2007 15:49:00 -0600 Subject: Feature idea: network based livecd installer In-Reply-To: <1180726346.2642.14.camel@zelda.fubar.dk> References: <46606213.5020505@cora.nwra.com> <1180726346.2642.14.camel@zelda.fubar.dk> Message-ID: <4660944C.7060608@cora.nwra.com> David Zeuthen wrote: > > That's indeed the plan; see my Live CD presentation I gave at the RH > summit for some future features we want to add > > http://people.redhat.com/davidz/Summit07_livecd_davidz.pdf > > which includes this. > > Note I'm not working actively on the Live CD tools right now so Jeremy > probably knows better when that feature is going to land; it shouldn't > be more than a nights or two work to get something up and running; it's > basically just adding some network drivers and user-mode bits (dhcp > client etc.) to the (pretty flexible) initramfs that the live cd uses. > Great! I'll sign up on the mailing list a see where I can help out... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jesusr at redhat.com Fri Jun 1 21:51:37 2007 From: jesusr at redhat.com (jesusr at redhat.com) Date: Fri, 1 Jun 2007 17:51:37 -0400 Subject: Meaningless name (was: Re: rpms/xchat/devel ...) In-Reply-To: <1180649583.3475.2.camel@localhost.localdomain> References: <1180639616.9513.4.camel@localhost.localdomain> <1180642169.9513.24.camel@localhost.localdomain> <1180646159.5761.54.camel@vader.jdub.homelinux.org> <1180646779.10152.0.camel@localhost.localdomain> <1180648995.5761.59.camel@vader.jdub.homelinux.org> <1180649583.3475.2.camel@localhost.localdomain> Message-ID: <20070601215137.GB8914@transam.devel.redhat.com> On Thu, May 31, 2007 at 06:13:03PM -0400, Matthias Clasen wrote: > On Thu, 2007-05-31 at 17:03 -0500, Josh Boyer wrote: > > > If you're referring to migrating Windows users, even they realize there > > is more than one program to accomplish the same task. Think of AIM, > > Trillian, ICQ, blah blah blah. Or McAfee vs. Symantec. Or IE vs. > > Firefox. Hell, even Microsoft doesn't label IE as "Web browser" (which > > is another bogosity we do but one thing at a time). Personally, I think listing the name of the application is "too Windowish". I really like the menu item to be generic, i.e. "IRC client", "Web browser", etc. That should be for the default applications which I should be able to change with the Preferred applications applet. Subsequent installed apps should just be listed as the application name. So if I have Epiphany, Firefox and Konqueror with Firefox as my default, I should see Epiphany and Konqueror in the list but not Firefox. Just my 2 cents. -- jesus m. rodriguez | jesusr at redhat.com sr. software engineer | irc: zeus red hat network | 919.754.4413 x44413 +-------------------------------------------+ | "we can not change our past, but we can | | define our future" | +-------------------------------------------+ From mschwendt.tmp0701.nospam at arcor.de Fri Jun 1 21:59:49 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 1 Jun 2007 23:59:49 +0200 Subject: koji can't find a newly build dependency In-Reply-To: <20070601213351.GA27920@free.fr> References: <20070601213351.GA27920@free.fr> Message-ID: <20070601235949.ab6b4deb.mschwendt.tmp0701.nospam@arcor.de> On Fri, 1 Jun 2007 23:33:51 +0200, Patrice Dumas wrote: > Hello, > > I have just rebuilt libdap: > http://koji.fedoraproject.org/koji/buildinfo?buildID=7748 > > Now I am trying to build packages depending on libdap, but on x86_64 > there are errors because libdap-devel isn't found. Isn't it supposed > to be here? I am missing something, or maybe there is a bug somewhere? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=23306 With koji you need to wait longer before a build is included in the buildroot for subsequent build jobs. The corresponding 'newRepo' task must have completed. http://koji.fedoraproject.org/koji/tasks?state=all&method=newRepo&order=-completion_time Alternatively, test the chain-build command. From a.badger at gmail.com Fri Jun 1 22:01:51 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 01 Jun 2007 15:01:51 -0700 Subject: koji can't find a newly build dependency In-Reply-To: <20070601213351.GA27920@free.fr> References: <20070601213351.GA27920@free.fr> Message-ID: <1180735311.19774.69.camel@localhost.localdomain> On Fri, 2007-06-01 at 23:33 +0200, Patrice Dumas wrote: > Hello, > > I have just rebuilt libdap: > http://koji.fedoraproject.org/koji/buildinfo?buildID=7748 > > Now I am trying to build packages depending on libdap, but on x86_64 > there are errors because libdap-devel isn't found. Isn't it supposed > to be here? I am missing something, or maybe there is a bug somewhere? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=23306 > I think you need to use koji's chain-building facility to ensure that the libdap package is included in the repository before the next package is built. These mailing list posts ought to help:: https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02146.html https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01850.html -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri Jun 1 22:09:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 01 Jun 2007 15:09:57 -0700 Subject: koji weirdness In-Reply-To: <1180639944.21359.14.camel@burren.boston.redhat.com> References: <465A8F08.90708@hhs.nl> <200705280941.51943.jkeating@redhat.com> <465BDE48.9010606@hhs.nl> <200705290633.56160.jkeating@redhat.com> <1180639944.21359.14.camel@burren.boston.redhat.com> Message-ID: <1180735797.19774.78.camel@localhost.localdomain> On Thu, 2007-05-31 at 15:32 -0400, Mike Bonnet wrote: > I just checked in an alternate chain-build implementation to > Makefile.common, based on a target we were using internally (and have > tested rather extensively). Update your common/ directories and run > "make help" to see the chain-build usage. > > You specify the packages that the current package depends on using the > CHAIN= parameter to "make chain-build". The packages specified in the > CHAIN= parameter will be checked out into a temp directory and "make > cvsurl" will be called to get their CVS URL (this will reference the > latest tag that was applied to the package on the current branch, and > that tag must not have been built in Koji already). The CVS URLs from > each CHAIN= package and the current package will be used to generate the > appropriate koji command-line to build each package in order (the > current package will be built last, and should not appear in the CHAIN= > parameter). What do you do if you have several packages that have a common dependency? For instance: bzrtools Requires: bzr >= %{majorver} bzr < %{nextver} bzr-gtk Requires: bzr >= %{majorver} bzr < %{nextver} Does cd bzr-gtk/devel ; make chain-build CHAIN='bzr bzrtools' build bzr, then bzrtools when bzr is ready, then bzr-gtk when bzrtools is ready? Or does it attempt to make bzr and bzr-gtk independently followed by bzr-gtk? Related to this is specifying more than one package. foo Requires: bar, bar Requires: baz. An update of baz requires an update of bar which requires an update of foo. Does cd foo/devel ; make chain-build CHAIN='baz bar' do the right thing? Thanks, -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ruben at rubenkerkhof.com Fri Jun 1 22:19:10 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sat, 2 Jun 2007 00:19:10 +0200 Subject: Sponsorship request for pybackpack In-Reply-To: References: Message-ID: <2D1A818E-0054-42FA-A1BE-AB4FFEAADD1B@rubenkerkhof.com> On 1-jun-2007, at 20:37, Andrew Price wrote: > Hello, > > I'm the maintainer of a python/gnome backup tool called pybackpack > which > was originally started as a Fedora project for the Google summer of > code > in 2005 but I took over from the original maintainer (Dave Arter) some > time ago. It still hasn't gotten into fedora but a review request bug > (bug #221884) has been open for a while. could you let me know > where to > go from here? I'm led to believe that I need to request > sponsorship, but > I'm not entirely familiar with Fedora's processes. Hi Andrew, A sponsor has to do a review of your package and approve it. The review request is blocking the FE-NEEDSPONSOR bug, so you're on the list of people needing a sponsor. Check out http://fedoraproject.org/wiki/PackageMaintainers/ HowToGetSponsored Ruben From chasd at silveroaks.com Fri Jun 1 22:41:25 2007 From: chasd at silveroaks.com (chasd) Date: Fri, 1 Jun 2007 17:41:25 -0500 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <20070601213601.35AA773D65@hormel.redhat.com> References: <20070601213601.35AA773D65@hormel.redhat.com> Message-ID: <97343C4F-0E08-4C43-B29B-7FD03F119B3F@silveroaks.com> > Several points by various posters Let me state my point a different way : I don't wish there to be a regression where the auto-pick-time-zone- fu takes longer or is less accurate than a human picking the correct one when a network configuration is encountered that hasn't been taken into account, or internet access is not available or allowed at installation time. Other OS's that will remain nameless have to time out during their "phone home" install step if there is no proxy or default route supplied. I wouldn't like that to happen on Fedora just to guess my time zone. Maybe I'm the only one that does all OS installs isolated from the internet, so I'm a corner case. Charles Dostale From pp at ee.oulu.fi Fri Jun 1 23:33:13 2007 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Sat, 2 Jun 2007 02:33:13 +0300 Subject: Fedora 8 Schedule In-Reply-To: <1180731487.11951.37.camel@dawkins> References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> <1180731487.11951.37.camel@dawkins> Message-ID: <20070601233313.GA11965@ee.oulu.fi> On Fri, Jun 01, 2007 at 10:58:07PM +0200, David Nielsen wrote: > I hear KDE 4.1 is aimed at being a 6 month release, this would then mean > we align nicely for a F9 with KDE4 and GNOME 2.22. That would accomplice > the goal of adjusting the schedule which was aimed for rather nicely.. > provided neither projects slips their release date. Why does the KDE spin have to be released at the same time as the general GNOME-oriented release? With F7 creating custom spins should be "easy". Just have a time when the GNOME desktop will be ready (and well-tested) as the F8 release, release a F8 KDE spin beta/release candidate at the same time, wait for KDE final to be out and release a F8+updates+KDE4 spin after some time of testing. It will much likely be of much better quality than the "real" F8 by then, since the entire distro will have a month or so of testing by those idiots that happen to believe GNOME is the better desktop. -- Pekka Pietikainen (a GNOME user) From pp at ee.oulu.fi Fri Jun 1 23:36:11 2007 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Sat, 2 Jun 2007 02:36:11 +0300 Subject: Very much packages with fc6 tag instead of fc7 in the FC7 tree In-Reply-To: <45365.29376.qm@web51512.mail.re2.yahoo.com> References: <465FD2A4.2010306@linux-kernel.at> <45365.29376.qm@web51512.mail.re2.yahoo.com> Message-ID: <20070601233611.GB11965@ee.oulu.fi> On Fri, Jun 01, 2007 at 05:39:16AM -0700, Steve G wrote: > > people updating via yum - which if I recall, is not officially supported. I'd > like to see this policy changed in F8 so that admins/users can spot failed > upgrades or orphaned packages. That is far greater value than saying its to save > bandwidth when it doesn't. Ever heard of "yum list extras"? Great for finding obsolete packages on your system. -- Pekka Pietikainen From dennis at ausil.us Fri Jun 1 23:42:21 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 1 Jun 2007 18:42:21 -0500 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706011139.04795.jkeating@redhat.com> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <1180708542.12595.295.camel@mccallum.corsepiu.local> <200706011139.04795.jkeating@redhat.com> Message-ID: <200706011842.22194.dennis@ausil.us> Once upon a time Friday 01 June 2007, Jesse Keating wrote: > On Friday 01 June 2007 10:35:42 Ralf Corsepius wrote: > > I had brought this topic up many months ago, but it was shot down by > > Jesse and Dennis. A real pity, IMO. > > We've obviated the need for buildsys-macros by having the definitions > provided in it inside redhat-rpm-config. > > We could get rid of buildsys-build by making a perhaps 'hidden' group > within comps that is the buildsys-build group, since mock can easily do a > groupinstall instead of a package install to populate the buildroot. These > two things together would obviate the need for a separate repo all > together. buildsys-macros still exists with only printf %s%b "%" "__arch_install_post /usr/lib/rpm/check-buildroot\n" >> $RPM_BUILD_ROOT/etc/rpm/macros.checkbuild so we can still run check-buildroot at least for mock builds.. Dennis From jkeating at redhat.com Fri Jun 1 23:45:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 19:45:15 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706011842.22194.dennis@ausil.us> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706011139.04795.jkeating@redhat.com> <200706011842.22194.dennis@ausil.us> Message-ID: <200706011945.15676.jkeating@redhat.com> On Friday 01 June 2007 19:42:21 Dennis Gilmore wrote: > buildsys-macros still exists with only > printf %s%b "%" "__arch_install_post /usr/lib/rpm/check-buildroot\n" >> > $RPM_BUILD_ROOT/etc/rpm/macros.checkbuild > > so we can still run check-buildroot at least for mock builds.. Right, and we can split the check-buildroot out into it's own package or whatnot so that we can do that on user's systems too, but not pull in all of what currently provides check-buildroot. We talked about that before on one of the lists. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From valent.turkovic at gmail.com Fri Jun 1 23:34:20 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 2 Jun 2007 01:34:20 +0200 Subject: Firefox 2.0 fails to install Flash 9 plugin Message-ID: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> Firefox 2.0 fails to install Flash 9 plugin - for me personally this is a minor bug but for standard desktop user (let's call him John) it is a major problem. Check out BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242175 Please look at the video, it shows that this error is repeatable: http://www.youtube.com/watch?v=-_ayaoEUHZ4 Regards Valent -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From katzj at redhat.com Sat Jun 2 00:00:58 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 01 Jun 2007 20:00:58 -0400 Subject: updates, updates-testing and comps In-Reply-To: <466072FD.9080308@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <200706011107.02464.jkeating@redhat.com> <466072FD.9080308@hhs.nl> Message-ID: <1180742458.14463.6.camel@aglarond.local> On Fri, 2007-06-01 at 21:26 +0200, Hans de Goede wrote: > So lets say I put blobAndConquer, a new package which I've submitted through > bodhi today in comps-f7.xml.in, and that comps gets rebuild from this. Then > yes, people with updates-testing enabled will be able to install it, but people > without updates-testing enabled, will see it to and get an error that it isn't > available when trying to install it. Not very pretty if you ask me. They shouldn't be shown it -- it should get filtered out as a non-available package. Otherwise, people would have all kinds of problems with arch-specific packages Jeremy From a.badger at gmail.com Sat Jun 2 00:07:08 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 01 Jun 2007 17:07:08 -0700 Subject: Fedora 8 Schedule In-Reply-To: <20070601233313.GA11965@ee.oulu.fi> References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> <1180731487.11951.37.camel@dawkins> <20070601233313.GA11965@ee.oulu.fi> Message-ID: <1180742828.19774.94.camel@localhost.localdomain> On Sat, 2007-06-02 at 02:33 +0300, Pekka Pietikainen wrote: > On Fri, Jun 01, 2007 at 10:58:07PM +0200, David Nielsen wrote: > > I hear KDE 4.1 is aimed at being a 6 month release, this would then mean > > we align nicely for a F9 with KDE4 and GNOME 2.22. That would accomplice > > the goal of adjusting the schedule which was aimed for rather nicely.. > > provided neither projects slips their release date. > Why does the KDE spin have to be released at the same time as the general > GNOME-oriented release? The reason is that the distro as a whole has a release at that time, not just The GNOME spin or KDE spin, Server Spin, or etc. So if we ship KDE3 as part of the distro wide release we probably don't want to ship KDE4 as an update... at least, not without having kde3 compatibility packages which Rex and Kevin think will be a fair amount of work. Could we decide that our next release will revolve around spins instead of a distro-wide freeze? Yes, but I don't think it's a realistic goal for five months from now. We'd probably want to change the way we do branching of cvs for releases and tagging of packages so that each spin could have a different release tree if the need to make changes arose. But we'd still need to have changes pushed back to a "mainline" so we didn't have twenty different forks of Fedora, just temporary deviations for when a spin was freezing for release. We'd also have to figure out how to make sane bugzilla components for these things, decide how to manage EOL issues for different spins, come up with a way for updates to target different spins, etc. All in all, it would be a huge set of changes to the way we build Fedora and we should carefully weigh the benefits before deciding we want to do the work to make it a reality. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat Jun 2 00:11:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 20:11:32 -0400 Subject: construct to do 'if not' in rpm specs Message-ID: <200706012011.32686.jkeating@redhat.com> I need to do a construct in an rpm spec: if value if not othervalue stuff endif endif but my google skills are lacking finding the construct to do a generic 'if not' in a spec file... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From naheemzaffar at gmail.com Sat Jun 2 00:08:01 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 2 Jun 2007 01:08:01 +0100 Subject: Firefox 2.0 fails to install Flash 9 plugin In-Reply-To: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> References: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> Message-ID: <3adc77210706011708i2ee4503cg5e80656f9c1b8ec2@mail.gmail.com> Works for me. I tried on i686 as root. Did you restart firefox after yum update? That did throw up some issues for me til I restarted. (stupid me had firefox open when updating via yum - and then was puzzled at the hoard of firefox related errors. All gone after restarting firefox) On 02/06/07, Valent Turkovic wrote: > Firefox 2.0 fails to install Flash 9 plugin - for me personally this > is a minor bug but for standard desktop user (let's call him John) it > is a major problem. > > Check out BZ: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242175 > > Please look at the video, it shows that this error is repeatable: > http://www.youtube.com/watch?v=-_ayaoEUHZ4 > > Regards > Valent > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241 > Skype: valent.turkovic > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jspaleta at gmail.com Sat Jun 2 00:20:53 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 16:20:53 -0800 Subject: Firefox 2.0 fails to install Flash 9 plugin In-Reply-To: <3adc77210706011708i2ee4503cg5e80656f9c1b8ec2@mail.gmail.com> References: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> <3adc77210706011708i2ee4503cg5e80656f9c1b8ec2@mail.gmail.com> Message-ID: <604aa7910706011720x7d2db7efkd7deb6b9c0885cdc@mail.gmail.com> On 6/1/07, Naheem Zaffar wrote: > Works for me. I tried on i686 as root. Does it work as a normal user. I just did this on my rawhide box... it works just fine for me as a normal user. I'd have to wait till a revert one of my rawhide boxes to f7 to be 100% sure its a comparable situation...but i'd be a little shocked if at this point my rawhide box worked but f7 didn't since there hasnt been that much diversion between the two yet. -jef From lightsolphoenix at gmail.com Sat Jun 2 00:42:27 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Fri, 1 Jun 2007 20:42:27 -0400 Subject: construct to do 'if not' in rpm specs In-Reply-To: <200706012011.32686.jkeating@redhat.com> References: <200706012011.32686.jkeating@redhat.com> Message-ID: <200706012042.27987.lightsolphoenix@gmail.com> On Friday, June 01, 2007 8:11 pm Jesse Keating wrote: > I need to do a construct in an rpm spec: > > if value > if not othervalue > stuff > endif > endif > > but my google skills are lacking finding the construct to do a generic 'if > not' in a spec file... I was under the distinct impression that the .spec file is simply a bunch of BASH scripts... -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From naheemzaffar at gmail.com Sat Jun 2 00:43:19 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 2 Jun 2007 01:43:19 +0100 Subject: Firefox 2.0 fails to install Flash 9 plugin In-Reply-To: <604aa7910706011720x7d2db7efkd7deb6b9c0885cdc@mail.gmail.com> References: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> <3adc77210706011708i2ee4503cg5e80656f9c1b8ec2@mail.gmail.com> <604aa7910706011720x7d2db7efkd7deb6b9c0885cdc@mail.gmail.com> Message-ID: <3adc77210706011743q6043ff3cgb4ab967e182192c8@mail.gmail.com> On 02/06/07, Jeff Spaleta wrote: > On 6/1/07, Naheem Zaffar wrote: > > Works for me. I tried on i686 as root. > > Does it work as a normal user. > Just tried.. and it doesn't. (I was surprised that I had to re install it as I had always thought installing it as root installed it for all users? or is that just if you use the mplug rpm?) From peter at thecodergeek.com Sat Jun 2 01:26:41 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 01 Jun 2007 18:26:41 -0700 Subject: construct to do 'if not' in rpm specs In-Reply-To: <200706012011.32686.jkeating@redhat.com> References: <200706012011.32686.jkeating@redhat.com> Message-ID: <1180747601.3532.2.camel@tuxhugs> On Fri, 2007-06-01 at 20:11 -0400, Jesse Keating wrote: > I need to do a construct in an rpm spec: > > if value > if not othervalue > stuff > endif > endif Perhaps not the most elegant solution, but would would using only the else clause suffice? %if ## This space intentionally left blank. :) %else do_stuff --arg1 --arg2 %end -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat Jun 2 00:28:13 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 01 Jun 2007 17:28:13 -0700 Subject: construct to do 'if not' in rpm specs In-Reply-To: <200706012011.32686.jkeating@redhat.com> References: <200706012011.32686.jkeating@redhat.com> Message-ID: <1180744093.19774.96.camel@localhost.localdomain> On Fri, 2007-06-01 at 20:11 -0400, Jesse Keating wrote: > I need to do a construct in an rpm spec: > > if value > if not othervalue > stuff > endif > endif > > but my google skills are lacking finding the construct to do a generic 'if > not' in a spec file... > %if %{value} %if ! %{othervalue} stuff %endif %endif http://docs.fedoraproject.org/drafts/rpm-guide-en/ch10s06.html#id2981284 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat Jun 2 01:48:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 21:48:20 -0400 Subject: construct to do 'if not' in rpm specs In-Reply-To: <200706012011.32686.jkeating@redhat.com> References: <200706012011.32686.jkeating@redhat.com> Message-ID: <200706012148.24085.jkeating@redhat.com> On Friday 01 June 2007 20:11:32 Jesse Keating wrote: > I need to do a construct in an rpm spec: > > if value > ? if not othervalue > ? ? stuff > ? endif > endif > > but my google skills are lacking finding the construct to do a generic 'if > not' in a spec file... Thanks for the suggestions, however I realized I needed to to do something slightly different, and could use a comparison for it: %if value %if 0{?%rhel} > 4 stuff %endif %endif -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at thecodergeek.com Sat Jun 2 02:11:24 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 01 Jun 2007 19:11:24 -0700 Subject: [Fwd: Fedora Core 6 Update: lftp-3.5.9-0.fc6] In-Reply-To: <465ED601.1000705@unb.ca> References: <465ED601.1000705@unb.ca> Message-ID: <1180750284.6346.3.camel@tuxhugs> On Thu, 2007-05-31 at 11:04 -0300, John DeDourek wrote: > The attached announcement for lftp, version 3.5.9, release 0.fc6 > was received yesterday. However, my yum.log file on my FC6 box > shows an update to lftp.i386.3.5.9-8.fc6 on Apr 13, 2007. Yum > did not update lftp today (May 31). > > I am confused. What have I missed? It's probably a mishap with the update notifications or your mail server. The notification lists a date of April 4, which means this is nearly two months old and can be safely ignored so late after the fact. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Sat Jun 2 02:14:47 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 01 Jun 2007 19:14:47 -0700 Subject: construct to do 'if not' in rpm specs In-Reply-To: <1180744093.19774.96.camel@localhost.localdomain> References: <200706012011.32686.jkeating@redhat.com> <1180744093.19774.96.camel@localhost.localdomain> Message-ID: <1180750487.6346.5.camel@tuxhugs> On Fri, 2007-06-01 at 17:28 -0700, Toshio Kuratomi wrote: > %if %{value} > %if ! %{othervalue} > stuff > %endif > %endif RPM conditionals and simplicity hand-in-hand...who knew? :) Thanks, Toshio. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Sat Jun 2 02:21:31 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Jun 2007 21:21:31 -0500 Subject: How to request a new review for a package of mine? In-Reply-To: <200706011326.23569@rineau.tsetse> References: <200706011326.23569@rineau.tsetse> Message-ID: >>>>> "LR" == Laurent Rineau writes: LR> I would like to ask a new review, for the package that I have LR> pushed to Rawhide. Should?I open a new Review Request, in BZ, or LR> re-open bug #199168 (CGAL's RR)? I would open a new request (so that there's no confusion about who is assigned to the ticket or over the blockers) and just reference the old ticket. LR> If I want to push CGAL-3.3 to Fedora?Extras 5 and 6 and Fedora?7, LR> should I create a compat-CGAL-3.2 package, knowing that no Fedora LR> package depends on CGAL? We should take care not to break user-build code as well during a release. Is there some compelling reason to push the updated code out to released versions of the distro? - J< From buytenh at wantstofly.org Sat Jun 2 03:29:55 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Sat, 2 Jun 2007 05:29:55 +0200 Subject: fedora for ARM Message-ID: <20070602032955.GC16918@xi.wantstofly.org> Hi all, I haven't been active on this mailing list since 2004 or so, so let me (re-)introduce myself. I'm Lennert Buytenhek, and I live in the Netherlands. As far as open source contributions go (other things I've done probably aren't very interesting), in the past I have written an ext2 resizer (called ext2resize), contributed ext2 support to PartEd, rewrote the bridging support in Linux 2.3.something, hacked on User Mode Linux, and a bunch of other stuff, and these days, among other things, I am occasionally seen hacking on ARM Linux kernel Things. Recently, I produced an unofficial (but-seems-to-work-all-right) port of FC6 to the ARM architecture (after having ported FC2/3/4 to ARM in the past): http://ftp.linux.org.uk/pub/linux/arm/fedora/ The current set of diffs[*][**] is available for inspection here: http://ftp.linux.org.uk/pub/linux/arm/fedora/diffs/ I'm posting here because I would really really like to get the relevant diffs merged back into Fedora. I believe that ARM is well-supported in the various upstream projects that Fedora packages, and so this should be a relatively painless process (if you look at the diffs referenced above, most diffs are actually only spec file changes to cope with the addition of a new architecture.) I'll follow up with a mail with thoughts about secondary architectures. thanks, Lennert [*] Some of which were produced by Russell King (ARM Linux kernel maintainer) or Ralph Siemsen (Netwinder project.) [**] NB: not necessarily the same set that we'll end up submitting for inclusion. From buytenh at wantstofly.org Sat Jun 2 03:42:06 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Sat, 2 Jun 2007 05:42:06 +0200 Subject: thoughts about secondary architectures Message-ID: <20070602034206.GF16918@xi.wantstofly.org> Reply-To: Hi, I have read the recent 'secondary architectures' thread with interest. (Sorry for joining in late and breaking the thread and such.) My view is that it's clear that most of the people hacking on Fedora and using Fedora care only about x86/x86_64 systems, and that I (and the other people who are interested in secondary architectures) should try as much as possible to avoid making the lives of the x86 people difficult, if we ever want to have a chance of getting our patches merged without pissing everyone else off. After some thinking, I guess I am of the opinion (in case my opinion counts for anything) that build failures on secondary architectures should probably not affect primary architectures. Mostly for the reason above. While it is very well possible that there is some bug in a package that does not surface on x86, 99.9% of the Fedora developers are unlikely to care about that if the package builds OK on x86 and no ill effects are seen on x86. >From a purely technical point of view I would advocate that a build failure on any architecture fails the package build, but there will only have to be 3 or 4 cases where some gcc ICE causes some package to fail to build on some secondary architecture but build fine on x86 and the x86 people will hate us forever afterwards, and will eventually start clamoring that getting all these secondary architectures on board was a bad idea to begin with. (Which, of course, would be totally understandable at that point.) There is a similar issue with build speed. While my fastest ARM box (800 MHz with 512K L2 cache) is quite snappy as far as ARM systems go, it is probably no match for even the crappiest of x86 boxes. The fastest ARM CPU I know of is a dual core 1.2GHz, which is still no match for x86. This doesn't mean, IMHO, that it makes no sense to run Fedora on ARM systems. But it does mean that if the building of packages on primary architectures is throttled at the speed of building packages on ARM, we're going to make a lot of (x86) Fedora developers very sad, angry, frustrated, or all of the above. So, IMHO, ideally, the existence of secondary architectures should not significantly affect the typical workflow of an x86 Fedora developer, and secondary architectures should not negatively affect development on x86. If that means that the secondary arch maintainers will have to work twice as hard or three times as hard, then so be it (speaking as a potential future secondary arch maintainer!) -- if your architecture is not in the position of representing 99% of the Fedora userbase, you'd better have very good arguments for having your architecture be included in Fedora. Just my 2ct. thanks, Lennert From rc040203 at freenet.de Sat Jun 2 03:55:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jun 2007 05:55:15 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <604aa7910706010952i6906466eo934d57c644bd714@mail.gmail.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> <46603F7D.1050407@fedoraproject.org> <1180714860.12595.361.camel@mccallum.corsepiu.local> <604aa7910706010952i6906466eo934d57c644bd714@mail.gmail.com> Message-ID: <1180756515.12595.412.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 08:52 -0800, Jeff Spaleta wrote: > On 6/1/07, Ralf Corsepius wrote: > > Nope, that's mathematics, get yourself a book on logic or similar ... > > Rigorous mathematical logic analysis is an extremely poor toolset to > bring to bear on human designed policy structures.... You mean ... because human imperfectness tends to switch off logic because humans are tempted to follow their limited horizons and perception? > my wife > reaffirms that for me quite often when I attempt to use the strictures > of logic to understand the decision making processes she is using. So > in the context of this discussion, I think Rahul's reaction isn't so > much out of place. I find Rahul's reaction absurd, because we are talking about technical issues and technical standards/metrics here, which I don't see any reason not to apply logic to. Ralf From rc040203 at freenet.de Sat Jun 2 04:08:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jun 2007 06:08:11 +0200 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706011139.04795.jkeating@redhat.com> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706011437.59049.opensource@till.name> <1180708542.12595.295.camel@mccallum.corsepiu.local> <200706011139.04795.jkeating@redhat.com> Message-ID: <1180757291.12595.420.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 11:39 -0400, Jesse Keating wrote: > On Friday 01 June 2007 10:35:42 Ralf Corsepius wrote: > > I had brought this topic up many months ago, but it was shot down by > > Jesse and Dennis. A real pity, IMO. > > We've obviated the need for buildsys-macros by having the definitions provided > in it inside redhat-rpm-config. > > We could get rid of buildsys-build by making a perhaps 'hidden' group within > comps that is the buildsys-build group, since mock can easily do a > groupinstall instead of a package install to populate the buildroot. These > two things together would obviate the need for a separate repo all together. I think we are talking past each other. What I am referring to is to package the contents of http://buildsys.fedoraproject.org/buildgroups into an rpm being shipped as part of Fedora (e.g. as /usr/share/mock/buildgroups) and to let Fedora's standard mock configuration (/etc/mock) refer to these files on a local disk. This would avoid mock having to contact http://b.fp.o each time it is invoked (avoids network traffic). It also avoids local mock builds to fail when b.fp.o is non-reachable. Ralf From jkeating at redhat.com Sat Jun 2 04:14:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 00:14:58 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <1180757291.12595.420.camel@mccallum.corsepiu.local> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706011139.04795.jkeating@redhat.com> <1180757291.12595.420.camel@mccallum.corsepiu.local> Message-ID: <200706020014.58292.jkeating@redhat.com> On Saturday 02 June 2007 00:08:11 Ralf Corsepius wrote: > What I am referring to is to package the contents of > http://buildsys.fedoraproject.org/buildgroups > > into an rpm being shipped as part of Fedora (e.g. > as /usr/share/mock/buildgroups) and > to let Fedora's standard mock configuration (/etc/mock) refer to these > files on a local disk. > > This would avoid mock having to contact http://b.fp.o each time it is > invoked (avoids network traffic). It also avoids local mock builds to > fail when b.fp.o is non-reachable. Or instead obviate the need for those packages all together by having the buildgroup definition in the stock comps file, the rest of the macros defined in redhat-rpm-config, and accomplish the same goal. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bojan at rexursive.com Sat Jun 2 04:22:26 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 2 Jun 2007 04:22:26 +0000 (UTC) Subject: if this is a bug then it is a nasty BLOCKER for F7 References: <64b14b300705280631o2a5bb40fs2f7d3d9df65a01db@mail.gmail.com> <1180513221.2573.10.camel@localhost.localdomain> Message-ID: Bojan Smojver rexursive.com> writes: > Once I find out what's actually causing the hangs, I'll report > back. Surprisingly enough, it's b44. That didn't need to be blacklisted in FC6. Looks like a regression. -- Bojan From lightsolphoenix at gmail.com Sat Jun 2 04:32:49 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 2 Jun 2007 00:32:49 -0400 Subject: Potential errors in the KDE LiveCD Message-ID: <200706020032.49789.lightsolphoenix@gmail.com> Okay, I performed a hard drive install off the KDE LiveCD, and caught a couple of problems: 1) I keep getting an error from DBus because it still contains references to gdm, even though the KDE LiveCD uses kdm. 2) Actually, I don't know if this is specifically a KDE LiveCD problem, but I noticed an odd problem... During the default startup, the system is set up to start DBus, then NetworkManager to get the 'Net connection. The problem is DBus will not start if the system has been set up to get account information over a network connection if the connection has not already been established. However, NetworkManager refuses to start before DBus starts. Ultimately, the only solution I found was to reactivate the default network startup, so DBus could contact the network system for account information before NetworkManager started. Is this just a problem I seem to be experiencing? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From kevin at scrye.com Sat Jun 2 04:37:29 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 1 Jun 2007 22:37:29 -0600 Subject: Fedora 8 Schedule In-Reply-To: References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> Message-ID: <20070601223729.7a5bb06d@ghistelwchlohm.scrye.com> On Fri, 1 Jun 2007 14:16:17 +0000 (UTC) kevin.kofler at chello.at (Kevin Kofler) wrote: > I wrote: > > worse, because this means it's misaligned with both the GNOME and > > KDE schedules, at least one of which is central to every desktop > > user's experience of Fedora. > > Whoops, let's make this "most desktop users' experience", lest we > anger the XFCE and lightweight WM users. Sorry for that. ;-) :) Just as a data point Xfce is not on a time based release cycle. The next version will be ready when its ready. > Kevin Kofler kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at redhat.com Sat Jun 2 05:24:30 2007 From: buildsys at redhat.com (Build System) Date: Sat, 2 Jun 2007 01:24:30 -0400 Subject: rawhide report: 20070601 changes Message-ID: <200706020524.l525OU7X002727@porkchop.devel.redhat.com> New package alexandria Book collection manager New package bigboard Sidebar application launcher using mugshot.org New package firewalk Active reconnaissance network security tool New package gnome-vfs2-obexftp ObexFTP over Bluetooth support for GNOME New package perl-Crypt-OpenSSL-X509 Perl interface to OpenSSL for X509 New package perl-Net-IPv6Addr Perl module to check validity of IPv6 addresses New package remind A sophisticated calendar and alarm program New package revisor Fedora "Spin" Graphical User Interface Updated Packages: CGAL-3.3-0.1.RC1.fc8 -------------------- * Wed May 30 2007 Laurent Rineau - 3.3-0.1.RC1.fc8 - New upstream version: 3.3-RC1 - Obsolete patches CGAL-3.2.1-build-libCGALQt-shared.patch, CGAL-3.2.1-build-no-static-lib.patch, CGAL-3.2.1-config.h-endianness_detection.patch. These patchs have been merged and adapted by upstream. - New option --disable-static - Shipped OpenNL and CORE have been renamed by upstream: - %{_includedir}/OpenNL is now /usr/include/CGAL/OpenNL - %{_includedir}/CORE is now /usr/include/CGAL/CORE - libCORE has been rename libCGALcore++ Reasons: - CGAL/OpenNL is a special version of OpenNL, rewritten for CGAL in C++ by the OpenNL author, - CGAL/CORE is a fork of CORE-1.7. CORE-1.7 is no longer maintained by its authors, and CORE-2.0 is awaited since 2004. In previous releases of this package, CORE was excluded from the package, because %{_includedir}/CORE/ was a name too generic (see comment #8 of %{_includedir}/CGAL/CORE, CORE is now shipped with CGAL. - move %{_datadir}/CGAL/make/makefile to %{_sysconfdir}/CGAL/makefile (because it is a config file). alsa-utils-1.0.14-0.7.rc2.fc8 ----------------------------- * Wed May 30 2007 Martin Stransky 1.0.14-0.7.rc2 - updated alsanumute for Siemens Lifebook S7020 (#241639) - unmute Master Mono for all drivers * Wed May 02 2007 Martin Stransky 1.0.14-0.6.rc2 - added fix for #238442 (unmute Mono channel for w4550, xw4600, xw6600, and xw8600) blam-1.8.3-4.fc8 ---------------- * Wed May 30 2007 Peter Gordon - 1.8.3-4 - Add a patch to fix the default theme directory search path to prevent crashes at startup (fixes bug 241465): + fix-THEME_DIR-path.patch bluez-utils-3.11-2.fc8 ---------------------- * Fri Jun 01 2007 - Bastien Nocera - 3.11-2 - Add upstream patch to list discovered printer devices in the CUPS backend bootparamd-0.17-25.fc8 ---------------------- * Wed May 30 2007 Ondrej Dvoracek - 0.17-25 - corrected init script (#237824) bugzilla-3.0-3.fc7 ------------------ * Thu May 31 2007 John Berninger - 3.0-3 - Update tag for F-7 branch * Fri May 18 2007 John Berninger - 3.0-2 - update Requires for bz's 241037, 241206 * Fri May 18 2007 John Berninger - 3.0-1 - update to upstream version 3.0 - add new dependencies on mod_perl, perl-SOAP-Lite - refactor patch(es) to change paths for read-only /usr busybox-1:1.5.1-2.fc8 --------------------- * Fri Jun 01 2007 Ivana Varekova - 1:1.5.1-2 - add msh shell cfengine-2.2.1-1.fc8 -------------------- * Wed May 30 2007 Jeff Sheltren 2.2.1-1 - Update to upstream 2.2.1 - Remove SELinux patch (included upstream) * Fri May 11 2007 Jeff Sheltren 2.2.0-1 - Update to upstream 2.2.0 - No longer need automake,autoconf for build * Wed Apr 25 2007 Jeff Sheltren 2.1.22-4 - Update SELinux patch charis-fonts-4.100-1.fc8 ------------------------ * Thu May 31 2007 Nicolas Mailhot ??? 4.100-1 ??? add fontconfig setup file ??? make spec closer to the dejavu one to simplify maintenance clamav-0.90.3-1.fc8 ------------------- * Thu May 31 2007 Enrico Scholz - 0.90.3-1 - updated to 0.90.3 - BR tcpd.h instead of tcp_wrappers(-devel) to make it build both in FC6- and F7+ ctapi-cyberjack-3.0.0beta1-2.fc8 -------------------------------- * Thu May 31 2007 Frank B??ttner - 3.0.0beta1-2.fc8 - rebuild with the missing file * Tue May 08 2007 Frank B??ttner - 3.0.0beta1-1.fc8 - first build for the new version * Fri May 04 2007 Frank B??ttner - 2.0.14-2.fc8 - rebuild for the ppc64 arch dejavu-fonts-2.17-3.fc8 ----------------------- * Thu May 31 2007 Nicolas Mailhot ??? 2.17-3 ??? small spec cleanups dwatch-0.1.1-3.fc8 ------------------ epiphany-extensions-2.19.2-1 ---------------------------- * Wed May 30 2007 Peter Gordon - 2.19.2-1 - Update to new upstream release (2.19.2); and rebuild for newer Firefox/Gecko version (2.0.0.4). evolution-2.11.2-2.fc8 ---------------------- * Thu May 31 2007 Matthew Barnes - 2.11.2-2.fc8 - Evolution no longer requires libgnomeprint[ui]. * Fri May 18 2007 Matthew Barnes - 2.11.2-1.fc8 - Update to 2.11.2 - Bump evo_major to 2.12. - Bump eds_version to 1.11.0. - Update files with new plugins and icons. - Remove patch for RH bug #190359 (fixed upstream). - Remove patch for RH bug #218801 (fixed upstream). - Remove patch for RH bug #234315 (fixed upstream). - Remove patch for RH bug #236399 (fixed upstream). - Remove patch for RH bug #236860 (fixed upstream). - Remove patch for RH bug #238551 (fixed upstream). - Remove patch for GNOME bug #373837 (fixed upstream). - Remove patch for GNOME bug #373116 (fixed upstream). - Remove patch for GNOME bug #418971 (fixed upstream). - Remove patch for GNOME bug #419469 (fixed upstream). - Remove patch for GNOME bug #419524 (fixed upstream). - Remove evolution-2.6.0-prototypes.patch (obsolete). * Wed May 16 2007 Matthew Barnes - 2.10.1-17.fc7 - Revise patch for GNOME bug #362638 to fix RH bug #237206 (certificate prompt causes crash, again). evolution-connector-2.11.2-2.fc8 -------------------------------- * Fri Jun 01 2007 Matthew Barnes - 2.11.2-2.fc8 - List static ldap libraries in the proper order. - Compile with -Werror. * Fri May 18 2007 Matthew Barnes - 2.11.2-1.fc8 - Update to 2.11.2 - Bump evo_version to 2.11.0, eds_version to 1.11.0, and evo_major to 2.12. - Remove evolution-exchange-2.5.3-fix-marshaller.patch (obsolete). - Remove patch for GNOME bug #405916 (fixed upstream). * Thu Apr 26 2007 Matthew Barnes - 2.10.1-3.fc7 - Regenerate configure to pick up 64-bit changes to acinclude.m4. - Require autoconf and automake to build. evolution-data-server-1.11.2-3.fc8 ---------------------------------- * Thu May 31 2007 Matthew Barnes - 1.11.2-3.fc7 - Revise patch for GNOME bug #376991 to fix RH bug #241974. fedora-package-config-apt-7.89-8 -------------------------------- * Fri Jun 01 2007 Axel Thimm - 7.89-8 - Update to post-F7. * Fri Jun 01 2007 Axel Thimm - 7-7 - Update to F7. fedora-package-config-smart-7.89-9 ---------------------------------- * Fri Jun 01 2007 Axel Thimm - 7.89-9 - Update to post-F7 rawhide. * Fri Jun 01 2007 Axel Thimm - 7-8 - Update to Fedora 7. fedora-release-7.89-1 --------------------- * Wed May 30 2007 Jesse Keating - 7.89-1 - And we're back to rawhide. Re-enable devel repos * Thu May 24 2007 Jesse Keating - 7-3 - We have a name! - Require the newer release notes * Mon May 21 2007 Jesse Keating - 7-2 - Use Everything in the non-mirror URL to the release tree firefox-2.0.0.4-1.fc8 --------------------- * Wed May 30 2007 Christopher Aillon 2.0.0.4-1 - Final version * Wed May 23 2007 Christopher Aillon 2.0.0.4-0.rc3 - Update to 2.0.0.4 RC3 * Tue Apr 17 2007 Christopher Aillon 2.0.0.3-4 - Fix permissions of the man page freetype-2.3.4-3.fc8 -------------------- * Thu May 31 2007 Behdad Esfahbod 2.3.4-3 - Add freetype-2.3.4-ttf-overflow.patch * Thu Apr 12 2007 Behdad Esfahbod 2.3.4-2 - Add alpha to 64-bit archs (#236166) fribidi-0.10.8-1.fc8 -------------------- * Thu May 31 2007 Caolan McNamara 0.10.8-1 - next version funtools-1.3.0-0.5.b33.fc8 -------------------------- * Thu May 03 2007 Sergio Pascual 1.3.0-0.5.b33 - New upstream version fuse-convmvfs-0.2.4-1.fc8 ------------------------- * Fri Jun 01 2007 ZC Miao - 0.2.4-1 - update to 0.2.4 galeon-2.0.3-9.fc7 ------------------ * Fri Jun 01 2007 Denis Leroy - 2.0.3-9 - Rebuild with gecko-libs 1.8.1.4 gimp-2:2.2.15-1.fc8 ------------------- * Thu May 31 2007 Nils Philippsen - 2:2.2.15-1 - version 2.2.15 Bugs fixed in GIMP 2.2.15 ========================= - fixed parsing of GFig files with CRLF line endings (bug #346988) - guard against a possible stack overflow in the Sunras loader (bug #433902) - fixed definition of datarootdir in gimptool-2.0 (bug #436386) - fixed Perspective tool crash on Mac OS X (bug #349483) - fixed area resizing in the Image Map plug-in (bug #439222) - added missing library in gimptool-2.0 --libs output - added new localizations: Occitan and Persian - remove obsolete sunras-overflow patch gossip-0.25-3.fc8 ----------------- * Wed May 30 2007 Brian Pepple - 0.25-3 - Bump the minimum version of loudmouth needed. (#241752) hal-cups-utils-0.6.10-1.fc8 --------------------------- * Wed May 30 2007 Tim Waugh 0.6.10-1 - 0.6.10: - Use new D-Bus interface, NewPrinterNotification. halberd-0.2.2-2.fc8 ------------------- hotwire-0.554-3.fc8 ------------------- * Fri Jun 01 2007 Colin Walters - 0.554-3 - really add br hunspell-en-0.20061130-1.fc8 ---------------------------- hunspell-gl-0.20070504-1.fc8 ---------------------------- hunspell-hu-1.2-1.fc8 --------------------- * Fri Jun 01 2007 Caolan McNamara - 1.2-1 - next version hunspell-lt-1.1-1.20061127cvs.fc8 --------------------------------- hunspell-pl-0.20070506-1.fc8 ---------------------------- hunspell-pt-0.20070411-1.fc8 ---------------------------- initng-0.6.10.1-1.fc8 --------------------- * Thu May 31 2007 Daniel Malmgren 0.6.10.1-1 - New upstreams version - Removed macros from changelog to make rpmlint happy * Thu Mar 29 2007 Daniel Malmgren 0.6.10-2 - Include patch from che to sole console font issue * Tue Mar 27 2007 Daniel Malmgren 0.6.10-1 - New upstreams version initng-ifiles-0.1.3-1.fc8 ------------------------- * Thu May 31 2007 Daniel Malmgren 0.1.3-1 - New upstreams version - Removed the no longer needed virtcheck patch k3b-0:1.0.1-1.fc8 ----------------- * Wed May 30 2007 Rex Dieter - 0:1.0.1-1 - k3b-1.0.1 - include icon/mime scriptlets - cleanup/simplify BR's - optimize %configure - restore applnk/.hidden bits libexif-0.6.15-1.fc8 -------------------- * Wed May 30 2007 Matthias Clasen - 0.6.15-1 - Update to 0.6.15 - Drop obsolete patch libpng10-1.0.26-1.fc8 --------------------- * Sun May 20 2007 Paul Howarth 1.0.26-1 - update to 1.0.26 to address DoS issue (#240398, CVE-2007-2445) - update soname patch - libpng.txt now has a versioned filename libpqxx-2.6.9-1.fc8 ------------------- * Tue May 22 2007 Rex Dieter 2.6.9-1 - libpqxx-2.6.9 libsemanage-2.0.3-3.fc8 ----------------------- * Fri Jun 01 2007 Dan Walsh - 2.0.3-3 - Rebuild for rawhide * Thu May 03 2007 Dan Walsh - 2.0.3-2 - Apply patch to fix dependencies in spec file from Robert Scheck * Wed Apr 25 2007 Dan Walsh - 2.0.3-1 - Upgrade to latest from NSA * Fix to libsemanage man patches so whatis will work better from Dan Walsh livecd-tools-009-1.fc8 ---------------------- * Wed May 30 2007 Jeremy Katz - 009-1 - miscellaneous live config changes - fix isomd5 checking syntax error logrotate-3.7.5-5.fc8 --------------------- * Thu May 31 2007 Tomas Smetana 3.7.5-5 - fix ignoring pre/postrotate arguments (related #241766) lyx-1.5.0-0.7.rc1.fc8 --------------------- * Fri Jun 01 2007 Rex Dieter 1.5.0-0.7.rc1 - lyx-1.5.0rc1 mISDN-1.1.3-1.fc8 ----------------- * Wed May 30 2007 David Woodhouse 1.1.3-1 - Update to 1.1.3 man-pages-2.51-2.fc8 -------------------- * Thu May 31 2007 Ivana Varekova 2.51-2 - remove mount page patch - fix mmap patch * Wed May 30 2007 Ivana Varekova 2.51-1 - update to 2.51 * Mon May 21 2007 Ivana Varekova 2.49-1 - update to 2.49 mash-0.1.16-1.fc8 ----------------- * Thu May 31 2007 Bill Nottingham 0.1.16-1 - fix arch handling * Thu May 31 2007 Bill Nottingham 0.1.15-1 - propagate errors better - handle signatures in koji correctly * Wed May 30 2007 Bill Nottingham 0.1.14-1 - add a use_sqlite config option for determining whether to use createrepo -d mod_nss-1.0.7-1.fc8 ------------------- * Fri Jun 01 2007 Rob Crittenden 1.0.7-1 - Update to 1.0.7 - Remove Requires for nss and nspr since those are handled automatically by versioned libraries - Updated URL and Source to reference directory.fedoraproject.org mtools-3.9.11-1.fc8 ------------------- * Thu May 31 2007 Adam Tkac 3.9.11-1.fc8 - updated to latest upstream (3.9.11) * Fri May 11 2007 Adam Tkac 3.9.10-7.fc7 - in the end script has been completely rewriten by * Fri May 11 2007 Adam Tkac 3.9.10-6.fc7 - some minor changes in sh patch (changed sh to bash) nagios-2.7-2.fc8 ---------------- nautilus-actions-1.4.1-1.fc8 ---------------------------- * Thu May 03 2007 Deji Akingunola - 1.4.1-1 - New (bug-fix) release nfswatch-4.99.9-1.fc8 --------------------- * Wed May 30 2007 Christian Iseli 4.99.9-1 - new upstream version nss-3.11.7-2.fc8 ---------------- * Fri Jun 01 2007 Kai Engert - 3.11.7-2 - Update to 3.11.7, but freebl/softokn remain at 3.11.5. - Use a workaround to avoid mozilla bug 51429. openoffice.org-1:2.2.1-18.1.fc8 ------------------------------- * Thu May 31 2007 Caolan McNamara - 1:2.2.1-18.1 - next 2.2.1 release candidate - add Jan's stocmerge.all.patch paps-0.6.6-20.fc8 ----------------- * Wed May 30 2007 Akira TAGOH - 0.6.6-20 - Fix to not do wordwrap when 'wrap=false' is given. (#240588) pciutils-2.2.5-1.fc8 -------------------- * Thu May 31 2007 Harald Hoyer - 2.2.5-1 - version 2.2.5 perl-Algorithm-C3-0.07-1.fc8 ---------------------------- * Thu May 31 2007 Chris Weyl 0.07-1 - update to 0.07 - include t/ in doc - minor spec reworkage to deal with the once and future perl split perl-AppConfig-1.65-1.fc8 ------------------------- * Thu May 31 2007 Jose Pedro Oliveira - 1.65-1 - Update to 1.65. perl-Archive-Extract-0.22-1.fc8 ------------------------------- * Wed May 30 2007 Steven Pritchard 0.22-1 - Update to 0.22. perl-CGI-Ex-2.13-1.fc8 ---------------------- * Thu May 31 2007 Chris Weyl 2.13-1 - update to 2.13 perl-Class-C3-XS-0.06-1.fc8 --------------------------- * Thu May 31 2007 Chris Weyl 0.06-1 - update to 0.06-1 perl-Class-Data-Accessor-0.04001-1.fc8 -------------------------------------- * Thu May 31 2007 Chris Weyl 0.04001-1 - update -- 0.40001 clarifies conflicting license statements perl-Class-MOP-0.38-1.fc8 ------------------------- * Thu May 31 2007 Chris Weyl 0.38-1 - update to 0.38 - add t/ to doc - minor spec rework to deal with the once and future perl split perl-ExtUtils-CBuilder-0.19-1.fc8 --------------------------------- * Thu May 31 2007 Jose Pedro Oliveira - 0.19-1 - Update to 0.19. perl-File-HomeDir-0.65-1.fc8 ---------------------------- * Wed May 30 2007 Jose Pedro Oliveira - 0.65-1 - Update to 0.65. perl-Gtk2-Notify-0.03-1.fc8 --------------------------- * Thu May 31 2007 Chris Weyl 0.03-1 - update to 0.03 - add t/ to doc - spec updates to deal with the once and future perl split perl-Image-Info-1.25-1.fc8 -------------------------- * Wed May 30 2007 Jose Pedro Oliveira - 1.25-1 - Update to 1.25. perl-JSON-XS-1.22-1.fc8 ----------------------- * Fri Jun 01 2007 Chris Weyl 1.22-1 - update to 1.22 perl-Module-CoreList-2.11-1.fc8 ------------------------------- * Wed May 30 2007 Jose Pedro Oliveira - 2.11-1 - Update to 2.11. perl-Module-Info-0.31-1.fc8 --------------------------- * Wed May 30 2007 Steven Pritchard 0.31-1 - Update to 0.31. perl-Module-Versions-Report-1.03-1.fc8 -------------------------------------- * Thu May 31 2007 Jose Pedro Oliveira - 1.03-1 - Update to 1.03. - New upstream maintainer. perl-Moose-0.22-1.fc8 --------------------- * Thu May 31 2007 Chris Weyl 0.22-1 - update to 0.22 perl-Params-Util-0.25-1.fc8 --------------------------- * Wed May 30 2007 Ralf Cors??pius - 0.25-1 - Upstream update. perl-Pod-Simple-3.05-1.fc8 -------------------------- * Wed May 30 2007 Jose Pedro Oliveira - 3.05-1 - Update to 3.05. policycoreutils-2.0.19-2.fc8 ---------------------------- * Fri Jun 01 2007 Dan Walsh 2.0.19-2 - Fix genhomedircon to work in stage2 builds of anaconda pulseaudio-0.9.6-2.fc8 ---------------------- * Tue May 29 2007 Pierre Ossman 0.9.6-2 - Add libatomic_ops-devel as a build requirement. * Tue May 29 2007 Pierre Ossman 0.9.6-1 - Upgrade to 0.9.6. pungi-0.3.7-1.fc8 ----------------- * Wed May 30 2007 Jesse Keating - 0.3.7-1 - Handle the cdsize variable correctly - More fixes for cached download stuff - Fix default CD size storing - Update comps file with what shipped for F7 * Fri May 25 2007 Jesse Keating - 0.3.6-1 - Handle the cdsize variable correctly * Thu May 24 2007 Jesse Keating - 0.3.5-1 - Use the right flavor in the Everything configs python-2.5.1-1.fc8 ------------------ * Thu May 31 2007 Jeremy Katz - 2.5.1-1 - update to python 2.5.1 * Mon Mar 19 2007 Jeremy Katz - 2.5.3-12 - fix alpha build (#231961) * Tue Feb 13 2007 Jeremy Katz - 2.5.3-11 - tcl/tk was reverted; rebuild again python-urlgrabber-3.0.0-1.fc8 ----------------------------- * Thu May 31 2007 Jeremy Katz - 3.0.0-1 - update to 3.0.0 qt4-4.3.0-2.fc8 --------------- * Wed May 30 2007 Rex Dieter 4.3.0-2 - ExclusiveArch: %ix86 -> i386 (for koji) * Wed May 30 2007 Rex Dieter 4.3.0-1 - qt-4.3.0(final) * Fri May 04 2007 Kevin Kofler 4.3.0-0.5.rc1 - update to 4.3.0 RC1 - drop LD_RUN_PATH hack referencer-1.0.4-1.fc8 ---------------------- * Thu May 31 2007 Deji Akingunola - 1.0.4-1 - New release ruby-gnome2-0.16.0-6.fc8 ------------------------ * Thu May 31 2007 Allisson Azevedo 0.16.0-6 - New gecko engine scim-1.4.6-3.fc8 ---------------- * Wed May 30 2007 Jens Petersen - 1.4.6-3 - save the hotkey for lang in initial-locale-hotkey-186861.patch again * Tue May 29 2007 Jens Petersen - 1.4.6-2 - fix initial-locale-hotkey-186861.patch to read system hotkey config correctly (reported by Eugene Teo, #241629) * Mon May 21 2007 Jens Petersen - 1.4.6-1 - update to 1.4.6 release - scim_panel-observe-workarea-xprop-204442.patch and scim_x11_frontend-ic-focus-LTC27940-215953.patch are no longer needed - update scim-1.4.5-panel-menu-fixes.patch and scim_panel_gtk-icon-size-fixes.patch scim-anthy-1.2.4-1.fc8 ---------------------- * Wed May 30 2007 Akira TAGOH - 1.2.4-1 - New upstream release. - we don't need the below patches anymore: - scim-anthy-helper-moduledir.patch - scim-anthy-1.2.2-gettextize.patch - scim-anthy-1.2.0-fix-no-n-candidates.patch seamonkey-1.1.2-2.fc8 --------------------- * Thu May 31 2007 Kai Engert 1.1.2-2 - SeaMonkey 1.1.2 spandsp-0.0.4-0.1.pre2.fc8 -------------------------- syslog-ng-2.0.4-3.fc8 --------------------- * Thu May 31 2007 Jose Pedro Oliveira - 2.0.4-3 - Increase the number of unix-stream max-connections (10 -> 32). system-config-bind-4.0.2-8.fc8 ------------------------------ * Wed May 30 2007 Ondrej Dvoracek - 4.0.2.8 - Corrected summary in spec file (#234102) * Wed Apr 25 2007 Ondrej Dvoracek - 4.0.2.7 - Removed broken URL (#237363) system-config-printer-0.7.66-1.fc8 ---------------------------------- * Wed May 30 2007 Tim Waugh 0.7.66-1 - 0.7.66: - Allow job-hold-until to be set (bug #239776). - Implement new printer notifications. tasks-0.7-2.fc8 --------------- * Tue May 29 2007 Dan Young - 0.7-2 - Update URLs * Mon May 28 2007 Dan Young - 0.7-1 - New upstream release tor-0.1.2.14-1.fc8 ------------------ * Sat May 26 2007 Enrico Scholz - 0.1.2.14-1 - updated to 0.1.2.14 util-vserver-0.30.213-1.fc8 --------------------------- * Thu May 31 2007 Enrico Scholz - 0.30.213-1 - updated to 0.30.213 - disabled dietlibc build for PPC64 - enabled support for 'util-vserver' initscript * Fri Apr 20 2007 Enrico Scholz - 0.30.212-4 - BR some tools tested by ./configure wallpapoz-0.4-1.fc8 ------------------- * Thu May 31 2007 Mamoru Tasaka - 0.4-1 - 0.4 release! xchat-1:2.8.2-7.fc8 ------------------- * Thu May 31 2007 Kevin Kofler - 1:2.8.2-7 - revert to redhat-desktop patch pending further discussion * Thu May 31 2007 Kevin Kofler - 1:2.8.2-6 - apply xc282-fixtrayzombies.diff from upstream xfce4-mixer-4.4.1-2.fc8 ----------------------- * Wed May 30 2007 Kevin Fenzi - 4.4.1-2 - Build with ALSA instead of OSS (fixes bug #239513) xfsdump-2.2.45-1.fc8 -------------------- * Thu May 31 2007 Eric Sandeen - 2.2.45-1 - Update to xfsdump 2.2.45 xfsprogs-2.8.20-2.fc8 --------------------- * Thu May 31 2007 Eric Sandeen 2.8.20-2 - Fix ppc64 build... again * Fri May 25 2007 Eric Sandeen 2.8.20-1 - Upgrade to xfsprogs 2.8.20, several xfs_repair fixes xorg-x11-drv-vesa-1.3.0-7.fc8 ----------------------------- * Thu May 31 2007 Adam Jackson 1.3.0-7 - Attempt to fix vesa crash of doom. (#241491) xtide-2.9.3-2.fc8 ----------------- * Thu May 31 2007 Mamoru Tasaka - 2.9.3-2 - Ship US part tcd data, which are under public domain. yum-presto-0.3.10-1.fc8 ----------------------- * Tue May 01 2007 Jonathan Dieter - 0.3.10-1 - Use new -a option to deltarpm to only check against a certain architecture. This allows us to work completely correctly on x86_64. - Add "*" to repository of deltarpm as it *doesn't* screw up depsolving. zabbix-1.4-2.fc8 ---------------- * Wed May 30 2007 Jarod Wilson 1.4-2 - Add placeholder zabbix.conf.php From motienko at gmail.com Sat Jun 2 06:00:29 2007 From: motienko at gmail.com (Oleg Motienko) Date: Sat, 2 Jun 2007 10:00:29 +0400 Subject: Legality of Fedora in production environment Message-ID: Hello, Dmitry Butskoy wrote at 2007-05-11 13:01:24 GMT: > Our local linux distributors recommend to not download from Internet, > but buy their box, which includes CDs accompanied with some license > facsimile paper (just to show polices at least "something"). There is some Russian resalers who make "own" licensies special for police etc. For example - Mandriva for 10 workstation: http://www.linuxcenter.ru/screenshot/lc1865/1.jpg It signed with Mezon.RU company. So, a price of this paper (just paper, without any cd/dvd etc) is 3500 rubles (~ 100 euro). Distro box's price is 2500 rubles. http://www.linuxcenter.ru/shop/distros/linux-distros/License_10_PC_Mandriva_Linux_PP_Plus_2007_Spring/ http://www.linuxcenter.ru/shop/distros/linux-distros/Mandriva_Linux_Powerpack_Plus_2007_Spring/ -- Regards, Oleg From fedora-gmane.00004 at genesis-x.nildram.co.uk Sat Jun 2 00:11:42 2007 From: fedora-gmane.00004 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sat, 02 Jun 2007 01:11:42 +0100 Subject: Firefox 2.0 fails to install Flash 9 plugin In-Reply-To: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> References: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> Message-ID: <07p6j4-o8f.ln1@sky.matrix> Verily I say unto thee, that Valent Turkovic spake thusly: > Firefox 2.0 fails to install Flash 9 plugin - for me personally this > is a minor bug but for standard desktop user (let's call him John) it > is a major problem. > > Check out BZ: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242175 > > Please look at the video, it shows that this error is repeatable: > http://www.youtube.com/watch?v=-_ayaoEUHZ4 1 ... This is surely a Firefox bug, not a Fedora bug. 2 ... This is the Windows-centric method of installing Flash. Use RPM instead. 3 ... Installing Flash using this method will only install it into that user's profile. Using RPM will install it globally, making it available to all users on the system. http://macromedia.mplug.org/site_uh.html From fedora at leemhuis.info Sat Jun 2 06:29:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 02 Jun 2007 08:29:18 +0200 Subject: Fedora 8 Schedule In-Reply-To: <466093A3.2060008@benl.co.uk> References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> <1180731487.11951.37.camel@dawkins> <466093A3.2060008@benl.co.uk> Message-ID: <46610E3E.8080106@leemhuis.info> On 01.06.2007 23:46, Benjamin Lewis wrote: > dragoran wrote: >> On 6/1/07, *David Nielsen* > > wrote: >> [...] >> For KDE4 to hit on the final devel freeze we are merely talking >> putting >> back the schedule by about a week which if we push Test3 devel >> freeze to >> the the 25th of September that would allow us to ship Test3 with KDE >> 4.0-rc1 and GNOME 2.20 - I'm hoping that will provide helpful for >> getting testers to start using the release and we can accommodate both >> major releases in the final release. >> >> Cut dates would then be: >> September 19th - GNOME 2.20 >> September 25th - KDE 4.0-rc1 >> September 25th - Test3 devel freeze >> October 1st - Test3 release >> October 23th - KDE 4.0 final >> October 23th - Final devel freeze. >> November 7th - Final release >> >> - Is this insanity? >> - If I'm to understand Rex KDE packagers get the tarballs in time to >> make this? >> - can we live with doing freezes on a Tuesday instead of a Monday? >> >> And we'd be roughly on schedule with GNOME and KDE for F9 >> following that >> considering a standard 6 month cycle. >> +1 > +1 /me votes for the Fedora-Schedule as it is in the wiki and adjust that in August / early September to the KDE 4.0 Schedule if it looks like KDE 4.0 will ship as scheduled. KDE 4.0 is a big rework afaics. Especially those in my experiences from the open source software world tend to slip quite often for weeks or even months. That would be a major problem for Fedora then. Or are you guys that voted for "+1" really 100% sure KDE 4.0 will be on time? What is your backup plan if KDE 4.0 slips for one or two months? CU knurd From frank-buettner at gmx.net Sat Jun 2 06:49:36 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 02 Jun 2007 08:49:36 +0200 Subject: No updates for FC7 via rsync Message-ID: <46611300.10203@gmx.net> Hello, does any know whitch rsync mirror will provides the updates for FC7? Until now I can' find the update directory on any rsync mirror. Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From Axel.Thimm at ATrpms.net Sat Jun 2 07:10:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Jun 2007 09:10:28 +0200 Subject: retiring gpg-pubkey packages In-Reply-To: <538877.88990.qm@web51501.mail.re2.yahoo.com> References: <538877.88990.qm@web51501.mail.re2.yahoo.com> Message-ID: <20070602071028.GB7159@neu.nirvana> Hi, On Fri, Jun 01, 2007 at 08:03:27AM -0700, Steve G wrote: > I was also looking over the "yum list extras" and noticed something. It ignores > the gpg-pubkey packages. > > [root ~]# rpm -q gpg-pubkey > gpg-pubkey-db42a60e-37ea5438 > gpg-pubkey-731002fa-400b9109 > gpg-pubkey-db42a60e-37ea5438 > gpg-pubkey-4f2a6fd2-3f9d9d3b > gpg-pubkey-1ac70ce6-41bebeef > gpg-pubkey-db42a60e-37ea5438 > > Do we have any utility that identifies old keys that are no longer needed? Seems > like you'd want to carry only the latest for security reasons. How should the system know whether it is needed or not? You may have not pulled yet a single package from the repo in question (like rawhide, ATrpms etc), so it boils down to a matter of site policy. In theory, if all keys are mentioned in the yum config files, you can remove all and let yum get back only the ones that are registred in there. -- 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 Jun 2 07:14:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Jun 2007 09:14:33 +0200 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> Message-ID: <20070602071433.GC7159@neu.nirvana> On Fri, Jun 01, 2007 at 09:22:48AM -0800, Jeff Spaleta wrote: > On 6/1/07, Christopher Aillon wrote: > >Actually, many people do network installs. I have no DVD burner so the > >DVD ISO does me no good. So I downloaded the boot.iso to load up > >anaconda, and pointed the installer at the right places on the network. > > Much less downloading as you only update what you need. > > For people who do network based upgrades/re-installs...... > would it be feasible, and appropriate to provide a package in the F7 > repo which contained the F8 installer image as a grub entry for an F7 > system at the time of F8 release. So people could install that and > reboot into the installer via their grub menu and do an upgrade via > the installer.. instead of being tempted to do a live upgrade just > with yum. Maybe that's what koan does? I haven't used it, but in the cobbler/koan tandem, koan is used instead of pxebooting a system, so it probably just does something similar to what you describe. > Clever monkeys can do this manually now with some effort to pull the > installer image from the iso. The question is, does it make sense to > make this easier for the general userbase and provide a package in a > timely manner into F7 for the F8 release? > > -jef > -- 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 caillon at redhat.com Sat Jun 2 07:38:30 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 02 Jun 2007 03:38:30 -0400 Subject: Firefox 2.0 fails to install Flash 9 plugin In-Reply-To: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> References: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> Message-ID: <46611E76.8070007@redhat.com> Valent Turkovic wrote: > Firefox 2.0 fails to install Flash 9 plugin - for me personally this > is a minor bug but for standard desktop user (let's call him John) it > is a major problem. > > Check out BZ: I'm really inclined to start ignoring bugs that get announced on this list. Especially from people that already know about bugzilla. If they don't get addressed in a timely fashion, then I guess you can feel free to escalate, but srsly, can we just stick to bugzilla please? Can you imagine how much of a pain this list would be if every bug was announced here? From jspaleta at gmail.com Sat Jun 2 07:46:35 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 23:46:35 -0800 Subject: Don't put new packages through updates-testing In-Reply-To: <1180756515.12595.412.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> <46603F7D.1050407@fedoraproject.org> <1180714860.12595.361.camel@mccallum.corsepiu.local> <604aa7910706010952i6906466eo934d57c644bd714@mail.gmail.com> <1180756515.12595.412.camel@mccallum.corsepiu.local> Message-ID: <604aa7910706020046n79642a23l16c0e39ba22fd90c@mail.gmail.com> On 6/1/07, Ralf Corsepius wrote: > You mean ... because human imperfectness tends to switch off logic > because humans are tempted to follow their limited horizons and > perception? that's one interpretation, which if you think is valid would make for a quite interesting dissection for a person with a certain sort of doctorate and a nice comfy couch. Another would be that the application of any rigorous logic relies fundamentally on a baseline set of clearly defined and unambiguously communicated axioms which are held as universally true by all those involved. Its very easy for people, when relating with each other..even over technical matters, to presume that the other people in the conversation hold fast to the same axiomaticly true statements as they do. Moreover, there's no guarantee that different people with conflicting points of view, each with their own set of baseline assumptions, can reconcile the conflicting assumptions through logical rigor....even if they are accurately communicated. So its not so much that people stop using logic or that people are incapable of using logic... as it is that people use a different but completely self-consistent logic and don't really take the time to see if everyone is in fundamental agreement before stomping around getting all puffed up and acting self-importante. Such miscommunications only deepen when individuals in the discussion presume (logically of course) their logic is the only correct logic and therefore everyone else is being illogical. Though at the moment, thankfully, I am at a loss to point out a specific example as someone who makes a habit of this sort of thing, I'd hate to continue to drag this conversation away from reasonably constructive discussion by pointing fingers at anyone in particular, Ralf. > I find Rahul's reaction absurd, because we are talking about technical > issues and technical standards/metrics here, which I don't see any > reason not to apply logic to. To my very great dismay, my legal team has informed me that you are in fact entitled to your opinion concerning Rahul's opinion. But please Ralf, let's keep this discussion above such petty emotional outbursts. People look up to you for your logic and reason.. don't tanish that so cheaply. -jef"If I can prove to you that you don't exist, what are the chances that you'll disappear in a puff of contradictory smoke?"spaleta From martinjh at blueyonder.co.uk Sat Jun 2 07:43:03 2007 From: martinjh at blueyonder.co.uk (Martin J Hooper) Date: Sat, 02 Jun 2007 08:43:03 +0100 Subject: Install Problems FC7 Message-ID: <46611F87.5020704@blueyonder.co.uk> Posted on user but thought it would be better here instead... When I try install F7 I get the following error message: Partition Table on device sda was unreadable But if I drop out of Anaconda to the command line and do a fdisk -l I get all the current partitions working fine. Do I need to report this as a bug or is there a workaround to get it all working? Motherboard details here: http://tinyurl.com/34d6fp Storage details: HL-DT-ST DVDRAM GSA-4163B ATA Device [CD-ROM drive] JLMS XJ-HD166S ATA Device [CD-ROM drive] 3.5" format removeable media [Floppy drive] ST3120022A [Hard drive] (120.03 GB) -- drive 0, s/n 3JS12G0E, rev 3.54, SMART Status: Healthy WDC WD800BB-00DKA0 [Hard drive] (80.03 GB) -- drive 1, s/n WD-WCAHL5800619, rev 77.07W77, SMART Status: Healthy From pertusus at free.fr Sat Jun 2 07:54:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 09:54:25 +0200 Subject: koji can't find a newly build dependency In-Reply-To: <1180735311.19774.69.camel@localhost.localdomain> References: <20070601213351.GA27920@free.fr> <1180735311.19774.69.camel@localhost.localdomain> Message-ID: <20070602075425.GA11101@free.fr> On Fri, Jun 01, 2007 at 03:01:51PM -0700, Toshio Kuratomi wrote: > > > I think you need to use koji's chain-building facility to ensure that > the libdap package is included in the repository before the next package > is built. These mailing list posts ought to help:: > > https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02146.html > > https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01850.html Maybe the CHAIN= parameter should be documented in make chain-build --help Also I think it would be nice to have a possibility to see what is gonna be done without anything being done for real. -- Pat From abo at kth.se Sat Jun 2 07:56:13 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 02 Jun 2007 09:56:13 +0200 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> Message-ID: <1180770973.5035.91.camel@home.alexander.bostrom.net> fre 2007-06-01 klockan 09:22 -0800 skrev Jeff Spaleta: > For people who do network based upgrades/re-installs...... > would it be feasible, and appropriate to provide a package in the F7 > repo which contained the F8 installer image as a grub entry for an F7 > system at the time of F8 release. So people could install that and > reboot into the installer via their grub menu and do an upgrade via > the installer.. instead of being tempted to do a live upgrade just > with yum. Yeah, while I have done done FTP upgrades, it doesn't feel very safe, because downloading packages while the upgrade process is running is quite risky. A network problem or an incomplete mirror, and the upgrade will stop in the middle. It would be better if the upgrade was like a yum upgrade (download first, then upgrade) but with the additional Anaconda upgrade magic. Could it simply use /mnt/sysimage/var/cache/anaconda for that purpose? Then they could even by pre-downloaded by the running OS before rebooting into the Anaconda GRUB entry. If Anaconda needs to for example do an ext3 to ext4 conversion, it can mount /mnt/sysimage, download everything it will need for the entire upgrade process, umount, do the conversion and the mount it again for the RPM upgrades. Hmm? /abo From sundaram at fedoraproject.org Sat Jun 2 08:00:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 13:30:16 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <1180726721.19774.62.camel@localhost.localdomain> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> Message-ID: <46612390.7030302@fedoraproject.org> Toshio Kuratomi wrote: > On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: >> Hans de Goede wrote: >>> Not true many reviewers review on the latest stable, it says nowhere >>> that a review should be done on rawhide. >> Review is about guidelines and nowhere in the guideline does it even say >> that the fucntionality of the package should be tested. When I suggested >> that it be added I got back a knee jerk reaction to participate in >> reviews myself. >> > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > > - SHOULD: The reviewer should test that the package functions as > described. A package should not segfault instead of running, for > example. I suggested that it the "SHOULD" be changed to "MUST". A package that doesnt even start shouldnt be getting past reviews. Rahul From nicolas.mailhot at laposte.net Sat Jun 2 08:04:46 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 02 Jun 2007 10:04:46 +0200 Subject: Fedora 8 Schedule In-Reply-To: <1180742828.19774.94.camel@localhost.localdomain> References: <1180704141.3553.29.camel@dhcp83-186.boston.redhat.com> <1180731487.11951.37.camel@dawkins> <20070601233313.GA11965@ee.oulu.fi> <1180742828.19774.94.camel@localhost.localdomain> Message-ID: <1180771486.17342.5.camel@rousalka.dyndns.org> Le vendredi 01 juin 2007 ? 17:07 -0700, Toshio Kuratomi a ?crit : > On Sat, 2007-06-02 at 02:33 +0300, Pekka Pietikainen wrote: > > On Fri, Jun 01, 2007 at 10:58:07PM +0200, David Nielsen wrote: > > > I hear KDE 4.1 is aimed at being a 6 month release, this would then mean > > > we align nicely for a F9 with KDE4 and GNOME 2.22. That would accomplice > > > the goal of adjusting the schedule which was aimed for rather nicely.. > > > provided neither projects slips their release date. > > Why does the KDE spin have to be released at the same time as the general > > GNOME-oriented release? > > The reason is that the distro as a whole has a release at that time, not > just The GNOME spin or KDE spin, Server Spin, or etc. Also there's no way packagers would accept to freeze fedora-devel twice at a month interval to accommodate a spin on a different schedule. So you'd have the choice of starting from a month-old devel fork (which is 1/6th of a typical release cycle, and getting stale) or try to restabilize devel alone (devel breaks very fast after a release because everyone is fed up with waiting and pushes his pet unstable feature as soon as it's unfrozen) -- 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 pertusus at free.fr Sat Jun 2 08:20:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 10:20:17 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46612390.7030302@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> Message-ID: <20070602082017.GB11101@free.fr> On Sat, Jun 02, 2007 at 01:30:16PM +0530, Rahul Sundaram wrote: > Toshio Kuratomi wrote: > >On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: > >>Hans de Goede wrote: > >>>Not true many reviewers review on the latest stable, it says nowhere > >>>that a review should be done on rawhide. > >>Review is about guidelines and nowhere in the guideline does it even say > >>that the fucntionality of the package should be tested. When I suggested > >>that it be added I got back a knee jerk reaction to participate in > >>reviews myself. > >> > >http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > > > >- SHOULD: The reviewer should test that the package functions as > >described. A package should not segfault instead of running, for > >example. > > I suggested that it the "SHOULD" be changed to "MUST". A package that > doesnt even start shouldnt be getting past reviews. For simple applications, sure, but for libs, modules and servers? And for example when the package consist in multiple commands should them all be tested? -- Pat From j.w.r.degoede at hhs.nl Sat Jun 2 08:22:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 02 Jun 2007 10:22:52 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602082017.GB11101@free.fr> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> Message-ID: <466128DC.5050000@hhs.nl> Patrice Dumas wrote:s > On Sat, Jun 02, 2007 at 01:30:16PM +0530, Rahul Sundaram wrote: >> Toshio Kuratomi wrote: >>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: >>>> Hans de Goede wrote: >>>>> Not true many reviewers review on the latest stable, it says nowhere >>>>> that a review should be done on rawhide. >>>> Review is about guidelines and nowhere in the guideline does it even say >>>> that the fucntionality of the package should be tested. When I suggested >>>> that it be added I got back a knee jerk reaction to participate in >>>> reviews myself. >>>> >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: >>> >>> - SHOULD: The reviewer should test that the package functions as >>> described. A package should not segfault instead of running, for >>> example. >> I suggested that it the "SHOULD" be changed to "MUST". A package that >> doesnt even start shouldnt be getting past reviews. > > For simple applications, sure, but for libs, modules and servers? And for > example when the package consist in multiple commands should them all be > tested? > Exactly, there are very good reasons why this is a SHOULD and not a MUST. I'm sure almost every reviewer will give a program a test run in the simple program case / scenarion. Why must everything by regulated with rules, procedures and more rules? Why can't we just TRUST each other, I'm getting very tired, sick even, of this! Regards, Hans From j.w.r.degoede at hhs.nl Sat Jun 2 08:26:09 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 02 Jun 2007 10:26:09 +0200 Subject: proposal: new guidelines for rule makers Message-ID: <466129A1.7010805@hhs.nl> Hi all, Since those making packaging guidelines and other rules seem to be out of touch with the workfloor these days I would like to propose the following guideline for rulemakers: Those making guidelines / rules within the Fedora project must actively maintain atleast 30 packages. Rationale: How can one make rules if one isn't involved in that which is regulated oneself? Regards, Hans From pertusus at free.fr Sat Jun 2 08:29:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 10:29:28 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <466128DC.5050000@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <466128DC.5050000@hhs.nl> Message-ID: <20070602082928.GD11101@free.fr> On Sat, Jun 02, 2007 at 10:22:52AM +0200, Hans de Goede wrote: > > Exactly, there are very good reasons why this is a SHOULD and not a MUST. > I'm sure almost every reviewer will give a program a test run in the simple > program case / scenarion. Why must everything by regulated with rules, > procedures and more rules? Why can't we just TRUST each other, I'm getting > very tired, sick even, of this! We need rules to enforce best practices, but I can only agree with you that during the merge there has been a lot more procedures and choices are increasingly being removed from the maintainers hands to go to specific groups. I think this is a very bad direction. I am not saying that there shouldn't be a control (mainly from the rel-eng group, from fesco for packaging issues...) but the choice should always be in the packager hands. -- Pat From sundaram at fedoraproject.org Sat Jun 2 08:34:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:04:28 +0530 Subject: proposal: new guidelines for rule makers In-Reply-To: <466129A1.7010805@hhs.nl> References: <466129A1.7010805@hhs.nl> Message-ID: <46612B94.8020409@fedoraproject.org> Hans de Goede wrote: > Hi all, > > > > Since those making packaging guidelines and other rules seem to be out > of touch with the workfloor these days I would like to propose the > following guideline for rulemakers: > > Those making guidelines / rules within the Fedora project must actively > maintain atleast 30 packages. > > Rationale: How can one make rules if one isn't involved in that which is > regulated oneself? > > Packaging guidelines also cover licensing details which isn't connected to workflow. There are several other policies within the guidelines which involve some amount of politics (kernel modules anyone?). This rule would mean that everybody who proposes any drafts, folks in the packaging committee and FESCo would have to maintain 30 packages. Rahul From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 08:41:14 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 10:41:14 +0200 Subject: Broken deps in Fedora 7 Message-ID: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> Without test-updates, I see these dependency problems in Fedora 7 + Released Updates. Some are due to missing ExcludeArch. Scroll down for i386 and x86_64. But the total number of problems is shocking. source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: ardour-0.99.3-8.fc7.src.rpm package: ardour - 0.99.3-8.fc7.ppc64 from fedora-7-ppc64 unresolved deps: liblrdf.so.2()(64bit) source rpm: bittorrent-4.4.0-5.fc7.src.rpm package: bittorrent - 4.4.0-5.fc7.noarch from fedora-7-ppc64 unresolved deps: python-crypto source rpm: chmsee-1.0.0-0.17.beta2.fc7.src.rpm package: chmsee - 1.0.0-0.17.beta2.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: em8300-0.16.2-1.fc7.src.rpm package: em8300 - 0.16.2-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: em8300-kmod >= 0:0.16.2 source rpm: emerald-themes-0.2.0-1.fc7.src.rpm package: emerald-themes - 0.2.0-1.fc7.noarch from fedora-7-ppc64 unresolved deps: emerald >= 0:0.2.0 beryl-core >= 0:0.2.0 source rpm: epiphany-extensions-2.18.1-1.src.rpm package: epiphany-extensions - 2.18.1-1.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: freenx-0.6.0-12.fc7.src.rpm package: freenx - 0.6.0-12.fc7.ppc64 from fedora-7-ppc64 unresolved deps: nx source rpm: geda-examples-20070216-2.fc7.src.rpm package: geda-examples - 20070216-2.fc7.noarch from fedora-7-ppc64 unresolved deps: geda-gschem source rpm: glest-data-2.0.0-2.fc7.src.rpm package: glest-data - 2.0.0-2.fc7.noarch from fedora-7-ppc64 unresolved deps: glest = 0:2.0.0 source rpm: gnome-python2-extras-2.14.3-2.fc7.src.rpm package: gnome-python2-gtkmozembed - 2.14.3-2.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: gsynaptics-0.9.11-1.fc7.src.rpm package: gsynaptics - 0.9.11-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: synaptics source rpm: koan-0.3.1-2.fc7.src.rpm package: koan - 0.3.1-2.fc7.noarch from fedora-7-ppc64 unresolved deps: syslinux source rpm: netcdf-decoders-4.1.4-1.fc7.src.rpm package: netcdf-decoders - 4.1.4-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: perl(NetCDF) source rpm: oooqs2-1.0-3.fc6.src.rpm package: oooqs2 - 1.0-3.fc6.ppc64 from fedora-7-ppc64 unresolved deps: openoffice.org-draw openoffice.org-base openoffice.org-calc openoffice.org-writer openoffice.org-math openoffice.org-impress source rpm: openoffice.org-dict-cs_CZ-20060303-5.fc7.src.rpm package: openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 from fedora-7-ppc64 unresolved deps: openoffice.org-core source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: python-basemap-0.9.5-1.fc7.src.rpm package: python-basemap - 0.9.5-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: python-matplotlib >= 0:0.81 source rpm: python-paramiko-1.6.4-1.fc7.src.rpm package: python-paramiko - 1.6.4-1.fc7.noarch from fedora-7-ppc64 unresolved deps: python-crypto >= 0:1.9 source rpm: python-twisted-conch-0.7.0-4.fc7.src.rpm package: python-twisted-conch - 0.7.0-4.fc7.ppc64 from fedora-7-ppc64 unresolved deps: python-crypto source rpm: resapplet-0.1.1-5.fc7.src.rpm package: resapplet - 0.1.1-5.fc7.ppc64 from fedora-7-ppc64 unresolved deps: system-config-display source rpm: revisor-2.0.3.6-1.fc7.src.rpm package: revisor - 2.0.3.6-1.fc7.noarch from fedora-updates-7-ppc64 unresolved deps: livecd-tools source rpm: rosegarden4-1.4.0-1.fc7.src.rpm package: rosegarden4 - 1.4.0-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: liblrdf.so.2()(64bit) source rpm: ruby-gnome2-0.16.0-5.fc7.src.rpm package: ruby-gtkmozembed - 0.16.0-5.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.ppc64 from fedora-7-ppc64 unresolved deps: php = 0:5.2.1 source rpm: trac-0.10.3.1-2.fc7.src.rpm package: trac - 0.10.3.1-2.fc7.noarch from fedora-7-ppc64 unresolved deps: python-clearsilver >= 0:0.9.3 source rpm: wxMaxima-0.7.2-1.fc7.src.rpm package: wxMaxima - 0.7.2-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: maxima >= 0:5.11 source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: blam-1.8.3-3.fc7.src.rpm package: blam - 1.8.3-3.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: chmsee-1.0.0-0.17.beta2.fc7.src.rpm package: chmsee - 1.0.0-0.17.beta2.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: epiphany-extensions-2.18.1-1.src.rpm package: epiphany-extensions - 2.18.1-1.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: glest-data-2.0.0-2.fc7.src.rpm package: glest-data - 2.0.0-2.fc7.noarch from fedora-7-ppc unresolved deps: glest = 0:2.0.0 source rpm: gnome-python2-extras-2.14.3-2.fc7.src.rpm package: gnome-python2-gtkmozembed - 2.14.3-2.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc from fedora-7-ppc unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.src.rpm package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc from fedora-7-ppc unresolved deps: kernel-ppc = 0:2.6.20-1.3104.fc7 source rpm: em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.src.rpm package: kmod-em8300-smp - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc from fedora-7-ppc unresolved deps: kernel-ppc = 0:2.6.20-1.3104.fc7smp source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.ppc from fedora-7-ppc unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: revisor-2.0.3.6-1.fc7.src.rpm package: revisor - 2.0.3.6-1.fc7.noarch from fedora-updates-7-ppc unresolved deps: livecd-tools source rpm: ruby-gnome2-0.16.0-5.fc7.src.rpm package: ruby-gtkmozembed - 0.16.0-5.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.ppc from fedora-7-ppc unresolved deps: php = 0:5.2.1 source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: blam-1.8.3-3.fc7.src.rpm package: blam - 1.8.3-3.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: chmsee-1.0.0-0.17.beta2.fc7.src.rpm package: chmsee - 1.0.0-0.17.beta2.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: epiphany-extensions-2.18.1-1.src.rpm package: epiphany-extensions - 2.18.1-1.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: gnome-python2-extras-2.14.3-2.fc7.src.rpm package: gnome-python2-gtkmozembed - 2.14.3-2.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 from fedora-7-x86_64 unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 from fedora-7-x86_64 unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.src.rpm package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 from fedora-7-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.20-1.3104.fc7 source rpm: em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.src.rpm package: kmod-em8300-kdump - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 from fedora-7-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.20-1.3104.fc7kdump source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 from fedora-7-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.21-1.3116.fc7 source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 from fedora-7-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.i386 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.i386 from fedora-7-x86_64 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: ruby-gnome2-0.16.0-5.fc7.src.rpm package: ruby-gtkmozembed - 0.16.0-5.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.x86_64 from fedora-7-x86_64 unresolved deps: php = 0:5.2.1 source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: blam-1.8.3-3.fc7.src.rpm package: blam - 1.8.3-3.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: chmsee-1.0.0-0.17.beta2.fc7.src.rpm package: chmsee - 1.0.0-0.17.beta2.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: epiphany-extensions-2.18.1-1.src.rpm package: epiphany-extensions - 2.18.1-1.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: gnome-python2-extras-2.14.3-2.fc7.src.rpm package: gnome-python2-gtkmozembed - 2.14.3-2.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 from fedora-7-i386 unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.src.rpm package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 from fedora-7-i386 unresolved deps: kernel-i586 = 0:2.6.20-1.3104.fc7 source rpm: em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.src.rpm package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 from fedora-7-i386 unresolved deps: kernel-i686 = 0:2.6.20-1.3104.fc7 source rpm: em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.src.rpm package: kmod-em8300-PAE - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 from fedora-7-i386 unresolved deps: kernel-i686 = 0:2.6.20-1.3104.fc7PAE source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 from fedora-7-i386 unresolved deps: kernel-i586 = 0:2.6.21-1.3116.fc7 source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 from fedora-7-i386 unresolved deps: kernel-i686 = 0:2.6.21-1.3116.fc7 source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 from fedora-7-i386 unresolved deps: kernel-i686 = 0:2.6.21-1.3116.fc7PAE source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.i386 from fedora-7-i386 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: ruby-gnome2-0.16.0-5.fc7.src.rpm package: ruby-gtkmozembed - 0.16.0-5.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.i386 from fedora-7-i386 unresolved deps: php = 0:5.2.1 From sundaram at fedoraproject.org Sat Jun 2 08:47:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:17:40 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602082017.GB11101@free.fr> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> Message-ID: <46612EAC.30806@fedoraproject.org> Patrice Dumas wrote: > On Sat, Jun 02, 2007 at 01:30:16PM +0530, Rahul Sundaram wrote: >> Toshio Kuratomi wrote: >>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: >>>> Hans de Goede wrote: >>>>> Not true many reviewers review on the latest stable, it says nowhere >>>>> that a review should be done on rawhide. >>>> Review is about guidelines and nowhere in the guideline does it even say >>>> that the fucntionality of the package should be tested. When I suggested >>>> that it be added I got back a knee jerk reaction to participate in >>>> reviews myself. >>>> >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: >>> >>> - SHOULD: The reviewer should test that the package functions as >>> described. A package should not segfault instead of running, for >>> example. >> I suggested that it the "SHOULD" be changed to "MUST". A package that >> doesnt even start shouldnt be getting past reviews. > > For simple applications, sure, but for libs, modules and servers? And for > example when the package consist in multiple commands should them all be > tested? The base functionality must still be tested. A application that segfaults on startup should never get pass review. Rahul From sundaram at fedoraproject.org Sat Jun 2 08:51:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:21:16 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <466128DC.5050000@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <466128DC.5050000@hhs.nl> Message-ID: <46612F84.9080700@fedoraproject.org> Hans de Goede wrote: > > Exactly, there are very good reasons why this is a SHOULD and not a > MUST. I'm sure almost every reviewer will give a program a test run in > the simple program case / scenarion. Why must everything by regulated > with rules, procedures and more rules? Why can't we just TRUST each > other, We need to coordinate and not everyone has the same understanding of what is required in a review. New packagers have explicitly asked before for more guidelines. If you believe that every reviewer already tests the simple program case then there shouldn't any problem in documenting that. Rahul From rc040203 at freenet.de Sat Jun 2 08:56:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jun 2007 10:56:23 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46612390.7030302@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> Message-ID: <1180774583.12595.425.camel@mccallum.corsepiu.local> On Sat, 2007-06-02 at 13:30 +0530, Rahul Sundaram wrote: > Toshio Kuratomi wrote: > > On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: > >> Hans de Goede wrote: > >>> Not true many reviewers review on the latest stable, it says nowhere > >>> that a review should be done on rawhide. > >> Review is about guidelines and nowhere in the guideline does it even say > >> that the fucntionality of the package should be tested. When I suggested > >> that it be added I got back a knee jerk reaction to participate in > >> reviews myself. > >> > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > > > > - SHOULD: The reviewer should test that the package functions as > > described. A package should not segfault instead of running, for > > example. > > I suggested that it the "SHOULD" be changed to "MUST". A package that > doesnt even start shouldnt be getting past reviews. 1. packages never start, applications do. 2. many applications, when being cluelessly used, only mean they have a functional "usage()" 3. You can't launch anything in library packages. SCNR Ralf From sundaram at fedoraproject.org Sat Jun 2 08:59:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:29:22 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <1180774583.12595.425.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> Message-ID: <4661316A.8000903@fedoraproject.org> Ralf Corsepius wrote: > On Sat, 2007-06-02 at 13:30 +0530, Rahul Sundaram wrote: >> Toshio Kuratomi wrote: >>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: >>>> Hans de Goede wrote: >>>>> Not true many reviewers review on the latest stable, it says nowhere >>>>> that a review should be done on rawhide. >>>> Review is about guidelines and nowhere in the guideline does it even say >>>> that the fucntionality of the package should be tested. When I suggested >>>> that it be added I got back a knee jerk reaction to participate in >>>> reviews myself. >>>> >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: >>> >>> - SHOULD: The reviewer should test that the package functions as >>> described. A package should not segfault instead of running, for >>> example. >> I suggested that it the "SHOULD" be changed to "MUST". A package that >> doesnt even start shouldnt be getting past reviews. > 1. packages never start, applications do. Pendantic waste. > 2. many applications, when being cluelessly used, only mean they have a > functional "usage()" Which covers base functionality. > 3. You can't launch anything in library packages. Irrelevant to this rule then. Rahul From sundaram at fedoraproject.org Sat Jun 2 08:59:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:29:42 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <1180774583.12595.425.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> Message-ID: <4661317E.2050502@fedoraproject.org> Ralf Corsepius wrote: > On Sat, 2007-06-02 at 13:30 +0530, Rahul Sundaram wrote: >> Toshio Kuratomi wrote: >>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: >>>> Hans de Goede wrote: >>>>> Not true many reviewers review on the latest stable, it says nowhere >>>>> that a review should be done on rawhide. >>>> Review is about guidelines and nowhere in the guideline does it even say >>>> that the fucntionality of the package should be tested. When I suggested >>>> that it be added I got back a knee jerk reaction to participate in >>>> reviews myself. >>>> >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: >>> >>> - SHOULD: The reviewer should test that the package functions as >>> described. A package should not segfault instead of running, for >>> example. >> I suggested that it the "SHOULD" be changed to "MUST". A package that >> doesnt even start shouldnt be getting past reviews. > 1. packages never start, applications do. Pedantic waste. > 2. many applications, when being cluelessly used, only mean they have a > functional "usage()" Which covers base functionality. > 3. You can't launch anything in library packages. Irrelevant to this rule then. Rahul From rc040203 at freenet.de Sat Jun 2 09:01:43 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jun 2007 11:01:43 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <466128DC.5050000@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <466128DC.5050000@hhs.nl> Message-ID: <1180774904.12595.432.camel@mccallum.corsepiu.local> On Sat, 2007-06-02 at 10:22 +0200, Hans de Goede wrote: > Patrice Dumas wrote:s > > On Sat, Jun 02, 2007 at 01:30:16PM +0530, Rahul Sundaram wrote: > >> Toshio Kuratomi wrote: > >>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: > >>>> Hans de Goede wrote: > >>>>> Not true many reviewers review on the latest stable, it says nowhere > >>>>> that a review should be done on rawhide. > >>>> Review is about guidelines and nowhere in the guideline does it even say > >>>> that the fucntionality of the package should be tested. When I suggested > >>>> that it be added I got back a knee jerk reaction to participate in > >>>> reviews myself. > >>>> > >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > >>> > >>> - SHOULD: The reviewer should test that the package functions as > >>> described. A package should not segfault instead of running, for > >>> example. > >> I suggested that it the "SHOULD" be changed to "MUST". A package that > >> doesnt even start shouldnt be getting past reviews. > > > > For simple applications, sure, but for libs, modules and servers? And for > > example when the package consist in multiple commands should them all be > > tested? > > > > Exactly, there are very good reasons why this is a SHOULD and not a MUST. I'm > sure almost every reviewer will give a program a test run in the simple program > case / scenarion. Why should they and what would this give? "Hello world" links as proof a compiler is functional? Assuring function is an upstream task, but judging whether a package is suitable for public use is the rpm maintainer's job. That's one prime reason why I repeatedly refused to approve certain packages. > Why must everything by regulated with rules, procedures and > more rules? Why can't we just TRUST each other, I'm getting very tired, sick > even, of this! You're not alone - I feel this merger is not a merger but a "hostile take-over by some dark powers". Ralf From pertusus at free.fr Sat Jun 2 09:06:54 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 11:06:54 +0200 Subject: proposal: new guidelines for rule makers In-Reply-To: <466129A1.7010805@hhs.nl> References: <466129A1.7010805@hhs.nl> Message-ID: <20070602090654.GE11101@free.fr> On Sat, Jun 02, 2007 at 10:26:09AM +0200, Hans de Goede wrote: > Hi all, I don't know exactly what should be done, and maybe this is only a temporary issue, but in my opinion we've lost some of the simplicity and community smell of extras during the merge. Taking my example, in the past I had never had a will to look at what the infrastructure team was doing because it always seemed to me that they always did everything to make me productive. plague, for example was a change for a better, using bugzilla instead of mail for submission (after some reorganization). Now every innovation seems to add more burden to my work. Sometime after many screams of some community members (almost always the same people) things ameliorate but it is always in an opposition even on things that are evidently getting in our way. I don't know exactly what is going wrong. Maybe it is just that I am less adapted to doing a distro with all the constraints, and I better fit in environment where it is assumed that I am working for a niche. Maybe it is an issue about who is deciding now and that the objectives are different now, and it leads to more burden because of that -- while there is gain for some kind of users that are typically not those I target. Maybe it is that balance was lost in FESCO/FAB. -- Pat From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 09:19:32 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 11:19:32 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <466128DC.5050000@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <466128DC.5050000@hhs.nl> Message-ID: <20070602111932.2b7a491c.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 10:22:52 +0200, Hans de Goede wrote: > >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > >>> > >>> - SHOULD: The reviewer should test that the package functions as > >>> described. A package should not segfault instead of running, for > >>> example. > >> I suggested that it the "SHOULD" be changed to "MUST". A package that > >> doesnt even start shouldnt be getting past reviews. > > > > For simple applications, sure, but for libs, modules and servers? And for > > example when the package consist in multiple commands should them all be > > tested? > > > > Exactly, there are very good reasons why this is a SHOULD and not a MUST. I'm > sure almost every reviewer will give a program a test run in the simple program > case / scenarion. "almost every reviewer" is not equal to "all packagers and all reviewers". Which is the reason why the guidelines include this SHOULD item. Many of the guidelines have their origin at fedora.us where the gained experience lead to appropriate policies. [Not even all packagers test their updates before pushing them to multiple dists. One of the biggest risks of %{dist}-aided mass-updates.] > Why must everything by regulated with rules, procedures and > more rules? Why can't we just TRUST each other, I'm getting very tired, sick > even, of this! +1 However, I agree that the second "should" in the guideline really ought to be replaced like this: - SHOULD: The reviewer should test that the package functions as described. A package must not (!) segfault instead of running, for example. From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 09:25:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 11:25:28 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46612EAC.30806@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> Message-ID: <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 14:17:40 +0530, Rahul Sundaram wrote: > The base functionality must still be tested. That is much too vague. > A application that > segfaults on startup should never get pass review. It's "should" here again. The app may work fine in the reviewers environment, but malfunction in a different environment. For the reviewer it's called "best effort". The reviewer is encouraged to perform at least some tests. But to define what _must_ be tested and how to create a protocol for reproducibility and accountability, is the fundamental problem. From sundaram at fedoraproject.org Sat Jun 2 09:25:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 14:55:37 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46613791.5030809@fedoraproject.org> Michael Schwendt wrote: > On Sat, 02 Jun 2007 14:17:40 +0530, Rahul Sundaram wrote: > >> The base functionality must still be tested. > > That is much too vague. We need to sit down and define the details more precisely if we agree with the fundamental idea. > It's "should" here again. > > The app may work fine in the reviewers environment, but malfunction in a > different environment. Sure but the reviewer shouldn't be skipping this step. Agree? Rahul From pertusus at free.fr Sat Jun 2 09:30:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 11:30:03 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46613791.5030809@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> Message-ID: <20070602093003.GF11101@free.fr> On Sat, Jun 02, 2007 at 02:55:37PM +0530, Rahul Sundaram wrote: > > Sure but the reviewer shouldn't be skipping this step. Agree? In most cases, but not when there are a lot of commands/apps in one package. And also it may depend on the user base (that is sometimes it is easier for users to test some part of a package than for packagers, in that case it may be better to wait for bug reports. Of course this is untrue for packages for mass user consumption, but may be true for niche packages which only target experienced users). -- Pat From rc040203 at freenet.de Sat Jun 2 09:34:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jun 2007 11:34:16 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <4661316A.8000903@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> Message-ID: <1180776857.12595.437.camel@mccallum.corsepiu.local> On Sat, 2007-06-02 at 14:29 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Sat, 2007-06-02 at 13:30 +0530, Rahul Sundaram wrote: > >> Toshio Kuratomi wrote: > >>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: > >>>> Hans de Goede wrote: > >>>>> Not true many reviewers review on the latest stable, it says nowhere > >>>>> that a review should be done on rawhide. > >>>> Review is about guidelines and nowhere in the guideline does it even say > >>>> that the fucntionality of the package should be tested. When I suggested > >>>> that it be added I got back a knee jerk reaction to participate in > >>>> reviews myself. > >>>> > >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: > >>> > >>> - SHOULD: The reviewer should test that the package functions as > >>> described. A package should not segfault instead of running, for > >>> example. > >> I suggested that it the "SHOULD" be changed to "MUST". A package that > >> doesnt even start shouldnt be getting past reviews. > > 1. packages never start, applications do. > > Pendantic waste. > > > 2. many applications, when being cluelessly used, only mean they have a > > functional "usage()" > > Which covers base functionality. Bullshit - You apparently don't have any clues about what you are talking about. > > 3. You can't launch anything in library packages. > > Irrelevant to this rule then. Bullshit^2 - It's whether a lib is shipped separately or as part of a set of applications basically is an upstream packaging issue. Ralf From sundaram at fedoraproject.org Sat Jun 2 09:37:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 15:07:33 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <1180776857.12595.437.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> <1180776857.12595.437.camel@mccallum.corsepiu.local> Message-ID: <46613A5D.1080508@fedoraproject.org> Ralf Corsepius wrote: >> Which covers base functionality. > Bullshit - You apparently don't have any clues about what you are talking about. Right. Being pedantic and swearing is more important. > >>> 3. You can't launch anything in library packages. >> Irrelevant to this rule then. > Bullshit^2 - It's whether a lib is shipped separately or as part of a > set of applications basically is an upstream packaging issue. You misunderstood. If a package only contains a library and if there is a rule that says applications must be tested during review to ensure that they start then that rule is irrelevant to a library. Rahul From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 09:50:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 11:50:21 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46613791.5030809@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> Message-ID: <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 14:55:37 +0530, Rahul Sundaram wrote: > Michael Schwendt wrote: > > On Sat, 02 Jun 2007 14:17:40 +0530, Rahul Sundaram wrote: > > > >> The base functionality must still be tested. > > > > That is much too vague. > > We need to sit down and define the details more precisely if we agree > with the fundamental idea. Don't you fear that it would drive away reviewers? Back in time we've had to be very careful not to raise the bar too high. What has changed so that the Fedora Project is willing to increase the work for volunteer reviewers and packagers? There are many packages in the collection, which have been packaged only because they are build- or run-time requirements. For some packages, even minor version updates result in a unified diff of at least 2MiB in size. For some programs apparently even a large bunch of upstream developers cannot perform enough testing. > > It's "should" here again. > > > > The app may work fine in the reviewers environment, but malfunction in a > > different environment. > > Sure but the reviewer shouldn't be skipping this step. Agree? The packager should not skip it either, but some do. So what? It's too easy for them to excuse themselves with a brief "cannot reproduce that, works for me" and a quick fix as an update. Quick updates are not possible anymore, however, because the self-proclaimed Fedora Bureaucracy task-force has set up new hurdles and is working on producing even newer ones. From sundaram at fedoraproject.org Sat Jun 2 09:55:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 15:25:04 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46613E78.1010703@fedoraproject.org> Michael Schwendt wrote: > On Sat, 02 Jun 2007 14:55:37 +0530, Rahul Sundaram wrote: > >> Michael Schwendt wrote: >>> On Sat, 02 Jun 2007 14:17:40 +0530, Rahul Sundaram wrote: >>> >>>> The base functionality must still be tested. >>> That is much too vague. >> We need to sit down and define the details more precisely if we agree >> with the fundamental idea. > > Don't you fear that it would drive away reviewers? I does raise the bar a bit on the reviewers. I fear more that we are driving away users by the mentality around pushing packaging and waiting for bug reports to arrive that the package is basically broken. If we continue along that path more we won't be left with much users. Package maintainers or reviewers obviously don't love freeze or QA policies but it is a necessary evil if we are focusing on serving end users with robust software. Rahul From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 10:28:39 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 12:28:39 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46613E78.1010703@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> Message-ID: <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 15:25:04 +0530, Rahul Sundaram wrote: > >>>> The base functionality must still be tested. > >>> That is much too vague. > >> We need to sit down and define the details more precisely if we agree > >> with the fundamental idea. > > > > Don't you fear that it would drive away reviewers? > > I does raise the bar a bit on the reviewers. I fear more that we are > driving away users by the mentality around pushing packaging and waiting > for bug reports to arrive that the package is basically broken. If we > continue along that path more we won't be left with much users. You're pushing at the wrong side. That FESCO has neglected to pursue some important goals [of the past] is no secret. The community has lost control over what used to be a community-driven Fedora Extras. The new updates system has been advertised for many months as offering QA features, such as a repoclosure that would prevent broken dependencies from entering the repo. Instead, our precious users are confronted with what I consider an extremely questionable updates-testing strategy that doesn't fix their typical problems. Add to that a repository structure that has turnt into a playground and a moving target for our users. From pertusus at free.fr Sat Jun 2 10:40:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 12:40:39 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46613E78.1010703@fedoraproject.org> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> Message-ID: <20070602104039.GH11101@free.fr> On Sat, Jun 02, 2007 at 03:25:04PM +0530, Rahul Sundaram wrote: > > Package maintainers or reviewers obviously don't love freeze or QA > policies but it is a necessary evil if we are focusing on serving end > users with robust software. It really depends on the package and on the userbase. Sometimes pushing packages and waiting for bugreports is the best solution. Once again it really depends and should be left to the maintainer choice. -- Pat From dwmw2 at infradead.org Sat Jun 2 10:45:06 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 02 Jun 2007 11:45:06 +0100 Subject: thoughts about secondary architectures In-Reply-To: <20070602034206.GF16918@xi.wantstofly.org> References: <20070602034206.GF16918@xi.wantstofly.org> Message-ID: <1180781106.25232.118.camel@pmac.infradead.org> On Sat, 2007-06-02 at 05:42 +0200, Lennert Buytenhek wrote: > My view is that it's clear that most of the people hacking on Fedora > and using Fedora care only about x86/x86_64 systems, and that I (and > the other people who are interested in secondary architectures) > should try as much as possible to avoid making the lives of the x86 > people difficult, if we ever want to have a chance of getting our > patches merged without pissing everyone else off. I think you do us a disservice here. I hope that getting sensible patches merged should always be easy, regardless of how the build system works. There aren't many of us who'll start refusing your patches just because your build system pissed us off, hopefully :) We're trying to make it easier for people to build Fedora for new architectures. As you've so capably demonstrated, it's already _possible_ to do that -- but we want to make it less painful, and in particular we want to help you keep in sync with Fedora during the development cycle. (At least, that's what I _think_ we're trying to achieve -- Spot's document itself lacked any explicit rationale.) Yes, we want to keep the impact on the package maintainers minimal. But that doesn't mean it has to be entirely zero. If we want _zero_ impact, then you might just as well keep building it for yourself as you already are. > While it is very well possible that there is some bug in a package > that does not surface on x86, 99.9% of the Fedora developers are > unlikely to care about that (Actually I think are many more than 1 in 1000 who are more conscientious than that and actually do care about portability. We're not _that_ lackadaisical, as a rule.) > if the package builds OK on x86 and no ill effects are seen on x86. Nevertheless, in the case where a package _used_ to work on ARM and the updated version suddenly doesn't build, don't you think that warrants at least a _glance_ from the package maintainer to see if it's actually a _generic_ issue which just happens to bite on ARM today for some timing-related or other not 100% repeatable reason? That glance is _all_ that should be required -- package maintainers should _definitely_ have the option of just pushing a button to say they don't care, and shipping the package anyway on all the architectures for which it _did_ build. We don't want to make life hard for them; you're right. But we don't necessarily want them to ignore failures which could show up a real problem, either. We could see the builds on other architectures as free testing. They often _do_ show up issues which are generic, and not just arch-specific. Especially in the cases where the package in question _used_ to build OK on that architecture -- which is all we'd be expecting the package maintainers to notice in the general case. > From a purely technical point of view I would advocate that a build > failure on any architecture fails the package build, but there will > only have to be 3 or 4 cases where some gcc ICE causes some package > to fail to build on some secondary architecture but build fine on > x86 and the x86 people will hate us forever afterwards, and will > eventually start clamoring that getting all these secondary > architectures on board was a bad idea to begin with. (Which, of > course, would be totally understandable at that point.) I don't think it would be understandable at all. It's not as if it would take them long to glance at the failure and click the "don't care" button. (Well, OK, we'd want a bug filed, but there can be automated assistance with templates for that, even though it's a bad idea to have it all done _completely_ automatically). If we think GCC is going to be unstable on some platforms, then perhaps the 'complete rebuild in mock' process which Matt Domsch has been doing should be made mandatory? That would generally help to catch such compiler-related problems before they affect package maintainers. > There is a similar issue with build speed. While my fastest ARM box > (800 MHz with 512K L2 cache) is quite snappy as far as ARM systems go, > it is probably no match for even the crappiest of x86 boxes. The > fastest ARM CPU I know of is a dual core 1.2GHz, which is still no > match for x86. > > This doesn't mean, IMHO, that it makes no sense to run Fedora on ARM > systems. > > But it does mean that if the building of packages on primary > architectures is throttled at the speed of building packages on ARM, > we're going to make a lot of (x86) Fedora developers very sad, angry, > frustrated, or all of the above. Not really. The builds for the architecture they _care_ about would be available in koji from the moment they finish, and with the 'chain-build' option they'd be able to build subsequent dependent packages immediately too. The only thing that would be waiting is the push to the main repository... which also in practice waits for mirrors to sync and other stuff like that. It's hardly a fast-path. If there are architectures which are _really_ slow, and it really does start to cause problems, then _perhaps_ we'd need to stop waiting for those architectures. I think we should try to avoid that unless it's really necessary though. Not only would we be pushing partially-failed packages without any investigation, but you'd also start getting build failures and inconsistencies on that architecture even when there wasn't actually a real problem -- if a developer doesn't use chain-build but just submits jobs one after the other, before the first job finished on all architectures. The repository for that architecture wouldn't really be in sync with Fedora at all -- you haven't gained much over the current situation where you're entirely on your own. Perhaps one way to deal with this potential problem is to allow the package maintainer to push the 'go ahead and push it anyway' button in the build system even _before_ the build has run to completion on every architecture? That way, the build would _normally_ wait for everyone to finish and the repositories would remain in sync, and potential bugs would get at least a cursory glance before the package is shipped -- but in the fairly rare case where there's an urgent need for it in the actual repositories, the package maintainer could speed things up. (Presumably they'd need to have a way to force the mirrors to sync up immediately too, if they're in this much of a rush? Something which has never been brought up as an issue before, AIUI.) > So, IMHO, ideally, the existence of secondary architectures should > not significantly affect the typical workflow of an x86 Fedora > developer, and secondary architectures should not negatively affect > development on x86. This is true, but taken to extremes it means we may as well not bother trying to make life easier for you at all. I think the whole point of the proposal is that there _are_ things we can do, which are simple enough for us, which will help you a lot. Should we refuse even to lift a finger to merge your patches, just because we're too lazy? Despite the fact that you then have to work "two or three times as hard" because you have to work around our recalcitrance? If so, then why are we bothering with this proposal at all? You might as well just keep doing it on your own, surely? I think that if we're going to bother doing _anything_, the least we should do is merge your patches and keep the build system in sync in the _default_ case. Yes, package maintainers should have the option not to care about builds which fail on ARM -- but any competent maintainer should at least be taking a _cursory_ look at any new failure. If we _really_ have to, we could have an option not to wait for the build to complete -- but using that should be discouraged except in very special cases. As I said, it's not as if packages making it to the mirrors is a fast path. -- dwmw2 From sundaram at fedoraproject.org Sat Jun 2 10:46:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 16:16:27 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46614A83.7080004@fedoraproject.org> Michael Schwendt wrote: > On Sat, 02 Jun 2007 15:25:04 +0530, Rahul Sundaram wrote: > >>>>>> The base functionality must still be tested. >>>>> That is much too vague. >>>> We need to sit down and define the details more precisely if we agree >>>> with the fundamental idea. >>> Don't you fear that it would drive away reviewers? >> I does raise the bar a bit on the reviewers. I fear more that we are >> driving away users by the mentality around pushing packaging and waiting >> for bug reports to arrive that the package is basically broken. If we >> continue along that path more we won't be left with much users. > > You're pushing at the wrong side. > > That FESCO has neglected to pursue some important goals [of the past] is > no secret. I am not sure assigning blame is going to be useful in changing anything. It is a fact that we could do better in our QA processes without directly involving FESCo. The community has lost control over what used to be a > community-driven Fedora Extras. The new updates system has been advertised > for many months as offering QA features, such as a repoclosure that would > prevent broken dependencies from entering the repo Fedora Extras had a rolling updates model which allows more freedom for package maintainers but it is inconsistent with what was Fedora Core and due to the differences in infrastructure and policies there wasn't a good model on the whole. There has been a lot of work merging the repos and the setting up the new update system and very few people are contributing but I do see improvements being made. Rahul From sundaram at fedoraproject.org Sat Jun 2 10:48:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 16:18:37 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602104039.GH11101@free.fr> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> Message-ID: <46614B05.8090606@fedoraproject.org> Patrice Dumas wrote: > On Sat, Jun 02, 2007 at 03:25:04PM +0530, Rahul Sundaram wrote: >> Package maintainers or reviewers obviously don't love freeze or QA >> policies but it is a necessary evil if we are focusing on serving end >> users with robust software. > > It really depends on the package and on the userbase. Sometimes pushing > packages and waiting for bugreports is the best solution. Once again > it really depends and should be left to the maintainer choice. Users facing these broken packages might just leave rather than report bugs. Do you care about that? Rahul From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 11:01:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 13:01:02 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46614B05.8090606@fedoraproject.org> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> Message-ID: <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 16:18:37 +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: > > On Sat, Jun 02, 2007 at 03:25:04PM +0530, Rahul Sundaram wrote: > >> Package maintainers or reviewers obviously don't love freeze or QA > >> policies but it is a necessary evil if we are focusing on serving end > >> users with robust software. > > > > It really depends on the package and on the userbase. Sometimes pushing > > packages and waiting for bugreports is the best solution. Once again > > it really depends and should be left to the maintainer choice. > > Users facing these broken packages might just leave rather than report > bugs. Do you care about that? Even worse if the users face broken packages that have gone through something labeled "updates-testing". From sundaram at fedoraproject.org Sat Jun 2 11:01:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 16:31:10 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46614DF6.1080903@fedoraproject.org> Michael Schwendt wrote: > On Sat, 02 Jun 2007 16:18:37 +0530, Rahul Sundaram wrote: > >> Patrice Dumas wrote: >>> On Sat, Jun 02, 2007 at 03:25:04PM +0530, Rahul Sundaram wrote: >>>> Package maintainers or reviewers obviously don't love freeze or QA >>>> policies but it is a necessary evil if we are focusing on serving end >>>> users with robust software. >>> It really depends on the package and on the userbase. Sometimes pushing >>> packages and waiting for bugreports is the best solution. Once again >>> it really depends and should be left to the maintainer choice. >> Users facing these broken packages might just leave rather than report >> bugs. Do you care about that? > > Even worse if the users face broken packages that have gone through > something labeled "updates-testing". Alteast then they can contribute towards testing. Bypassing that gives noone besides the maintainers any chance. Rahul From pertusus at free.fr Sat Jun 2 11:14:29 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 13:14:29 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46614B05.8090606@fedoraproject.org> References: <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> Message-ID: <20070602111429.GI11101@free.fr> On Sat, Jun 02, 2007 at 04:18:37PM +0530, Rahul Sundaram wrote: > > Users facing these broken packages might just leave rather than report > bugs. Do you care about that? Yes, but I am thinking about users that report bugs rather than leave, for packages that are not necessarily in a better shape anywhere else. I can give examples of my packages if you like. -- Pat From pertusus at free.fr Sat Jun 2 11:19:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 13:19:24 +0200 Subject: anyone willing to maintain xcalc? Message-ID: <20070602111924.GJ11101@free.fr> Hello, The submitter of xcalc here did a good job, but he hasn't the will to become a fedora member: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204513 I think it is nice to have X-only light apps in setups with light desktops for example. I would like to have xcalc in fedora and I am ready to co-maintain, but I already have too much packages and with the changes in procedures/merge/EPEL I would like to have more time for other tasks. Isn't there anybody else interested to maintain it? As a side note it was in fedora before the X split. -- Pat From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 11:28:36 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 13:28:36 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46614A83.7080004@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> Message-ID: <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 16:16:27 +0530, Rahul Sundaram wrote: > Michael Schwendt wrote: > > On Sat, 02 Jun 2007 15:25:04 +0530, Rahul Sundaram wrote: > > > >>>>>> The base functionality must still be tested. > >>>>> That is much too vague. > >>>> We need to sit down and define the details more precisely if we agree > >>>> with the fundamental idea. > >>> Don't you fear that it would drive away reviewers? > >> I does raise the bar a bit on the reviewers. I fear more that we are > >> driving away users by the mentality around pushing packaging and waiting > >> for bug reports to arrive that the package is basically broken. If we > >> continue along that path more we won't be left with much users. > > > > You're pushing at the wrong side. > > > > That FESCO has neglected to pursue some important goals [of the past] is > > no secret. > > I am not sure assigning blame is going to be useful in changing > anything. It is a fact that we could do better in our QA processes > without directly involving FESCo. Unfortunately, you won't find enough volunteers who would be willing to jump over unnecessary hurdles before realising that they would likely not get the proper privileges to clean up wreckage in the distribution. Not even sponsors have the privileges anymore to intervene in CVS or buildsys (thanks god the people I sponsor are the FESCo chair, FESCo members and pleasant packagers who don't cause any trouble anymore). FESCo is directly responsible for implementing stuff that makes many things unnecessarily harder. AWOL procedures, ACLs, after years there still is no team that could step in and apply emergency fixes. Just like FC6 updates still contain broken deps, there is no indication that F7 will be any better. Already in the first week, there are broken dependencies which also make yum upgrades from FC6 much more difficult if not impossible. And those that would be fixed quickly, are not fixed because they sit in updates-testing or because packagers need to take time and learn about bodhi'n'stuff. You call it "blame", others call it "opening eyes". Historically, it has been necessary several times, too. From dev at nigelj.com Sat Jun 2 11:26:42 2007 From: dev at nigelj.com (Nigel Jones) Date: Sat, 02 Jun 2007 23:26:42 +1200 Subject: anyone willing to maintain xcalc? In-Reply-To: <20070602111924.GJ11101@free.fr> References: <20070602111924.GJ11101@free.fr> Message-ID: <466153F2.5010008@nigelj.com> Patrice Dumas wrote: > Hello, > > The submitter of xcalc here did a good job, but he hasn't the will to > become a fedora member: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204513 > > I think it is nice to have X-only light apps in setups with light > desktops for example. I would like to have xcalc in fedora and I am > ready to co-maintain, but I already have too much packages and with > the changes in procedures/merge/EPEL I would like to have more time > for other tasks. Isn't there anybody else interested to maintain it? > As a side note it was in fedora before the X split. I'm actually looking at it right now (I noticed the fedora-package-review traffic). I just want to look through the whole bugzilla entry first. N.J. From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 11:37:06 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 13:37:06 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46614DF6.1080903@fedoraproject.org> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> <46614DF6.1080903@fedoraproject.org> Message-ID: <20070602133706.0cd16c4a.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 16:31:10 +0530, Rahul Sundaram wrote: > >> Users facing these broken packages might just leave rather than report > >> bugs. Do you care about that? > > > > Even worse if the users face broken packages that have gone through > > something labeled "updates-testing". > > Alteast then they can contribute towards testing. Users who would "leave" don't try out so-called test-updates anyway. An estimated big percentage of those few users, who do try out test-updates, won't take the time to report a problem. There's too much of a risk of hearing "know thing" or FIXED/RAWHIDE. From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 11:38:35 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 13:38:35 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602133706.0cd16c4a.mschwendt.tmp0701.nospam@arcor.de> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> <46614DF6.1080903@fedoraproject.org> <20070602133706.0cd16c4a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070602133835.2f0a465c.mschwendt.tmp0701.nospam@arcor.de> On Sat, 2 Jun 2007 13:37:06 +0200, Michael Schwendt wrote: > On Sat, 02 Jun 2007 16:31:10 +0530, Rahul Sundaram wrote: > > > >> Users facing these broken packages might just leave rather than report > > >> bugs. Do you care about that? > > > > > > Even worse if the users face broken packages that have gone through > > > something labeled "updates-testing". > > > > Alteast then they can contribute towards testing. > > Users who would "leave" don't try out so-called test-updates anyway. > > An estimated big percentage of those few users, who do try out > test-updates, won't take the time to report a problem. There's too > much of a risk of hearing "know thing" or FIXED/RAWHIDE. s/know/known/ From spng.yang at gmail.com Sat Jun 2 11:34:02 2007 From: spng.yang at gmail.com (Ken YANG) Date: Sat, 02 Jun 2007 19:34:02 +0800 Subject: liferea depend on firefox-2.0.3, not 2.0.4 in FC8 rawhide Message-ID: <466155AA.2040709@gmail.com> hi all, when i install lifrea by yum, i found: Resolving Dependencies --> Running transaction check ---> Package liferea.i386 0:1.2.15b-1.fc8 set to be updated --> Processing Dependency: firefox = 2.0.0.3 for package: liferea --> Finished Dependency Resolution Error: Missing Dependency: firefox = 2.0.0.3 is needed by package liferea i am using fc8 rawhide From sundaram at fedoraproject.org Sat Jun 2 11:40:35 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 17:10:35 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602133706.0cd16c4a.mschwendt.tmp0701.nospam@arcor.de> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> <46614DF6.1080903@fedoraproject.org> <20070602133706.0cd16c4a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46615733.4060506@fedoraproject.org> Michael Schwendt wrote: > On Sat, 02 Jun 2007 16:31:10 +0530, Rahul Sundaram wrote: > >>>> Users facing these broken packages might just leave rather than report >>>> bugs. Do you care about that? >>> Even worse if the users face broken packages that have gone through >>> something labeled "updates-testing". >> Alteast then they can contribute towards testing. > > Users who would "leave" don't try out so-called test-updates anyway. > > An estimated big percentage of those few users, who do try out > test-updates, won't take the time to report a problem. There's too > much of a risk of hearing "know thing" or FIXED/RAWHIDE. We are assuming a lot here without any data to back up these assumptions. At any rate I don't think we are going to convince each other so I would leave the final decision to FESCo. Rahul From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 11:47:10 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 13:47:10 +0200 Subject: liferea depend on firefox-2.0.3, not 2.0.4 in FC8 rawhide In-Reply-To: <466155AA.2040709@gmail.com> References: <466155AA.2040709@gmail.com> Message-ID: <20070602134710.8e1e56ab.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 19:34:02 +0800, Ken YANG wrote: > > hi all, > > when i install lifrea by yum, i found: > > Resolving Dependencies > --> Running transaction check > ---> Package liferea.i386 0:1.2.15b-1.fc8 set to be updated > --> Processing Dependency: firefox = 2.0.0.3 for package: liferea > --> Finished Dependency Resolution > Error: Missing Dependency: firefox = 2.0.0.3 is needed by package liferea > > > i am using fc8 rawhide Check koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=7768 Wait for the next rawhide push where the package should be included. From ville.skytta at iki.fi Sat Jun 2 11:48:26 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 2 Jun 2007 14:48:26 +0300 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706011945.15676.jkeating@redhat.com> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706011842.22194.dennis@ausil.us> <200706011945.15676.jkeating@redhat.com> Message-ID: <200706021448.27123.ville.skytta@iki.fi> On Saturday 02 June 2007, Jesse Keating wrote: > On Friday 01 June 2007 19:42:21 Dennis Gilmore wrote: > > buildsys-macros still exists with only > > printf %s%b "%" "__arch_install_post /usr/lib/rpm/check-buildroot\n" >> > > $RPM_BUILD_ROOT/etc/rpm/macros.checkbuild > > > > so we can still run check-buildroot at least for mock builds.. > > Right, and we can split the check-buildroot out into it's own package or > whatnot so that we can do that on user's systems too, but not pull in all > of what currently provides check-buildroot. We talked about that before on > one of the lists. Splitting is trivial, I have plans to work on this soon in rpmdevtools, but automatically enabling eg. check-buildroot if the package is installed is trickier. I don't think we can define __arch_install_post automatically (ie. "claim ownership of the macro") for all systems. If the system already had __arch_install_post set to something in let's say /etc/rpm/macros, what happens? What about ~/.rpmmacros? From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 12:07:27 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 14:07:27 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46615733.4060506@fedoraproject.org> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> <46614DF6.1080903@fedoraproject.org> <20070602133706.0cd16c4a.mschwendt.tmp0701.nospam@arcor.de> <46615733.4060506@fedoraproject.org> Message-ID: <20070602140727.a13bcd89.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 17:10:35 +0530, Rahul Sundaram wrote: > Michael Schwendt wrote: > > On Sat, 02 Jun 2007 16:31:10 +0530, Rahul Sundaram wrote: > > > >>>> Users facing these broken packages might just leave rather than report > >>>> bugs. Do you care about that? > >>> Even worse if the users face broken packages that have gone through > >>> something labeled "updates-testing". > >> Alteast then they can contribute towards testing. > > > > Users who would "leave" don't try out so-called test-updates anyway. > > > > An estimated big percentage of those few users, who do try out > > test-updates, won't take the time to report a problem. There's too > > much of a risk of hearing "know thing" or FIXED/RAWHIDE. > > We are assuming a lot here without any data to back up these > assumptions. At any rate I don't think we are going to convince each > other so I would leave the final decision to FESCo. Data that back up these assumptions are found in historical evidence that "updates testing" has not been a success so far. Both Core developers and users have complained about it [*]. Developers about lack of feedback. Users about broken released updates, which have come out of the testing repo, and even about updates which have been published despite bug reports. With F7 comes an attempt at enforcing updates-testing for all of us, in hope to increase the number of guinea pigs. And while we install test updates which fix something, our precious users continue seeing breakage. [*] You participate in so many public communication channels, you must have seen such topics, too (yes, another assumption ;). From spng.yang at gmail.com Sat Jun 2 12:02:24 2007 From: spng.yang at gmail.com (Ken YANG) Date: Sat, 02 Jun 2007 20:02:24 +0800 Subject: liferea depend on firefox-2.0.3, not 2.0.4 in FC8 rawhide In-Reply-To: <20070602134710.8e1e56ab.mschwendt.tmp0701.nospam@arcor.de> References: <466155AA.2040709@gmail.com> <20070602134710.8e1e56ab.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46615C50.4050700@gmail.com> Michael Schwendt wrote: > On Sat, 02 Jun 2007 19:34:02 +0800, Ken YANG wrote: > >> hi all, >> >> when i install lifrea by yum, i found: >> >> Resolving Dependencies >> --> Running transaction check >> ---> Package liferea.i386 0:1.2.15b-1.fc8 set to be updated >> --> Processing Dependency: firefox = 2.0.0.3 for package: liferea >> --> Finished Dependency Resolution >> Error: Missing Dependency: firefox = 2.0.0.3 is needed by package liferea >> >> >> i am using fc8 rawhide > > Check koji: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=7768 > > Wait for the next rawhide push where the package should be included. thank you very much > From denis at poolshark.org Sat Jun 2 12:08:15 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 02 Jun 2007 14:08:15 +0200 Subject: anyone willing to maintain xcalc? In-Reply-To: <466153F2.5010008@nigelj.com> References: <20070602111924.GJ11101@free.fr> <466153F2.5010008@nigelj.com> Message-ID: <46615DAF.8000909@poolshark.org> Nigel Jones wrote: > Patrice Dumas wrote: >> Hello, >> >> The submitter of xcalc here did a good job, but he hasn't the will to >> become a fedora member: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204513 >> >> I think it is nice to have X-only light apps in setups with light >> desktops for example. I would like to have xcalc in fedora and I am >> ready to co-maintain, but I already have too much packages and with >> the changes in procedures/merge/EPEL I would like to have more time >> for other tasks. Isn't there anybody else interested to maintain it? >> As a side note it was in fedora before the X split. > > I'm actually looking at it right now (I noticed the > fedora-package-review traffic). > > I just want to look through the whole bugzilla entry first. I can pick it up also. Let me know Nigel. From sundaram at fedoraproject.org Sat Jun 2 12:13:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 17:43:18 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602140727.a13bcd89.mschwendt.tmp0701.nospam@arcor.de> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> <46614B05.8090606@fedoraproject.org> <20070602130102.b54b74fc.mschwendt.tmp0701.nospam@arcor.de> <46614DF6.1080903@fedoraproject.org> <20070602133706.0cd16c4a.mschwendt.tmp0701.nospam@arcor.de> <46615733.4060506@fedoraproject.org> <20070602140727.a13bcd89.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46615EDE.2090907@fedoraproject.org> Michael Schwendt wrote: > On Sat, 02 Jun 2007 17:10:35 +0530, Rahul Sundaram wrote: > >> Michael Schwendt wrote: >>> On Sat, 02 Jun 2007 16:31:10 +0530, Rahul Sundaram wrote: >>> >>>>>> Users facing these broken packages might just leave rather than report >>>>>> bugs. Do you care about that? >>>>> Even worse if the users face broken packages that have gone through >>>>> something labeled "updates-testing". >>>> Alteast then they can contribute towards testing. >>> Users who would "leave" don't try out so-called test-updates anyway. >>> >>> An estimated big percentage of those few users, who do try out >>> test-updates, won't take the time to report a problem. There's too >>> much of a risk of hearing "know thing" or FIXED/RAWHIDE. >> We are assuming a lot here without any data to back up these >> assumptions. At any rate I don't think we are going to convince each >> other so I would leave the final decision to FESCo. > > Data that back up these assumptions are found in historical evidence that > "updates testing" has not been a success so far. Both Core developers and > users have complained about it [*]. Developers have pushed updates inconsistently into updates-testing and Fedora Extras didn't use the system at all so there wasn't much of a incentive for me to request interested people to participate. If there is a good consistent document policy on updates-testing it is much better for developers and end users regardless of what the policy actually is. > You participate in so many public communication channels, you must > have seen such topics, too (yes, another assumption ;). Yes. I have seen more complaints from users and much less from developers. Rahul From sundaram at fedoraproject.org Sat Jun 2 12:14:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 17:44:18 +0530 Subject: Potential errors in the KDE LiveCD In-Reply-To: <200706020032.49789.lightsolphoenix@gmail.com> References: <200706020032.49789.lightsolphoenix@gmail.com> Message-ID: <46615F1A.9050700@fedoraproject.org> Kelly wrote: > Okay, I performed a hard drive install off the KDE LiveCD, and caught a couple > of problems: > > 1) I keep getting an error from DBus because it still contains references to > gdm, even though the KDE LiveCD uses kdm. This is documented in http://fedoraproject.org/wiki/Bugs/F7Common Don't know about the second issue. Rahul From hughsient at gmail.com Sat Jun 2 12:21:31 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 02 Jun 2007 13:21:31 +0100 Subject: if this is a bug then it is a nasty BLOCKER for F7 In-Reply-To: References: <64b14b300705280631o2a5bb40fs2f7d3d9df65a01db@mail.gmail.com> <1180513221.2573.10.camel@localhost.localdomain> Message-ID: <1180786891.2355.20.camel@localhost.localdomain> On Sat, 2007-06-02 at 04:22 +0000, Bojan Smojver wrote: > Bojan Smojver rexursive.com> writes: > > > Once I find out what's actually causing the hangs, I'll report > > back. > > Surprisingly enough, it's b44. That didn't need to be blacklisted in FC6. Looks > like a regression. Can you file it in kernel bugzilla please. Thanks, Richard, From dev at nigelj.com Sat Jun 2 12:26:15 2007 From: dev at nigelj.com (Nigel Jones) Date: Sun, 03 Jun 2007 00:26:15 +1200 Subject: anyone willing to maintain xcalc? In-Reply-To: <46615DAF.8000909@poolshark.org> References: <20070602111924.GJ11101@free.fr> <466153F2.5010008@nigelj.com> <46615DAF.8000909@poolshark.org> Message-ID: <466161E7.6030402@nigelj.com> Denis Leroy wrote: > Nigel Jones wrote: >> Patrice Dumas wrote: >>> Hello, >>> >>> The submitter of xcalc here did a good job, but he hasn't the will to >>> become a fedora member: >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204513 >>> >>> I think it is nice to have X-only light apps in setups with light >>> desktops for example. I would like to have xcalc in fedora and I am >>> ready to co-maintain, but I already have too much packages and with >>> the changes in procedures/merge/EPEL I would like to have more time >>> for other tasks. Isn't there anybody else interested to maintain it? >>> As a side note it was in fedora before the X split. >> >> I'm actually looking at it right now (I noticed the >> fedora-package-review traffic). >> >> I just want to look through the whole bugzilla entry first. > > I can pick it up also. Let me know Nigel. > I think I'll pass N.J. From jkeating at redhat.com Sat Jun 2 12:30:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 08:30:10 -0400 Subject: No updates for FC7 via rsync In-Reply-To: <46611300.10203@gmx.net> References: <46611300.10203@gmx.net> Message-ID: <200706020830.10931.jkeating@redhat.com> On Saturday 02 June 2007 02:49:36 Frank B?ttner wrote: > Hello, > does any know whitch rsync mirror will provides the updates for FC7? > Until now I can' find the update directory on any rsync mirror. You're looking in pub/fedora/linux/updates/7 ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 2 12:32:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 08:32:39 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706020832.39558.jkeating@redhat.com> On Saturday 02 June 2007 04:41:14 Michael Schwendt wrote: > Without test-updates, I see these dependency problems in Fedora 7 + > Released Updates. Some are due to missing ExcludeArch. Scroll down for > i386 and x86_64. But the total number of problems is shocking. We're still working out the kinks in the dep checker for updates. With as many packages as we have the time to see if the update set is valid is reaching toward an hour + -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 2 12:33:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 08:33:32 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706021448.27123.ville.skytta@iki.fi> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706011945.15676.jkeating@redhat.com> <200706021448.27123.ville.skytta@iki.fi> Message-ID: <200706020833.32990.jkeating@redhat.com> On Saturday 02 June 2007 07:48:26 Ville Skytt? wrote: > I don't think we can define __arch_install_post automatically (ie. "claim > ownership of the macro") for all systems. ?If the system already had > __arch_install_post set to something in let's say /etc/rpm/macros, what > happens? ?What about ~/.rpmmacros? These override the redhat-rpm-macros don't they? I'm not sure of the preference order. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Sat Jun 2 13:08:02 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 2 Jun 2007 13:08:02 +0000 (UTC) Subject: Unsigned packages (ntfs-config) References: <3adc77210706011344h22eabe5et1bf71e8749594239@mail.gmail.com> Message-ID: Naheem Zaffar gmail.com> writes: > It seems that atleast one package in the repo is unsigned: Another one: scons-0.97-2.fc7.noarch.rpm, at least in the x86_64 repository (but it being noarch, I'd guess i386 is probably affected too). Kevin Kofler From fedora at leemhuis.info Sat Jun 2 13:21:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 02 Jun 2007 15:21:30 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46616EDA.8030007@leemhuis.info> On 02.06.2007 12:28, Michael Schwendt wrote: > On Sat, 02 Jun 2007 15:25:04 +0530, Rahul Sundaram wrote: > > [...] The community has lost control over what used to be a > community-driven Fedora Extras. [...] +1 to that -- if Fedora Extras one or two years ago would have wanted to switch something like koji or bodhi then I'd say FESCo would have looked at it first before Extras would have started to use it. FESCo further would have insisted on proper docs, clear rules (discussed by the community beforehand) and easy procedures. These days it seems to me some developers simply do some stuff(?) (often without much FESCo involvement, not enough public discussion beforehand and insufficient rules or docs) and contributors have to deal with the outcome, if they like or not. Okay, we wanted the merge. I these days think we maybe did it to fast, as it and all the new tools created a lot of confusion and burden on the contributors. But okay, we are merged now, and it has lots of benefits afaics. So lets deal with it now -- for example by making "contributing to Fedora easy again, get the community involved better into the decisions process and make packagers happy again" one of the most important "Features" for Fedora 8. Otherwise the merge might fail in the end. Just my 2 cent. CU thl (?) -- note that up to some point simply doing stuff is great From laxathom at fedoraproject.org Sat Jun 2 13:27:52 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 2 Jun 2007 09:27:52 -0400 Subject: Unsigned packages (ntfs-config) In-Reply-To: <200706011708.04375.jkeating@redhat.com> References: <3adc77210706011344h22eabe5et1bf71e8749594239@mail.gmail.com> <200706011708.04375.jkeating@redhat.com> Message-ID: <62bc09df0706020627g248890a6sffdff1ddbbd03d6a@mail.gmail.com> 2007/6/1, Jesse Keating : > > On Friday 01 June 2007 16:44:15 Naheem Zaffar wrote: > > Should I file a bug report, or are these teething problems for a new > > release? > > There are a few known. We're going to fix them. i've to update ntfs-config to next release, could i launch koji or wait fix done ? -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sat Jun 2 13:26:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 09:26:38 -0400 Subject: Unsigned packages (ntfs-config) In-Reply-To: <62bc09df0706020627g248890a6sffdff1ddbbd03d6a@mail.gmail.com> References: <3adc77210706011344h22eabe5et1bf71e8749594239@mail.gmail.com> <200706011708.04375.jkeating@redhat.com> <62bc09df0706020627g248890a6sffdff1ddbbd03d6a@mail.gmail.com> Message-ID: <200706020926.38738.jkeating@redhat.com> On Saturday 02 June 2007 09:27:52 Xavier Lamien wrote: > i've to update ntfs-config to next release, could i launch koji or wait fix > done ? Update away -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bojan at rexursive.com Sat Jun 2 13:39:06 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 02 Jun 2007 23:39:06 +1000 Subject: Package php-pear-Mail-Mime not signed in F7 Message-ID: <1180791546.2969.1.camel@shrek.rexursive.com> Bugzilla doesn't seem to know about this package, so could someone with enough privileges please sign this package in F7? -- Bojan From bojan at rexursive.com Sat Jun 2 13:44:00 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 2 Jun 2007 13:44:00 +0000 (UTC) Subject: if this is a bug then it is a nasty BLOCKER for F7 References: <64b14b300705280631o2a5bb40fs2f7d3d9df65a01db@mail.gmail.com> <1180513221.2573.10.camel@localhost.localdomain> <1180786891.2355.20.camel@localhost.localdomain> Message-ID: Richard Hughes gmail.com> writes: > Can you file it in kernel bugzilla please. Thanks, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242234 -- Bojan From bpepple at fedoraproject.org Sat Jun 2 14:00:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 02 Jun 2007 10:00:18 -0400 Subject: liferea depend on firefox-2.0.3, not 2.0.4 in FC8 rawhide In-Reply-To: <466155AA.2040709@gmail.com> References: <466155AA.2040709@gmail.com> Message-ID: <1180792818.3207.1.camel@kennedy> On Sat, 2007-06-02 at 19:34 +0800, Ken YANG wrote: > hi all, > > when i install lifrea by yum, i found: > > Resolving Dependencies > --> Running transaction check > ---> Package liferea.i386 0:1.2.15b-1.fc8 set to be updated > --> Processing Dependency: firefox = 2.0.0.3 for package: liferea > --> Finished Dependency Resolution > Error: Missing Dependency: firefox = 2.0.0.3 is needed by package liferea > > > i am using fc8 rawhide this has already been built. http://koji.fedoraproject.org/koji/buildinfo?buildID=7768 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat Jun 2 14:07:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 10:07:30 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706021007.30552.jkeating@redhat.com> On Saturday 02 June 2007 04:41:14 Michael Schwendt wrote: > Without test-updates, I see these dependency problems in Fedora 7 + > Released Updates. Some are due to missing ExcludeArch. Scroll down for > i386 and x86_64. But the total number of problems is shocking. It looks like the majority of these are firefox related. Since it was a security update of Firefox, I don't think we would have waited for all these packages to catch up. The others look like ppc64 fallout still which is being worked on, and only a couple that don't fall into the above bucket: syck-0.55-14.fc7.src.rpm -> php = 0:5.2.1 Looks like tibbs built it in updates-candidate, but there is no update request for it that I can see. revisor-2.0.3.6-1.fc7.src.rpm -> livecd-tools(ppc) Probably needs to have an %ifnarch ppc ppc64 around the livecd-tools requirement. I've pinged the revisor guys. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Sat Jun 2 14:18:39 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 02 Jun 2007 15:18:39 +0100 Subject: Broken deps in Fedora 7 In-Reply-To: <200706021007.30552.jkeating@redhat.com> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> Message-ID: <1180793919.25232.121.camel@pmac.infradead.org> On Sat, 2007-06-02 at 10:07 -0400, Jesse Keating wrote: > revisor-2.0.3.6-1.fc7.src.rpm -> livecd-tools(ppc) Probably needs to > have an %ifnarch ppc ppc64 around the livecd-tools requirement. I've > pinged the revisor guys. I provided the basics of ppc support for livecd-tools a few weeks ago. -- dwmw2 From frank-buettner at gmx.net Sat Jun 2 14:20:47 2007 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Sat, 02 Jun 2007 16:20:47 +0200 Subject: No updates for FC7 via rsync In-Reply-To: <200706020830.10931.jkeating@redhat.com> References: <46611300.10203@gmx.net> <200706020830.10931.jkeating@redhat.com> Message-ID: <46617CBF.1070604@gmx.net> Jesse Keating schrieb: > On Saturday 02 June 2007 02:49:36 Frank B?ttner wrote: >> Hello, >> does any know whitch rsync mirror will provides the updates for FC7? >> Until now I can' find the update directory on any rsync mirror. > > You're looking in pub/fedora/linux/updates/7 ? > > Yes. but this directory don't exits on the rsync mirrors. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From denis at poolshark.org Sat Jun 2 14:21:03 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 02 Jun 2007 16:21:03 +0200 Subject: Broken deps in Fedora 7 In-Reply-To: <200706021007.30552.jkeating@redhat.com> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> Message-ID: <46617CCF.8090605@poolshark.org> Jesse Keating wrote: > On Saturday 02 June 2007 04:41:14 Michael Schwendt wrote: >> Without test-updates, I see these dependency problems in Fedora 7 + >> Released Updates. Some are due to missing ExcludeArch. Scroll down for >> i386 and x86_64. But the total number of problems is shocking. > > It looks like the majority of these are firefox related. Since it was a > security update of Firefox, I don't think we would have waited for all these > packages to catch up. how should we tackle this in the future ? 1) go towards an automated rebuild system, where the firefox maintainer can ask for automated rebuilds of the handful of packages that depend on it 2) instead, notify (automatically) the maintainers of the affected packages as soon as a firefox successful build appears in koji, but otherwise don't slow down the firefox release From jkeating at redhat.com Sat Jun 2 14:19:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 10:19:06 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <1180793919.25232.121.camel@pmac.infradead.org> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <1180793919.25232.121.camel@pmac.infradead.org> Message-ID: <200706021019.07005.jkeating@redhat.com> On Saturday 02 June 2007 10:18:39 David Woodhouse wrote: > I provided the basics of ppc support for livecd-tools a few weeks ago. Hence I told them (yet) on the 'no livecd-tools for ppc'. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Jun 2 14:22:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 19:52:28 +0530 Subject: Broken deps in Fedora 7 In-Reply-To: <200706021007.30552.jkeating@redhat.com> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> Message-ID: <46617D24.6080504@fedoraproject.org> Jesse Keating wrote: > On Saturday 02 June 2007 04:41:14 Michael Schwendt wrote: >> Without test-updates, I see these dependency problems in Fedora 7 + >> Released Updates. Some are due to missing ExcludeArch. Scroll down for >> i386 and x86_64. But the total number of problems is shocking. > > It looks like the majority of these are firefox related. Since it was a > security update of Firefox, I don't think we would have waited for all these > packages to catch up. I don't see how breaking all these dependencies without even any announcement to fedora-maintainers to notify other package maintainers depending on Firefox in the absence of build system taking of it automatically is a good thing. Rahul From jkeating at redhat.com Sat Jun 2 14:22:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 10:22:00 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <46617CCF.8090605@poolshark.org> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <46617CCF.8090605@poolshark.org> Message-ID: <200706021022.04053.jkeating@redhat.com> On Saturday 02 June 2007 10:21:03 Denis Leroy wrote: > how should we tackle this in the future ? > > 1) go towards an automated rebuild system, where the firefox maintainer > can ask for automated rebuilds of the handful of packages that depend on it > > 2) instead, notify (automatically) the maintainers of the affected > packages as soon as a firefox successful build appears in koji, but > otherwise don't slow down the firefox release I think it depends on the nature of the update and the flaw. Koji does have dep information in the database. What is missing is a utility to run once a new package is tagged to check if the build it is replacing is specifically needed by anything and thus there are broken deps. Theoretically the maintainer for those other packages and the maintainer that did the build could be notified via email that the dep problem exists so that they can work out a solution. Patches anybody? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 2 14:22:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 10:22:15 -0400 Subject: No updates for FC7 via rsync In-Reply-To: <46617CBF.1070604@gmx.net> References: <46611300.10203@gmx.net> <200706020830.10931.jkeating@redhat.com> <46617CBF.1070604@gmx.net> Message-ID: <200706021022.15186.jkeating@redhat.com> On Saturday 02 June 2007 10:20:47 Frank B?ttner wrote: > Yes. but this directory don't exits on the rsync mirrors. WHICH mirrors? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 2 14:26:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 10:26:59 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <46617D24.6080504@fedoraproject.org> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <46617D24.6080504@fedoraproject.org> Message-ID: <200706021026.59806.jkeating@redhat.com> On Saturday 02 June 2007 10:22:28 Rahul Sundaram wrote: > I don't see how breaking all these dependencies without even any > announcement to fedora-maintainers to notify other package maintainers > depending on Firefox in the absence of build system taking of it > automatically is a good thing. And where did you see me say that this was a good thing? Please stop putting bad intentions in my mouth. As I stated before we're still working on the dep checking part of bodhi and there is room for improvement within koji to alert maintainers when a new build will break deps of other builds. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Jun 2 14:36:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 20:06:07 +0530 Subject: Broken deps in Fedora 7 In-Reply-To: <200706021026.59806.jkeating@redhat.com> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <46617D24.6080504@fedoraproject.org> <200706021026.59806.jkeating@redhat.com> Message-ID: <46618057.2080002@fedoraproject.org> Jesse Keating wrote: > On Saturday 02 June 2007 10:22:28 Rahul Sundaram wrote: >> I don't see how breaking all these dependencies without even any >> announcement to fedora-maintainers to notify other package maintainers >> depending on Firefox in the absence of build system taking of it >> automatically is a good thing. > > And where did you see me say that this was a good thing? Please stop putting > bad intentions in my mouth. Where did I say that you said it was a good thing? I said I don't see how this could be a good thing. As I stated before we're still working on the > dep checking part of bodhi and there is room for improvement within koji to > alert maintainers when a new build will break deps of other builds. That would be helpful if it stops pushing updates when they break dependencies in addition to notifying all the relevant maintainers not just of the package but also package maintainers who depend on that package. In the specific case of the Firefox didn't the maintainer know that that new update was breaking dependencies? Rahul From mmcgrath at redhat.com Sat Jun 2 14:42:27 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 02 Jun 2007 09:42:27 -0500 Subject: Broken deps in Fedora 7 In-Reply-To: <46618057.2080002@fedoraproject.org> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <46617D24.6080504@fedoraproject.org> <200706021026.59806.jkeating@redhat.com> <46618057.2080002@fedoraproject.org> Message-ID: <466181D3.2020801@redhat.com> Rahul Sundaram wrote: > > That would be helpful if it stops pushing updates when they break > dependencies in addition to notifying all the relevant maintainers not > just of the package but also package maintainers who depend on that > package. In the specific case of the Firefox didn't the maintainer > know that that new update was breaking dependencies? > https://hosted.fedoraproject.org/projects/bodhi/browser and https://hosted.fedoraproject.org/projects/koji/browser If we spent less time arguing on the list and more time emailing Luke and Mike asking "how can I help" I think we'd all be in better shape.... -Mike From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 14:53:54 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 16:53:54 +0200 Subject: Broken deps in Fedora 7 Test Updates In-Reply-To: <200706020832.39558.jkeating@redhat.com> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706020832.39558.jkeating@redhat.com> Message-ID: <20070602165354.ff502c98.mschwendt.tmp0701.nospam@arcor.de> On Sat, 2 Jun 2007 08:32:39 -0400, Jesse Keating wrote: > > Without test-updates, I see these dependency problems in Fedora 7 + > > Released Updates. Some are due to missing ExcludeArch. Scroll down for > > i386 and x86_64. But the total number of problems is shocking. > > We're still working out the kinks in the dep checker for updates. With as > many packages as we have the time to see if the update set is valid is > reaching toward an hour + Fresh wreckage: source rpm: koan-0.4.0-1.fc7.src.rpm package: koan - 0.4.0-1.fc7.noarch from fedora-updates-testing-7-ppc64 unresolved deps: syslinux source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-ppc64 unresolved deps: deltarpm >= 0:3.4-2 source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-ppc unresolved deps: deltarpm >= 0:3.4-2 source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-x86_64 unresolved deps: deltarpm >= 0:3.4-2 source rpm: em8300-kmod-0.16.2-6.2.6.21_1.3194.fc7.src.rpm package: kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 from fedora-up dates-testing-7-i386 unresolved deps: kernel-i686 = 0:2.6.21-1.3194.fc7PAE-debug source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-i386 unresolved deps: deltarpm >= 0:3.4-2 --- full list including test updates (!) --- source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: ardour-0.99.3-8.fc7.src.rpm package: ardour - 0.99.3-8.fc7.ppc64 from fedora-7-ppc64 unresolved deps: liblrdf.so.2()(64bit) source rpm: bittorrent-4.4.0-5.fc7.src.rpm package: bittorrent - 4.4.0-5.fc7.noarch from fedora-7-ppc64 unresolved deps: python-crypto source rpm: emerald-themes-0.2.0-1.fc7.src.rpm package: emerald-themes - 0.2.0-1.fc7.noarch from fedora-7-ppc64 unresolved deps: emerald >= 0:0.2.0 beryl-core >= 0:0.2.0 source rpm: geda-examples-20070216-2.fc7.src.rpm package: geda-examples - 20070216-2.fc7.noarch from fedora-7-ppc64 unresolved deps: geda-gschem source rpm: glest-data-2.0.0-2.fc7.src.rpm package: glest-data - 2.0.0-2.fc7.noarch from fedora-7-ppc64 unresolved deps: glest = 0:2.0.0 source rpm: gsynaptics-0.9.11-1.fc7.src.rpm package: gsynaptics - 0.9.11-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: synaptics source rpm: koan-0.4.0-1.fc7.src.rpm package: koan - 0.4.0-1.fc7.noarch from fedora-updates-testing-7-ppc64 unresolved deps: syslinux source rpm: netcdf-decoders-4.1.4-1.fc7.src.rpm package: netcdf-decoders - 4.1.4-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: perl(NetCDF) source rpm: oooqs2-1.0-3.fc6.src.rpm package: oooqs2 - 1.0-3.fc6.ppc64 from fedora-7-ppc64 unresolved deps: openoffice.org-draw openoffice.org-base openoffice.org-calc openoffice.org-writer openoffice.org-math openoffice.org-impress source rpm: openoffice.org-dict-cs_CZ-20060303-5.fc7.src.rpm package: openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 from fedora-7-ppc64 unresolved deps: openoffice.org-core source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.ppc64 from fedora-7-ppc64 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: python-basemap-0.9.5-1.fc7.src.rpm package: python-basemap - 0.9.5-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: python-matplotlib >= 0:0.81 source rpm: python-paramiko-1.6.4-1.fc7.src.rpm package: python-paramiko - 1.6.4-1.fc7.noarch from fedora-7-ppc64 unresolved deps: python-crypto >= 0:1.9 source rpm: python-twisted-conch-0.7.0-4.fc7.src.rpm package: python-twisted-conch - 0.7.0-4.fc7.ppc64 from fedora-7-ppc64 unresolved deps: python-crypto source rpm: resapplet-0.1.1-5.fc7.src.rpm package: resapplet - 0.1.1-5.fc7.ppc64 from fedora-7-ppc64 unresolved deps: system-config-display source rpm: revisor-2.0.3.6-1.fc7.src.rpm package: revisor - 2.0.3.6-1.fc7.noarch from fedora-updates-7-ppc64 unresolved deps: livecd-tools source rpm: rosegarden4-1.4.0-1.fc7.src.rpm package: rosegarden4 - 1.4.0-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: liblrdf.so.2()(64bit) source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.ppc64 from fedora-7-ppc64 unresolved deps: php = 0:5.2.1 source rpm: trac-0.10.3.1-2.fc7.src.rpm package: trac - 0.10.3.1-2.fc7.noarch from fedora-7-ppc64 unresolved deps: python-clearsilver >= 0:0.9.3 source rpm: wxMaxima-0.7.2-1.fc7.src.rpm package: wxMaxima - 0.7.2-1.fc7.ppc64 from fedora-7-ppc64 unresolved deps: maxima >= 0:5.11 source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-ppc64 unresolved deps: deltarpm >= 0:3.4-2 source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: blam-1.8.3-3.fc7.src.rpm package: blam - 1.8.3-3.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: glest-data-2.0.0-2.fc7.src.rpm package: glest-data - 2.0.0-2.fc7.noarch from fedora-7-ppc unresolved deps: glest = 0:2.0.0 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc from fedora-7-ppc unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.ppc from fedora-7-ppc unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.ppc from fedora-7-ppc unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: revisor-2.0.3.6-1.fc7.src.rpm package: revisor - 2.0.3.6-1.fc7.noarch from fedora-updates-7-ppc unresolved deps: livecd-tools source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.ppc from fedora-7-ppc unresolved deps: php = 0:5.2.1 source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-ppc unresolved deps: deltarpm >= 0:3.4-2 source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: blam-1.8.3-3.fc7.src.rpm package: blam - 1.8.3-3.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 from fedora-7-x86_64 unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 from fedora-7-x86_64 unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 from fedora-7-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.21-1.3116.fc7 source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 from fedora-7-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.i386 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.i386 from fedora-7-x86_64 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.x86_64 from fedora-7-x86_64 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.x86_64 from fedora-7-x86_64 unresolved deps: php = 0:5.2.1 source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-x86_64 unresolved deps: deltarpm >= 0:3.4-2 source rpm: Democracy-0.9.5.1-8.fc7.src.rpm package: Democracy - 0.9.5.1-8.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: blam-1.8.3-3.fc7.src.rpm package: blam - 1.8.3-3.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: gtkmozembedmm-1.4.2.cvs20060817-10.fc7.src.rpm package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 from fedora-7-i386 unresolved deps: gecko-libs = 0:1.8.1.3 source rpm: em8300-kmod-0.16.2-6.2.6.21_1.3194.fc7.src.rpm package: kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 from fedora-updates-testing-7-i386 unresolved deps: kernel-i686 = 0:2.6.21-1.3194.fc7PAE-debug source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 from fedora-7-i386 unresolved deps: kernel-i586 = 0:2.6.21-1.3116.fc7 source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 from fedora-7-i386 unresolved deps: kernel-i686 = 0:2.6.21-1.3116.fc7 source rpm: sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7.src.rpm package: kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 from fedora-7-i386 unresolved deps: kernel-i686 = 0:2.6.21-1.3116.fc7PAE source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml - 0.16.4-2.fc7.i386 from fedora-7-i386 unresolved deps: firefox = 0:2.0.0.3 source rpm: openvrml-0.16.4-2.fc7.src.rpm package: openvrml-devel - 0.16.4-2.fc7.i386 from fedora-7-i386 unresolved deps: firefox-devel = 0:2.0.0.3 source rpm: syck-0.55-14.fc7.src.rpm package: syck-php - 0.55-14.fc7.i386 from fedora-7-i386 unresolved deps: php = 0:5.2.1 source rpm: yum-presto-0.3.10-1.fc7.src.rpm package: yum-presto - 0.3.10-1.fc7.noarch from fedora-updates-testing-7-i386 unresolved deps: deltarpm >= 0:3.4-2 From ville.skytta at iki.fi Sat Jun 2 15:11:46 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 2 Jun 2007 18:11:46 +0300 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706020833.32990.jkeating@redhat.com> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706021448.27123.ville.skytta@iki.fi> <200706020833.32990.jkeating@redhat.com> Message-ID: <200706021811.46742.ville.skytta@iki.fi> On Saturday 02 June 2007, Jesse Keating wrote: > On Saturday 02 June 2007 07:48:26 Ville Skytt? wrote: > > I don't think we can define __arch_install_post automatically (ie. "claim > > ownership of the macro") for all systems. ?If the system already had > > __arch_install_post set to something in let's say /etc/rpm/macros, what > > happens? ?What about ~/.rpmmacros? > > These override the redhat-rpm-macros don't they? I'm not sure of the > preference order. Neither am I, especially in the case if we include this stuff and enable it by default in a rpmdevtools subpackage. It would probably have to happen by dropping a let's say /etc/rpm/macros.rpmdevtools file; would that override something set in /etc/rpm/macros or vice versa? Anyway I guess setting it in redhat-rpm-config's defaults would be the safest way to do it. That would mean that the scripts [0] in question would be also better included in it instead of in a rpmdevtools subpackage. [0] In addition to check-buildroot, check-rpaths would be nice to have there. From frank-buettner at gmx.net Sat Jun 2 15:11:56 2007 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Sat, 02 Jun 2007 17:11:56 +0200 Subject: No updates for FC7 via rsync In-Reply-To: <200706021022.15186.jkeating@redhat.com> References: <46611300.10203@gmx.net> <200706020830.10931.jkeating@redhat.com> <46617CBF.1070604@gmx.net> <200706021022.15186.jkeating@redhat.com> Message-ID: <466188BC.5040502@gmx.net> Jesse Keating schrieb: > On Saturday 02 June 2007 10:20:47 Frank B?ttner wrote: >> Yes. but this directory don't exits on the rsync mirrors. > > WHICH mirrors? > > rsync.uni-bayreuth.de::fedora/linux/ rsync://ftp.uni-muenster.de/fedora/linux/ for example These are on the list at http://mirrors.fedoraproject.org/publiclist And other for example rsync://sunsite.mff.cuni.cz/fedora/linux will work. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Sat Jun 2 15:48:58 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 2 Jun 2007 18:48:58 +0300 Subject: Broken deps in Fedora 7 Test Updates In-Reply-To: <20070602165354.ff502c98.mschwendt.tmp0701.nospam@arcor.de> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706020832.39558.jkeating@redhat.com> <20070602165354.ff502c98.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706021848.59628.ville.skytta@iki.fi> On Saturday 02 June 2007, Michael Schwendt wrote: > > source rpm: em8300-kmod-0.16.2-6.2.6.21_1.3194.fc7.src.rpm > package: kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 from > fedora-updates-testing-7-i386 unresolved deps: > kernel-i686 = 0:2.6.21-1.3194.fc7PAE-debug $ rpm -qp --provides kernel-PAE-debug-2.6.21-1.3194.fc7.i686.rpm [...] kernel-i686 = 2.6.21-1.3194.fc7PAE-debug Perhaps something in what creates this report is broken, ie. not handling the two dashes in the right-side "EVR" the same way as rpm, yum, and smart. None of those (tested on FC6) have any problem with this dependency. Note that this ends up with the version of the provides being "2.6.21-1.3194.fc7PAE" (yes, with the dash) and release being "debug" in repodata which is not pretty, but again, it works. More discussion/info in https://bugzilla.redhat.com/227533 From pertusus at free.fr Sat Jun 2 15:53:23 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 17:53:23 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <46616EDA.8030007@leemhuis.info> References: <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> Message-ID: <20070602155323.GA2840@free.fr> On Sat, Jun 02, 2007 at 03:21:30PM +0200, Thorsten Leemhuis wrote: > On 02.06.2007 12:28, Michael Schwendt wrote: > > On Sat, 02 Jun 2007 15:25:04 +0530, Rahul Sundaram wrote: > > > > [...] The community has lost control over what used to be a > > community-driven Fedora Extras. [...] > > +1 to that -- if Fedora Extras one or two years ago would have wanted to > switch something like koji or bodhi then I'd say FESCo would have looked > at it first before Extras would have started to use it. FESCo further > would have insisted on proper docs, clear rules (discussed by the > community beforehand) and easy procedures. I can't agree more to that, Thorsten. Thanks to have put it so clearly. -- Pat From pertusus at free.fr Sat Jun 2 15:58:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 17:58:19 +0200 Subject: anyone willing to maintain xcalc? In-Reply-To: <46615DAF.8000909@poolshark.org> References: <20070602111924.GJ11101@free.fr> <466153F2.5010008@nigelj.com> <46615DAF.8000909@poolshark.org> Message-ID: <20070602155819.GB2840@free.fr> On Sat, Jun 02, 2007 at 02:08:15PM +0200, Denis Leroy wrote: > > I can pick it up also. Let me know Nigel. Nice. I think the best is to open a new submission ticket, I will review it shortly. -- Pat From caillon at redhat.com Sat Jun 2 16:41:49 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 02 Jun 2007 12:41:49 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <46618057.2080002@fedoraproject.org> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <46617D24.6080504@fedoraproject.org> <200706021026.59806.jkeating@redhat.com> <46618057.2080002@fedoraproject.org> Message-ID: <46619DCD.2090909@redhat.com> Rahul Sundaram wrote: > In the specific case of the Firefox didn't the maintainer know > that that new update was breaking dependencies? Why don't you ask him? From sundaram at fedoraproject.org Sat Jun 2 16:45:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Jun 2007 22:15:42 +0530 Subject: Broken deps in Fedora 7 In-Reply-To: <46619DCD.2090909@redhat.com> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <46617D24.6080504@fedoraproject.org> <200706021026.59806.jkeating@redhat.com> <46618057.2080002@fedoraproject.org> <46619DCD.2090909@redhat.com> Message-ID: <46619EB6.9010704@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> In the specific case of the Firefox didn't the maintainer know that >> that new update was breaking dependencies? > > Why don't you ask him? I am ;-) Rahul From darrellpf at gmail.com Sat Jun 2 16:58:32 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 2 Jun 2007 09:58:32 -0700 Subject: rawhide report: 20070601 changes In-Reply-To: <200706020524.l525OU7X002727@porkchop.devel.redhat.com> References: <200706020524.l525OU7X002727@porkchop.devel.redhat.com> Message-ID: The 3199 kernel seems to have some strange problems on i386. 1) Spends quite a bit of time at startup at "Press I for interactive startup" before the udev line appears. 2) The system clock wasn't set properly (ntp had problems?) 3) The beagle desktop search applet died when it started 4) Java (the Sun version) segfaulted Lots of processes such as firefox continued to work ok. Reverting to 3194 kernel made the strangeness disappear. darrell From nicolas.mailhot at laposte.net Sat Jun 2 17:21:22 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 02 Jun 2007 19:21:22 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <46616EDA.8030007@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> Message-ID: <1180804882.3294.24.camel@rousalka.dyndns.org> Le samedi 02 juin 2007 ? 15:21 +0200, Thorsten Leemhuis a ?crit : > On 02.06.2007 12:28, Michael Schwendt wrote: > > On Sat, 02 Jun 2007 15:25:04 +0530, Rahul Sundaram wrote: > > > > [...] The community has lost control over what used to be a > > community-driven Fedora Extras. [...] > > +1 to that -- if Fedora Extras one or two years ago would have wanted to > switch something like koji or bodhi then I'd say FESCo would have looked > at it first before Extras would have started to use it. I don't agree at all: 1. FESCo's past decisions were constrained by the way Core was built, it's totally unreasonable to claim it would have made the same choices in a merged context 2. Merging means Core packages have their say on Extras just like Extras packagers have their say on Core. That's how merges work. Original control is diluted in exchange of a broader reach. 3. The current grumbling and contestation is aimed both at merge changes and at FESCo decisions. People object to decisions enforcement because they just want to do their own thing. FE was never about freewheeling individualities (witness the numerous guidelines produced). I don't hear many base packagers objecting, and frankly the way the "community" is invoked in support of a small number of personalities is grating on my nerves a lot. Community ? big packagers club 4. I'm actually pretty amazed things went so smoothly considering the late crash-landing of koji and bodhi. The infrastructure team made a terrific job, give them some slack. Things will be fixed faster by cool problem reporting than by flaming endlessly on the lists. -- 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 tibbs at math.uh.edu Sat Jun 2 17:39:16 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2007 12:39:16 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Not even sponsors have the privileges anymore to intervene in CVS MS> or buildsys (thanks god the people I sponsor are the FESCo chair, MS> FESCo members and pleasant packagers who don't cause any trouble MS> anymore). Many of us desperately want this; we even brought it up at the last FESCO meeting but unfortunately the infrastructure just isn't there. It's the packageDB thing again. Fortunately Red Hat has hired Toshio so hopefully something will happen with that in the relatively near future. I personally have taken that as a commitment to getting something done here. Kevin and I (both community people with no ties to Red Hat) simply asked for more access and it was granted to us, so I don't see any institutional denial of CVS or buildsys access. If you (or anyone else) needs access to a package they've been locked out of, just ask for it. (It should suffice to make a regular CVS admin request and explain the situation.) I am not sufficiently informed as to which types of koji access are available. MS> [...] after years there still is no team that could step in and MS> apply emergency fixes. Well, speaking as someone who has done just that, I'm not exactly sure what you think is lacking here. I'm not disagreeing with the entirety of your message, but I think that perhaps you are misinformed as to the points which I have commented on here. - J< From pertusus at free.fr Sat Jun 2 17:42:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 19:42:04 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180804882.3294.24.camel@rousalka.dyndns.org> References: <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <1180804882.3294.24.camel@rousalka.dyndns.org> Message-ID: <20070602174203.GD2840@free.fr> On Sat, Jun 02, 2007 at 07:21:22PM +0200, Nicolas Mailhot wrote: > > 2. Merging means Core packages have their say on Extras just like Extras > packagers have their say on Core. That's how merges work. Original > control is diluted in exchange of a broader reach. The issue is not there. The issue is more an issue of methods. There was no discussion in advance and no consideration of how to limit the impact on packager work. > 3. The current grumbling and contestation is aimed both at merge changes > and at FESCo decisions. People object to decisions enforcement because > they just want to do their own thing. FE was never about freewheeling > individualities (witness the numerous guidelines produced). I don't hear > many base packagers objecting, and frankly the way the "community" is > invoked in support of a small number of personalities is grating on my > nerves a lot. Community ? big packagers club Enforcing guidelines on packaging is a different issue than choosing processes and workflow. Especially in Fedora: packaging guidelines are open to comment by anyone, ratified by the FPC and FESCO. The processes and workflow have been implemented without discussing with anybody, without any control by the community. It wouldn't be an issue if the choices were seen by all the community members as best, but lately all the choices were associated with putting choices about packages in other persons hands than packagers and complex procedures that add a lot of steps to the workflow. Ok, a lot of packagers didn't said anything but quite a few did, and it is always the same about all issues, most of the packagers don't say anything. > 4. I'm actually pretty amazed things went so smoothly considering the > late crash-landing of koji and bodhi. The infrastructure team made a > terrific job, give them some slack. Things will be fixed faster by cool > problem reporting than by flaming endlessly on the lists. Once again the issue is not a technical one, the infrastructure team did indeed very well (especially with koji, in my opinion) but the methods used to drive Fedora. -- Pat From dwmw2 at infradead.org Sat Jun 2 17:46:20 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 02 Jun 2007 18:46:20 +0100 Subject: Don't put new packages through updates-testing In-Reply-To: References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1180806380.25232.137.camel@pmac.infradead.org> On Sat, 2007-06-02 at 12:39 -0500, Jason L Tibbitts III wrote: > Kevin and I (both community people with no ties to Red Hat) simply > asked for more access and it was granted to us, so I don't see any > institutional denial of CVS or buildsys access. If you (or anyone > else) needs access to a package they've been locked out of, just ask > for it. (It should suffice to make a regular CVS admin request and > explain the situation.) I am not sufficiently informed as to which > types of koji access are available. Can I submit a 'regular CVS admin request' for removing all the pkg.acl files from all packages? Or at least the ones which were added without the maintainer's explicit request? If we want to foster teamwork, then _defaulting_ to a completely closed policy is a very poor choice. -- dwmw2 From tibbs at math.uh.edu Sat Jun 2 17:56:22 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2007 12:56:22 -0500 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <46616EDA.8030007@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> Okay, we wanted the merge. Yes, we did. You and I sat in the same meetings at the same conference and for my part I can't say that what we have now is fundamentally any different than what was promised to us. Yes, we're not all of the way there, and unfortunately a release complicated matters, but I simply don't see any of the negative shifts away from the community that I keep seeing complaints about. - J< From neugens at limasoftware.net Sat Jun 2 18:08:25 2007 From: neugens at limasoftware.net (Mario Torre) Date: Sat, 02 Jun 2007 20:08:25 +0200 Subject: Firefox 2.0 fails to install Flash 9 plugin In-Reply-To: <604aa7910706011720x7d2db7efkd7deb6b9c0885cdc@mail.gmail.com> References: <64b14b300706011634j42ad5d10jd741aeabe3bee755@mail.gmail.com> <3adc77210706011708i2ee4503cg5e80656f9c1b8ec2@mail.gmail.com> <604aa7910706011720x7d2db7efkd7deb6b9c0885cdc@mail.gmail.com> Message-ID: <1180807705.3390.6.camel@nirvana.limasoftware.net> Il giorno ven, 01/06/2007 alle 16.20 -0800, Jeff Spaleta ha scritto: > On 6/1/07, Naheem Zaffar wrote: > > Works for me. I tried on i686 as root. > > Does it work as a normal user. > > I just did this on my rawhide box... it works just fine for me as a normal user. > I'd have to wait till a revert one of my rawhide boxes to f7 to be > 100% sure its a comparable situation...but i'd be a little shocked if > at this point my rawhide box worked but f7 didn't since there hasnt > been that much diversion between the two yet. > > -jef Works for me on the first try, normal user, under F7 (i386). I was even amazed because I used to install it via rpm magics, instead it worked out of the box (a great step for usability). Hope that helps, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From Lam at Lam.pl Sat Jun 2 18:23:27 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 02 Jun 2007 20:23:27 +0200 Subject: rawhide report: 20070601 changes In-Reply-To: References: <200706020524.l525OU7X002727@porkchop.devel.redhat.com> Message-ID: <1180808607.4028.7.camel@pensja.lam.pl> Dnia 02-06-2007, sob o godzinie 09:58 -0700, darrell pfeifer napisa?(a): > 4) Java (the Sun version) segfaulted On my system, QuakeForge (compiled by me 4 days ago, when development was an almost-F7) segfaults in memset() (run from _dl_map_object_from_fd() trying to map a shared library) when I try to run it, also "ldd `which nq-glx`" is crashing, but "/lib/ld-linux.so.2 `nq-glx`" runs the game. Weird. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From davej at redhat.com Sat Jun 2 18:38:28 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 2 Jun 2007 14:38:28 -0400 Subject: fedora for ARM In-Reply-To: <20070602032955.GC16918@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> Message-ID: <20070602183828.GI7445@redhat.com> On Sat, Jun 02, 2007 at 05:29:55AM +0200, Lennert Buytenhek wrote: Hi Lennert, > I'm posting here because I would really really like to get the relevant > diffs merged back into Fedora. I took a quick look at the kernel dir, and the specfile changes are pretty unoffensive, and mergable imo. The config file however I think might be better served if it was done differently. Instead of having a single flat config file, the Fedora kernel rpm generates configs out of templates (see configs/ dir in cvs) It should be fairly simple to change this though.. just remove all the symbols from your current config that are already in config-generic (except for ones you want to override). Then add a stanza to Makefile.config to call merge.pl on config-generic and config-arm. The advantages of doing it this way are that we don't have to update n config files when upstream adds a new option, just adding it to config-generic gets it automatically added to all archs where it makes sense. Having a quick scan through some of the options you have set.. # CONFIG_UTRACE is not set note that this will also disable ptrace too afaik. (I'm aware that there are difficulties of porting utrace to arm). CONFIG_DEFAULT_DEADLINE=y Any reason not to go with CFQ like we do on other archs? CONFIG_IDE=y Has anyone looked at porting the ARM ATA drivers over to libata ? # CONFIG_VT is not set Is this always going to be useless on ARM ? # CONFIG_MMC is not set might be handy for handhelds ? # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT3_FS_XATTR is not set # CONFIG_SECURITY is not set aww, no selinux ? There's a lot of stuff built in =y, rather than modular which seems a little wasteful. (In fact, there's nothing =m, yet CONFIG_MODULES=y :-) There's a few things that stuck out that seem like they may be useful (ipsec support for eg) in some use-cases for embedded systems that were disabled. I'll concede that Fedora-ARM is breaking new ground here, in that its the first arch we're supporting (other than olpc I guess) where the size of the generated rpms is a concern, but I think there's probably a balance to be struck between what we have so far, and a 'generic' kernel that may be of use to many different projects without them needing to rebuild parts of the kernel that were left out. Dave -- http://www.codemonkey.org.uk From buildsys at redhat.com Sat Jun 2 18:52:29 2007 From: buildsys at redhat.com (Build System) Date: Sat, 2 Jun 2007 14:52:29 -0400 Subject: rawhide report: 20070602 changes Message-ID: <200706021852.l52IqTCW001347@porkchop.devel.redhat.com> New package calcurse Text-based personal organizer New package libkdcraw A library for decoding RAW picture files New package perl-Crypt-OpenSSL-RSA Perl interface to OpenSSL for RSA New package xournal Xournal notetaking, sketching and PDF annotation Updated Packages: chmsee-1.0.0-0.19.beta2.fc8 --------------------------- * Sat Jun 02 2007 bbbush - 1.0.0-0.18.beta2 - update for firefox 1.5.0.12 and 2.0.0.4 clearsilver-0.10.4-4.fc8 ------------------------ * Fri Jun 01 2007 Jeffrey C. Ollie - 0.10.4-4 - Minor cleanups * Fri Jun 01 2007 Jesse Keating - 0.10.4-3.1 - Disable java subpackages on el4 gnome-python2-extras-2.14.3-2.fc8 --------------------------------- * Fri Jun 01 2007 Matthew Barnes - 2.14.3-3.fc7 - Rebuild against firefox-2.0.0.4. gnome-vfs2-obexftp-0.2-7.fc8 ---------------------------- * Sat Jun 02 2007 - Bastien Nocera - 0.2-7 - Fix crash when we can't connect through an rfcomm socket, reported by Olivier Fourdan kernel-2.6.21-1.3199.fc8 ------------------------ * Fri Jun 01 2007 Dave Jones - Disable ppc64 builds. http://koji.fedoraproject.org/koji/getfile?taskID=21950&name=build.log * Fri Jun 01 2007 Dave Jones - Update utrace to latest. * Fri Jun 01 2007 Dave Jones - 2.6.22-rc3-git6 libdap-3.7.7-1.fc8.1 -------------------- * Thu May 31 2007 Patrice Dumas 3.7.7-1.1 - update to 3.7.7 * Sat May 12 2007 Patrice Dumas 3.7.6-4 - remove static libs - set the same doc file timestamps for all arches * Mon Apr 30 2007 Patrice Dumas 3.7.6-3 - correct the library install order - keep timestamps - add documentation in a subpackage liferea-1.2.15b-2.fc8 --------------------- * Fri Jun 01 2007 Brian Pepple - 1.2.15b-2 - Rebuild for new gecko release. perl-Class-C3-0.18-1.fc8 ------------------------ * Fri Jun 01 2007 Chris Weyl 0.18-1 - update to 0.18 * Wed May 09 2007 Chris Weyl 0.17-1 - update to 0.17 - BR Class::C3::XS * Mon Sep 25 2006 Chris Weyl 0.14-1 - update to 0.14 perl-Data-Alias-1.05-1.fc8 -------------------------- * Fri Jun 01 2007 Chris Weyl 1.05-1 - update to 1.05 perl-Event-1.09-1.fc8 --------------------- * Fri Jun 01 2007 Chris Weyl 1.09-1 - update to 1.09 - add t/ to doc perl-Sub-Exporter-0.974-1.fc8 ----------------------------- * Fri Jun 01 2007 Chris Weyl 0.974-1 - update to 0.974 From jkeating at redhat.com Sat Jun 2 18:54:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 14:54:16 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <46618057.2080002@fedoraproject.org> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021026.59806.jkeating@redhat.com> <46618057.2080002@fedoraproject.org> Message-ID: <200706021454.20046.jkeating@redhat.com> On Saturday 02 June 2007 10:36:07 Rahul Sundaram wrote: > In the specific case of the Firefox didn't the maintainer know > that that new update was breaking dependencies? In the specific case of a firefox security update it's often best to _not_ hold up the update until every single fringe package that builds against firefox catches up. I wonder if this is one of the reasons that upstream isn't ready for firefox to be a platform to build against yet. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 2 18:55:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 14:55:11 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706021811.46742.ville.skytta@iki.fi> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706020833.32990.jkeating@redhat.com> <200706021811.46742.ville.skytta@iki.fi> Message-ID: <200706021455.11539.jkeating@redhat.com> On Saturday 02 June 2007 11:11:46 Ville Skytt? wrote: > [0] In addition to check-buildroot, check-rpaths would be nice to have > there. Indeed they would. Lets work with Jon Masters to get these integrated by F8 Test 1. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 2 19:00:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 15:00:10 -0400 Subject: No updates for FC7 via rsync In-Reply-To: <466188BC.5040502@gmx.net> References: <46611300.10203@gmx.net> <200706021022.15186.jkeating@redhat.com> <466188BC.5040502@gmx.net> Message-ID: <200706021500.10874.jkeating@redhat.com> On Saturday 02 June 2007 11:11:56 Frank B?ttner wrote: > Jesse Keating schrieb: > > On Saturday 02 June 2007 10:20:47 Frank B?ttner wrote: > >> Yes. but this directory don't exits on the rsync mirrors. > > > > WHICH mirrors? > > rsync.uni-bayreuth.de::fedora/linux/ > rsync://ftp.uni-muenster.de/fedora/linux/ > for example > These are on the list at http://mirrors.fedoraproject.org/publiclist > And other for example rsync://sunsite.mff.cuni.cz/fedora/linux will work. That's entirely up to the mirrors to provide such rsync access. We provide the rsync access to our mirrors, they in turn choose what they provide to the world at large, and we have no real control over that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Sat Jun 2 19:19:23 2007 From: buc at odusz.so-cdu.ru (buc) Date: Sat, 02 Jun 2007 23:19:23 +0400 Subject: FreeTDS (legal) In-Reply-To: <1180624504.6254.558.camel@localhost.localdomain> References: <20070531082107.2e47582d.jklowden@freetds.org> <465EC40B.4000108@hhs.nl> <1180624504.6254.558.camel@localhost.localdomain> Message-ID: <1180811963.2247.11.camel@localhost.localdomain> On Thu, 2007-05-31 at 10:15 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-05-31 at 14:48 +0200, Hans de Goede wrote: > > > Thanks for your long mail! > > > > Notice that freetds is currently in livna already, but having it in Fedora > > proper would be advantagous for packages like libgda (which could then support) > > tds) and php-freetds > > > > This gets a +1 from me. > > > > Spot, does this need to go through RH-legal, or can you ok it? > > I'm still not happy about the only available standards document being > marked confidential, but I'm convinced there is no patent concern. > > This should be fine to move to Fedora. > > James, thanks for the clarifications. > > ~spot > Well, I'll begin the moving (submit for review etc.) in coming week. Additionally, I'll handle php-mssql stuff too. James, Could you please add all your clarifications into upstream's tarball (as some README.patents file or similar) ? Regards, Dmitry Butskoy From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 19:25:32 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 21:25:32 +0200 Subject: kmod-em8300-PAE-debug - Re: Broken deps in Fedora 7 Test Updates In-Reply-To: <200706021848.59628.ville.skytta@iki.fi> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706020832.39558.jkeating@redhat.com> <20070602165354.ff502c98.mschwendt.tmp0701.nospam@arcor.de> <200706021848.59628.ville.skytta@iki.fi> Message-ID: <20070602212532.6bffa5e8.mschwendt.tmp0701.nospam@arcor.de> On Sat, 2 Jun 2007 18:48:58 +0300, Ville Skytt? wrote: > On Saturday 02 June 2007, Michael Schwendt wrote: > > > > source rpm: em8300-kmod-0.16.2-6.2.6.21_1.3194.fc7.src.rpm > > package: kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 from > > fedora-updates-testing-7-i386 unresolved deps: > > kernel-i686 = 0:2.6.21-1.3194.fc7PAE-debug > > $ rpm -qp --provides kernel-PAE-debug-2.6.21-1.3194.fc7.i686.rpm > [...] > kernel-i686 = 2.6.21-1.3194.fc7PAE-debug > > Perhaps something in what creates this report is broken, ie. not handling the > two dashes in the right-side "EVR" the same way as rpm, yum, and smart. None > of those (tested on FC6) have any problem with this dependency. Remember that yum 2.6.1 is the backend for repoclosure. In this case, a whatProvides for "kernel-i686 EQ 0:2.6.21-1.3194.fc7PAE-debug" doesn't find any provider. When copying these two packages kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686.rpm kernel-PAE-debug-2.6.21-1.3194.fc7.i686.rpm into a local repository, the problem is not reproducible, and the same yum query returns the kernel package. I need to dig deeper. The kmod-em8300-PAE-debug packages in FE6, have they ever before caused false positives like here with F7? From a.badger at gmail.com Sat Jun 2 19:24:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 02 Jun 2007 12:24:27 -0700 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <46616EDA.8030007@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> Message-ID: <1180812267.30126.33.camel@localhost.localdomain> On Sat, 2007-06-02 at 15:21 +0200, Thorsten Leemhuis wrote: > On 02.06.2007 12:28, Michael Schwendt wrote: > > On Sat, 02 Jun 2007 15:25:04 +0530, Rahul Sundaram wrote: > > > > [...] The community has lost control over what used to be a > > community-driven Fedora Extras. [...] > > +1 to that -- if Fedora Extras one or two years ago would have wanted to > switch something like koji or bodhi then I'd say FESCo would have looked > at it first before Extras would have started to use it. FESCo further > would have insisted on proper docs, clear rules (discussed by the > community beforehand) and easy procedures. > I don't agree with this portion entirely. There are two ways in which control has been shifted in the past year: 1) The community has *delegated* control over some of the implementation to certain teams (notably releng and infrastructure). This means there is less hands on work being done that involves all community members and more goal driven work. The merge, for instance, was a goal given to infrastructure to implement tools for and releng to create the policies that would allow "Core" to make a Fedora 7 Release. 2) The community is in the process of integrating the Core Packager Community and the Extras Packager Community. This means that the power of both entities will become less concentrated as concerns from each need to be addressed. > So lets deal with it [the merge] now -- for example by making "contributing to > Fedora easy again, get the community involved better into the decisions > process and make packagers happy again" one of the most important > "Features" for Fedora 8. Otherwise the merge might fail in the end. +1. I think one of the goals that FESCo and the community need to hand to infrastructure and releng for the F8 cycle is "Make things easier to use". This thread is proof that this will require some debate. I think what would help all sides see the way forward is to enunciate the issues and goals as they see them before stepping into the realm of solutions. We need to lay out what the problems the current procedures address are and what the procedures leave to be desired. Then we can provide solutions that have different tradeoffs to see how they work or, when all the planets align, solutions that address all the concerns :-) Another goal that I think we need is to work on integrating the Core and Extras Communities. When Fedora started, there was a commitment from within Red Hat that decision making would happen on public forums with community input. Despite the problems outlined above, I think the past year has seen this commitment become much more solid than before (Board Meetings in IRC, discussions by the internal teams on the mailing lists, the merge allowing people from the Extras Community to make spins, Extras Community members on the releng team, etc.) However, we need to take the next step. We've consolidated our decision making under one hierarchy but we need to combine our communities as well. It shouldn't matter that we have some people working at Red Hat, some for Dell, some for themselves, some for universities.... We need to find ways to start thinking of ourselves as one community. And we need to start communicating with each other as members of a single team. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ben.lewis at benl.co.uk Sat Jun 2 19:26:37 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Sat, 02 Jun 2007 20:26:37 +0100 Subject: Change to U.T.C. based release times Message-ID: <4661C46D.5070105@benl.co.uk> Hi all. A small-ish proposal, but one which would affect everyone - I propose moving from a release time based on Eastern time, and hence affected by D.S.T., to one based on U.T.C. - to this end I propose changing to 13:00 UTC - which is 10:00 EST and 11:00 EDT (those times may well be wrong, but you get the idea! :)). My rationale for this is that it can get just a little confusing trying to tell people the time of a release when its been thrown by an hour due to D.S.T. All thoughts (and corrections to the numbers, most probably) welcome. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Sat Jun 2 19:31:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 15:31:00 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180812267.30126.33.camel@localhost.localdomain> References: <46601BAF.8000507@hhs.nl> <46616EDA.8030007@leemhuis.info> <1180812267.30126.33.camel@localhost.localdomain> Message-ID: <200706021531.00989.jkeating@redhat.com> On Saturday 02 June 2007 15:24:27 Toshio Kuratomi wrote: > It shouldn't > matter that we have some people working at Red Hat, some for Dell, some > for themselves, some for universities.... We need to find ways to start > thinking of ourselves as one community. ?And we need to start > communicating with each other as members of a single team. +10. This is a big thing I've been trying to stress. Employment should not matter anymore when talking about Fedora Community. Sure I'm employed by Red Hat to work on Fedora. When I was at Pogo Linux, a slice of my time was paid for by them to work on Fedora Legacy and to represent the wants of IHVs in Fedora. I'm sure there are other people who are paid in part for their work on Fedora. Who signs the paycheck needs not matter. What matters is the work they do and the value they bring to the Fedora project, and what intrests they represent. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 2 19:31:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 15:31:40 -0400 Subject: Change to U.T.C. based release times In-Reply-To: <4661C46D.5070105@benl.co.uk> References: <4661C46D.5070105@benl.co.uk> Message-ID: <200706021531.40892.jkeating@redhat.com> On Saturday 02 June 2007 15:26:37 Benjamin Lewis wrote: > Hi all. > > A small-ish proposal, but one which would affect everyone - I propose > moving from a release time based on Eastern time, and hence affected by > D.S.T., to one based on U.T.C. - to this end I propose changing to 13:00 > UTC - which is 10:00 EST and 11:00 EDT (those times may well be wrong, > but you get the idea! :)). My rationale for this is that it can get just > a little confusing trying to tell people the time of a release when its > been thrown by an hour due to D.S.T. > > All thoughts (and corrections to the numbers, most probably) welcome. Everywhere that I listed the release time I thought I listed the UTC time as well. Did I miss somewhere? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 19:42:45 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 21:42:45 +0200 Subject: kmod-em8300-PAE-debug - Re: Broken deps in Fedora 7 Test Updates In-Reply-To: <20070602212532.6bffa5e8.mschwendt.tmp0701.nospam@arcor.de> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706020832.39558.jkeating@redhat.com> <20070602165354.ff502c98.mschwendt.tmp0701.nospam@arcor.de> <200706021848.59628.ville.skytta@iki.fi> <20070602212532.6bffa5e8.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070602214245.184ee12e.mschwendt.tmp0701.nospam@arcor.de> On Sat, 2 Jun 2007 21:25:32 +0200, Michael Schwendt wrote: > On Sat, 2 Jun 2007 18:48:58 +0300, Ville Skytt? wrote: > > > On Saturday 02 June 2007, Michael Schwendt wrote: > > > > > > source rpm: em8300-kmod-0.16.2-6.2.6.21_1.3194.fc7.src.rpm > > > package: kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 from > > > fedora-updates-testing-7-i386 unresolved deps: > > > kernel-i686 = 0:2.6.21-1.3194.fc7PAE-debug > > > > $ rpm -qp --provides kernel-PAE-debug-2.6.21-1.3194.fc7.i686.rpm > > [...] > > kernel-i686 = 2.6.21-1.3194.fc7PAE-debug $ sudo yum -c $(pwd)/yum.f7.conf --enablerepo=fedora-updates-testing-7-i386 --enablerepo=fedora-7-i386 list kernel-PAE-debug Setting up repositories Reading repository metadata in from local files Available Packages kernel-PAE-debug.i686 2.6.21-1.3194.fc7 fedora-7-i386 However: $ sudo yum -c $(pwd)/yum.f7.conf --enablerepo=fedora-updates-testing-7-i386 --enablerepo=fedora-7-i386 localinstall kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686.rpm Setting up Local Package Process Examining kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686.rpm: kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 Marking kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686.rpm to be installed Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package kmod-em8300-PAE-debug.i686 0:0.16.2-6.2.6.21_1.3194.fc7 set to be installed --> Running transaction check --> Processing Dependency: em8300-kmod-common >= 0.16.2 for package: kmod-em8300-PAE-debug --> Processing Dependency: kernel-i686 = 2.6.21-1.3194.fc7PAE-debug for package: kmod-em8300-PAE-debug --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package em8300.i386 0:0.16.2-1.fc7 set to be updated --> Running transaction check --> Processing Dependency: kernel-i686 = 2.6.21-1.3194.fc7PAE-debug for package: kmod-em8300-PAE-debug --> Finished Dependency Resolution Error: Missing Dependency: kernel-i686 = 2.6.21-1.3194.fc7PAE-debug is needed by package kmod-em8300-PAE-debug Yum bug? F6 metadata broken? These queries have been done with an up-to-date FC6. From ben.lewis at benl.co.uk Sat Jun 2 19:44:07 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Sat, 02 Jun 2007 20:44:07 +0100 Subject: Change to U.T.C. based release times In-Reply-To: <200706021531.40892.jkeating@redhat.com> References: <4661C46D.5070105@benl.co.uk> <200706021531.40892.jkeating@redhat.com> Message-ID: <4661C887.9010405@benl.co.uk> Jesse Keating wrote: > On Saturday 02 June 2007 15:26:37 Benjamin Lewis wrote: > >> Hi all. >> >> A small-ish proposal, but one which would affect everyone - I propose >> moving from a release time based on Eastern time, and hence affected by >> D.S.T., to one based on U.T.C. - to this end I propose changing to 13:00 >> UTC - which is 10:00 EST and 11:00 EDT (those times may well be wrong, >> but you get the idea! :)). My rationale for this is that it can get just >> a little confusing trying to tell people the time of a release when its >> been thrown by an hour due to D.S.T. >> >> All thoughts (and corrections to the numbers, most probably) welcome. >> > > Everywhere that I listed the release time I thought I listed the UTC time as > well. Did I miss somewhere? > It is the fact that, due to D.S.T., there are _two_ U.T.C. times that bothers me, hence imho we should move to an U.T.C. based time. And no, I don't think you missed any. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From naheemzaffar at gmail.com Sat Jun 2 19:50:20 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 2 Jun 2007 20:50:20 +0100 Subject: Change to U.T.C. based release times In-Reply-To: <4661C887.9010405@benl.co.uk> References: <4661C46D.5070105@benl.co.uk> <200706021531.40892.jkeating@redhat.com> <4661C887.9010405@benl.co.uk> Message-ID: <3adc77210706021250k3a781f8co96501433803ab723@mail.gmail.com> Maybe also add GMT to the announcements to make it easier for the rest of the world to calculate the time? On 02/06/07, Benjamin Lewis wrote: > Jesse Keating wrote: > > On Saturday 02 June 2007 15:26:37 Benjamin Lewis wrote: > > > >> Hi all. > >> > >> A small-ish proposal, but one which would affect everyone - I propose > >> moving from a release time based on Eastern time, and hence affected by > >> D.S.T., to one based on U.T.C. - to this end I propose changing to 13:00 > >> UTC - which is 10:00 EST and 11:00 EDT (those times may well be wrong, > >> but you get the idea! :)). My rationale for this is that it can get just > >> a little confusing trying to tell people the time of a release when its > >> been thrown by an hour due to D.S.T. > >> > >> All thoughts (and corrections to the numbers, most probably) welcome. > >> > > > > Everywhere that I listed the release time I thought I listed the UTC time as > > well. Did I miss somewhere? > > > It is the fact that, due to D.S.T., there are _two_ U.T.C. times that > bothers me, hence imho we should move to an U.T.C. based time. > And no, I don't think you missed any. > > -- > > Benjamin Lewis > Fedora Ambassador > ben.lewis at benl.co.uk > > ----------------------------------------------------------------------- > http://benl.co.uk./ PGP Key: 0x647E480C > > "In cases of major discrepancy, it is always reality that got it wrong" > -- RFC 1118 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From tibbs at math.uh.edu Sat Jun 2 20:09:23 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2007 15:09:23 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: <1180806380.25232.137.camel@pmac.infradead.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <1180806380.25232.137.camel@pmac.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Can I submit a 'regular CVS admin request' for removing all the DW> pkg.acl files from all packages? Well, you could submit it. I certainly wouldn't act on it, mainly because I just got the necessary access and don't really want to lose it so soon. But I don't disagree with the general sentiment. DW> If we want to foster teamwork, then _defaulting_ to a completely DW> closed policy is a very poor choice. Well, see the logs from the most recent FESCO meeting. This is what we were complaining about. Some solutions were proposed, and I hope to see something happen soon. Personally I'd prefer to require people who want an ACL to say so in the CVS request; otherwise the package doesn't get one. - J< From drago01 at gmail.com Sat Jun 2 20:21:32 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 2 Jun 2007 22:21:32 +0200 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179326006.14246.44.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> Message-ID: On 5/16/07, Richard Hughes wrote: > > New in Fedora 7 we have the new pm-utils and hal-info dmi based matching > of suspend quirks. We are doing finer matching to the laptop make and > model, to make suspend (and more importantly resume) work for more > people. > > What this means: > > * Some machines that suspended in FC6 might not work in F7 > * Lots of machines that did not suspend in FC6 might work in F7 > > So, if you have to edit a file or add stuff to grub to get suspend > working in F7, that's a bug. This stuff should just work on the majority > or laptops. > > To help, and to try and make clearer all this new stuff, I've written a > few pages here: > http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html > > This is not the permanent location, nor are these documents finished - > I'm hoping to add more and more content to them over the next few days. > > So please point out new ideas, typos or maybe just general questions, > and I'll try to answer then on these pages as best I can. for me suspend and resume works (using the nvidia drivers) but after resume I only see a black page outside of X (vt switch) any ideas? (using the nv driver = no resume at all) -------------- next part -------------- An HTML attachment was scrubbed... URL: From foolish at guezz.net Sat Jun 2 20:34:22 2007 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Sat, 02 Jun 2007 22:34:22 +0200 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> Message-ID: <1180816462.3783.14.camel@localhost.localdomain> I just did a package like this actually, and I did send an email to -devel about it asking for feedback. Got no response though. This package consist of the vmlinuz and initrd.img files from the isolinux dir on the install media and puts them in /grub/ + it uses grubby to add the grub boot entry to launch Anaconda with the askmethod option. I have made packages for i386 and x86_64. I've only tested the i386 one and it works for me. For FC-6 to F-7: http://fedoraproject.org/wiki/SindrePedersenBjordal/FedoraBootAnaconda SPEC here: http://folk.ntnu.no/sindrb/packages/fedora-bootanaconda.spec SRPM here: http://folk.ntnu.no/sindrb/packages/fedora-bootanaconda-7-1.fc7.src.rpm Simple bash script to generate the source tarballs: http://folk.ntnu.no/sindrb/fedora-bootanaconda/genfedorabootanaconda.sh Usage: genfedorabootanaconda example (for Fedora 8): genfedorabootanaconda 8 fre, 01.06.2007 kl. 09.22 -0800, skrev Jeff Spaleta: > On 6/1/07, Christopher Aillon wrote: > > Actually, many people do network installs. I have no DVD burner so the > > DVD ISO does me no good. So I downloaded the boot.iso to load up > > anaconda, and pointed the installer at the right places on the network. > > Much less downloading as you only update what you need. > > For people who do network based upgrades/re-installs...... > would it be feasible, and appropriate to provide a package in the F7 > repo which contained the F8 installer image as a grub entry for an F7 > system at the time of F8 release. So people could install that and > reboot into the installer via their grub menu and do an upgrade via > the installer.. instead of being tempted to do a live upgrade just > with yum. Clever monkeys can do this manually now with some effort to > pull the installer image from the iso. The question is, does it make > sense to make this easier for the general userbase and provide a > package in a timely manner into F7 for the F8 release? > > -jef -- Sindre Pedersen Bj?rdal - http://www.fedoraproject.org/wiki/SindrePedersenBjordal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From fedora at camperquake.de Sat Jun 2 20:42:29 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 2 Jun 2007 22:42:29 +0200 Subject: Change to U.T.C. based release times In-Reply-To: <3adc77210706021250k3a781f8co96501433803ab723@mail.gmail.com> References: <4661C46D.5070105@benl.co.uk> <200706021531.40892.jkeating@redhat.com> <4661C887.9010405@benl.co.uk> <3adc77210706021250k3a781f8co96501433803ab723@mail.gmail.com> Message-ID: <20070602224229.1219ebdb@lain.camperquake.de> Hi. On Sat, 2 Jun 2007 20:50:20 +0100, Naheem Zaffar wrote > Maybe also add GMT to the announcements to make it easier for the rest > of the world to calculate the time? For this discussion GMT is the same as UTC. From hk at circlestorm.org Sat Jun 2 20:53:13 2007 From: hk at circlestorm.org (Hans K. Rosbach) Date: Sat, 2 Jun 2007 22:53:13 +0200 Subject: Change to U.T.C. based release times References: <4661C46D.5070105@benl.co.uk><200706021531.40892.jkeating@redhat.com><4661C887.9010405@benl.co.uk><3adc77210706021250k3a781f8co96501433803ab723@mail.gmail.com> <20070602224229.1219ebdb@lain.camperquake.de> Message-ID: <155a01c7a558$092a2310$0a00000a@DEAD2> From: "Ralf Ertzinger" > On Sat, 2 Jun 2007 20:50:20 +0100, Naheem Zaffar wrote > > Maybe also add GMT to the announcements to make it easier for the rest > > of the world to calculate the time? > > For this discussion GMT is the same as UTC. Maybe timings should be specified as ex: "10:00 UTC/GMT" just for clarity. Atleast it is my understanding that GMT is what most europeans learn to calculate by. Ex: Norway is GMT+1 and UTC was something I never really knew what was until I finally decided to google it. Just my two ?re. -HK From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 21:01:19 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 23:01:19 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> On 02 Jun 2007 12:39:16 -0500, Jason L Tibbitts III wrote: > Kevin and I (both community people with no ties to Red Hat) simply > asked for more access and it was granted to us, so I don't see any > institutional denial of CVS or buildsys access. If you (or anyone > else) needs access to a package they've been locked out of, just ask > for it. (It should suffice to make a regular CVS admin request and > explain the situation.) That's impracticable, because as a sponsor I would like to be able to "go in" any time and apply changes without having to request assistance from a cvs admin first. This has worked before without anyone complaining, ever. Listen, I used to be the community sponsor with the most community sponsorees (even without the 1-2 that are not connected to my account officially due to early problems with the old FAS). That has shifted a tiny bit, but there are still 17 contributors sponsored by my account. As long as a sponsor's responsibilities remain unclear and the access privileges are taken away, too, the motivation to continue with sponsoring is reduced dramatically. CVS admin access is something that was offered to me several weeks ago for helping with processing the endless stream of branch requests. I didn't accept because it is something anybody else can do, too. Btw, I'm not surprised that special privileges are distributed among FESCo members. There used to be a plan on taking away privileges from people who leave FESCo. > I am not sufficiently informed as to which > types of koji access are available. There's only admin access afaik. But as the Extras signers are being obsoleted with the new rel-eng group, things are shifting away from the community here, too. Also, in the past, admin access to plague has not been given either. I've asked once about it, but don't know who exactly decided that it would not be necessary. > MS> [...] after years there still is no team that could step in and > MS> apply emergency fixes. > > Well, speaking as someone who has done just that, I'm not exactly sure > what you think is lacking here. "not exactly" or "not at all"? Realization of old plans is lacking. I see no such team. I see bottlenecks all over the place. From markg85 at gmail.com Sat Jun 2 21:10:56 2007 From: markg85 at gmail.com (Mark) Date: Sat, 2 Jun 2007 23:10:56 +0200 Subject: Fedora 7 (KDE & Gnome Live CD) : buffer io error on device sr0 Message-ID: <6e24a8e80706021410p617bf601g8f37f9eda8ae089c@mail.gmail.com> Hey, i`ve booted both fedora 7 live cd and i get about 10 errors with: "buffer io error on device sr0" I`ve only tested it with the x86 version on a Acer Aspire 5630. (Core 2 duo T5200) those 10 errers take a while to load and really slow down the boot progress. also why isn`t the boot progress graphical? i do have a gui environment when fully booted and i can even turn on 3d stuff (hardware acceleration works out of the box). Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.lewis at benl.co.uk Sat Jun 2 21:14:28 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Sat, 02 Jun 2007 22:14:28 +0100 Subject: Change to U.T.C. based release times In-Reply-To: <155a01c7a558$092a2310$0a00000a@DEAD2> References: <4661C46D.5070105@benl.co.uk><200706021531.40892.jkeating@redhat.com><4661C887.9010405@benl.co.uk><3adc77210706021250k3a781f8co96501433803ab723@mail.gmail.com> <20070602224229.1219ebdb@lain.camperquake.de> <155a01c7a558$092a2310$0a00000a@DEAD2> Message-ID: <4661DDB4.8030807@benl.co.uk> Hans K. Rosbach wrote: > From: "Ralf Ertzinger" > >> On Sat, 2 Jun 2007 20:50:20 +0100, Naheem Zaffar wrote >> >>> Maybe also add GMT to the announcements to make it easier for the rest >>> of the world to calculate the time? >>> >> For this discussion GMT is the same as UTC. >> > > Maybe timings should be specified as ex: "10:00 UTC/GMT" just for clarity. > Atleast it is my understanding that GMT is what most europeans learn to > calculate by. Ex: Norway is GMT+1 and UTC was something I never > really knew what was until I finally decided to google it. > > Just my two ?re. > > -HK No. Either we use GMT or we use UTC. Personally I prefer GMT, but I'm trying to be international, and using a term with Greenwich in it seems wrong in that context. - Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From bpepple at fedoraproject.org Sat Jun 2 21:22:19 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 02 Jun 2007 17:22:19 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1180819339.3207.13.camel@kennedy> On Sat, 2007-06-02 at 23:01 +0200, Michael Schwendt wrote: > > I am not sufficiently informed as to which > > types of koji access are available. > > There's only admin access afaik. But as the Extras signers are being > obsoleted with the new rel-eng group, things are shifting away from the > community here, too. I don't agree with you on this statement, since there are non-redhat employees (I'm assuming this is what you mean by the statement about shifting away from the community) on it. Also, folks that are interested in joining are encouraged to contact them. http://fedoraproject.org/wiki/ReleaseEngineering Later, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Sat Jun 2 21:24:17 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 02 Jun 2007 14:24:17 -0700 Subject: Orphans: openbox, obconf, obmenu Message-ID: <1180819457.27569.16.camel@tuxhugs> Hi, all. With the 3.4 Preview releases of Openbox as well as related obconf and obmenu releases, I'm officially putting these three packages into Orphan status. I've been doing just "package monkey" work (version bumps, rebuilds, etc.) for the past several months; but since I no longer use them, I feel that I can't properly maintain them, and that my time is better spent on my other work and packages within Fedora. I had mentioned on the Openbox mailing list that I would try to get the Preview release stuff into CVS soon; but I just don't have the motive for it any longer. Apologies for any inconvience this may cause. Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Sat Jun 2 21:00:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 02 Jun 2007 23:00:14 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <20070602174203.GD2840@free.fr> References: <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <1180804882.3294.24.camel@rousalka.dyndns.org> <20070602174203.GD2840@free.fr> Message-ID: <1180818014.3300.17.camel@rousalka.dyndns.org> Le samedi 02 juin 2007 ? 19:42 +0200, Patrice Dumas a ?crit : > On Sat, Jun 02, 2007 at 07:21:22PM +0200, Nicolas Mailhot wrote: > > > > 2. Merging means Core packages have their say on Extras just like Extras > > packagers have their say on Core. That's how merges work. Original > > control is diluted in exchange of a broader reach. > > The issue is not there. The issue is more an issue of methods. There was > no discussion in advance There was > and no consideration of how to limit the impact on packager work. Again the infrastructure team deserves more credit than you give it. At some point you have to ship and do fine-tuning later. With perfect hindsight better questions would have been asked, but with perfect hindsight people wouldn't have had to ask them in the first place, and that F7 happened is testament the delivered infrastructure/process does not fall too far of the mark. The problems are obvious now because we have something (tools+processes) to play with, and that's loads more we'd have if people had discussed it half a year more. -- 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 mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 21:47:29 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 2 Jun 2007 23:47:29 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <1180819339.3207.13.camel@kennedy> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> <1180819339.3207.13.camel@kennedy> Message-ID: <20070602234729.adbffc74.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 17:22:19 -0400, Brian Pepple wrote: > On Sat, 2007-06-02 at 23:01 +0200, Michael Schwendt wrote: > > > I am not sufficiently informed as to which > > > types of koji access are available. > > > > There's only admin access afaik. But as the Extras signers are being > > obsoleted with the new rel-eng group, things are shifting away from the > > community here, too. > > I don't agree with you on this statement, since there are non-redhat > employees (I'm assuming this is what you mean by the statement about > shifting away from the community) on it. Also, folks that are > interested in joining are encouraged to contact them. > > http://fedoraproject.org/wiki/ReleaseEngineering Moot. 2/7. Rex is only there because there are big expectations with regard to him leading the KDE efforts. Remains Josh as the only one from the community. However, the page does not comment on repository management at all. From ville.skytta at iki.fi Sat Jun 2 21:46:05 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 3 Jun 2007 00:46:05 +0300 Subject: kmod-em8300-PAE-debug - Re: Broken deps in Fedora 7 Test Updates In-Reply-To: <20070602214245.184ee12e.mschwendt.tmp0701.nospam@arcor.de> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <20070602212532.6bffa5e8.mschwendt.tmp0701.nospam@arcor.de> <20070602214245.184ee12e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706030046.06999.ville.skytta@iki.fi> On Saturday 02 June 2007, Michael Schwendt wrote: > However: > > $ sudo yum -c $(pwd)/yum.f7.conf --enablerepo=fedora-updates-testing-7-i386 > --enablerepo=fedora-7-i386 localinstall > kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686.rpm Setting up Local > Package Process > Examining kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686.rpm: > kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 Marking > kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686.rpm to be installed > Setting up repositories > Reading repository metadata in from local files > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package kmod-em8300-PAE-debug.i686 0:0.16.2-6.2.6.21_1.3194.fc7 set to > be installed --> Running transaction check > --> Processing Dependency: em8300-kmod-common >= 0.16.2 for package: > kmod-em8300-PAE-debug --> Processing Dependency: kernel-i686 = > 2.6.21-1.3194.fc7PAE-debug for package: kmod-em8300-PAE-debug --> > Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > ---> Package em8300.i386 0:0.16.2-1.fc7 set to be updated > --> Running transaction check > --> Processing Dependency: kernel-i686 = 2.6.21-1.3194.fc7PAE-debug for > package: kmod-em8300-PAE-debug --> Finished Dependency Resolution > Error: Missing Dependency: kernel-i686 = 2.6.21-1.3194.fc7PAE-debug is > needed by package kmod-em8300-PAE-debug Reproduced. But if kernel-PAE-debug is already installed, a subsequent "yum install kmod-em8300-PAE-debug" succeeds for me. I don't remember hearing about these dependency problems before in the FE-6 repo. PAE-debug has been enabled and IIRC unchanged in the em8300-kmod package since March 15 (kernel 2.6.20-1.2925.fc6). From ville.skytta at iki.fi Sat Jun 2 21:47:20 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 3 Jun 2007 00:47:20 +0300 Subject: kmod-em8300-PAE-debug - Re: Broken deps in Fedora 7 Test Updates In-Reply-To: <200706030046.06999.ville.skytta@iki.fi> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <20070602214245.184ee12e.mschwendt.tmp0701.nospam@arcor.de> <200706030046.06999.ville.skytta@iki.fi> Message-ID: <200706030047.20865.ville.skytta@iki.fi> On Sunday 03 June 2007, Ville Skytt? wrote: > I don't remember hearing about these dependency problems before in the FE-6 > repo. PAE-debug has been enabled and IIRC unchanged in the em8300-kmod > package since March 15 (kernel 2.6.20-1.2925.fc6). ...apart from a hack that went into the last package revision due to Provides changes in the latest FC-6 update kernel. From jwboyer at jdub.homelinux.org Sat Jun 2 21:57:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 02 Jun 2007 16:57:54 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <1180806380.25232.137.camel@pmac.infradead.org> Message-ID: <1180821475.3218.1.camel@vader.jdub.homelinux.org> On Sat, 2007-06-02 at 15:09 -0500, Jason L Tibbitts III wrote: > >>>>> "DW" == David Woodhouse writes: > > DW> Can I submit a 'regular CVS admin request' for removing all the > DW> pkg.acl files from all packages? > > Well, you could submit it. I certainly wouldn't act on it, mainly > because I just got the necessary access and don't really want to lose > it so soon. But I don't disagree with the general sentiment. If this is desired, we should start a simple wiki page that package maintainers can add requests to for their packages. I don't want to bulk handle anything without the maintainers' input. Start a page, allow 2 weeks for entries, then do the changes. > > DW> If we want to foster teamwork, then _defaulting_ to a completely > DW> closed policy is a very poor choice. > > Well, see the logs from the most recent FESCO meeting. This is what > we were complaining about. Some solutions were proposed, and I hope > to see something happen soon. Personally I'd prefer to require people > who want an ACL to say so in the CVS request; otherwise the package > doesn't get one. We should revisit that again soon. josh From bpepple at fedoraproject.org Sat Jun 2 22:06:03 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 02 Jun 2007 18:06:03 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602234729.adbffc74.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> <1180819339.3207.13.camel@kennedy> <20070602234729.adbffc74.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1180821963.3207.22.camel@kennedy> On Sat, 2007-06-02 at 23:47 +0200, Michael Schwendt wrote: > On Sat, 02 Jun 2007 17:22:19 -0400, Brian Pepple wrote: > > > On Sat, 2007-06-02 at 23:01 +0200, Michael Schwendt wrote: > > > > > > There's only admin access afaik. But as the Extras signers are being > > > obsoleted with the new rel-eng group, things are shifting away from the > > > community here, too. > > > > I don't agree with you on this statement, since there are non-redhat > > employees (I'm assuming this is what you mean by the statement about > > shifting away from the community) on it. Also, folks that are > > interested in joining are encouraged to contact them. > > > > http://fedoraproject.org/wiki/ReleaseEngineering > > Moot. 2/7. Rex is only there because there are big expectations with > regard to him leading the KDE efforts. Remains Josh as the only one from > the community. However, the page does not comment on repository management > at all. There is nothing preventing more community members from joining the rel-eng team. It's just a matter of contacting them as they state on their wiki page. Later, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Sat Jun 2 22:03:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 02 Jun 2007 17:03:27 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602234729.adbffc74.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> <1180819339.3207.13.camel@kennedy> <20070602234729.adbffc74.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1180821807.3218.6.camel@vader.jdub.homelinux.org> On Sat, 2007-06-02 at 23:47 +0200, Michael Schwendt wrote: > On Sat, 02 Jun 2007 17:22:19 -0400, Brian Pepple wrote: > > > On Sat, 2007-06-02 at 23:01 +0200, Michael Schwendt wrote: > > > > I am not sufficiently informed as to which > > > > types of koji access are available. > > > > > > There's only admin access afaik. But as the Extras signers are being > > > obsoleted with the new rel-eng group, things are shifting away from the > > > community here, too. > > > > I don't agree with you on this statement, since there are non-redhat > > employees (I'm assuming this is what you mean by the statement about > > shifting away from the community) on it. Also, folks that are > > interested in joining are encouraged to contact them. > > > > http://fedoraproject.org/wiki/ReleaseEngineering > > Moot. 2/7. Rex is only there because there are big expectations with > regard to him leading the KDE efforts. Remains Josh as the only one from > the community. However, the page does not comment on repository management > at all. rel-eng doesn't equal CVS admin. They are separate groups that have some overlapping members. CVS admins are Dennis, myself, Warren, Jens, Spot, Jason, Kevin, Bill, Jeremy, and Jesse. There might be some others I'm unaware of. So for CVS admin stuff, that's 4 non-Red Hat, 6 Red Hat. I intentionally avoid the term "community" because as Toshio has said, we need to start becoming one again. josh From mschwendt.tmp0701.nospam at arcor.de Sat Jun 2 22:18:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 3 Jun 2007 00:18:28 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <1180821807.3218.6.camel@vader.jdub.homelinux.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> <1180819339.3207.13.camel@kennedy> <20070602234729.adbffc74.mschwendt.tmp0701.nospam@arcor.de> <1180821807.3218.6.camel@vader.jdub.homelinux.org> Message-ID: <20070603001828.e6b255d3.mschwendt.tmp0701.nospam@arcor.de> On Sat, 02 Jun 2007 17:03:27 -0500, Josh Boyer wrote: > On Sat, 2007-06-02 at 23:47 +0200, Michael Schwendt wrote: > > On Sat, 02 Jun 2007 17:22:19 -0400, Brian Pepple wrote: > > > > > On Sat, 2007-06-02 at 23:01 +0200, Michael Schwendt wrote: > > > > > I am not sufficiently informed as to which > > > > > types of koji access are available. > > > > > > > > There's only admin access afaik. But as the Extras signers are being > > > > obsoleted with the new rel-eng group, things are shifting away from the > > > > community here, too. > > > > > > I don't agree with you on this statement, since there are non-redhat > > > employees (I'm assuming this is what you mean by the statement about > > > shifting away from the community) on it. Also, folks that are > > > interested in joining are encouraged to contact them. > > > > > > http://fedoraproject.org/wiki/ReleaseEngineering > > > > Moot. 2/7. Rex is only there because there are big expectations with > > regard to him leading the KDE efforts. Remains Josh as the only one from > > the community. However, the page does not comment on repository management > > at all. > > rel-eng doesn't equal CVS admin. With "repository" I mean package repository, not CVS. From jwboyer at jdub.homelinux.org Sat Jun 2 22:14:13 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 02 Jun 2007 17:14:13 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: <20070603001828.e6b255d3.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> <1180819339.3207.13.camel@kennedy> <20070602234729.adbffc74.mschwendt.tmp0701.nospam@arcor.de> <1180821807.3218.6.camel@vader.jdub.homelinux.org> <20070603001828.e6b255d3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1180822454.3218.10.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 00:18 +0200, Michael Schwendt wrote: > On Sat, 02 Jun 2007 17:03:27 -0500, Josh Boyer wrote: > > > On Sat, 2007-06-02 at 23:47 +0200, Michael Schwendt wrote: > > > On Sat, 02 Jun 2007 17:22:19 -0400, Brian Pepple wrote: > > > > > > > On Sat, 2007-06-02 at 23:01 +0200, Michael Schwendt wrote: > > > > > > I am not sufficiently informed as to which > > > > > > types of koji access are available. > > > > > > > > > > There's only admin access afaik. But as the Extras signers are being > > > > > obsoleted with the new rel-eng group, things are shifting away from the > > > > > community here, too. > > > > > > > > I don't agree with you on this statement, since there are non-redhat > > > > employees (I'm assuming this is what you mean by the statement about > > > > shifting away from the community) on it. Also, folks that are > > > > interested in joining are encouraged to contact them. > > > > > > > > http://fedoraproject.org/wiki/ReleaseEngineering > > > > > > Moot. 2/7. Rex is only there because there are big expectations with > > > regard to him leading the KDE efforts. Remains Josh as the only one from > > > the community. However, the page does not comment on repository management > > > at all. > > > > rel-eng doesn't equal CVS admin. > > With "repository" I mean package repository, not CVS. Ah. My mistake. With that definition, the differences from the past at the moment are only with released versions of Fedora. And, as this thread demonstrates, there's ongoing discussion there. josh From buildsys at fedoraproject.org Sat Jun 2 22:41:30 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 02 Jun 2007 22:41:30 -0000 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 Message-ID: <20070602224130.1229.76138@extras64.linux.duke.edu> Summary of broken packages (by owner): braden AT endoframe.com openvrml - 0.16.4-2.fc7.i386 openvrml - 0.16.4-2.fc7.i386 openvrml - 0.16.4-2.fc7.ppc openvrml - 0.16.4-2.fc7.ppc64 openvrml - 0.16.4-2.fc7.x86_64 openvrml-devel - 0.16.4-2.fc7.i386 openvrml-devel - 0.16.4-2.fc7.i386 openvrml-devel - 0.16.4-2.fc7.ppc openvrml-devel - 0.16.4-2.fc7.ppc64 openvrml-devel - 0.16.4-2.fc7.x86_64 cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch glest-data - 2.0.0-2.fc7.noarch giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 jdieter AT gmail.com yum-presto - 0.3.10-1.fc7.noarch yum-presto - 0.3.10-1.fc7.noarch yum-presto - 0.3.10-1.fc7.noarch yum-presto - 0.3.10-1.fc7.noarch jeff AT ocjtech.us trac - 0.10.3.1-2.fc7.noarch jonathansteffan AT gmail.com revisor - 2.0.3.6-1.fc7.noarch revisor - 2.0.3.6-1.fc7.noarch jwilson AT redhat.com emerald-themes - 0.2.0-1.fc7.noarch karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 mdehaan AT redhat.com koan - 0.4.0-1.fc7.noarch oliver AT linux-kernel.at syck-php - 0.55-14.fc7.i386 syck-php - 0.55-14.fc7.ppc syck-php - 0.55-14.fc7.ppc64 syck-php - 0.55-14.fc7.x86_64 orion AT cora.nwra.com netcdf-decoders - 4.1.4-1.fc7.ppc64 python-basemap - 0.9.5-1.fc7.ppc64 paul AT city-fan.org bittorrent - 4.4.0-5.fc7.noarch peter AT thecodergeek.com blam - 1.8.3-3.fc7.i386 blam - 1.8.3-3.fc7.ppc blam - 1.8.3-3.fc7.x86_64 rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 shahms AT shahms.com python-paramiko - 1.6.4-1.fc7.noarch thomas AT apestaart.org python-twisted-conch - 0.7.0-4.fc7.ppc64 tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 Democracy - 0.9.5.1-8.fc7.ppc Democracy - 0.9.5.1-8.fc7.ppc64 Democracy - 0.9.5.1-8.fc7.x86_64 ville.skytta AT iki.fi kmod-em8300-PAE-debug - 0.16.2-6.2.6.21_1.3194.fc7.i686 ====================================================================== Broken packages in fedora-7-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 blam-1.8.3-3.fc7.i386 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE openvrml-0.16.4-2.fc7.i386 requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.i386 requires firefox-devel = 0:2.0.0.3 syck-php-0.55-14.fc7.i386 requires php = 0:5.2.1 ====================================================================== Broken packages in fedora-7-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) bittorrent-4.4.0-5.fc7.noarch requires python-crypto emerald-themes-0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 emerald-themes-0.2.0-1.fc7.noarch requires beryl-core >= 0:0.2.0 geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics netcdf-decoders-4.1.4-1.fc7.ppc64 requires perl(NetCDF) oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core openvrml-0.16.4-2.fc7.ppc64 requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.ppc64 requires firefox-devel = 0:2.0.0.3 python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 python-paramiko-1.6.4-1.fc7.noarch requires python-crypto >= 0:1.9 python-twisted-conch-0.7.0-4.fc7.ppc64 requires python-crypto resapplet-0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) syck-php-0.55-14.fc7.ppc64 requires php = 0:5.2.1 trac-0.10.3.1-2.fc7.noarch requires python-clearsilver >= 0:0.9.3 wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in fedora-7-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 blam-1.8.3-3.fc7.ppc requires firefox = 0:2.0.0.3 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 openvrml-0.16.4-2.fc7.ppc requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.ppc requires firefox-devel = 0:2.0.0.3 syck-php-0.55-14.fc7.ppc requires php = 0:5.2.1 ====================================================================== Broken packages in fedora-7-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 blam-1.8.3-3.fc7.x86_64 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump openvrml-0.16.4-2.fc7.i386 requires firefox = 0:2.0.0.3 openvrml-0.16.4-2.fc7.x86_64 requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.i386 requires firefox-devel = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.x86_64 requires firefox-devel = 0:2.0.0.3 syck-php-0.55-14.fc7.x86_64 requires php = 0:5.2.1 ====================================================================== Broken packages in fedora-updates-7-ppc64: revisor-2.0.3.6-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-7-ppc: revisor-2.0.3.6-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-testing-7-i386: kmod-em8300-PAE-debug-0.16.2-6.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE-debug yum-presto-0.3.10-1.fc7.noarch requires deltarpm >= 0:3.4-2 ====================================================================== Broken packages in fedora-updates-testing-7-ppc64: koan-0.4.0-1.fc7.noarch requires syslinux yum-presto-0.3.10-1.fc7.noarch requires deltarpm >= 0:3.4-2 ====================================================================== Broken packages in fedora-updates-testing-7-ppc: yum-presto-0.3.10-1.fc7.noarch requires deltarpm >= 0:3.4-2 ====================================================================== Broken packages in fedora-updates-testing-7-x86_64: yum-presto-0.3.10-1.fc7.noarch requires deltarpm >= 0:3.4-2 From foolish at guezz.net Sat Jun 2 23:24:49 2007 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Sun, 03 Jun 2007 01:24:49 +0200 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180816462.3783.14.camel@localhost.localdomain> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180816462.3783.14.camel@localhost.localdomain> Message-ID: <1180826689.3783.16.camel@localhost.localdomain> eeh, .. and puts them in /boot/, not /grub/ l?r, 02.06.2007 kl. 22.34 +0200, skrev Sindre Pedersen Bjordal: > I just did a package like this actually, and I did send an email to > -devel about it asking for feedback. Got no response though. > > This package consist of the vmlinuz and initrd.img files from the > isolinux dir on the install media and puts them in /grub/ + it uses > grubby to add the grub boot entry to launch Anaconda with the askmethod > option. I have made packages for i386 and x86_64. I've only tested the > i386 one and it works for me. > > For FC-6 to F-7: > http://fedoraproject.org/wiki/SindrePedersenBjordal/FedoraBootAnaconda > > SPEC here: http://folk.ntnu.no/sindrb/packages/fedora-bootanaconda.spec > SRPM here: > http://folk.ntnu.no/sindrb/packages/fedora-bootanaconda-7-1.fc7.src.rpm > > Simple bash script to generate the source tarballs: > http://folk.ntnu.no/sindrb/fedora-bootanaconda/genfedorabootanaconda.sh > > Usage: genfedorabootanaconda > example (for Fedora 8): genfedorabootanaconda 8 > > fre, 01.06.2007 kl. 09.22 -0800, skrev Jeff Spaleta: > > On 6/1/07, Christopher Aillon wrote: > > > Actually, many people do network installs. I have no DVD burner so the > > > DVD ISO does me no good. So I downloaded the boot.iso to load up > > > anaconda, and pointed the installer at the right places on the network. > > > Much less downloading as you only update what you need. > > > > For people who do network based upgrades/re-installs...... > > would it be feasible, and appropriate to provide a package in the F7 > > repo which contained the F8 installer image as a grub entry for an F7 > > system at the time of F8 release. So people could install that and > > reboot into the installer via their grub menu and do an upgrade via > > the installer.. instead of being tempted to do a live upgrade just > > with yum. Clever monkeys can do this manually now with some effort to > > pull the installer image from the iso. The question is, does it make > > sense to make this easier for the general userbase and provide a > > package in a timely manner into F7 for the F8 release? > > > > -jef -- Sindre Pedersen Bj?rdal - http://www.fedoraproject.org/wiki/SindrePedersenBjordal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From tibbs at math.uh.edu Sat Jun 2 23:47:36 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2007 18:47:36 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> That's impracticable, because as a sponsor I would like to be able MS> to "go in" any time and apply changes without having to request MS> assistance from a cvs admin first. I was only proposing it as a temporary workaround until we have the necessary infrastructure. If you're not interested in a working workaround but instead simply want to complain about something which we know to be changing as soon as possible, then I suppose there's little point in my participation in the discussion. MS> Btw, I'm not surprised that special privileges are distributed MS> among FESCo members. And frankly I'm not surprised you have fabricated something else to complain about. Do you really think that it's my FESCo membership which makes me eligible for those privileges? Do you actually intend to denigrate the contributions I've made to Fedora? - J< From j.w.r.degoede at hhs.nl Sun Jun 3 00:30:41 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 02:30:41 +0200 Subject: proposal: new guidelines for rule makers In-Reply-To: <46612B94.8020409@fedoraproject.org> References: <466129A1.7010805@hhs.nl> <46612B94.8020409@fedoraproject.org> Message-ID: <46620BB1.6020208@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: >> Hi all, >> >> >> >> Since those making packaging guidelines and other rules seem to be out >> of touch with the workfloor these days I would like to propose the >> following guideline for rulemakers: >> >> Those making guidelines / rules within the Fedora project must >> actively maintain atleast 30 packages. >> >> Rationale: How can one make rules if one isn't involved in that which >> is regulated oneself? >> >> > > Packaging guidelines also cover licensing details which isn't connected > to workflow. There are several other policies within the guidelines > which involve some amount of politics (kernel modules anyone?). This > rule would mean that everybody who proposes any drafts, folks in the > packaging committee and FESCo would have to maintain 30 packages. > Yes it would, and that would be a good thing! Let the people building the distro decide how it is build! As for licensing issues, since RH is paying mosts of the bills at the end RH decided what is okay licensing wise, and to me they have earned that right, because "paying the bills" == "building the distro" Regards, Hans From j.w.r.degoede at hhs.nl Sun Jun 3 00:36:05 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 02:36:05 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602104039.GH11101@free.fr> References: <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602104039.GH11101@free.fr> Message-ID: <46620CF5.1050306@hhs.nl> Patrice Dumas wrote: > On Sat, Jun 02, 2007 at 03:25:04PM +0530, Rahul Sundaram wrote: >> Package maintainers or reviewers obviously don't love freeze or QA >> policies but it is a necessary evil if we are focusing on serving end >> users with robust software. > > It really depends on the package and on the userbase. Sometimes pushing > packages and waiting for bugreports is the best solution. Once again > it really depends and should be left to the maintainer choice. > +1 From j.w.r.degoede at hhs.nl Sun Jun 3 00:39:07 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 02:39:07 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46612F84.9080700@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <466128DC.5050000@hhs.nl> <46612F84.9080700@fedoraproject.org> Message-ID: <46620DAB.1000506@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: > >> >> Exactly, there are very good reasons why this is a SHOULD and not a >> MUST. I'm sure almost every reviewer will give a program a test run in >> the simple program case / scenarion. Why must everything by regulated >> with rules, procedures and more rules? Why can't we just TRUST each >> other, > > We need to coordinate and not everyone has the same understanding of > what is required in a review. New packagers have explicitly asked before > for more guidelines. If you believe that every reviewer already tests > the simple program case then there shouldn't any problem in documenting > that. > Well since we've just written about it, it now is documented. No need to change the guidelines. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jun 3 00:44:21 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 02:44:21 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <4661316A.8000903@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> Message-ID: <46620EE5.6030707@hhs.nl> Rahul Sundaram wrote: > Ralf Corsepius wrote: >> On Sat, 2007-06-02 at 13:30 +0530, Rahul Sundaram wrote: >>> Toshio Kuratomi wrote: >>>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: >>>>> Hans de Goede wrote: >>>>>> Not true many reviewers review on the latest stable, it says >>>>>> nowhere that a review should be done on rawhide. >>>>> Review is about guidelines and nowhere in the guideline does it >>>>> even say that the fucntionality of the package should be tested. >>>>> When I suggested that it be added I got back a knee jerk reaction >>>>> to participate in reviews myself. >>>>> >>>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: >>>> >>>> - SHOULD: The reviewer should test that the package functions as >>>> described. A package should not segfault instead of running, for >>>> example. >>> I suggested that it the "SHOULD" be changed to "MUST". A package that >>> doesnt even start shouldnt be getting past reviews. >> 1. packages never start, applications do. > > Pendantic waste. > >> 2. many applications, when being cluelessly used, only mean they have a >> functional "usage()" > > Which covers base functionality. > Ralf wrote in reply to this: " - You apparently don't have any clues about what you are talking about." I do not agree with the beep, but let me stress the point: "You apparently don't have any clues about what you are talking about." What Ralf means with: >> 2. many applications, when being cluelessly used, only mean they have a >> functional "usage()" And which should be fully understandable by anyone who claims to have enough domain knowledge to discuss and decide policies, is that if a reviewer just runs app foo like this: foo That changes then are large the user will see something like: usage: foo [opt] or Which sure does NOT cover basic functionality. First please get a clue about what we are talking about (by say packaging 30 packages?) and then return to this discussion. Thank you for first getting a clue, Hans From jwboyer at jdub.homelinux.org Sun Jun 3 01:20:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 02 Jun 2007 20:20:17 -0500 Subject: proposal: new guidelines for rule makers In-Reply-To: <46620BB1.6020208@hhs.nl> References: <466129A1.7010805@hhs.nl> <46612B94.8020409@fedoraproject.org> <46620BB1.6020208@hhs.nl> Message-ID: <1180833617.3218.18.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 02:30 +0200, Hans de Goede wrote: > Rahul Sundaram wrote: > > Hans de Goede wrote: > >> Hi all, > >> > >> > >> > >> Since those making packaging guidelines and other rules seem to be out > >> of touch with the workfloor these days I would like to propose the > >> following guideline for rulemakers: > >> > >> Those making guidelines / rules within the Fedora project must > >> actively maintain atleast 30 packages. > >> > >> Rationale: How can one make rules if one isn't involved in that which > >> is regulated oneself? > >> > >> > > > > Packaging guidelines also cover licensing details which isn't connected > > to workflow. There are several other policies within the guidelines > > which involve some amount of politics (kernel modules anyone?). This > > rule would mean that everybody who proposes any drafts, folks in the > > packaging committee and FESCo would have to maintain 30 packages. > > > > Yes it would, and that would be a good thing! Let the people building the > distro decide how it is build! As for licensing issues, since RH is paying > mosts of the bills at the end RH decided what is okay licensing wise, and to me > they have earned that right, because "paying the bills" == "building the distro" I don't want to misinterpret what you're saying here, so I'll ask you straight out. Are you suggesting that because I do not maintain 30 packages I am unqualified to be a member of FESCo? Should I go out and submit about 20 more packages that I'll never use myself just to inflate my statistics and make myself eligible? I could counter your proposal with "only people who have managed x distro releases can be in FESCo". Or "only people who have written test cases for 30 packages can be in FESCo". Or "only people who have debugged problems on all architectures can be in FESCo". Or "only people who have translated for 30 packages can be in FESCo". Seriously, I understand where you are coming from but your blanket qualification is lacking. There is more to making Fedora than maintaining a number of packages. To suggest others are unqualified because they do not maintain a large number of packages is both naive and insulting. josh From obi at unixkiste.org Sun Jun 3 04:03:30 2007 From: obi at unixkiste.org (Stefan Held) Date: Sun, 03 Jun 2007 06:03:30 +0200 Subject: Packaging Guideline for JNI Libs? Message-ID: <1180843410.3001.2.camel@workstation.unixkiste.local> Hello guys. Is there a packaging guideline which describes where JNI native libraries for java libs should be installed to? Would a directory /usr/lib/jni be a bad idea or simply place that lib into /usr/lib? Thx for your answers. -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, IRCNet: Obi_Wan the second destroys the text. --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = EAF2 6A65 D102 F2DB 4970 2A67 455B 98F2 572C 3FA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dev at nigelj.com Sun Jun 3 04:07:07 2007 From: dev at nigelj.com (Nigel Jones) Date: Sun, 03 Jun 2007 16:07:07 +1200 Subject: proposal: new guidelines for rule makers In-Reply-To: <1180833617.3218.18.camel@vader.jdub.homelinux.org> References: <466129A1.7010805@hhs.nl> <46612B94.8020409@fedoraproject.org> <46620BB1.6020208@hhs.nl> <1180833617.3218.18.camel@vader.jdub.homelinux.org> Message-ID: <46623E6B.5060803@nigelj.com> Josh Boyer wrote: > On Sun, 2007-06-03 at 02:30 +0200, Hans de Goede wrote: >> Rahul Sundaram wrote: >>> Hans de Goede wrote: >>>> Hi all, >>>> >>>> >>>> >>>> Since those making packaging guidelines and other rules seem to be out >>>> of touch with the workfloor these days I would like to propose the >>>> following guideline for rulemakers: >>>> >>>> Those making guidelines / rules within the Fedora project must >>>> actively maintain atleast 30 packages. >>>> >>>> Rationale: How can one make rules if one isn't involved in that which >>>> is regulated oneself? >>>> >>>> >>> Packaging guidelines also cover licensing details which isn't connected >>> to workflow. There are several other policies within the guidelines >>> which involve some amount of politics (kernel modules anyone?). This >>> rule would mean that everybody who proposes any drafts, folks in the >>> packaging committee and FESCo would have to maintain 30 packages. >>> >> Yes it would, and that would be a good thing! Let the people building the >> distro decide how it is build! As for licensing issues, since RH is paying >> mosts of the bills at the end RH decided what is okay licensing wise, and to me >> they have earned that right, because "paying the bills" == "building the distro" > > I don't want to misinterpret what you're saying here, so I'll ask you > straight out. > > Are you suggesting that because I do not maintain 30 packages I am > unqualified to be a member of FESCo? > > Should I go out and submit about 20 more packages that I'll never use > myself just to inflate my statistics and make myself eligible? > I hope you wouldn't have to as well! My point of view is FESco should be comprised of people from all parts of the Fedora community. I think myself and the 90% of people listed in Koji with less than 30 packages would hate to see the 1/8th of the community that have more running FESco. To have a community you have to have people from all types of lives, the rich ones, the middle class ones, and the poor ones (for this analogy think of packages as a currency), if you have the community run by a set of people comprising of the 'elitist rich people' then you loose the 'poor people' and possibly some of the 'middle class people'. If you have the community run by the poor people, the 'rich people' loose interest and basically kill off the community once again. For a community to work properly we need people from all 'social statuses'. Now for some figures (these are rough, I'm too lazy to count exactly): ~40-45 packagers owning 30+ SRPMS (10.5%) ~100 packagers owning 10-29 SRPMS (25%) ~70 packagers owning 5-9 SRPMS (17%) ~190 packagers owning 1-4 SRPMS (46%) ~15-20 packagers owning 0 SRPMS (0.5%) (There is 1% missing over the general spread due to rounding and estimates) As one of the people in the 5-9 SRPMS bracket, I'm happy with the current changes, *BUT* I'm looking forward to when the tools are united under 'packagedb' which I hope will happen. I wish some changes didn't happen just before the release, but the overall effect seems good so far. N.J. From abraxis at telkomsa.net Sun Jun 3 06:00:25 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Sun, 3 Jun 2007 08:00:25 +0200 Subject: pungi error Message-ID: <20070603060025.GA13719@eeyore.32.boerneef.vornavalley> Hi all, I've been trying to create an Eveything set of DVDs and I've run into a problem - pungi errors out with - Traceback (most recent call last): File "/usr/bin/pungi", line 187, in main() File "/usr/bin/pungi", line 122, in main mypungi.doSplittree() File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 230, in doSplittree output = timber.main() File "/usr/lib/anaconda-runtime/splittree.py", line 391, in main self.createSplitDirs() File "/usr/lib/anaconda-runtime/splittree.py", line 233, in createSplitDirs self.createDiscInfo(i) File "/usr/lib/anaconda-runtime/splittree.py", line 151, in createDiscInfo raise RuntimeError, "CRITICAL ERROR : self.real_arch is not the same as self.arch" RuntimeError: CRITICAL ERROR : self.real_arch is not the same as self.arch This happens with the pungi stalled with F7 as well as pungi-0.3.7-1 pulled from updates-testing. Any ideas? -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From mschwendt.tmp0701.nospam at arcor.de Sun Jun 3 06:27:50 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 3 Jun 2007 08:27:50 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070603082750.d049f2b4.mschwendt.tmp0701.nospam@arcor.de> On 02 Jun 2007 18:47:36 -0500, Jason L Tibbitts III wrote: > MS> That's impracticable, because as a sponsor I would like to be able > MS> to "go in" any time and apply changes without having to request > MS> assistance from a cvs admin first. > > I was only proposing it as a temporary workaround until we have the > necessary infrastructure. If you're not interested in a working > workaround but instead simply want to complain about something which > we know to be changing as soon as possible, then I suppose there's > little point in my participation in the discussion. Where is the "working work-around"? None of the messages in this thread so far has described a "working work-around". Anyway, the rest of your message enters an area I do not intend to cover here. So, please don't try to drag me into it. From Axel.Thimm at ATrpms.net Sun Jun 3 06:33:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 3 Jun 2007 08:33:21 +0200 Subject: proposal: new guidelines for rule makers In-Reply-To: <466129A1.7010805@hhs.nl> References: <466129A1.7010805@hhs.nl> Message-ID: <20070603063321.GX7159@neu.nirvana> Hi, On Sat, Jun 02, 2007 at 10:26:09AM +0200, Hans de Goede wrote: > Hi all, > > > > Since those making packaging guidelines and other rules seem to be out of > touch with the workfloor these days I would like to propose the following > guideline for rulemakers: > > Those making guidelines / rules within the Fedora project must actively > maintain atleast 30 packages. with my FPC hat on: Are there any recent packaging guidelines that make you say that? I don't agree with everything that passes, but it isn't that crappy either. > Rationale: How can one make rules if one isn't involved in that which is > regulated oneself? There's a lot of truth in this. But unfortunately that's the classical issue of management losing touch with reality, and there is no easy recipe on how to rectify this. > I'd say let's raise that bar to `grep goede owners.list | wc -l` :) That would probably leave only a handful of people, or perhaps only one ;) -- 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 Sun Jun 3 06:48:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 08:48:35 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> Message-ID: <46626443.6020804@leemhuis.info> On 02.06.2007 19:56, Jason L Tibbitts III wrote: >>>>>> "TL" == Thorsten Leemhuis writes: > > TL> Okay, we wanted the merge. > Yes, we did. You and I sat in the same meetings at the same > conference Yes. And we all expected it would be a bumpy merge, but well, it was much more bumpy then I had expected... > and for my part I can't say that what we have now is > fundamentally any different than what was promised to us. No. But the way we got it was the problem. It was much to hectic. > Yes, we're > not all of the way there, and unfortunately a release complicated > matters, Yes, I'm aware of it. That why I wrote 'let make "contributing to Fedora easy again, get the community involved better into the decisions process and make packagers happy again" one of the most important "Features" for Fedora 8. Otherwise the merge might fail in the end.' in my mail. > but I simply don't see any of the negative shifts away from > the community that I keep seeing complaints about. Well, see all those discussion that happened when ACLs were added, kjoi introduced, the freezes were introduced and bodi put in place. Sure, there are always discussions, but all those were quite worse and there was a lot of confusion afaics... Don't read fedora-maintainers for a week and suddenly you are not aware of how to build or push a package. Further: I don't blame the current situation is FESCo's fault (?,?) -- there were afaics a lot of things that went wrong over the past months in different areas of Fedora. Some things just happened and if there would have been more time then many things likely would have worked out better. But as far as I can see there are lot's of people unhappy with some of the things in the past months. Just see the discussions on fedora-maintainers when ACLs in CVS were introduced, koji enabled, freezes happened and bodhi was enabled. Sure, only some people participate in those discussion (often the same ones). But a lot of people in the past weeks told me in private (via ICQ, Jabber, IRC, mail and on FUDCOn at LinuxTag now) that they were quite unhappy with the recent happenings. I assume most of them will say "okay, we wanted the merge". But the hard part is now done -- so let's try to work better now to make contributors happy again, as we need them. CU thl (?) -- and I'm not even sure it would have been much different if I would still have been in FESCo. I would have yeeled loudly here and there, but well, time was pressing quite hard (?) -- especially as even now it's still unclear what parts the Board and FESCo are responsible for and how both groups interact with groups like the release tea From fedora at leemhuis.info Sun Jun 3 07:02:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 09:02:29 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180812267.30126.33.camel@localhost.localdomain> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <1180812267.30126.33.camel@localhost.localdomain> Message-ID: <46626785.5010809@leemhuis.info> On 02.06.2007 21:24, Toshio Kuratomi wrote: > [...] > Another goal that I think we need is to work on integrating the Core and > Extras Communities. +1 > When Fedora started, there was a commitment from > within Red Hat that decision making would happen on public forums with > community input. Despite the problems outlined above, I think the past > year has seen this commitment become much more solid than before (Board > Meetings in IRC, discussions by the internal teams on the mailing lists, > the merge allowing people from the Extras Community to make spins, > Extras Community members on the releng team, etc.) Agreed, but some other things got worse at the same time afaics. > However, we need to > take the next step. We've consolidated our decisio making under one > hierarchy but we need to combine our communities as well. +1 > It shouldn't > matter that we have some people working at Red Hat, some for Dell, some > for themselves, some for universities.... We need to find ways to start > thinking of ourselves as one community. Then we have to act like one -- e.g. it's a two way street and both sides have to learn and work together. That was not always the case in the past months. There were afaics rare people that worked in "heads down mode to get foo done quickly" because they feared that going via proper public discussions and Committees would have taken to much time. > And we need to start > communicating with each other as members of a single team. +1 CU thl From rc040203 at freenet.de Sun Jun 3 07:38:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 09:38:36 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <46626443.6020804@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <46626443.6020804@leemhuis.info> Message-ID: <1180856317.12595.498.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 08:48 +0200, Thorsten Leemhuis wrote: > Further: I don't blame the current situation is FESCo's fault (?,?) It's definitely not their fault alone, but there can't be any doubt they share their part of guilt. One aspect: They allowed things to happen the way they happened and did not intervene when things began to derail. A question closely related to this: Would have FESCo been in a position to intervene? I am inclined to think no. The real decisions are taken elsewhere. Ralf From dwmw2 at infradead.org Sun Jun 3 07:54:42 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 03 Jun 2007 08:54:42 +0100 Subject: Don't put new packages through updates-testing In-Reply-To: <1180821475.3218.1.camel@vader.jdub.homelinux.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <1180806380.25232.137.camel@pmac.infradead.org> <1180821475.3218.1.camel@vader.jdub.homelinux.org> Message-ID: <1180857282.25232.145.camel@pmac.infradead.org> On Sat, 2007-06-02 at 16:57 -0500, Josh Boyer wrote: > If this is desired, we should start a simple wiki page that package > maintainers can add requests to for their packages. I don't want to > bulk handle anything without the maintainers' input. Someone already _did_ such things without the maintainers' consent -- my packages have ACLs where they didn't have them before. Please, do it the other way round and let maintainers _ask_ for ACLs if they actually want them. And make them give a _good_ reason too, not just "no teamwork here please". As it stands, it seems like the whole process of 'opening' the Core packages was a deception -- they really seem to be more closed than before. Not particularly impressed. -- dwmw2 From Fedora at FamilleCollet.com Sun Jun 3 07:55:19 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sun, 03 Jun 2007 09:55:19 +0200 Subject: FreeTDS (legal) In-Reply-To: <1180811963.2247.11.camel@localhost.localdomain> References: <20070531082107.2e47582d.jklowden@freetds.org> <465EC40B.4000108@hhs.nl> <1180624504.6254.558.camel@localhost.localdomain> <1180811963.2247.11.camel@localhost.localdomain> Message-ID: <466273E7.5040801@FamilleCollet.com> buc a ?crit : > Well, I'll begin the moving (submit for review etc.) in coming week. > > Additionally, I'll handle php-mssql stuff too. > This should probably go to php-extras SRPM in FC <= 6 which already provide php-mhash, php-mcrypt, ... from php sources (because dependencies are in Extras) For F7 it's probably a good idea to merge php and php-extras, since all dependencies are now in the "Fedora" repository. Regards Remi. From j.w.r.degoede at hhs.nl Sun Jun 3 08:20:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 10:20:16 +0200 Subject: proposal: new guidelines for rule makers In-Reply-To: <46623E6B.5060803@nigelj.com> References: <466129A1.7010805@hhs.nl> <46612B94.8020409@fedoraproject.org> <46620BB1.6020208@hhs.nl> <1180833617.3218.18.camel@vader.jdub.homelinux.org> <46623E6B.5060803@nigelj.com> Message-ID: <466279C0.5060408@hhs.nl> Nigel Jones wrote: > > Now for some figures (these are rough, I'm too lazy to count exactly): > ~40-45 packagers owning 30+ SRPMS (10.5%) > ~100 packagers owning 10-29 SRPMS (25%) > ~70 packagers owning 5-9 SRPMS (17%) > ~190 packagers owning 1-4 SRPMS (46%) > ~15-20 packagers owning 0 SRPMS (0.5%) > (There is 1% missing over the general spread due to rounding and estimates) > I do not want to really go here, but if you want todo this in a fair way, try making numbers how many % of the total number of packages is maintained by which group. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jun 3 08:23:34 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 10:23:34 +0200 Subject: proposal: new guidelines for rule makers In-Reply-To: <1180833617.3218.18.camel@vader.jdub.homelinux.org> References: <466129A1.7010805@hhs.nl> <46612B94.8020409@fedoraproject.org> <46620BB1.6020208@hhs.nl> <1180833617.3218.18.camel@vader.jdub.homelinux.org> Message-ID: <46627A86.3040601@hhs.nl> Josh Boyer wrote: > On Sun, 2007-06-03 at 02:30 +0200, Hans de Goede wrote: >> Rahul Sundaram wrote: >>> Hans de Goede wrote: >>>> Hi all, >>>> >>>> >>>> >>>> Since those making packaging guidelines and other rules seem to be out >>>> of touch with the workfloor these days I would like to propose the >>>> following guideline for rulemakers: >>>> >>>> Those making guidelines / rules within the Fedora project must >>>> actively maintain atleast 30 packages. >>>> >>>> Rationale: How can one make rules if one isn't involved in that which >>>> is regulated oneself? >>>> >>>> >>> Packaging guidelines also cover licensing details which isn't connected >>> to workflow. There are several other policies within the guidelines >>> which involve some amount of politics (kernel modules anyone?). This >>> rule would mean that everybody who proposes any drafts, folks in the >>> packaging committee and FESCo would have to maintain 30 packages. >>> >> Yes it would, and that would be a good thing! Let the people building the >> distro decide how it is build! As for licensing issues, since RH is paying >> mosts of the bills at the end RH decided what is okay licensing wise, and to me >> they have earned that right, because "paying the bills" == "building the distro" > > I don't want to misinterpret what you're saying here, so I'll ask you > straight out. > > Are you suggesting that because I do not maintain 30 packages I am > unqualified to be a member of FESCo? > You're taking me to serious here, notice the at the top of the original post. I've no intention to actually try and instantiate such a rule. I'm however woried that there seems to be a growing drift between the rule makers within Fedora and those running the primary process. Regards, Hans From fedora at leemhuis.info Sun Jun 3 08:24:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 10:24:11 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180856317.12595.498.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <46626443.6020804@leemhuis.info> <1180856317.12595.498.camel@mccallum.corsepiu.local> Message-ID: <46627AAB.90406@leemhuis.info> On 03.06.2007 09:38, Ralf Corsepius wrote: > On Sun, 2007-06-03 at 08:48 +0200, Thorsten Leemhuis wrote: > >> Further: I don't blame the current situation is FESCo's fault (?,?) > It's definitely not their fault alone, but there can't be any doubt they > share their part of guilt. Well, we all likely share a part. We all could have yelled louder if we wanted; it might have changed some things here and there. But I for one kept mostly quiet until now as I was willing to accept some bumpy time to get the merge done for F7. But F7 is out now, so now we need to get things in a better shape again. I'm actually *wondering* if we should have a "spare time packagers committee" (or something like that) that represents the packagers that do their package maintenance work in their spare time. They afaics sometimes simply don't have the time and the power to get their opinion heard without investing even more of their rare spare time. > One aspect: They allowed things to happen the way they happened and did > not intervene when things began to derail. > > A question closely related to this: Would have FESCo been in a position > to intervene? I am inclined to think no. I'm inclined to think "yes, if they wanted to". > The real decisions are taken elsewhere. Well, that's why I'm urging the board to clarify the work areas for the Board and FESCo. That is lingering around for months now (see fab-archives) and it seems everyone has different expectations in that area. Regarding that: I still wondering why there is a FESCo election scheduled for the near future when it's unclear what FESCo and its members will be responsible for. But it seems that's just me, as I did not even get one reply to my mail regarding that topic. (Send some days ago; see https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00012.html ) CU thl From nicolas.mailhot at laposte.net Sun Jun 3 08:38:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 03 Jun 2007 10:38:25 +0200 Subject: proposal: new guidelines for rule makers In-Reply-To: <466279C0.5060408@hhs.nl> References: <466129A1.7010805@hhs.nl> <46612B94.8020409@fedoraproject.org> <46620BB1.6020208@hhs.nl> <1180833617.3218.18.camel@vader.jdub.homelinux.org> <46623E6B.5060803@nigelj.com> <466279C0.5060408@hhs.nl> Message-ID: <1180859905.3442.5.camel@rousalka.dyndns.org> Le dimanche 03 juin 2007 ? 10:20 +0200, Hans de Goede a ?crit : > Nigel Jones wrote: > > > > Now for some figures (these are rough, I'm too lazy to count exactly): > > ~40-45 packagers owning 30+ SRPMS (10.5%) > > ~100 packagers owning 10-29 SRPMS (25%) > > ~70 packagers owning 5-9 SRPMS (17%) > > ~190 packagers owning 1-4 SRPMS (46%) > > ~15-20 packagers owning 0 SRPMS (0.5%) > > (There is 1% missing over the general spread due to rounding and estimates) > > > I do not want to really go here, but if you want todo this in a fair way, try > making numbers how many % of the total number of packages is maintained by > which group. And then you can weight the packages by popularity/usefulness, so people who maintain huge perl collections most people wouldn't care less about do not get an undue bonus One guy/gal = one vote is not a perfect rule, but at least it's an honest one with no special bias (like you get when you start down the weighted votes path) -- 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 pertusus at free.fr Sun Jun 3 08:40:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 10:40:56 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180818014.3300.17.camel@rousalka.dyndns.org> References: <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <1180804882.3294.24.camel@rousalka.dyndns.org> <20070602174203.GD2840@free.fr> <1180818014.3300.17.camel@rousalka.dyndns.org> Message-ID: <20070603083906.GA2826@free.fr> On Sat, Jun 02, 2007 at 11:00:14PM +0200, Nicolas Mailhot wrote: > > > and no consideration of how to limit the impact on packager work. > > Again the infrastructure team deserves more credit than you give it. I am not giving or removing credit to specific people or groups. I am stating where I see problems in the fedora lead with different objectives for some packagers and those who decide on processes. > At some point you have to ship and do fine-tuning later. With perfect > hindsight better questions would have been asked, but with perfect > hindsight people wouldn't have had to ask them in the first place, and > that F7 happened is testament the delivered infrastructure/process does > not fall too far of the mark. That is not my point, the merge is right, it happened in very little time, it is good that it wasn't plagued with lengthy discussions. The point is that in discussions many of the infrastructures team people showed that they wanted to add mandatory processes even when packagers wanted shortcuts, they wanted some defaults that didn't correspond to some packagers will. Once again it is not about the work done but about some directions. In general these are not technical points but more 'political' ones. For an example (if it is still unclear) I think freezes for releases are good, and it is very nice to have an infrastructure for that. However I think that instead of asking to a rel-eng to tag the build to enter the freeze, it should be up to the packager, with a possibility for rel-engs to deny it. > The problems are obvious now because we have something (tools+processes) > to play with, and that's loads more we'd have if people had discussed it > half a year more. Still speaking about the release freeze issue, I voiced my concerns well before, and the work to implement both way is certainly the same. Having put the decision to tag for the freeze or not in packagers hand wouldn't have delayed anything. It is a 'political' choice. -- Pat From rc040203 at freenet.de Sun Jun 3 08:50:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 10:50:15 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <46627AAB.90406@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <46626443.6020804@leemhuis.info> <1180856317.12595.498.camel@mccallum.corsepiu.local> <46627AAB.90406@leemhuis.info> Message-ID: <1180860616.12595.538.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 10:24 +0200, Thorsten Leemhuis wrote: > > On 03.06.2007 09:38, Ralf Corsepius wrote: > > On Sun, 2007-06-03 at 08:48 +0200, Thorsten Leemhuis wrote: > > > >> Further: I don't blame the current situation is FESCo's fault (?,?) > > It's definitely not their fault alone, but there can't be any doubt they > > share their part of guilt. > > Well, we all likely share a part. Right, and I don't think there is anything wrong with it, we are all imperfect humans and we all make mistakes and oversights. > We all could have yelled louder if we > wanted; it might have changed some things here and there. But I for one > kept mostly quiet until now as I was willing to accept some bumpy time > to get the merge done for F7. But F7 is out now, so now we need to get > things in a better shape again. > > I'm actually *wondering* if we should have a "spare time packagers > committee" (or something like that) that represents the packagers that > do their package maintenance work in their spare time. They afaics > sometimes simply don't have the time and the power to get their opinion > heard without investing even more of their rare spare time. Well, as I repeated said: I consider FESCo to be some sort of parliament constituting of representatives and not to be a "board of directors" or an administration. > > One aspect: They allowed things to happen the way they happened and did > > not intervene when things began to derail. > > > > A question closely related to this: Would have FESCo been in a position > > to intervene? I am inclined to think no. > > I'm inclined to think "yes, if they wanted to". ... the later half is the interesting part: I think, executive and legislative organs are too closely linked in FESCo. In other words, I think, current FESCo is not able to "monitor", because the "persons to monitor" are largely identical to "those to be monitored". > > The real decisions are taken elsewhere. Let me try to clarify: I am not referring to "technical committees" working out details (under a Fedora Governments direction/supervision), I am referring to non-technical, strategic decisions. Trying to project this on real world governments: * It's a government's job to decide upon "tax increases", not the "tax authorities". It's the tax authorities' job to work out (technical) details and the government's job to ratify them. * It's the government's job to decide upon "immigration regulations", not the "immigration office's". It's the "immigration offices' job to work out details and the government's job to ratify them. > Well, that's why I'm urging the board to clarify the work areas for the > Board and FESCo. > That is lingering around for months now (see > fab-archives) and it seems everyone has different expectations in that > area. I _did_ notice your posting and was waiting for FAB's and FESCO's voices. Their (non-) reaction to me is a strong indication for my claims above to be true. Ralf From pertusus at free.fr Sun Jun 3 08:53:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 10:53:17 +0200 Subject: Packaging Guideline for JNI Libs? In-Reply-To: <1180843410.3001.2.camel@workstation.unixkiste.local> References: <1180843410.3001.2.camel@workstation.unixkiste.local> Message-ID: <20070603085317.GB2826@free.fr> On Sun, Jun 03, 2007 at 06:03:30AM +0200, Stefan Held wrote: > Hello guys. > > Is there a packaging guideline which describes where JNI native > libraries for java libs should be installed to? > > Would a directory /usr/lib/jni be a bad idea or simply place that lib > into /usr/lib? I think that no guideliens exist, there was some discussionon a fedora java list, but I don't remember how it ended. My personal opinion (and I think that some FPC members would agree) is that it is very wrong to put the JNI native libraries for java libs in /usr/lib. /usr/lib should be reserved for libraries that are linked against with -lfoo, and unless I am wrong JNI libs are not linked against but dlopened. -- Pat From nicolas.mailhot at laposte.net Sun Jun 3 08:58:20 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 03 Jun 2007 10:58:20 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <20070603083906.GA2826@free.fr> References: <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <1180804882.3294.24.camel@rousalka.dyndns.org> <20070602174203.GD2840@free.fr> <1180818014.3300.17.camel@rousalka.dyndns.org> <20070603083906.GA2826@free.fr> Message-ID: <1180861100.3442.17.camel@rousalka.dyndns.org> Le dimanche 03 juin 2007 ? 10:40 +0200, Patrice Dumas a ?crit : > The > point is that in discussions many of the infrastructures team people > showed that they wanted to add mandatory processes even when packagers > wanted shortcuts, missing a some before packagers there > they wanted some defaults that didn't correspond to > some packagers will. Once again it is not about the work done but about > some directions. In general these are not technical points but more > 'political' ones. For an example (if it is still unclear) I think > freezes for releases are good, and it is very nice to have an > infrastructure for that. My personal opinion there (and I do not claim to represent anything more than myself) is former Extras was very good at some things, and former Core at others, and it's logical that merged processes and tools take the best of each. Extras was good at specifying packaging policy & had good build tools to enforce it ? koji is heavily inspired by the Extras buildsys Core was good at release engineering, and Extras never managed to create anything approaching ? release engineering tools and processes mostly follow Core rules > However I think that instead of asking to a > rel-eng to tag the build to enter the freeze, it should be up to the > packager, with a possibility for rel-engs to deny it. I suspect you've never tried to herd cats. Making this the rule instead of the exception like now wouldn't work because of human nature, there's always people who think they know better and would waste rel-eng time just when it's needed elsewhere. -- 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 Sun Jun 3 09:03:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 03 Jun 2007 11:03:34 +0200 Subject: Packaging Guideline for JNI Libs? In-Reply-To: <20070603085317.GB2826@free.fr> References: <1180843410.3001.2.camel@workstation.unixkiste.local> <20070603085317.GB2826@free.fr> Message-ID: <1180861414.3442.21.camel@rousalka.dyndns.org> Le dimanche 03 juin 2007 ? 10:53 +0200, Patrice Dumas a ?crit : > On Sun, Jun 03, 2007 at 06:03:30AM +0200, Stefan Held wrote: > > Hello guys. > > > > Is there a packaging guideline which describes where JNI native > > libraries for java libs should be installed to? > > > > Would a directory /usr/lib/jni be a bad idea or simply place that lib > > into /usr/lib? > > I think that no guideliens exist, there was some discussionon a fedora > java list, but I don't remember how it ended. > > My personal opinion (and I think that some FPC members would agree) And others wouldn't Arch-specific stuff ? libdir. Read your FHS again -- 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 buildsys at redhat.com Sun Jun 3 09:26:52 2007 From: buildsys at redhat.com (Build System) Date: Sun, 3 Jun 2007 05:26:52 -0400 Subject: rawhide report: 20070603 changes Message-ID: <200706030926.l539QqoQ012758@porkchop.devel.redhat.com> New package dwdiff Front end to diff for comparing files on a word per word basis New package onesixtyone An efficient SNMP scanner New package perl-Net-Write A portable interface to open and send raw data to network New package postgresql-pgpool-II Pgpool is a connection pooling/replication server for PostgreSQL New package telepathy-mission-control Central control for Telepathy connection manager New package trac-webadmin Web interface for administration of Trac Updated Packages: VLGothic-fonts-20070507-1.fc8 ----------------------------- * Sat Jun 02 2007 Ryo Dairiki - 20070507-1 - Update to 20070507 abe-1.1-5.fc8 ------------- * Fri Jun 01 2007 Wart 1.1-5 - Update desktop category for better game menu integration - Use improved download URL. bigloo-3.0a-4.fc8 ----------------- * Sat Jun 02 2007 Gerard Milmeister - 3.0a-4 - exclude ppc64 * Fri Jun 01 2007 Gerard Milmeister - 3.0a-3 - remove java ssl since it does not build with libgcj * Fri Jun 01 2007 Gerard Milmeister - 3.0a-1 - new version 3.0a claws-mail-2.9.2-1.fc8 ---------------------- * Tue May 15 2007 Andreas Bierfert 2.9.2-1 - version upgrade claws-mail-plugins-2.9.2-2.fc8 ------------------------------ * Sat Jun 02 2007 Andreas Bierfert 2.9.2-2 - bump * Tue May 15 2007 Andreas Bierfert 2.9.2-1 - version upgrade contacts-0.5-1.fc8 ------------------ * Sat Jun 02 2007 Denis Leroy - 0.5-1 - Update to 0.5 - Updated dependencies - Added icon cache and desktop database scripts dap-freeform_handler-3.7.5-2.fc8 -------------------------------- * Fri Jun 01 2007 Patrice Dumas 3.7.5-2 - rebuild against newer libdap * Tue May 01 2007 Patrice Dumas 3.7.5-1 - update to 3.7.5 dap-hdf4_handler-3.7.5-3.fc8 ---------------------------- * Fri Jun 01 2007 Patrice Dumas 3.7.5-3 - rebuild against newer libdap * Tue May 01 2007 Patrice Dumas 3.7.5-2 - update to 3.7.5 dap-netcdf_handler-3.7.6-3.fc8 ------------------------------ * Fri Jun 01 2007 Patrice Dumas 3.7.6-3 - rebuild against newer libdap and netcdf * Tue May 01 2007 Patrice Dumas 3.7.6-2 - update to 3.7.6 dap-server-3.7.4-4.fc8 ---------------------- * Fri Jun 01 2007 Patrice Dumas 3.7.4-4 - rebuild against newer libdap dates-0.4.2-1.fc8 ----------------- * Sat Jun 02 2007 Denis Leroy - 0.4.2-1 - Update to upstream 0.4.2 release gossip-0.26-1.fc8 ----------------- * Sat Jun 02 2007 Brian Pepple - 0.26-1 - Update to 0.26. - Drop telepathy bits, since it is being removed from Gossip. - Drop pixbuf patch, fixed upstream. jd-1.9.5-0.3.svn1106.fc8 ------------------------ * Sun Jun 03 2007 Mamoru Tasaka - 1.9.5-0.3.svn1106 - svn 1106 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta070528 * Tue May 22 2007 Mamoru Tasaka - 1.9.5-0.2.beta070516 - Support C/Migemo search kernel-2.6.21-1.3200.fc8 ------------------------ * Sat Jun 02 2007 David Woodhouse - Re-enable ppc64 builds. libgdiplus-1.2.4-1.fc8 ---------------------- * Sat Jun 02 2007 Christopher Aillon 1.2.4-1 - Update to 1.2.4 libnc-dap-3.7.0-4.fc8 --------------------- * Fri Jun 01 2007 Patrice Dumas 3.7.0-4 - remove static libs * Tue May 01 2007 Patrice Dumas 3.7.0-3 - Buildrequires gfortran for the fortran API * Mon Apr 30 2007 Patrice Dumas 3.7.0-2 - update to 3.7.0 openvrml-0.16.4-3.fc8 --------------------- * Sat Jun 02 2007 Braden McDaniel - 0.16.4-3 - Updated firefox dependency to 2.0.0.4. perl-Gtk2-TrayIcon-0.06-1.fc8 ----------------------------- * Sat Jun 02 2007 Chris Weyl 0.06-1 - update to 0.06 - add t/ to doc perl-POE-Component-SSLify-0.08-1.fc8 ------------------------------------ * Fri Jun 01 2007 Chris Weyl 0.08-1 - update to 0.08 perl-POE-Component-Server-SOAP-1.11-1.fc8 ----------------------------------------- * Sat Jun 02 2007 Chris Weyl 1.11-1 - update to 1.11 - add t/ to doc perl-bioperl-1.5.2_102-8.fc8 ---------------------------- * Mon May 07 2007 Alex Lancaster 1.5.2_102-8 - Spec file cleanups. - Improve description. pgfouine-1.0-1.fc8 ------------------ php-pear-Console-Table-1.0.7-1.fc8 ---------------------------------- * Wed May 02 2007 Remi Collet 1.0.7-1 - update to 1.0.7 php-pear-HTTP-Request-1.4.1-1.fc8 --------------------------------- php-pear-Log-1.9.11-1.fc8 ------------------------- * Wed May 02 2007 Remi Collet 1.9.11-1 - update to 1.9.11 python-nose-0.9.3-1.fc8 ----------------------- * Sat Jun 02 2007 Luke Macken 0.9.3-1 - Latest upstream release - Remove python-nose-0.9.2-mandir.patch python-psycopg2-2.0.5.1-8.fc8 ----------------------------- python-sqlobject-0.9.0-1.fc8 ---------------------------- * Sat Jun 02 2007 Luke Macken 0.9.0-1 - Latest upstream release recordmydesktop-0.3.4-1.fc8 --------------------------- * Sat Jun 02 2007 Sindre Pedersen Bj??rdal - 0.3.4-1 - New version 0.3.4 * Mon Mar 05 2007 Sindre Pedersen Bj??rdal - 0.3.3.1-3 - chmod +x on source files to make rpmlint happy * Mon Mar 05 2007 Sindre Pedersen Bj??rdal - 0.3.3.1-2 - Remove duplicate BR - Add missing zlib-devel BR - Preserve timestamps rxvt-unicode-8.2-1.fc8 ---------------------- * Sat Jun 02 2007 Andreas Bierfert 8.2-1 - version upgrade (#239421) scribus-1.3.4-1.fc8 ------------------- * Sat Jun 02 2007 Andreas Bierfert 1.3.4 - version upgrade tig-0.7-4.fc8 ------------- * Sat Jun 02 2007 James Bowes - 0.7-4 - Ensure that the version string is set in the binary. * Fri Jun 01 2007 James Bowes - 0.7-3 - Incorporate differences from jcollie's tig spec. * Fri Jun 01 2007 James Bowes - 0.7-2 - Update spec file after review feedback. xchat-1:2.8.2-8.fc8 ------------------- * Sat Jun 02 2007 Kevin Kofler - 1:2.8.2-8 - disable tray icon by default (#241923) * Thu May 31 2007 Kevin Kofler - 1:2.8.2-7 - revert to redhat-desktop patch pending further discussion * Thu May 31 2007 Kevin Kofler - 1:2.8.2-6 - apply xc282-fixtrayzombies.diff from upstream From fedora at leemhuis.info Sun Jun 3 09:30:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 11:30:14 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180860616.12595.538.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <46626443.6020804@leemhuis.info> <1180856317.12595.498.camel@mccallum.corsepiu.local> <46627AAB.90406@leemhuis.info> <1180860616.12595.538.camel@mccallum.corsepiu.local> Message-ID: <46628A26.9090609@leemhuis.info> On 03.06.2007 10:50, Ralf Corsepius wrote: > On Sun, 2007-06-03 at 10:24 +0200, Thorsten Leemhuis wrote: >> On 03.06.2007 09:38, Ralf Corsepius wrote: >>> On Sun, 2007-06-03 at 08:48 +0200, Thorsten Leemhuis wrote: > >> I'm actually *wondering* if we should have a "spare time packagers >> committee" (or something like that) that represents the packagers that >> do their package maintenance work in their spare time. They afaics >> sometimes simply don't have the time and the power to get their opinion >> heard without investing even more of their rare spare time. > Well, as I repeated said: I consider FESCo to be some sort of parliament > constituting of representatives and not to be a "board of directors" or > an administration. Sure -- but FESCo had a lot to do in the past already and now with the merge it has even more to do. Even when I was chair I was unhappy with some parts of how FESCo represented the community and interacted with it. You, Ralf were one of those that pointed out a lot of problems in private or in public when needed; but there were more pressing issues for FESCo, so I found no time to deal with all of them (or better: only with a few). I assume now with the merge and more stuff to do it will get even more problematic for FESCo members to deal with all the things the spare time packagers might bring up. So it might make sense to split out some work areas into sub-committees, that can focus on special areas and preset solution to FESCo where FESCo then can say "well done, we make it so". That way the spare time packagers might get their opinion heard better. > [...] CU thl From pertusus at free.fr Sun Jun 3 09:32:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 11:32:40 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180861100.3442.17.camel@rousalka.dyndns.org> References: <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <1180804882.3294.24.camel@rousalka.dyndns.org> <20070602174203.GD2840@free.fr> <1180818014.3300.17.camel@rousalka.dyndns.org> <20070603083906.GA2826@free.fr> <1180861100.3442.17.camel@rousalka.dyndns.org> Message-ID: <20070603093240.GD2826@free.fr> On Sun, Jun 03, 2007 at 10:58:20AM +0200, Nicolas Mailhot wrote: > > missing a some before packagers there Indeed. > Extras was good at specifying packaging policy & had good build tools to > enforce it ? koji is heavily inspired by the Extras buildsys But it is improved, isn't it? > Core was good at release engineering, and Extras never managed to create > anything approaching ? release engineering tools and processes mostly > follow Core rules Maybe there is room for improvement in core rules now that there are other packagers involved. > > However I think that instead of asking to a > > rel-eng to tag the build to enter the freeze, it should be up to the > > packager, with a possibility for rel-engs to deny it. > > I suspect you've never tried to herd cats. Making this the rule instead > of the exception like now wouldn't work because of human nature, there's > always people who think they know better and would waste rel-eng time > just when it's needed elsewhere. Of course, but the right way to handle that is not by coming in the way of those who really know better, but by educating those who think they know better. -- Pat From fedora at leemhuis.info Sun Jun 3 09:43:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 11:43:10 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180861100.3442.17.camel@rousalka.dyndns.org> References: <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <1180804882.3294.24.camel@rousalka.dyndns.org> <20070602174203.GD2840@free.fr> <1180818014.3300.17.camel@rousalka.dyndns.org> <20070603083906.GA2826@free.fr> <1180861100.3442.17.camel@rousalka.dyndns.org> Message-ID: <46628D2E.8090206@leemhuis.info> On 03.06.2007 10:58, Nicolas Mailhot wrote: > Le dimanche 03 juin 2007 ? 10:40 +0200, Patrice Dumas a ?crit : > > My personal opinion there (and I do not claim to represent anything more > than myself) is former Extras was very good at some things, and former > Core at others, and it's logical that merged processes and tools take > the best of each. > > Extras was good at specifying packaging policy & had good build tools to > enforce it ? koji is heavily inspired by the Extras buildsys > > Core was good at release engineering, and Extras never managed to create > anything approaching ? release engineering tools and processes mostly > follow Core rules Extras was good (but still far from perfect) when it comes to get the community heard and representing it. Extras had a transparent (but still far from perfect) transparent decision process where everyone could get heard if he wanted to. Debatably decisions in Extras were done by Committee. I fear that those are the things we are losing with the merge. At least I got the impression (and some people told me they had a similar impression) we lost some parts of it already during the past months. No big deal, the time was pressing, so it was acceptable. But we need to get back on track now IMHO. That's why I'm raising my voice here in this discussion. CU knurd From pertusus at free.fr Sun Jun 3 09:42:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 11:42:34 +0200 Subject: Packaging Guideline for JNI Libs? In-Reply-To: <1180861414.3442.21.camel@rousalka.dyndns.org> References: <1180843410.3001.2.camel@workstation.unixkiste.local> <20070603085317.GB2826@free.fr> <1180861414.3442.21.camel@rousalka.dyndns.org> Message-ID: <20070603094233.GE2826@free.fr> On Sun, Jun 03, 2007 at 11:03:34AM +0200, Nicolas Mailhot wrote: > Le dimanche 03 juin 2007 ? 10:53 +0200, Patrice Dumas a ?crit : > > On Sun, Jun 03, 2007 at 06:03:30AM +0200, Stefan Held wrote: > > > Hello guys. > > > > > > Is there a packaging guideline which describes where JNI native > > > libraries for java libs should be installed to? > > > > > > Would a directory /usr/lib/jni be a bad idea or simply place that lib > > > into /usr/lib? > > > > I think that no guideliens exist, there was some discussionon a fedora > > java list, but I don't remember how it ended. > > > > My personal opinion (and I think that some FPC members would agree) > > And others wouldn't > Arch-specific stuff ? libdir. Read your FHS again I am not saying that they shouldn't be below /usr/lib, but I think that they shouldn't be right in /usr/lib. For example in /usr/lib/jni could be right. I just have reread the FHS it indeed isn't completly certain that it is right, since it says that "Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory." So if there is already a directory holding java related architecture dependent files, it should be used instead. Seems like there are already some directories for java in /usr/lib, I don't know exactly what is their use. They are owned by jpackage-utils and are: /usr/lib/java /usr/lib/java-1.4.1 /usr/lib/java-1.6.0 /usr/lib/java-1.3.1 /usr/lib/java-1.4.2 /usr/lib/java-ext /usr/lib/java-1.4.0 /usr/lib/java-1.5.0 Maybe one of these directory is searched for for jni libraries. In that case I think it should be used instead of /usr/lib. -- Pat From aph at redhat.com Sun Jun 3 09:48:39 2007 From: aph at redhat.com (Andrew Haley) Date: Sun, 3 Jun 2007 10:48:39 +0100 Subject: Packaging Guideline for JNI Libs? In-Reply-To: <20070603085317.GB2826@free.fr> References: <1180843410.3001.2.camel@workstation.unixkiste.local> <20070603085317.GB2826@free.fr> Message-ID: <18018.36471.342491.122071@zebedee.pink> Patrice Dumas writes: > > /usr/lib should be reserved for libraries that are linked against > with -lfoo, and unless I am wrong JNI libs are not linked against > but dlopened. A sentence like this with a "should" but no "because" is ill-formed. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From dev at nigelj.com Sun Jun 3 10:03:33 2007 From: dev at nigelj.com (Nigel Jones) Date: Sun, 03 Jun 2007 22:03:33 +1200 Subject: Wakey wakey everyone (or: Why we need to think about contributing to other areas of Fedora) Message-ID: <466291F5.4090503@nigelj.com> As it seems to be the season for everyone to get their radical views about how Fedora should be etc, I think I'll post some of my personal views on where I think Fedora can improve... It seems that after the merge, quite a lot of discussion has revolved around the whole idea of "Why did you implement that, I don't like it, it interrupts my 'workflow'?" or "I liked it how it used to be" or even (I kind of agree with this) "Why wasn't I told? Why didn't you tell me before hand I'd have to learn a whole new set of make functions?" Some of the complaining I think is justified, personally I find a lack of specifics on what I have to do to get my updates into F7 a little annoying but I'm not making a big deal about it. Over my last ~2 months of contributing I think that both FESCo and rel-eng have done great work of late, it's noticeable, and it's allowed me to make great use of my limited time that I have to contribute to Fedora. Personally I think we also owe a lot of credit to the packagers who dedicate a lot of time to sets of highly useful, related packages (three main examples come to mind (cweyl (packager of a large number of high quality perl modules), xulchris (packager of a large number of high quality PHP Pear modules), and than (main packager for KDE packages)). The issue I see though is while groups such as Fedora Docs have well designed goals (I can't remember who pointed this out), I'm sure they could do with extra hands to produce some of the docs WE as maintainers both need and want. The infrastructure team need more people knowledgeable in python for their projects, and I'm sure the L10n and i10n groups could also use an extra hand from people knowledgeable in Fedora. So, please, lets all think twice about how we contribute to Fedora, instead of counting how many packages we each own like Scrooge does with money, but lets judge people by what their role in the community is, someone may only have limited spare time, and wish to maintain a couple of packages, but I think people that are serious about contributing to Fedora should also look into helping other areas. What I'm essentially trying to say is, lets get involved in other areas of Fedora, not just packaging. There is PackageDB in the works, if you want documentation for that in advance, maybe we should think about discovering what is required to do that and help get that done for release. Bodhi is nowhere near complete (they admit it on the trac too), maybe the packaging community should where possible help with that too! Thats my 2 cents (quite possibly nearing $1), N.J. P.S. Yes, I myself am happy to eat my own words and look into helping other areas where and when I can. P.S.S. A couple of clarifications: * I'm not saying anyone is doing a bad job at maintaining, I'm just saying we need to make other aspects of Fedora better for our users, ourselves (i.e. current maintainers), and future maintainers. * I've missed quite a few people that have also done excellent work for Fedora and it's maintainers this is not intentional From fedora at leemhuis.info Sun Jun 3 10:43:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 12:43:10 +0200 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 In-Reply-To: <20070602224130.1229.76138@extras64.linux.duke.edu> References: <20070602224130.1229.76138@extras64.linux.duke.edu> Message-ID: <46629B3E.5000102@leemhuis.info> On 03.06.2007 00:41, Fedora Extras repoclosure wrote: ^^^^^^ ;-) > Summary of broken packages (by owner): > > fedora AT leemhuis.info > gsynaptics - 0.9.11-1.fc7.ppc64 > [...] > Broken packages in fedora-7-ppc64: > > gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics > [...] @rel-eng: please remove gsynaptics from the PPC64 devel tree until https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242323 (synaptics missing for ppc64) is solved somehow. I assume packages from the released tree for F7 are not removed even if broken? Then I'll likely have to ignore that report until above bug is solved somehow. CU knurd /me for doesn't add a "ExcludeArch: ppc64" to gsynaptics in the hope to get a reply to the bug soon From buildsys at fedoraproject.org Sun Jun 3 11:55:12 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 03 Jun 2007 11:55:12 -0000 Subject: Summary - Broken dependencies in Fedora Everything development - 2007-06-03 Message-ID: <20070603115512.21135.72978@extras64.linux.duke.edu> Summary of broken packages (by owner): From buildsys at fedoraproject.org Sun Jun 3 11:59:56 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 03 Jun 2007 11:59:56 -0000 Subject: Summary - Broken dependencies in Fedora Everything development - 2007-06-03 Message-ID: <20070603115956.21266.18897@extras64.linux.duke.edu> New report for: Axel.Thimm AT ATrpms.net package: freenx - 0.6.0-12.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: nx ====================================================================== New report for: ville.skytta AT iki.fi package: em8300 - 0.16.2-1.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: em8300-kmod >= 0:0.16.2 package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 from rawhide-development-i386 unresolved deps: kernel-i586 = 0:2.6.20-1.3104.fc7 package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 from rawhide-development-i386 unresolved deps: kernel-i686 = 0:2.6.20-1.3104.fc7 package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc from rawhide-development-ppc unresolved deps: kernel-ppc = 0:2.6.20-1.3104.fc7 package: kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 from rawhide-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.20-1.3104.fc7 package: kmod-em8300-PAE - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 from rawhide-development-i386 unresolved deps: kernel-i686 = 0:2.6.20-1.3104.fc7PAE package: kmod-em8300-kdump - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 from rawhide-development-x86_64 unresolved deps: kernel-x86_64 = 0:2.6.20-1.3104.fc7kdump package: kmod-em8300-smp - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc from rawhide-development-ppc unresolved deps: kernel-ppc = 0:2.6.20-1.3104.fc7smp ====================================================================== New report for: jonathansteffan AT gmail.com package: revisor - 2.0.3.6-1.fc8.noarch from rawhide-development-ppc64 unresolved deps: livecd-tools package: revisor - 2.0.3.6-1.fc8.noarch from rawhide-development-ppc unresolved deps: livecd-tools ====================================================================== New report for: tmraz AT redhat.com package: openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: openoffice.org-core ====================================================================== New report for: karlthered AT gmail.com package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 from rawhide-development-x86_64 unresolved deps: gecko-libs = 0:1.8.1.3 package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 from rawhide-development-i386 unresolved deps: gecko-libs = 0:1.8.1.3 package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc from rawhide-development-ppc unresolved deps: gecko-libs = 0:1.8.1.3 package: gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: gecko-libs = 0:1.8.1.3 ====================================================================== New report for: mbarnes AT redhat.com package: gnome-python2-totem - 2.18.0-1.fc7.i386 from rawhide-development-i386 unresolved deps: libtotem-plparser.so.1 package: gnome-python2-totem - 2.18.0-1.fc7.ppc from rawhide-development-ppc unresolved deps: libtotem-plparser.so.1 package: gnome-python2-totem - 2.18.0-1.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: libtotem-plparser.so.1()(64bit) package: gnome-python2-totem - 2.18.0-1.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libtotem-plparser.so.1()(64bit) ====================================================================== New report for: cgoorah AT yahoo.com.au package: geda-examples - 20070216-2.fc7.noarch from rawhide-development-ppc64 unresolved deps: geda-gschem ====================================================================== New report for: jwilson AT redhat.com package: emerald-themes - 0.2.0-1.fc7.noarch from rawhide-development-ppc64 unresolved deps: emerald >= 0:0.2.0 beryl-core >= 0:0.2.0 ====================================================================== New report for: mdehaan AT redhat.com package: koan - 0.3.1-2.fc7.noarch from rawhide-development-ppc64 unresolved deps: syslinux ====================================================================== New report for: seg AT haxxed.com package: rosegarden4 - 1.4.0-1.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: liblrdf.so.2()(64bit) ====================================================================== New report for: denis AT poolshark.org package: brasero - 0.5.2-1.fc7.i386 from rawhide-development-i386 unresolved deps: libtotem-plparser.so.1 package: brasero - 0.5.2-1.fc7.ppc from rawhide-development-ppc unresolved deps: libtotem-plparser.so.1 package: brasero - 0.5.2-1.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libtotem-plparser.so.1()(64bit) ====================================================================== New report for: dennis AT ausil.us package: oooqs2 - 1.0-3.fc6.ppc64 from rawhide-development-ppc64 unresolved deps: openoffice.org-draw openoffice.org-base openoffice.org-calc openoffice.org-writer openoffice.org-math openoffice.org-impress ====================================================================== New report for: tscherf AT redhat.com package: Democracy - 0.9.5.1-8.fc7.i386 from rawhide-development-i386 unresolved deps: firefox = 0:2.0.0.3 package: Democracy - 0.9.5.1-8.fc7.ppc from rawhide-development-ppc unresolved deps: firefox = 0:2.0.0.3 package: Democracy - 0.9.5.1-8.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: firefox = 0:2.0.0.3 package: Democracy - 0.9.5.1-8.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: firefox = 0:2.0.0.3 ====================================================================== New report for: jdieter AT gmail.com package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-ppc64 unresolved deps: deltarpm >= 0:3.4-2 package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-ppc unresolved deps: deltarpm >= 0:3.4-2 package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-x86_64 unresolved deps: deltarpm >= 0:3.4-2 package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-i386 unresolved deps: deltarpm >= 0:3.4-2 ====================================================================== New report for: tcallawa AT redhat.com package: xsupplicant - 1.2.8-1.fc7.1.i386 from rawhide-development-i386 unresolved deps: libiw.so.28 package: xsupplicant - 1.2.8-1.fc7.1.ppc from rawhide-development-ppc unresolved deps: libiw.so.28 package: xsupplicant - 1.2.8-1.fc7.1.x86_64 from rawhide-development-x86_64 unresolved deps: libiw.so.28()(64bit) ====================================================================== New report for: green AT redhat.com package: ardour - 0.99.3-8.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: liblrdf.so.2()(64bit) ====================================================================== New report for: foolish AT guezz.net package: gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch from rawhide-development-ppc64 unresolved deps: recordmydesktop = 0:0.3.3.1 package: gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch from rawhide-development-ppc unresolved deps: recordmydesktop = 0:0.3.3.1 package: gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch from rawhide-development-x86_64 unresolved deps: recordmydesktop = 0:0.3.3.1 package: gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch from rawhide-development-i386 unresolved deps: recordmydesktop = 0:0.3.3.1 ====================================================================== New report for: walters AT redhat.com package: bigboard - 0.4.0-2.i386 from rawhide-development-i386 unresolved deps: hippo-canvas-python >= 0:0.2.16 package: bigboard - 0.4.0-2.ppc from rawhide-development-ppc unresolved deps: hippo-canvas-python >= 0:0.2.16 package: bigboard - 0.4.0-2.ppc64 from rawhide-development-ppc64 unresolved deps: hippo-canvas-python >= 0:0.2.16 package: bigboard - 0.4.0-2.x86_64 from rawhide-development-x86_64 unresolved deps: hippo-canvas-python >= 0:0.2.16 ====================================================================== New report for: paul AT city-fan.org package: bittorrent - 4.4.0-5.fc7.noarch from rawhide-development-ppc64 unresolved deps: python-crypto ====================================================================== New report for: thomas AT apestaart.org package: python-twisted-conch - 0.7.0-4.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: python-crypto ====================================================================== New report for: gauret AT free.fr package: glest-data - 2.0.0-2.fc7.noarch from rawhide-development-ppc64 unresolved deps: glest = 0:2.0.0 package: glest-data - 2.0.0-2.fc7.noarch from rawhide-development-ppc unresolved deps: glest = 0:2.0.0 package: showimg-pgsql - 0.9.5-12.fc7.i386 from rawhide-development-i386 unresolved deps: libpqxx-2.6.8.so package: showimg-pgsql - 0.9.5-12.fc7.ppc from rawhide-development-ppc unresolved deps: libpqxx-2.6.8.so package: showimg-pgsql - 0.9.5-12.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: libpqxx-2.6.8.so()(64bit) package: showimg-pgsql - 0.9.5-12.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libpqxx-2.6.8.so()(64bit) ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: koffice-kexi-driver-pgsql - 1.6.2-3.fc7.i386 from rawhide-development-i386 unresolved deps: libpqxx-2.6.8.so package: koffice-kexi-driver-pgsql - 1.6.2-3.fc7.ppc from rawhide-development-ppc unresolved deps: libpqxx-2.6.8.so package: koffice-kexi-driver-pgsql - 1.6.2-3.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: libpqxx-2.6.8.so()(64bit) package: koffice-kexi-driver-pgsql - 1.6.2-3.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libpqxx-2.6.8.so()(64bit) ====================================================================== New report for: petersen AT redhat.com package: emacspeak - 26-1.fc8.noarch from rawhide-development-ppc64 unresolved deps: /usr/bin/tcl package: emacspeak - 26-1.fc8.noarch from rawhide-development-ppc unresolved deps: /usr/bin/tcl package: emacspeak - 26-1.fc8.noarch from rawhide-development-x86_64 unresolved deps: /usr/bin/tcl package: emacspeak - 26-1.fc8.noarch from rawhide-development-i386 unresolved deps: /usr/bin/tcl ====================================================================== New report for: shahms AT shahms.com package: python-paramiko - 1.6.4-1.fc7.noarch from rawhide-development-ppc64 unresolved deps: python-crypto >= 0:1.9 ====================================================================== New report for: kwizart AT gmail.com package: lcdproc - 0.5.2-1.fc8.i386 from rawhide-development-i386 unresolved deps: perl(Geo::METAR) package: lcdproc - 0.5.2-1.fc8.ppc from rawhide-development-ppc unresolved deps: perl(Geo::METAR) package: lcdproc - 0.5.2-1.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: perl(Geo::METAR) package: lcdproc - 0.5.2-1.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: perl(Geo::METAR) ====================================================================== New report for: orion AT cora.nwra.com package: python-basemap - 0.9.5-1.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: python-matplotlib >= 0:0.81 ====================================================================== New report for: rvokal AT redhat.com package: resapplet - 0.1.1-5.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: system-config-display ====================================================================== New report for: misa AT redhat.com package: python-docs - 2.5-1.fc7.noarch from rawhide-development-ppc64 unresolved deps: python = 0:2.5 package: python-docs - 2.5-1.fc7.noarch from rawhide-development-ppc unresolved deps: python = 0:2.5 package: python-docs - 2.5-1.fc7.noarch from rawhide-development-x86_64 unresolved deps: python = 0:2.5 package: python-docs - 2.5-1.fc7.noarch from rawhide-development-i386 unresolved deps: python = 0:2.5 ====================================================================== New report for: cbalint AT redhat.com package: gdal - 1.4.1-3.fc7.i386 from rawhide-development-x86_64 unresolved deps: libdapserver.so.2 package: gdal - 1.4.1-3.fc7.i386 from rawhide-development-i386 unresolved deps: libdapserver.so.2 package: gdal - 1.4.1-3.fc7.ppc from rawhide-development-ppc unresolved deps: libdapserver.so.2 package: gdal - 1.4.1-3.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: libdapserver.so.2()(64bit) package: gdal - 1.4.1-3.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libdapserver.so.2()(64bit) ====================================================================== New report for: fedora AT leemhuis.info package: gsynaptics - 0.9.11-1.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: synaptics ====================================================================== Summary of broken packages (by owner): Axel.Thimm AT ATrpms.net freenx - 0.6.0-12.fc7.ppc64 andreas.bierfert AT lowlatency.de koffice-kexi-driver-pgsql - 1.6.2-3.fc7.i386 koffice-kexi-driver-pgsql - 1.6.2-3.fc7.ppc koffice-kexi-driver-pgsql - 1.6.2-3.fc7.ppc64 koffice-kexi-driver-pgsql - 1.6.2-3.fc7.x86_64 cbalint AT redhat.com gdal - 1.4.1-3.fc7.i386 gdal - 1.4.1-3.fc7.i386 gdal - 1.4.1-3.fc7.ppc gdal - 1.4.1-3.fc7.ppc64 gdal - 1.4.1-3.fc7.x86_64 cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch denis AT poolshark.org brasero - 0.5.2-1.fc7.i386 brasero - 0.5.2-1.fc7.ppc brasero - 0.5.2-1.fc7.x86_64 dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 foolish AT guezz.net gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch gtk-recordmydesktop - 0.3.3.1-4.fc7.noarch gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch glest-data - 2.0.0-2.fc7.noarch showimg-pgsql - 0.9.5-12.fc7.i386 showimg-pgsql - 0.9.5-12.fc7.ppc showimg-pgsql - 0.9.5-12.fc7.ppc64 showimg-pgsql - 0.9.5-12.fc7.x86_64 giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 jdieter AT gmail.com yum-presto - 0.3.10-1.fc8.noarch yum-presto - 0.3.10-1.fc8.noarch yum-presto - 0.3.10-1.fc8.noarch yum-presto - 0.3.10-1.fc8.noarch jonathansteffan AT gmail.com revisor - 2.0.3.6-1.fc8.noarch revisor - 2.0.3.6-1.fc8.noarch jwilson AT redhat.com emerald-themes - 0.2.0-1.fc7.noarch karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 kwizart AT gmail.com lcdproc - 0.5.2-1.fc8.i386 lcdproc - 0.5.2-1.fc8.ppc lcdproc - 0.5.2-1.fc8.ppc64 lcdproc - 0.5.2-1.fc8.x86_64 mbarnes AT redhat.com gnome-python2-totem - 2.18.0-1.fc7.i386 gnome-python2-totem - 2.18.0-1.fc7.ppc gnome-python2-totem - 2.18.0-1.fc7.ppc64 gnome-python2-totem - 2.18.0-1.fc7.x86_64 mdehaan AT redhat.com koan - 0.3.1-2.fc7.noarch misa AT redhat.com python-docs - 2.5-1.fc7.noarch python-docs - 2.5-1.fc7.noarch python-docs - 2.5-1.fc7.noarch python-docs - 2.5-1.fc7.noarch orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 paul AT city-fan.org bittorrent - 4.4.0-5.fc7.noarch petersen AT redhat.com emacspeak - 26-1.fc8.noarch emacspeak - 26-1.fc8.noarch emacspeak - 26-1.fc8.noarch emacspeak - 26-1.fc8.noarch rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 shahms AT shahms.com python-paramiko - 1.6.4-1.fc7.noarch tcallawa AT redhat.com xsupplicant - 1.2.8-1.fc7.1.i386 xsupplicant - 1.2.8-1.fc7.1.ppc xsupplicant - 1.2.8-1.fc7.1.x86_64 thomas AT apestaart.org python-twisted-conch - 0.7.0-4.fc7.ppc64 tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 Democracy - 0.9.5.1-8.fc7.ppc Democracy - 0.9.5.1-8.fc7.ppc64 Democracy - 0.9.5.1-8.fc7.x86_64 ville.skytta AT iki.fi em8300 - 0.16.2-1.fc7.ppc64 kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 kmod-em8300-PAE - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 kmod-em8300-kdump - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 kmod-em8300-smp - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc walters AT redhat.com bigboard - 0.4.0-2.i386 bigboard - 0.4.0-2.ppc bigboard - 0.4.0-2.ppc64 bigboard - 0.4.0-2.x86_64 ====================================================================== Broken packages in rawhide-development-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 bigboard-0.4.0-2.i386 requires hippo-canvas-python >= 0:0.2.16 brasero-0.5.2-1.fc7.i386 requires libtotem-plparser.so.1 emacspeak-26-1.fc8.noarch requires /usr/bin/tcl gdal-1.4.1-3.fc7.i386 requires libdapserver.so.2 gnome-python2-totem-2.18.0-1.fc7.i386 requires libtotem-plparser.so.1 gtk-recordmydesktop-0.3.3.1-4.fc7.noarch requires recordmydesktop = 0:0.3.3.1 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 requires kernel-i586 = 0:2.6.20-1.3104.fc7 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 requires kernel-i686 = 0:2.6.20-1.3104.fc7 kmod-em8300-PAE-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 requires kernel-i686 = 0:2.6.20-1.3104.fc7PAE kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE koffice-kexi-driver-pgsql-1.6.2-3.fc7.i386 requires libpqxx-2.6.8.so lcdproc-0.5.2-1.fc8.i386 requires perl(Geo::METAR) python-docs-2.5-1.fc7.noarch requires python = 0:2.5 showimg-pgsql-0.9.5-12.fc7.i386 requires libpqxx-2.6.8.so xsupplicant-1.2.8-1.fc7.1.i386 requires libiw.so.28 yum-presto-0.3.10-1.fc8.noarch requires deltarpm >= 0:3.4-2 ====================================================================== Broken packages in rawhide-development-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) bigboard-0.4.0-2.ppc64 requires hippo-canvas-python >= 0:0.2.16 bittorrent-4.4.0-5.fc7.noarch requires python-crypto em8300-0.16.2-1.fc7.ppc64 requires em8300-kmod >= 0:0.16.2 emacspeak-26-1.fc8.noarch requires /usr/bin/tcl emerald-themes-0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 emerald-themes-0.2.0-1.fc7.noarch requires beryl-core >= 0:0.2.0 freenx-0.6.0-12.fc7.ppc64 requires nx gdal-1.4.1-3.fc7.ppc64 requires libdapserver.so.2()(64bit) geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-python2-totem-2.18.0-1.fc7.ppc64 requires libtotem-plparser.so.1()(64bit) gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics gtk-recordmydesktop-0.3.3.1-4.fc7.noarch requires recordmydesktop = 0:0.3.3.1 koan-0.3.1-2.fc7.noarch requires syslinux koffice-kexi-driver-pgsql-1.6.2-3.fc7.ppc64 requires libpqxx-2.6.8.so()(64bit) lcdproc-0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 python-docs-2.5-1.fc7.noarch requires python = 0:2.5 python-paramiko-1.6.4-1.fc7.noarch requires python-crypto >= 0:1.9 python-twisted-conch-0.7.0-4.fc7.ppc64 requires python-crypto resapplet-0.1.1-5.fc7.ppc64 requires system-config-display revisor-2.0.3.6-1.fc8.noarch requires livecd-tools rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) showimg-pgsql-0.9.5-12.fc7.ppc64 requires libpqxx-2.6.8.so()(64bit) wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 yum-presto-0.3.10-1.fc8.noarch requires deltarpm >= 0:3.4-2 ====================================================================== Broken packages in rawhide-development-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 bigboard-0.4.0-2.ppc requires hippo-canvas-python >= 0:0.2.16 brasero-0.5.2-1.fc7.ppc requires libtotem-plparser.so.1 emacspeak-26-1.fc8.noarch requires /usr/bin/tcl gdal-1.4.1-3.fc7.ppc requires libdapserver.so.2 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-python2-totem-2.18.0-1.fc7.ppc requires libtotem-plparser.so.1 gtk-recordmydesktop-0.3.3.1-4.fc7.noarch requires recordmydesktop = 0:0.3.3.1 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc requires kernel-ppc = 0:2.6.20-1.3104.fc7 kmod-em8300-smp-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc requires kernel-ppc = 0:2.6.20-1.3104.fc7smp koffice-kexi-driver-pgsql-1.6.2-3.fc7.ppc requires libpqxx-2.6.8.so lcdproc-0.5.2-1.fc8.ppc requires perl(Geo::METAR) python-docs-2.5-1.fc7.noarch requires python = 0:2.5 revisor-2.0.3.6-1.fc8.noarch requires livecd-tools showimg-pgsql-0.9.5-12.fc7.ppc requires libpqxx-2.6.8.so xsupplicant-1.2.8-1.fc7.1.ppc requires libiw.so.28 yum-presto-0.3.10-1.fc8.noarch requires deltarpm >= 0:3.4-2 ====================================================================== Broken packages in rawhide-development-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 bigboard-0.4.0-2.x86_64 requires hippo-canvas-python >= 0:0.2.16 brasero-0.5.2-1.fc7.x86_64 requires libtotem-plparser.so.1()(64bit) emacspeak-26-1.fc8.noarch requires /usr/bin/tcl gdal-1.4.1-3.fc7.i386 requires libdapserver.so.2 gdal-1.4.1-3.fc7.x86_64 requires libdapserver.so.2()(64bit) gnome-python2-totem-2.18.0-1.fc7.x86_64 requires libtotem-plparser.so.1()(64bit) gtk-recordmydesktop-0.3.3.1-4.fc7.noarch requires recordmydesktop = 0:0.3.3.1 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3104.fc7 kmod-em8300-kdump-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3104.fc7kdump kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump koffice-kexi-driver-pgsql-1.6.2-3.fc7.x86_64 requires libpqxx-2.6.8.so()(64bit) lcdproc-0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) python-docs-2.5-1.fc7.noarch requires python = 0:2.5 showimg-pgsql-0.9.5-12.fc7.x86_64 requires libpqxx-2.6.8.so()(64bit) xsupplicant-1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) yum-presto-0.3.10-1.fc8.noarch requires deltarpm >= 0:3.4-2 From dedourek at unb.ca Sun Jun 3 12:06:35 2007 From: dedourek at unb.ca (John DeDourek) Date: Sun, 03 Jun 2007 09:06:35 -0300 Subject: [Fwd: Fedora Core 6 Update: lftp-3.5.9-0.fc6] In-Reply-To: <1180750284.6346.3.camel@tuxhugs> References: <465ED601.1000705@unb.ca> <1180750284.6346.3.camel@tuxhugs> Message-ID: <4662AECB.8020000@unb.ca> Peter Gordon wrote: > On Thu, 2007-05-31 at 11:04 -0300, John DeDourek wrote: > >> The attached announcement for lftp, version 3.5.9, release 0.fc6 >> was received yesterday. However, my yum.log file on my FC6 box >> shows an update to lftp.i386.3.5.9-8.fc6 on Apr 13, 2007. Yum >> did not update lftp today (May 31). >> >> I am confused. What have I missed? >> > > It's probably a mishap with the update notifications or your mail > server. The notification lists a date of April 4, which means this is > nearly two months old and can be safely ignored so late after the fact. > Ah yes. I guess it was a late update notification. However, not a mishap on my mailserver. I read the update announcements at RedHat's site: https://www.redhat.com/archives/fedora-package-announce/2007-May/date.html And this https://www.redhat.com/archives/fedora-package-announce/2007-May/msg00052.html is listed as a May 30 update notification. So I guess it was their mail server (or other) mishap. :0) From jwboyer at jdub.homelinux.org Sun Jun 3 12:03:42 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 07:03:42 -0500 Subject: proposal: new guidelines for rule makers In-Reply-To: <46627A86.3040601@hhs.nl> References: <466129A1.7010805@hhs.nl> <46612B94.8020409@fedoraproject.org> <46620BB1.6020208@hhs.nl> <1180833617.3218.18.camel@vader.jdub.homelinux.org> <46627A86.3040601@hhs.nl> Message-ID: <1180872222.3218.21.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 10:23 +0200, Hans de Goede wrote: > Josh Boyer wrote: > > On Sun, 2007-06-03 at 02:30 +0200, Hans de Goede wrote: > >> Rahul Sundaram wrote: > >>> Hans de Goede wrote: > >>>> Hi all, > >>>> > >>>> > >>>> > >>>> Since those making packaging guidelines and other rules seem to be out > >>>> of touch with the workfloor these days I would like to propose the > >>>> following guideline for rulemakers: > >>>> > >>>> Those making guidelines / rules within the Fedora project must > >>>> actively maintain atleast 30 packages. > >>>> > >>>> Rationale: How can one make rules if one isn't involved in that which > >>>> is regulated oneself? > >>>> > >>>> > >>> Packaging guidelines also cover licensing details which isn't connected > >>> to workflow. There are several other policies within the guidelines > >>> which involve some amount of politics (kernel modules anyone?). This > >>> rule would mean that everybody who proposes any drafts, folks in the > >>> packaging committee and FESCo would have to maintain 30 packages. > >>> > >> Yes it would, and that would be a good thing! Let the people building the > >> distro decide how it is build! As for licensing issues, since RH is paying > >> mosts of the bills at the end RH decided what is okay licensing wise, and to me > >> they have earned that right, because "paying the bills" == "building the distro" > > > > I don't want to misinterpret what you're saying here, so I'll ask you > > straight out. > > > > Are you suggesting that because I do not maintain 30 packages I am > > unqualified to be a member of FESCo? > > > > You're taking me to serious here, notice the at the top of the original > post. Well, you had ended the before the suggestion so I wasn't sure :). > I've no intention to actually try and instantiate such a rule. I'm > however woried that there seems to be a growing drift between the rule makers > within Fedora and those running the primary process. I see. That is a valid concern, and one which I believe everyone wants to address now that F7 is out and people aren't running and screaming about getting it done :) josh From jwboyer at jdub.homelinux.org Sun Jun 3 12:04:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 07:04:58 -0500 Subject: Don't put new packages through updates-testing In-Reply-To: <1180857282.25232.145.camel@pmac.infradead.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <1180806380.25232.137.camel@pmac.infradead.org> <1180821475.3218.1.camel@vader.jdub.homelinux.org> <1180857282.25232.145.camel@pmac.infradead.org> Message-ID: <1180872298.3218.23.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 08:54 +0100, David Woodhouse wrote: > On Sat, 2007-06-02 at 16:57 -0500, Josh Boyer wrote: > > If this is desired, we should start a simple wiki page that package > > maintainers can add requests to for their packages. I don't want to > > bulk handle anything without the maintainers' input. > > Someone already _did_ such things without the maintainers' consent -- my > packages have ACLs where they didn't have them before. Please, do it the > other way round and let maintainers _ask_ for ACLs if they actually want > them. And make them give a _good_ reason too, not just "no teamwork here > please". Yes, I understand that. You know you can remove them right? josh From gauret at free.fr Sun Jun 3 12:39:26 2007 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 03 Jun 2007 14:39:26 +0200 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 References: <20070602224130.1229.76138@extras64.linux.duke.edu> Message-ID: > glest-data - 2.0.0-2.fc7.noarch > glest-data - 2.0.0-2.fc7.noarch glest-data are the data files for the glest game, which does not build on PPC (and is ExcludeArch'ed there, see https://bugzilla.redhat.com/219540). IIRC, it is not possible to add ExcludeArch to a Noarch package. Is it still the case ? If it still breaks, what should I do ? Thanks Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Quand on pense qu'il suffirait que les gens n'ach?tent pas pour que ?a ne se vende plus ! " -- Coluche From jkeating at redhat.com Sun Jun 3 12:53:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 08:53:37 -0400 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 In-Reply-To: <46629B3E.5000102@leemhuis.info> References: <20070602224130.1229.76138@extras64.linux.duke.edu> <46629B3E.5000102@leemhuis.info> Message-ID: <200706030853.38182.jkeating@redhat.com> On Sunday 03 June 2007 06:43:10 Thorsten Leemhuis wrote: > @rel-eng: please remove gsynaptics from the PPC64 devel tree until > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242323 (synaptics > missing for ppc64) is solved somehow. > > I assume packages from the released tree for F7 are not removed even if > broken? Then I'll likely have to ignore that report until above bug is > solved somehow. > > CU > knurd > > /me for doesn't add a "ExcludeArch: ppc64" to gsynaptics in the hope to > get a reply to the bug soon We don't remove things from the release tree. Why wouldn't you just exclude for now instead of dropping the package all together? Work on the 242323 bug as best you can and once it's done re-enable ppc64? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 12:56:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 08:56:16 -0400 Subject: Change to U.T.C. based release times In-Reply-To: <4661C887.9010405@benl.co.uk> References: <4661C46D.5070105@benl.co.uk> <200706021531.40892.jkeating@redhat.com> <4661C887.9010405@benl.co.uk> Message-ID: <200706030856.16676.jkeating@redhat.com> On Saturday 02 June 2007 15:44:07 Benjamin Lewis wrote: > It is the fact that, due to D.S.T., there are _two_ U.T.C. times that > bothers me, hence imho we should move to an U.T.C. based time. > And no, I don't think you missed any. By doing that it means we jitter the time for every place that does DST, not a good tradeoff IMHO. The time is going to change, either the UTC reference time or your local time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 12:57:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 08:57:17 -0400 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 In-Reply-To: References: <20070602224130.1229.76138@extras64.linux.duke.edu> Message-ID: <200706030857.17685.jkeating@redhat.com> On Sunday 03 June 2007 08:39:26 Aurelien Bompard wrote: > IIRC, it is not possible to add ExcludeArch to a Noarch package. Is it > still the case ? If it still breaks, what should I do ? You can excludearch a noarch. The Fedora 7 and higher compose tools understand that, as ugly as it is. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 12:58:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 08:58:33 -0400 Subject: pungi error In-Reply-To: <20070603060025.GA13719@eeyore.32.boerneef.vornavalley> References: <20070603060025.GA13719@eeyore.32.boerneef.vornavalley> Message-ID: <200706030858.33755.jkeating@redhat.com> On Sunday 03 June 2007 02:00:25 Neil Thompson wrote: > This happens with the pungi stalled with F7 as well as pungi-0.3.7-1 pulled > from updates-testing. ?Any ideas? Are you composing i386 on an i386 or x86_64 on an x86_64 or are you doing some cross thing like i386 on an x86_64 or x86_64 on an i386 (or ppc)? Due to anaconda tools, composes must happen on the same arch. You can use things like mock and setarch i386 to be able to compose i386 on x86_64, but not the opposite. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 13:00:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:00:49 -0400 Subject: Summary - Broken dependencies in Fedora Everything development - 2007-06-03 In-Reply-To: <20070603115956.21266.18897@extras64.linux.duke.edu> References: <20070603115956.21266.18897@extras64.linux.duke.edu> Message-ID: <200706030900.49763.jkeating@redhat.com> On Sunday 03 June 2007 07:59:56 Fedora Extras repoclosure wrote: > New report for: misa AT redhat.com > > package: python-docs erm, we need to get this reassigned. Any takers? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 13:03:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:03:28 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> References: <46601BAF.8000507@hhs.nl> <20070602230119.ee4d77d6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706030903.28468.jkeating@redhat.com> On Saturday 02 June 2007 17:01:19 Michael Schwendt wrote: > That's impracticable, because as a sponsor I would like to be able to "go > in" any time and apply changes without having to request assistance from a > cvs admin first. This has worked before without anyone complaining, ever. There is a simple solution. Work with the cvs acl setting scripts and with packageDB so that by default owner _and_ sponsor have access to packages. This is merely a technical problem. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sun Jun 3 13:09:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 15:09:43 +0200 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 In-Reply-To: <200706030853.38182.jkeating@redhat.com> References: <20070602224130.1229.76138@extras64.linux.duke.edu> <46629B3E.5000102@leemhuis.info> <200706030853.38182.jkeating@redhat.com> Message-ID: <4662BD97.4030900@leemhuis.info> On 03.06.2007 14:53, Jesse Keating wrote: > On Sunday 03 June 2007 06:43:10 Thorsten Leemhuis wrote: >> @rel-eng: please remove gsynaptics from the PPC64 devel tree until >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242323 (synaptics >> missing for ppc64) is solved somehow. >> >> I assume packages from the released tree for F7 are not removed even if >> broken? Then I'll likely have to ignore that report until above bug is >> solved somehow. >> >> CU >> knurd >> >> /me for doesn't add a "ExcludeArch: ppc64" to gsynaptics in the hope to >> get a reply to the bug soon > > We don't remove things from the release tree. I expected that. Then this will be broken until a synaptics for ppc64 shows up (if that happens) in Fedora 7 updates. That's life. BTW, why wasn't this PPC64 problem found earlier? Wasn't repoclosure run for ppc64? Do we expect that to be a problem that only happens due to the new ppc64 tree or is there anything we should do to prevent similar stuff in the future? > Why wouldn't you just exclude for now instead of dropping the package all > together? Work on the 242323 bug as best you can and once it's done > re-enable ppc64? Well, I could do that for devel, then the ppc64 version would vanish. But rebuilding something just to get rid of something never should have been build sounds crazy when those with access to the repo can do a simple "rm foo". It's devel in any case; waiting some days might be the best for now. CU thl From jwboyer at jdub.homelinux.org Sun Jun 3 13:05:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 08:05:37 -0500 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180860616.12595.538.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <46626443.6020804@leemhuis.info> <1180856317.12595.498.camel@mccallum.corsepiu.local> <46627AAB.90406@leemhuis.info> <1180860616.12595.538.camel@mccallum.corsepiu.local> Message-ID: <1180875937.3218.26.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 10:50 +0200, Ralf Corsepius wrote: > On Sun, 2007-06-03 at 10:24 +0200, Thorsten Leemhuis wrote: > > > > On 03.06.2007 09:38, Ralf Corsepius wrote: > > > On Sun, 2007-06-03 at 08:48 +0200, Thorsten Leemhuis wrote: > > > > > >> Further: I don't blame the current situation is FESCo's fault (?,?) > > > It's definitely not their fault alone, but there can't be any doubt they > > > share their part of guilt. > > > > Well, we all likely share a part. > Right, and I don't think there is anything wrong with it, we are all > imperfect humans and we all make mistakes and oversights. > > > We all could have yelled louder if we > > wanted; it might have changed some things here and there. But I for one > > kept mostly quiet until now as I was willing to accept some bumpy time > > to get the merge done for F7. But F7 is out now, so now we need to get > > things in a better shape again. > > > > I'm actually *wondering* if we should have a "spare time packagers > > committee" (or something like that) that represents the packagers that > > do their package maintenance work in their spare time. They afaics > > sometimes simply don't have the time and the power to get their opinion > > heard without investing even more of their rare spare time. > Well, as I repeated said: I consider FESCo to be some sort of parliament > constituting of representatives and not to be a "board of directors" or > an administration. > > > > One aspect: They allowed things to happen the way they happened and did > > > not intervene when things began to derail. > > > > > > A question closely related to this: Would have FESCo been in a position > > > to intervene? I am inclined to think no. > > > > I'm inclined to think "yes, if they wanted to". > ... the later half is the interesting part: I think, executive and > legislative organs are too closely linked in FESCo. > > In other words, I think, current FESCo is not able to "monitor", because > the "persons to monitor" are largely identical to "those to be > monitored". > > > > The real decisions are taken elsewhere. > Let me try to clarify: I am not referring to "technical committees" > working out details (under a Fedora Governments direction/supervision), > I am referring to non-technical, strategic decisions. > > Trying to project this on real world governments: > * It's a government's job to decide upon "tax increases", not the "tax > authorities". It's the tax authorities' job to work out (technical) > details and the government's job to ratify them. > * It's the government's job to decide upon "immigration regulations", > not the "immigration office's". It's the "immigration offices' job to > work out details and the government's job to ratify them. > > > Well, that's why I'm urging the board to clarify the work areas for the > > Board and FESCo. > > > That is lingering around for months now (see > > fab-archives) and it seems everyone has different expectations in that > > area. > > I _did_ notice your posting and was waiting for FAB's and FESCO's > voices. Their (non-) reaction to me is a strong indication for my claims > above to be true. Silence does not equal agreement. I've been quite busy and haven't found the time to writeup a response to Thorsten's email. His is an email that requires a bit more than a few sentences, so I want to write a response correctly. josh From jkeating at redhat.com Sun Jun 3 13:10:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:10:38 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <20070603093240.GD2826@free.fr> References: <46613791.5030809@fedoraproject.org> <1180861100.3442.17.camel@rousalka.dyndns.org> <20070603093240.GD2826@free.fr> Message-ID: <200706030910.38833.jkeating@redhat.com> On Sunday 03 June 2007 05:32:40 Patrice Dumas wrote: > Of course, but the right way to handle that is not by coming in the way > of those who really know better, but by educating those who think they > know better. History has proven to me that this is a losing battle. There is always somebody or some group of somebodies that "just didn't notice" that there was a freeze on, or "just didn't think" that their change would disrupt large sets of packages. Look, I don't even come close to thinking that the workflow we used for Fedora 7 freeze was ideal. Far from it. I stated as much when I posted about it. However it was a workflow that many current maintainers (former Core ones) were familiar with, and one that I was confident would allow Fedora 7 to be released without too much trouble. Now I'm more than willing to discuss new and better ways of managing freezes with these new tools at our disposal. By no means is the Fedora 7 way the way of the future. Lets have a series of rel-eng meetings with anybody who wants to come along to discuss better ways of handling freezes, and report our proposals to FESCO for ratification. We meet every Monday. http://fedoraproject.org/wiki/ReleaseEngineering -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 13:13:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:13:21 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180860616.12595.538.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <46627AAB.90406@leemhuis.info> <1180860616.12595.538.camel@mccallum.corsepiu.local> Message-ID: <200706030913.21832.jkeating@redhat.com> On Sunday 03 June 2007 04:50:15 Ralf Corsepius wrote: > I _did_ notice your posting and was waiting for FAB's and FESCO's > voices. Their (non-) reaction to me is a strong indication for my claims > above to be true. It was posted on a Friday afternoon here in the US, the Friday of a release week where most people involved in Fedora would be spending the weekend doing nothing related to Fedora or computers in general. Please give it a bit more time before confirming your conspiracy theories. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 13:17:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:17:11 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <46626443.6020804@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> Message-ID: <200706030917.12070.jkeating@redhat.com> On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: > Well, see all those discussion that happened when ACLs were added, kjoi > introduced, the freezes were introduced and bodi put in place. Sure, > there are always discussions, but all those were quite worse and there > was a lot of confusion afaics... Don't read fedora-maintainers for a > week and suddenly you are not aware of how to build or push a package. So without reading the mailing list for maintainers, nor reading wiki pages that were put up, how do you expect people to notice changes? Should we keep track of phone numbers and start war dialing? Email bomb people's inboxes? A lot of the "surprised" people were people that just tried to do things as normal and found that there were changes. Then instead of looking through the list for them or the wiki pages, they just posted and said "WHO CHANGED MY STUFF! REGRESSION!" Seriously I think it's rather impossible to make a change and have people be prepared for that change if said people never read appropriate mailing lists or monitor wiki pages. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Jun 3 13:23:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 Jun 2007 18:53:29 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <46620EE5.6030707@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> <46620EE5.6030707@hhs.nl> Message-ID: <4662C0D1.8000803@fedoraproject.org> Hans de Goede wrote: > Which sure does NOT cover basic functionality. First please get a clue > about what we are talking about (by say packaging 30 packages?) and then > return to this discussion. > > Thank you for first getting a clue, No thanks to you or Ralf for insulting your fellow contributors and showing the your "joke" claim wasn't really a joke after all. If you want to prevent me or anyone from suggesting anything at all before we start packaging a arbitrary number of 30 packages that isn't going to happen. Distribution building is more than packaging. It involves everything from documentation, translation to infrastructure work and lots more. We are all contributors in different areas. Keep that mind. Rahul From sundaram at fedoraproject.org Sun Jun 3 13:24:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 Jun 2007 18:54:32 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <46620DAB.1000506@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <466128DC.5050000@hhs.nl> <46612F84.9080700@fedoraproject.org> <46620DAB.1000506@hhs.nl> Message-ID: <4662C110.1080306@fedoraproject.org> Hans de Goede wrote: > Rahul Sundaram wrote: >> Hans de Goede wrote: >> >>> >>> Exactly, there are very good reasons why this is a SHOULD and not a >>> MUST. I'm sure almost every reviewer will give a program a test run >>> in the simple program case / scenarion. Why must everything by >>> regulated with rules, procedures and more rules? Why can't we just >>> TRUST each other, >> >> We need to coordinate and not everyone has the same understanding of >> what is required in a review. New packagers have explicitly asked >> before for more guidelines. If you believe that every reviewer already >> tests the simple program case then there shouldn't any problem in >> documenting that. >> > Well since we've just written about it, it now is documented. No need to > change the guidelines. No. Mailing lists posts don't constitute proper documentation. Rahul From j.w.r.degoede at hhs.nl Sun Jun 3 13:22:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 15:22:57 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706030910.38833.jkeating@redhat.com> References: <46613791.5030809@fedoraproject.org> <1180861100.3442.17.camel@rousalka.dyndns.org> <20070603093240.GD2826@free.fr> <200706030910.38833.jkeating@redhat.com> Message-ID: <4662C0B1.9070007@hhs.nl> Jesse Keating wrote: > On Sunday 03 June 2007 05:32:40 Patrice Dumas wrote: >> Of course, but the right way to handle that is not by coming in the way >> of those who really know better, but by educating those who think they >> know better. > > History has proven to me that this is a losing battle. There is always > somebody or some group of somebodies that "just didn't notice" that there was > a freeze on, or "just didn't think" that their change would disrupt large > sets of packages. > > Look, I don't even come close to thinking that the workflow we used for Fedora > 7 freeze was ideal. Far from it. I stated as much when I posted about it. > However it was a workflow that many current maintainers (former Core ones) > were familiar with, and one that I was confident would allow Fedora 7 to be > released without too much trouble. Now I'm more than willing to discuss new > and better ways of managing freezes with these new tools at our disposal. By > no means is the Fedora 7 way the way of the future. Lets have a series of > rel-eng meetings with anybody who wants to come along to discuss better ways > of handling freezes, and report our proposals to FESCO for ratification. We > meet every Monday. http://fedoraproject.org/wiki/ReleaseEngineering > I'm not so sure all the noise is about the freeze procedure, I for one was quite happy with the freeze procedure (no complaints there). My problems are with the lengthy updates procedure, as we can see it shaping up through bodhi. I think a good start would be for rel-eng to actually write down how they want this to work and why (without taking body into account please, first lets write a piece how this would ideally look). So far I have seen no policy with regards to updates just a tool which involves lots of additional steps, without any policy giving that tool a right of existence, its like creating a police force without first creating the laws which they should uphold. So please write a documents how updates should be managed / release engineered (and the current bodhi FAQ-ish document is not that IMHO), get this document discussed and ratified, and then see what this means for bodhi in the long run. For now we can use bodhi as is, as we need something, but for the future I would like to see a proper decission making process surrounding updates policy, with all the steps taken in the right order (and thus with the tool implementing the policy coming last, after the policy has first been written on paper, discussed and approved by the appropriate gremia). Regards, Hans From j.w.r.degoede at hhs.nl Sun Jun 3 13:27:50 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 15:27:50 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706030917.12070.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> Message-ID: <4662C1D6.8020108@hhs.nl> Jesse Keating wrote: > On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: >> Well, see all those discussion that happened when ACLs were added, kjoi >> introduced, the freezes were introduced and bodi put in place. Sure, >> there are always discussions, but all those were quite worse and there >> was a lot of confusion afaics... Don't read fedora-maintainers for a >> week and suddenly you are not aware of how to build or push a package. > > So without reading the mailing list for maintainers, nor reading wiki pages > that were put up, how do you expect people to notice changes? Should we keep > track of phone numbers and start war dialing? Email bomb people's inboxes? > A lot of the "surprised" people were people that just tried to do things as > normal and found that there were changes. Then instead of looking through > the list for them or the wiki pages, they just posted and said "WHO CHANGED > MY STUFF! REGRESSION!" Seriously I think it's rather impossible to make a > change and have people be prepared for that change if said people never read > appropriate mailing lists or monitor wiki pages. > > Thats not entirely fair. There is a loots of traffic on the maintainers / developer lists and much of the needed information is hidden deep down in subject wise only semi or irrelevant threads. There have been little clear announcements of changes, and when they were there the info was far from complete. As for the wiki that is currently very much out of sync with how things are done in the merged world / out of sync with reality. Regards, Hans From ben.lewis at benl.co.uk Sun Jun 3 13:30:02 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Sun, 03 Jun 2007 14:30:02 +0100 Subject: Change to U.T.C. based release times In-Reply-To: <200706030856.16676.jkeating@redhat.com> References: <4661C46D.5070105@benl.co.uk> <200706021531.40892.jkeating@redhat.com> <4661C887.9010405@benl.co.uk> <200706030856.16676.jkeating@redhat.com> Message-ID: <4662C25A.4090403@benl.co.uk> Jesse Keating wrote: > On Saturday 02 June 2007 15:44:07 Benjamin Lewis wrote: > >> It is the fact that, due to D.S.T., there are _two_ U.T.C. times that >> bothers me, hence imho we should move to an U.T.C. based time. >> And no, I don't think you missed any. >> > > By doing that it means we jitter the time for every place that does DST, not a > good tradeoff IMHO. The time is going to change, either the UTC reference > time or your local time. I understand that, but imho local jitter is better than global jitter. Just about everyone knows their offset from UTC, DST or no DST. I know the wiki has the infomation regarding the UTC times from Eastern, but very often this isn't what people - me included - are told when they ask. If I was given an UTC time then there would have been _no_ confusion. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Sun Jun 3 13:29:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:29:29 -0400 Subject: Change to U.T.C. based release times In-Reply-To: <4662C25A.4090403@benl.co.uk> References: <4661C46D.5070105@benl.co.uk> <200706030856.16676.jkeating@redhat.com> <4662C25A.4090403@benl.co.uk> Message-ID: <200706030929.29712.jkeating@redhat.com> On Sunday 03 June 2007 09:30:02 Benjamin Lewis wrote: > I understand that, but imho local jitter is better than global jitter. > Just about everyone knows their offset from UTC, DST or no DST. I know > the wiki has the infomation regarding the UTC times from Eastern, but > very often this isn't what people - me included - are told when they > ask. If I was given an UTC time then there would have been _no_ confusion. They _are_ given in a UTC time. That UTC time may be one hour later / earlier depending on the time of the year, but it is still listed in UTC and you're still able to convert from UTC to your local time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 13:32:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:32:41 -0400 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 In-Reply-To: <4662BD97.4030900@leemhuis.info> References: <20070602224130.1229.76138@extras64.linux.duke.edu> <200706030853.38182.jkeating@redhat.com> <4662BD97.4030900@leemhuis.info> Message-ID: <200706030932.42009.jkeating@redhat.com> On Sunday 03 June 2007 09:09:43 Thorsten Leemhuis wrote: > BTW, why wasn't this PPC64 problem found earlier? Wasn't repoclosure run > for ppc64? Do we expect that to be a problem that only happens due to > the new ppc64 tree or is there anything we should do to prevent similar > stuff in the future? This happened because Extras never built for ppc64, while Core did. Merge and you get fun. We noticed it once before, but it slipped our collective minds until after the merge happened and we started doing builds. The only reasonable recourse then was to try and bootstrap as much of Extras on ppc64 as possible and fix the remainders as we go forward. It's not like the ppc64 repos really get that much use, in fact until this release we never did a full ppc64 release tree. There was rawhide but that was it. > > Why wouldn't you just exclude for now instead of dropping the package all > > together? ?Work on the 242323 bug as best you can and once it's done > > re-enable ppc64? > > Well, I could do that for devel, then the ppc64 version would vanish. > But rebuilding something just to get rid of something never should have > been build sounds crazy when those with access to the repo can do a > simple "rm foo". > > It's devel in any case; waiting some days might be the best for now. Since rawhide is composed automatically nightly, physically removing the ppc64 package today would only result in it coming back tomorrow. The proper solution is to add the ExcludeArch so that it won't get picked up in future composes until the problem is fixed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sun Jun 3 13:34:56 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 15:34:56 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <4662C0D1.8000803@fedoraproject.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> <46620EE5.6030707@hhs.nl> <4662C0D1.8000803@fedoraproject.org> Message-ID: <4662C380.30102@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: > >> Which sure does NOT cover basic functionality. First please get a clue >> about what we are talking about (by say packaging 30 packages?) and >> then return to this discussion. >> >> Thank you for first getting a clue, > > No thanks to you or Ralf for insulting your fellow contributors and > showing the your "joke" claim wasn't really a joke after all. If you > want to prevent me or anyone from suggesting anything at all before we > start packaging a arbitrary number of 30 packages that isn't going to > happen. > The 30 packages part was not serious, it was an example. The getting a clue part is not a joke, if you do not understand what Ralf means with a simple program start (without any cmdline arguments) for many programs will only result in a usage message, and then claim that getting the usage message covers testing basic functionality, then you do not know what you're talking about. Ever heard of coverage percentages for software tests? Only getting the usage() message scores you about 1 to 0.1 % of coverage for a small program (and then I'm being very optimistic), even less for a larger one. > Distribution building is more than packaging. It involves everything > from documentation, translation to infrastructure work and lots more. We > are all contributors in different areas. Keep that mind. > I know that and I very much value and appreciate all the work done by documenters, tranlaters, the infra structure team and all I forget. However I'm not participating in discussions about translations as I know very little about translations. Learn to know you're own weakness-es, and if you have little knowledge of something, then don't mingle yourself in discussions about it. Atleast so far you've shown little knowledge of testing. Regards, Hans From fedora at leemhuis.info Sun Jun 3 13:36:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 15:36:28 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706030917.12070.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> Message-ID: <4662C3DC.7010906@leemhuis.info> On 03.06.2007 15:17, Jesse Keating wrote: > On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: >> Well, see all those discussion that happened when ACLs were added, kjoi >> introduced, the freezes were introduced and bodi put in place. Sure, >> there are always discussions, but all those were quite worse and there >> was a lot of confusion afaics... Don't read fedora-maintainers for a >> week and suddenly you are not aware of how to build or push a package. > So without reading the mailing list for maintainers, A low-traffic fedora-maintainers-announce was requested multiple times as some contributors mentioned that fedora-maintainers is to noisy for them. Some Red-Hat-engineers blocked that so long and hard that people that wanted it got frustrated and didn't drive that idea further in the past months. Like it or not, but for some people fedora-maintainers has to much traffic; so they just skim over it and easily miss important announcements. > [...] BTW, we are getting side-tracked. I didn't want to bring the fedora-maintainers-announce stuff into the game. I meant the lack of proper docs, rules and procedure for the start of some of those techniques needed for the merge as the problem. Cu thl From jkeating at redhat.com Sun Jun 3 13:35:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:35:52 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <4662C0B1.9070007@hhs.nl> References: <46613791.5030809@fedoraproject.org> <200706030910.38833.jkeating@redhat.com> <4662C0B1.9070007@hhs.nl> Message-ID: <200706030935.52450.jkeating@redhat.com> On Sunday 03 June 2007 09:22:57 Hans de Goede wrote: > So please write a documents how updates should be managed / release > engineered (and the current bodhi FAQ-ish document is not that IMHO), get > this document discussed and ratified, and then see what this means for > bodhi in the long run. > > For now we can use bodhi as is, as we need something, but for the future I > would like to see a proper decission making process surrounding updates > policy, with all the steps taken in the right order (and thus with the tool > implementing the policy coming last, after the policy has first been > written on paper, discussed and approved by the appropriate gremia). I'm not comfortable with just writing a document. In Core, we had a tool, and pretty much everything was left up to maintainers and what the tool would allow. Now, I would love to have discussions with interested parties (including yourself) on how policy should work so that the tool can adjust. The current tool is largely a mirror of what we were using internally (with a couple things missing yet) as we had nothing else for Luke to work with. There was either the internal tool, or the policyless uncontrolled chaos of Extras. We need to come up with something. Please join the next Release Engineering meeting to help us discuss this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ben.lewis at benl.co.uk Sun Jun 3 13:39:56 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Sun, 03 Jun 2007 14:39:56 +0100 Subject: Change to U.T.C. based release times In-Reply-To: <200706030929.29712.jkeating@redhat.com> References: <4661C46D.5070105@benl.co.uk> <200706030856.16676.jkeating@redhat.com> <4662C25A.4090403@benl.co.uk> <200706030929.29712.jkeating@redhat.com> Message-ID: <4662C4AC.6050705@benl.co.uk> Jesse Keating wrote: > On Sunday 03 June 2007 09:30:02 Benjamin Lewis wrote: > >> I understand that, but imho local jitter is better than global jitter. >> Just about everyone knows their offset from UTC, DST or no DST. I know >> the wiki has the infomation regarding the UTC times from Eastern, but >> very often this isn't what people - me included - are told when they >> ask. If I was given an UTC time then there would have been _no_ confusion. >> > > They _are_ given in a UTC time. That UTC time may be one hour later / earlier > depending on the time of the year, but it is still listed in UTC and you're > still able to convert from UTC to your local time. > I'm not denying that - jitter will occur whatever we do. But I do think an international project should use an international time - Universal Co-ordinated Time. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Sun Jun 3 13:41:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 Jun 2007 19:11:49 +0530 Subject: Don't put new packages through updates-testing In-Reply-To: <4662C380.30102@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> <46620EE5.6030707@hhs.nl> <4662C0D1.8000803@fedoraproject.org> <4662C380.30102@hhs.nl> Message-ID: <4662C51D.6020402@fedoraproject.org> Hans de Goede wrote: > > The 30 packages part was not serious, it was an example. The getting a > clue part is not a joke, Of course, not understanding cryptic messages was my fault. Instead of explaining like you did Ralf was to call people clueless and I wouldn't support that. > I know that and I very much value and appreciate all the work done by > documenters, tranlaters, the infra structure team and all I forget. > However I'm not participating in discussions about translations as I > know very little about translations. Learn to know you're own > weakness-es, and if you have little knowledge of something, then don't > mingle yourself in discussions about it. That does not mean that without being involved with 30 packages one cannot suggest improvements in the guidelines or workflow. Any attempt to restrict this is rather native. > Atleast so far you've shown little knowledge of testing. That explains why I was involved with precisely that in my previous job. Rahul From jkeating at redhat.com Sun Jun 3 13:41:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:41:15 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <4662C1D6.8020108@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706030917.12070.jkeating@redhat.com> <4662C1D6.8020108@hhs.nl> Message-ID: <200706030941.16003.jkeating@redhat.com> On Sunday 03 June 2007 09:27:50 Hans de Goede wrote: > Thats not entirely fair. There is a loots of traffic on the maintainers / > developer lists and much of the needed information is hidden deep down in > subject wise only semi or irrelevant threads. There have been little clear > announcements of changes, and when they were there the info was far from > complete. Every new procedure that I initiated I tried my best to start a new thread with a clear subject on the matter. I see the same things from others, such as "Pushing updates for Fedora 7" thread. This is probably one of the most maddening thing lately, so much complaint about communication with no suggestions on how to make it better. > > As for the wiki that is currently very much out of sync with how things are > done in the merged world / out of sync with reality. And you expect us to change it how? For god sakes if you run into a page that is inaccurate, point it out to somebody, hopefully the person who made it inaccurate by introducing a new policy. Maybe we need a tracker page of 'inaccurate pages'. Don't just expect them to be fixed automagically, point it out to somebody, change it yourself, do something. Don't just grow more and more frustrated finally bitching about it generically on a list in the middle of a long thread. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jun 3 13:50:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 15:50:11 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706030941.16003.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706030917.12070.jkeating@redhat.com> <4662C1D6.8020108@hhs.nl> <200706030941.16003.jkeating@redhat.com> Message-ID: <1180878611.12595.578.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 09:41 -0400, Jesse Keating wrote: > On Sunday 03 June 2007 09:27:50 Hans de Goede wrote: > > As for the wiki that is currently very much out of sync with how things are > > done in the merged world / out of sync with reality. ACK, wiki are moving targets, mushrooming all the time. > And you expect us to change it how? Post to lists, e.g. maintainers@ Ralf From jdieter at gmail.com Sun Jun 3 13:50:08 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 03 Jun 2007 16:50:08 +0300 Subject: Summary - Broken dependencies in Fedora Everything development - 2007-06-03 In-Reply-To: <20070603115956.21266.18897@extras64.linux.duke.edu> References: <20070603115956.21266.18897@extras64.linux.duke.edu> Message-ID: <1180878608.3942.3.camel@jndwidescreen.lesbg.loc> On Sun, 2007-06-03 at 11:59 +0000, Fedora Extras repoclosure wrote: > ====================================================================== > New report for: jdieter AT gmail.com > > package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-ppc64 > unresolved deps: > deltarpm >= 0:3.4-2 > > package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-ppc > unresolved deps: > deltarpm >= 0:3.4-2 > > package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-x86_64 > unresolved deps: > deltarpm >= 0:3.4-2 > > package: yum-presto - 0.3.10-1.fc8.noarch from rawhide-development-i386 > unresolved deps: > deltarpm >= 0:3.4-2 > I'm sorry, I thought deltarpm-3.4-2 had made it into Rawhide. How do I pull a package from Rawhide? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sun Jun 3 13:49:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:49:15 -0400 Subject: Change to U.T.C. based release times In-Reply-To: <4662C4AC.6050705@benl.co.uk> References: <4661C46D.5070105@benl.co.uk> <200706030929.29712.jkeating@redhat.com> <4662C4AC.6050705@benl.co.uk> Message-ID: <200706030949.16166.jkeating@redhat.com> On Sunday 03 June 2007 09:39:56 Benjamin Lewis wrote: > I'm not denying that - jitter will occur whatever we do. But I do think > an international project should use an international time - Universal > Co-ordinated Time. We do. We pick a Universal Co-ordinated Time for each of our releases. That time may not be the same for every release, just like the day may not be the same. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jun 3 13:54:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 15:54:09 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <4662C3DC.7010906@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> Message-ID: <1180878850.12595.583.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: > On 03.06.2007 15:17, Jesse Keating wrote: > > On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: > >> Well, see all those discussion that happened when ACLs were added, kjoi > >> introduced, the freezes were introduced and bodi put in place. Sure, > >> there are always discussions, but all those were quite worse and there > >> was a lot of confusion afaics... Don't read fedora-maintainers for a > >> week and suddenly you are not aware of how to build or push a package. > > So without reading the mailing list for maintainers, > > A low-traffic fedora-maintainers-announce was requested multiple times > as some contributors mentioned that fedora-maintainers is to noisy for > them. One way traffic is inappropriate for a community project. > Like it or not, but for some people fedora-maintainers has to much > traffic; Then they better should not be maintainers! This is Fedora, a wanna-be community project. Community projects live from communication. If you want it to be success, these people will have to leave their secret chambers and crawl into the light ;) > so they just skim over it and easily miss important announcements. If there were any ... Ralf From gemi at bluewin.ch Sun Jun 3 13:57:39 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 03 Jun 2007 15:57:39 +0200 Subject: Packages not signed Message-ID: <1180879060.3995.1.camel@localhost.localdomain> I have received several bug reports about packages from the F7 repository not signed. I presume that I as a package maintainer cannot do anything about it. Is this a known issue? Regards -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From bbbush.yuan at gmail.com Sun Jun 3 14:01:03 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sun, 3 Jun 2007 22:01:03 +0800 Subject: idiots guide to fedora contribution? In-Reply-To: <1180625045.4157.10.camel@eagle.danny.cz> References: <1180625045.4157.10.camel@eagle.danny.cz> Message-ID: <76e72f800706030701p410f460fve540d6cfba91773a@mail.gmail.com> > Neal Becker p??e v ?t 31. 05. 2007 v 10:34 -0400: > > Do I understand correctly that the procedures for updating the packages I > > maintain is changed? Is there a quick guide to the new procedure? (I > > looked a bit at the koji stuff, but I had more questions than answers). > > > Our experience is that you could find yourself a partner who is also maintaining packages, then you two could exchange your findings in fp.o documents and ideas. This let both of you feel easier and work better. Rarely both of you would fail. -- bbbush ^_^ From ben.lewis at benl.co.uk Sun Jun 3 14:02:01 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Sun, 03 Jun 2007 15:02:01 +0100 Subject: Change to U.T.C. based release times In-Reply-To: <200706030949.16166.jkeating@redhat.com> References: <4661C46D.5070105@benl.co.uk> <200706030929.29712.jkeating@redhat.com> <4662C4AC.6050705@benl.co.uk> <200706030949.16166.jkeating@redhat.com> Message-ID: <4662C9D9.2@benl.co.uk> Jesse Keating wrote: > On Sunday 03 June 2007 09:39:56 Benjamin Lewis wrote: > >> I'm not denying that - jitter will occur whatever we do. But I do think >> an international project should use an international time - Universal >> Co-ordinated Time. >> > > We do. We pick a Universal Co-ordinated Time for each of our releases. That > time may not be the same for every release, just like the day may not be the > same. > > What bothers me is the fact that we don't use UTC, we use Eastern Time (either EST or EDT) and get UTC _from_ that. So in fact we pick an Eastern Time time _not_ an UTC time. In any case, the only change would be a matter of one hour so I'm not really concerned anymore - if there is no will to change it I'm prepared to leave it. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Sun Jun 3 14:02:43 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 3 Jun 2007 14:02:43 +0000 (UTC) Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) References: <46601BAF.8000507@hhs.nl> <200706030917.12070.jkeating@redhat.com> <4662C1D6.8020108@hhs.nl> <200706030941.16003.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > And you expect us to change it how? For god sakes if you run into a page > that is inaccurate, point it out to somebody, hopefully the person who made > it inaccurate by introducing a new policy. Maybe we need a tracker page > of 'inaccurate pages'. Don't just expect them to be fixed automagically, > point it out to somebody, change it yourself, do something. Changing inaccurate pages myself as I noticed them is what I did. I fixed "BuildSystemClientSetup", for example. Kevin Kofler From fedora at leemhuis.info Sun Jun 3 14:05:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 16:05:14 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180878850.12595.583.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> <1180878850.12595.583.camel@mccallum.corsepiu.local> Message-ID: <4662CA9A.6050107@leemhuis.info> On 03.06.2007 15:54, Ralf Corsepius wrote: > On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: >> On 03.06.2007 15:17, Jesse Keating wrote: >>> On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: >>>> Well, see all those discussion that happened when ACLs were added, kjoi >>>> introduced, the freezes were introduced and bodi put in place. Sure, >>>> there are always discussions, but all those were quite worse and there >>>> was a lot of confusion afaics... Don't read fedora-maintainers for a >>>> week and suddenly you are not aware of how to build or push a package. >>> So without reading the mailing list for maintainers, >> A low-traffic fedora-maintainers-announce was requested multiple times >> as some contributors mentioned that fedora-maintainers is to noisy for >> them. > One way traffic is inappropriate for a community project. Ralf, I appreciate your opinions. But where did I say that that would mean "One way traffic"? That was and is nowhere written or meant. Just as fedora-extras-commit for example the fedora-maintainers-annouce list would have a reply to another mailing list where those that want to discuss something can discuss it. The plan was actually to subscribe fedora-maintainers to fedora-maintainers-annouce, so announcements show up on both list. >> Like it or not, but for some people fedora-maintainers has to much >> traffic; > Then they better should not be maintainers! > > This is Fedora, a wanna-be community project. Community projects live > from communication. If you want it to be success, these people will have > to leave their secret chambers and crawl into the light ;) Some community members just want to maintain their private pet-package. Those probably do not care if that much if there are two or eight steps to get a package pushed (as long as it's documented somewhere). You on the other hand do and you are right with it. But forcing maintainers to read a high-traffic mailing list just because they want to maintaining one package is likely something they care about. So let's please make package maintaining easy for them, too. > [...] CU knurd From jonathan.underwood at gmail.com Sun Jun 3 14:08:52 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 3 Jun 2007 15:08:52 +0100 Subject: Documentation [Was: The community has lost control... (Was: Re: Don't put new packages through updates-testing)] Message-ID: <645d17210706030708x29ec8bafw6b894985db29245@mail.gmail.com> Hi, I have been following the thread about the slightly chaotic F7 changes to infrastructure etc, and there seems to be agreement on one thing - much of the problems that the community faced stemmed from a lack of communication from the people making the substantial changes and the rest of the community. The rest (or a large part) of the community then perceived breakages and work flow hinderance and got upset and confused. On the positive side, the turnover during F7 was phenomenal and I am sure that the benefits outweigh the disruption by orders of magnitude. But the great news is, it's not too late to really make the most of this. What I believe is needed is a week of consolidated documentation writing. We need the barrier to contribution to Fedora to be orders of magnitude below where it is currently (and it was raised by several during the F7 process due to lack of documentation). So; here's my proposal. Everyone stop non-critical packaging work for a week and write some damn docs and really make the whole packaging and building processes transparent. I have no doubt that people intimately involved with the infrastructure changes are reading this and thinking "but it's all pretty obvious". Well, it is if you've been spending 8 hours a day for weeks working on it. ;) I actually started looking to do this and realized what a mess the current docs are in. Most of the important docs are squirreled away as drafts or personal FAQs. Nothing is finished. It's far too much work for one person. ASIDE: I'm also not convinced that the wiki platform we're using is actually conducice to writing good documentation. It's great for low entry for writing a single page, but it's rubbish for putting together a coherent set of docs. Is there something better we can look at using in the long term (not NOW though, priority number one should be getting some pages written) Anyway, that's my rant. jonathan From jkeating at redhat.com Sun Jun 3 14:10:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:10:01 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180878611.12595.578.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706030941.16003.jkeating@redhat.com> <1180878611.12595.578.camel@mccallum.corsepiu.local> Message-ID: <200706031010.01293.jkeating@redhat.com> On Sunday 03 June 2007 09:50:11 Ralf Corsepius wrote: > > And you expect us to change it how? > > Post to lists, e.g. maintainers@ Isn't that what others are complaining about? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 14:11:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:11:47 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: References: <46601BAF.8000507@hhs.nl> <200706030941.16003.jkeating@redhat.com> Message-ID: <200706031011.47790.jkeating@redhat.com> On Sunday 03 June 2007 10:02:43 Kevin Kofler wrote: > Changing inaccurate pages myself as I noticed them is what I did. I > fixed "BuildSystemClientSetup", for example. Thank you, I appreciate that, a lot! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Sun Jun 3 14:15:14 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 03 Jun 2007 10:15:14 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180860616.12595.538.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <46626443.6020804@leemhuis.info> <1180856317.12595.498.camel@mccallum.corsepiu.local> <46627AAB.90406@leemhuis.info> <1180860616.12595.538.camel@mccallum.corsepiu.local> Message-ID: <1180880114.2809.21.camel@kennedy> On Sun, 2007-06-03 at 10:50 +0200, Ralf Corsepius wrote: > On Sun, 2007-06-03 at 10:24 +0200, Thorsten Leemhuis wrote: > > > That is lingering around for months now (see > > fab-archives) and it seems everyone has different expectations in that > > area. > > I _did_ notice your posting and was waiting for FAB's and FESCO's > voices. Their (non-) reaction to me is a strong indication for my claims > above to be true. Well, I did speak to Thorsten on IRC about it for a while on Thursday, but since I've been fairly swamped with work I haven't had time to reply to the list. Anyway, I'm not really sure if we should delay the election, since we really don't know how long it's going to take to determine the exact responsibilities of FESCo now that the merge occurred. Maybe we could have a statement on the announcement of candidates stating something to the fact the FESCo responsibilities will most likely be changing in the future. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sun Jun 3 14:17:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:17:35 -0400 Subject: Summary - Broken dependencies in Fedora Everything development - 2007-06-03 In-Reply-To: <1180878608.3942.3.camel@jndwidescreen.lesbg.loc> References: <20070603115956.21266.18897@extras64.linux.duke.edu> <1180878608.3942.3.camel@jndwidescreen.lesbg.loc> Message-ID: <200706031017.35376.jkeating@redhat.com> On Sunday 03 June 2007 09:50:08 Jonathan Dieter wrote: > I'm sorry, I thought deltarpm-3.4-2 had made it into Rawhide. ?How do I > pull a package from Rawhide? You can ask rel-eng at fedoraproject.org to block your package from the collection. This is another good task item for the Wiki some place. Anybody want to suggest where this would go? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 3 14:18:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:18:31 -0400 Subject: Packages not signed In-Reply-To: <1180879060.3995.1.camel@localhost.localdomain> References: <1180879060.3995.1.camel@localhost.localdomain> Message-ID: <200706031018.31523.jkeating@redhat.com> On Sunday 03 June 2007 09:57:39 G?rard Milmeister wrote: > I have received several bug reports about packages from the F7 > repository not signed. I presume that I as a package maintainer cannot > do anything about it. Is this a known issue? Yes. I'm planning on signing the unsigned ones in the Everything repos, regenerating repodata, and resyncing to the mirrors on Monday at some point. At this time, all packages in updates and updates-testing on any up to date mirror should be signed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Sun Jun 3 14:28:59 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 3 Jun 2007 16:28:59 +0200 Subject: Summary - Broken dependencies in Fedora Everything 7 - 2007-06-02 In-Reply-To: <4662BD97.4030900@leemhuis.info> References: <20070602224130.1229.76138@extras64.linux.duke.edu> <46629B3E.5000102@leemhuis.info> <200706030853.38182.jkeating@redhat.com> <4662BD97.4030900@leemhuis.info> Message-ID: <20070603162859.a2192f52.mschwendt.tmp0701.nospam@arcor.de> On Sun, 03 Jun 2007 15:09:43 +0200, Thorsten Leemhuis wrote: > BTW, why wasn't this PPC64 problem found earlier? Because communication about ppc64 was very much unprecise. fedora-maintainers has had a few vague threads, but after the latest one in May, it took an unknown time for rawhide to become available. Adding to that, the rawhide report's own broken deps checker was disabled without notice. > Wasn't repoclosure run for ppc64? Not until somebody asked me whether it could be done as a work-around. From jkeating at redhat.com Sun Jun 3 14:23:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:23:31 -0400 Subject: Documentation [Was: The community has lost control... (Was: Re: Don't put new packages through updates-testing)] In-Reply-To: <645d17210706030708x29ec8bafw6b894985db29245@mail.gmail.com> References: <645d17210706030708x29ec8bafw6b894985db29245@mail.gmail.com> Message-ID: <200706031023.31536.jkeating@redhat.com> On Sunday 03 June 2007 10:08:52 Jonathan Underwood wrote: > I actually started looking to do this and realized what a mess the > current docs are in. Most of the important docs are squirreled away as > drafts or personal FAQs. Nothing is finished. It's far too much work > for one person. I agree. What's really needed is a strong individual though to take ownership of organizing the documentation and assigning various folks to produce or clean up the existing bits and rearrange them into the layout decided upon. This may be one of those cases where waiting for a committee to decide on something will just let it spin out of control. Would anybody like to take on this task of ring master for a documentation cleanup rearrangement? I think the start of what we have in PackageMaintainers/ is a great start and probably just needs more direction and love. I might suggest waiting another week or so for traffic to die down a bit so that the wiki isn't so overloaded, and to make sure that the Infrastructure team + Moin folks have finally fixed the Unicode issues. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jun 3 14:28:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 16:28:40 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706031010.01293.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706030941.16003.jkeating@redhat.com> <1180878611.12595.578.camel@mccallum.corsepiu.local> <200706031010.01293.jkeating@redhat.com> Message-ID: <1180880921.12595.608.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 10:10 -0400, Jesse Keating wrote: > On Sunday 03 June 2007 09:50:11 Ralf Corsepius wrote: > > > And you expect us to change it how? > > > > Post to lists, e.g. maintainers@ > > Isn't that what others are complaining about? As I already said, communication is the #1 basis for community-projects and you can't avoid communicating and discussing decisions. This might be inconvenient to @RH's working door-to-door, but you should be aware that most non-RH's door is several 1000miles away from yours, and that you and your @RH collegues probably communicate a lot of details in the "corridor/hallways/staircase" while "passing by". So yes, it will mean overhead, and it will be inconvenient, but such communication is inevitable. maintainers@ to me seems to be the ideal candidate wrt. communicating and discussion "workflow details" because it's subscribers are the audience being directly affected. Ralf From rc040203 at freenet.de Sun Jun 3 14:31:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 16:31:52 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <4662CA9A.6050107@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> <1180878850.12595.583.camel@mccallum.corsepiu.local> <4662CA9A.6050107@leemhuis.info> Message-ID: <1180881112.12595.612.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 16:05 +0200, Thorsten Leemhuis wrote: > On 03.06.2007 15:54, Ralf Corsepius wrote: > > On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: > >> On 03.06.2007 15:17, Jesse Keating wrote: > >>> On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: > >>>> Well, see all those discussion that happened when ACLs were added, kjoi > >>>> introduced, the freezes were introduced and bodi put in place. Sure, > >>>> there are always discussions, but all those were quite worse and there > >>>> was a lot of confusion afaics... Don't read fedora-maintainers for a > >>>> week and suddenly you are not aware of how to build or push a package. > >>> So without reading the mailing list for maintainers, > >> A low-traffic fedora-maintainers-announce was requested multiple times > >> as some contributors mentioned that fedora-maintainers is to noisy for > >> them. > > One way traffic is inappropriate for a community project. > > Ralf, I appreciate your opinions. But where did I say that that would > mean "One way traffic"? I assumed *announce to imply "read only list". Also you know, I am opposed to seeing more list, we already have enough of them - we need less. Ralf From jkeating at redhat.com Sun Jun 3 14:33:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:33:53 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180880921.12595.608.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706031010.01293.jkeating@redhat.com> <1180880921.12595.608.camel@mccallum.corsepiu.local> Message-ID: <200706031033.54125.jkeating@redhat.com> On Sunday 03 June 2007 10:28:40 Ralf Corsepius wrote: > As I already said, communication is the #1 basis for community-projects > and you can't avoid communicating and discussing decisions. > > This might be inconvenient to @RH's working door-to-door, but you should > be aware that most non-RH's door is several 1000miles away from yours, > and that you and your @RH collegues probably communicate a lot of > details in the "corridor/hallways/staircase" while "passing by". > > So yes, it will mean overhead, and it will be inconvenient, but such > communication is inevitable. > > maintainers@ to me seems to be the ideal candidate wrt. communicating > and discussion "workflow details" because it's subscribers are the > audience being directly affected. And that's where much of this has been discussed. The arguments I was talking about was that it was "too much noise" for the "casual packager" to keep up with. Most the things you're complaining about have been discussed either on maintianer's list or on public IRC channels. The Red Hat employees that were involved (as there were non RH employees involved too) work either in different offices or at home anyway, so in the hall conversations were impossible. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Sun Jun 3 14:15:14 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 03 Jun 2007 10:15:14 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180860616.12595.538.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46616EDA.8030007@leemhuis.info> <46626443.6020804@leemhuis.info> <1180856317.12595.498.camel@mccallum.corsepiu.local> <46627AAB.90406@leemhuis.info> <1180860616.12595.538.camel@mccallum.corsepiu.local> Message-ID: <1180880114.2809.21.camel@kennedy> On Sun, 2007-06-03 at 10:50 +0200, Ralf Corsepius wrote: > On Sun, 2007-06-03 at 10:24 +0200, Thorsten Leemhuis wrote: > > > That is lingering around for months now (see > > fab-archives) and it seems everyone has different expectations in that > > area. > > I _did_ notice your posting and was waiting for FAB's and FESCO's > voices. Their (non-) reaction to me is a strong indication for my claims > above to be true. Well, I did speak to Thorsten on IRC about it for a while on Thursday, but since I've been fairly swamped with work I haven't had time to reply to the list. Anyway, I'm not really sure if we should delay the election, since we really don't know how long it's going to take to determine the exact responsibilities of FESCo now that the merge occurred. Maybe we could have a statement on the announcement of candidates stating something to the fact the FESCo responsibilities will most likely be changing in the future. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Sun Jun 3 14:53:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 16:53:39 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706030941.16003.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706030917.12070.jkeating@redhat.com> <4662C1D6.8020108@hhs.nl> <200706030941.16003.jkeating@redhat.com> Message-ID: <4662D5F3.7070206@hhs.nl> Jesse Keating wrote: > On Sunday 03 June 2007 09:27:50 Hans de Goede wrote: >> Thats not entirely fair. There is a loots of traffic on the maintainers / >> developer lists and much of the needed information is hidden deep down in >> subject wise only semi or irrelevant threads. There have been little clear >> announcements of changes, and when they were there the info was far from >> complete. > > Every new procedure that I initiated I tried my best to start a new thread > with a clear subject on the matter. I see the same things from others, such > as "Pushing updates for Fedora 7" thread. This is probably one of the most > maddening thing lately, so much complaint about communication with no > suggestions on how to make it better. > I think the big problem here is time, the merge has been rushed and good documentation has been suffering from this. Ideally when new tools like koji and bodhi get introduced, first some proper documentation and detailed new workflow documents are written (preferably before making / introducing the tool, to allow discussion). However due to the time constrains there has been a serious lack of such documents. I'm not saying that you or anybody's intentions weren't good, and yes mails were send, but with very much incomplete / incomprehensible stuff in them. >> As for the wiki that is currently very much out of sync with how things are >> done in the merged world / out of sync with reality. > > And you expect us to change it how? For god sakes if you run into a page that > is inaccurate, point it out to somebody, hopefully the person who made it > inaccurate by introducing a new policy. Maybe we need a tracker page > of 'inaccurate pages'. Don't just expect them to be fixed automagically, > point it out to somebody, change it yourself, do something. Don't just grow > more and more frustrated finally bitching about it generically on a list in > the middle of a long thread. > Well when the powers that be make radical changes to the workflow I would _atleast_ expect them to update: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess Which is the primary document to consult when you want to introduce a new package, yet there is nothing about bodhi in this document. I do not expect anyone to update all niche pages of the wiki, but is it to much to ask to update a very important often consulted page like: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess When there are workflow changes? Sure in about a week, when I hopefully truely understand how bodhi works, I could edit it myself. But I would expect the people introducing such changes to atleast show some minimal effort to keep the most important pages of the wiki under the PackageMaintainers/ hierarchy up to date. Regards, Hans From fedora at leemhuis.info Sun Jun 3 14:40:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 16:40:36 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180881112.12595.612.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> <1180878850.12595.583.camel@mccallum.corsepiu.local> <4662CA9A.6050107@leemhuis.info> <1180881112.12595.612.camel@mccallum.corsepiu.local> Message-ID: <4662D2E4.5060100@leemhuis.info> On 03.06.2007 16:31, Ralf Corsepius wrote: > On Sun, 2007-06-03 at 16:05 +0200, Thorsten Leemhuis wrote: > > Also you know, I am opposed to seeing more list, Well, I think such a announce list is worth having another one. > we already have enough of them - we need less. Agreed. I still have that on my plate. Still waiting for hardware. Cu knurd From martin.sourada at seznam.cz Sun Jun 3 14:42:13 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 03 Jun 2007 16:42:13 +0200 Subject: PR: thunderbird-enigmail, building own thunderbird inside? Message-ID: <1180881734.3701.19.camel@pc-notebook> Hi, I'd like to take an enigmail review (bz #239336), but there is an issue I'd like to discuss more broadly here. Partial thunderbird build + some files from thunderbird sources are needed for enigmail to be built. These are the very files, IMO, that should go to thunderbird-devel package if there were any. Alas, there isn't, so to build enigmail extension, which has sources about 0.5 MB big and does not take long to build, we need to include thunderbird sources in the spec and build thunderbird there, which makes the srpm much bigger (from less then 1 MB to more than 35 MB), brings issue of duplicit source files in more packages and makes build much longer. I am not quite sure, how to approach this specific issue. Because, as I said, if we do it the way it is done now (in the review request) it would be very ineffective, we cannot add it to thunderbird package itself - that's out of question, it's an extension not necessary part - and that leaves us third way, which has not been trodden yet, I think - make the thunderbird-devel package, which would have all the necessary files in it. Than we would be able to patch the enigmail to build against it. What do you think of it? There are no guidelines yet for packaging firefox/thunderbird extensions, and enigmail, as many of us use it to gpg sign our mails, would be good to have. Thanks, Martin -------------- next part -------------- A non-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 Sun Jun 3 14:41:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:41:51 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <4662D5F3.7070206@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706030941.16003.jkeating@redhat.com> <4662D5F3.7070206@hhs.nl> Message-ID: <200706031041.52080.jkeating@redhat.com> On Sunday 03 June 2007 10:53:39 Hans de Goede wrote: > I do not expect anyone to update all niche pages of the wiki, but is it to > much to ask to update a very important often consulted page like: > http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess > > When there are workflow changes? Sure in about a week, when I hopefully > truely understand how bodhi works, I could edit it myself. But I would > expect the people introducing such changes to atleast show some minimal > effort to keep the most important pages of the wiki under the > PackageMaintainers/ hierarchy up to date. Do be perfectly honest, I didn't know this page really existed. I lost track of all the wiki places things were documented long ago, and since I knew how to do things I never looked it up. I hate to say it, but we need another wiki page (: One that covers the tasks of issuing changes to workflow. Way back when I was a member of a change control board, and there was Representatives from various parts of the company and they would make sure your change draft covered everything they needed, and that would include changing the proper wiki page in this case. Could not FESCO function in this way as well? Changes require a draft, draft would include things like updating the proper wiki pages when the change goes into effect, and things like a rollback plan. Can we discuss this at our next FESCO meeting? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Sun Jun 3 14:59:29 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 03 Jun 2007 10:59:29 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706031041.52080.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <200706030941.16003.jkeating@redhat.com> <4662D5F3.7070206@hhs.nl> <200706031041.52080.jkeating@redhat.com> Message-ID: <1180882769.2809.30.camel@kennedy> On Sun, 2007-06-03 at 10:41 -0400, Jesse Keating wrote: > On Sunday 03 June 2007 10:53:39 Hans de Goede wrote: > > I do not expect anyone to update all niche pages of the wiki, but is it to > > much to ask to update a very important often consulted page like: > > http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess > > > > When there are workflow changes? Sure in about a week, when I hopefully > > truely understand how bodhi works, I could edit it myself. But I would > > expect the people introducing such changes to atleast show some minimal > > effort to keep the most important pages of the wiki under the > > PackageMaintainers/ hierarchy up to date. > > Do be perfectly honest, I didn't know this page really existed. I lost track > of all the wiki places things were documented long ago, and since I knew how > to do things I never looked it up. I hate to say it, but we need another > wiki page (: One that covers the tasks of issuing changes to workflow. Way > back when I was a member of a change control board, and there was > Representatives from various parts of the company and they would make sure > your change draft covered everything they needed, and that would include > changing the proper wiki page in this case. > > Could not FESCO function in this way as well? Changes require a draft, draft > would include things like updating the proper wiki pages when the change goes > into effect, and things like a rollback plan. Can we discuss this at our > next FESCO meeting? Sounds like a good idea. I'll add it to the schedule. Later, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Sun Jun 3 15:00:32 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 3 Jun 2007 15:00:32 +0000 (UTC) Subject: Summary - Broken dependencies in Fedora Everything development - 2007-06-03 References: <20070603115956.21266.18897@extras64.linux.duke.edu> <1180878608.3942.3.camel@jndwidescreen.lesbg.loc> <200706031017.35376.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > This is another good task item for the Wiki some place. Anybody want to > suggest where this would go? Well, Extras had this page: http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests and I added on that page (on May 14, and Michael Schwendt made it even more visible on May 19) that in the Koji world, such requests should go to rel-eng. Kevin Kofler From jkeating at redhat.com Sun Jun 3 15:00:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 11:00:05 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706031041.52080.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <4662D5F3.7070206@hhs.nl> <200706031041.52080.jkeating@redhat.com> Message-ID: <200706031100.05261.jkeating@redhat.com> On Sunday 03 June 2007 10:41:51 Jesse Keating wrote: > Do be perfectly honest, I didn't know this page really existed. FWIW I just added content in there regarding bodhi, as well as reviewed the content for accuracy (made one change), and updated some branch names for F-7. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vnpenguin at vnoss.org Sun Jun 3 15:20:30 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sun, 3 Jun 2007 17:20:30 +0200 Subject: pungi : question about repo Message-ID: Hi all, I have some customized rpm packages which found in my local repo. Theses packages have the same name as original package of F7. How to tell pungi that the package ABC on my local repo should be installed, not ABC of F7 repo ? Thanks, -- http://vnoss.org From kevin.kofler at chello.at Sun Jun 3 15:27:36 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 3 Jun 2007 15:27:36 +0000 (UTC) Subject: pungi : question about repo References: Message-ID: Vnpenguin vnoss.org> writes: > I have some customized rpm packages which found in my local repo. > Theses packages have the same name as original package of F7. How to > tell pungi that the package ABC on my local repo should be installed, > not ABC of F7 repo ? I guess giving them a higher epoch-version-release (EVR) should do the trick. Kevin Kofler From hughsient at gmail.com Sun Jun 3 16:34:40 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 03 Jun 2007 17:34:40 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> Message-ID: <1180888480.2892.1.camel@localhost.localdomain> On Sat, 2007-06-02 at 22:21 +0200, dragoran wrote: > for me suspend and resume works (using the nvidia drivers) but after > resume I only see a black page outside of X (vt switch) > any ideas? (using the nv driver = no resume at all) Using the nv driver, have you tried all the suggestions on the site? Richard. From drago01 at gmail.com Sun Jun 3 17:07:59 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 3 Jun 2007 19:07:59 +0200 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1180888480.2892.1.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> <1180888480.2892.1.camel@localhost.localdomain> Message-ID: On 6/3/07, Richard Hughes wrote: > > On Sat, 2007-06-02 at 22:21 +0200, dragoran wrote: > > > for me suspend and resume works (using the nvidia drivers) but after > > resume I only see a black page outside of X (vt switch) > > any ideas? (using the nv driver = no resume at all) > > Using the nv driver, have you tried all the suggestions on the site? using the nvidia driver I have to use vesafb (pas svga=794 to the kernel) to fix the vt switch problem (=works now) using the nv driver: I tryed --quirk-dpms-on --quirk-vga-mode3 --quirk-vbe-post --quirk-vbestate-restore --quirk-vbemode-restore --quirk-s3-mode none of them worked... I also tryed to combine them (random and random orders) but nothing worked... any idea what to try next? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Sun Jun 3 17:15:49 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 03 Jun 2007 18:15:49 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <1180888480.2892.1.camel@localhost.localdomain> Message-ID: <1180890949.2892.12.camel@localhost.localdomain> On Sun, 2007-06-03 at 19:07 +0200, dragoran wrote: > > none of them worked... I also tryed to combine them (random and random > orders) but nothing worked... any idea what to try next? Look at similar models to yours already added to the quirk db and try those. I can't answer every mail individually (not enough hours in the day) for 1:1 debugging, but I'll continue adding content to the website. You might like to try s3mode and s3bios together as well. Richard. From jkeating at redhat.com Sun Jun 3 17:30:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 13:30:00 -0400 Subject: pungi : question about repo In-Reply-To: References: Message-ID: <200706031330.04237.jkeating@redhat.com> On Sunday 03 June 2007 11:20:30 Vnpenguin wrote: > Hi all, > I have some customized rpm packages which found in my local repo. > Theses packages have the same name as original package of F7. How to > tell pungi that the package ABC on my local repo should be installed, > not ABC of F7 repo ? In the repo config for the F7 repo, add excludes for these package names. They'll be excluded from that repo only to be found in your repo. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vnpenguin at vnoss.org Sun Jun 3 17:58:30 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sun, 3 Jun 2007 19:58:30 +0200 Subject: pungi : question about repo In-Reply-To: <200706031330.04237.jkeating@redhat.com> References: <200706031330.04237.jkeating@redhat.com> Message-ID: On 6/3/07, Jesse Keating wrote: > > In the repo config for the F7 repo, add excludes for these package names. > They'll be excluded from that repo only to be found in your repo. Excellent suggestion ! Thank you, @ Kevin Kofler : thank you ! -- http://vnoss.org From drago01 at gmail.com Sun Jun 3 18:09:21 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 3 Jun 2007 20:09:21 +0200 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1180890949.2892.12.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> <1180888480.2892.1.camel@localhost.localdomain> <1180890949.2892.12.camel@localhost.localdomain> Message-ID: On 6/3/07, Richard Hughes wrote: > > On Sun, 2007-06-03 at 19:07 +0200, dragoran wrote: > > > > none of them worked... I also tryed to combine them (random and random > > orders) but nothing worked... any idea what to try next? > > Look at similar models to yours already added to the quirk db and try > those. I can't answer every mail individually (not enough hours in the > day) for 1:1 debugging, but I'll continue adding content to the website. > You might like to try s3mode and s3bios together as well. ok will play with it later... -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fedora at FamilleCollet.com Sun Jun 3 18:16:47 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sun, 03 Jun 2007 20:16:47 +0200 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <1180881734.3701.19.camel@pc-notebook> References: <1180881734.3701.19.camel@pc-notebook> Message-ID: <4663058F.6010309@FamilleCollet.com> Result of my research before submitting this. Mandriva : 1 SRPMS = 3 RPMS mozilla-thunderbird (without langpack)=> + mozilla-thunderbird + mozilla-thunderbird-devel + mozilla-thunderbird-enigmail OpenSuse : 1 SRPMS = 1 RPMS MozillaThunderbird => MozillaThunderbird (thunderbird + enigmail) Debian (unstable) I'm not a .deb specialist, but it seems they build enigmail using a "icedov-devel" sub package (and a lot of patches). Remi. From vonbrand at inf.utfsm.cl Sun Jun 3 17:21:19 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 03 Jun 2007 13:21:19 -0400 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <1180878850.12595.583.camel@mccallum.corsepiu.local> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> <1180878850.12595.583.camel@mccallum.corsepiu.local> Message-ID: <200706031721.l53HLJ4O013921@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: > > On 03.06.2007 15:17, Jesse Keating wrote: > > > On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: > > >> Well, see all those discussion that happened when ACLs were added, kjoi > > >> introduced, the freezes were introduced and bodi put in place. Sure, > > >> there are always discussions, but all those were quite worse and there > > >> was a lot of confusion afaics... Don't read fedora-maintainers for a > > >> week and suddenly you are not aware of how to build or push a package. > > > So without reading the mailing list for maintainers, > > > > A low-traffic fedora-maintainers-announce was requested multiple times > > as some contributors mentioned that fedora-maintainers is to noisy for > > them. > One way traffic is inappropriate for a community project. Wrong... in any biggish community there are people who are very into it, and others more peripherally interested. You need some (low-traffic) announcements together with your typical high-volume, flame-war-infested (but hopefully not), discussion lists. > > Like it or not, but for some people fedora-maintainers has to much > > traffic; > Then they better should not be maintainers! Right. But there are other people interested in maintainance. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From caillon at redhat.com Sun Jun 3 18:19:23 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 03 Jun 2007 14:19:23 -0400 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <1180881734.3701.19.camel@pc-notebook> References: <1180881734.3701.19.camel@pc-notebook> Message-ID: <4663062B.6010800@redhat.com> Martin Sourada wrote: > make the thunderbird-devel package, which would have all the necessary > files in it. Than we would be able to patch the enigmail to build > against it. Nope. Not going to have multiple gecko devel environments. If I enable thunderbird-devel, I'll turn off firefox-devel. And I think firefox-devel is the more useful item right now. One of my goals for F8 is to have one gecko environment across the board which would allow for this. I hope to get it done around the test1 time frame and after a testing period, am likely to backport to older Fedorae. From caillon at redhat.com Sun Jun 3 18:22:10 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 03 Jun 2007 14:22:10 -0400 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <4663058F.6010309@FamilleCollet.com> References: <1180881734.3701.19.camel@pc-notebook> <4663058F.6010309@FamilleCollet.com> Message-ID: <466306D2.5020402@redhat.com> Remi Collet wrote: > Result of my research before submitting this. > > Mandriva : 1 SRPMS = 3 RPMS > mozilla-thunderbird (without langpack)=> > + mozilla-thunderbird > + mozilla-thunderbird-devel > + mozilla-thunderbird-enigmail > > OpenSuse : 1 SRPMS = 1 RPMS > MozillaThunderbird => MozillaThunderbird (thunderbird + enigmail) And I know that both of these approaches have been frowned upon by upstream. What people really ought to do if they want enigmail into Thunderbird is to knock the developers on the head with something and get them to address the code issues that the thunderbird guys have so we can just commit the damn thing into Thunderbird proper. From s.adam at diffingo.com Sun Jun 3 18:24:15 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sun, 03 Jun 2007 14:24:15 -0400 Subject: Proposal: Automated rebuild script for the buildsys Message-ID: <1180895055.14069.7.camel@Diffingo.localdomain> Hello, I had an idea today as I was running my usual update check. I'm not sure if it's possible or feasible, but if it is possible to write I think it would be a great feature for the buildsys. Today I checked for updates and found: firefox.i386 2.0.0.4-1.fc7 updates firefox-devel.i386 2.0.0.4-1.fc7 updates yelp.i386 2.18.1-4.fc7 updates If I try to update firefox or yelp, the dependency check fails because firefox = 2.0.0.3 is needed by gnome-python2-gtkmozembed. It's no trouble to wait a day or two for the gnome-python2-gtkmozembed, but I was thinking what if there was a list on the buildsys that kept track of certain packages like these - gnome-python2-gtkmozembed an yelp would be listed against firefox for example as they both require gecko-libs. This way, when the version tag (not release tag) changed, yelp and gnome-python2-gtkmozembed could be queued for rebuilding too so there are fewer dependency errors. Stewart From ndbecker2 at gmail.com Sun Jun 3 18:28:10 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 03 Jun 2007 14:28:10 -0400 Subject: emacs with xft support Message-ID: I built an rpm for emacs with nice font support. It is almost identical to the fc7 emacs22, but with the emacs cvs source and using config options to enable xft. AFAIK, you need emacs cvs to get the nice fonts. I put them here: https://nbecker.dyndns.org/RPM From debarshi.ray at gmail.com Sun Jun 3 18:34:50 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 4 Jun 2007 00:04:50 +0530 Subject: emacs with xft support In-Reply-To: References: Message-ID: <3170f42f0706031134q7300268bm505bf031970ca0fc@mail.gmail.com> Can it be installed without affecting the Fedora 7 Emacs? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From ndbecker2 at gmail.com Sun Jun 3 18:38:30 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 03 Jun 2007 14:38:30 -0400 Subject: emacs with xft support References: <3170f42f0706031134q7300268bm505bf031970ca0fc@mail.gmail.com> Message-ID: Debarshi 'Rishi' Ray wrote: > Can it be installed without affecting the Fedora 7 Emacs? > No. From janina at rednote.net Sun Jun 3 19:56:32 2007 From: janina at rednote.net (Janina Sajka) Date: Sun, 3 Jun 2007 15:56:32 -0400 Subject: Passwords Shouldn't Go Over http Message-ID: <20070603195632.GA6804@rednote.net> I'm shocked, actually, that my login to http://fedoraproject.org/wiki/BugsAndFeatureRequests is going http and not https. Bad, bad bad. -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From martin.sourada at seznam.cz Sun Jun 3 19:57:17 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 03 Jun 2007 21:57:17 +0200 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <4663062B.6010800@redhat.com> References: <1180881734.3701.19.camel@pc-notebook> <4663062B.6010800@redhat.com> Message-ID: <1180900637.2946.6.camel@pc-notebook> On Sun, 2007-06-03 at 20:19 +0200, Christopher Aillon wrote: > Martin Sourada wrote: > > make the thunderbird-devel package, which would have all the necessary > > files in it. Than we would be able to patch the enigmail to build > > against it. > > Nope. Not going to have multiple gecko devel environments. If I enable > thunderbird-devel, I'll turn off firefox-devel. And I think > firefox-devel is the more useful item right now. > > One of my goals for F8 is to have one gecko environment across the board > which would allow for this. I hope to get it done around the test1 time > frame and after a testing period, am likely to backport to older Fedorae. But that leave us only two choices, I think. Either leave the package as is and accept it to Fedora with the knowledge that it's dirty and needs to be fixed as soon as you (or someone else) provide the necessary devel packages (most likely the xulrunner??), and probably fill even a bug for this or something. Or, wait until the problem is fixed (which could however take quite a long time) and accept the package after. Martin -------------- next part -------------- A non-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 Sun Jun 3 20:12:15 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 03 Jun 2007 22:12:15 +0200 Subject: Headsup new (incompatible) libgnomedb and libgda have hit rawhide Message-ID: <4663209F.5050204@hhs.nl> Hi all, A bit late, as I was surprised with rawhide switching to F8 mode so soon, but here is a headsup, or more a heads after about a big leap in the libgda and libgnomedb versions, libgda and libgnomedb in Fedora have long been at the 1.9.100 unstable / testing version, as gnumeric needed something newer then the latest stable and stopped working with anything newer then 1.9.100 . However libgda and libgnomedb upstream have finally released a new stable version and a contributer has been so good as to provide a patch to gnumeric to make gnumeric work with this version. So a couple of days ago libgda-3.0.1 and libgnomedb-3.0.0 have hit rawhide, together with a gnumeric 1.6.3 update which works with these new versions. AFAIK gnumeric is the only user, but if not then please fix your packages to work with these new stable releases. Also AFAIK several potential libgnomedb using apps where sofar not packaged because of the libgda / libgnomedb long long testing phase. Now that there finally is a stable (most important ABI stable!) release, I expect to see other packages using libgda + libgnomedb showing up. When you add such a package please let me know, so that I can involve you in helping with testing with any gda / gnomedb updates. Since the 3.0.0 release is not ABI compatible with the 1.9.100 release I'm currently only releasing this for rawhide, however if requested I will concider pushing this as a F-7 updated too, so if you want to see it there, let me know Regards, Hans From caillon at redhat.com Sun Jun 3 20:07:24 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 03 Jun 2007 16:07:24 -0400 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <1180900637.2946.6.camel@pc-notebook> References: <1180881734.3701.19.camel@pc-notebook> <4663062B.6010800@redhat.com> <1180900637.2946.6.camel@pc-notebook> Message-ID: <46631F7C.2060209@redhat.com> Martin Sourada wrote: > But that leave us only two choices, I think. Either leave the package as > is and accept it to Fedora with the knowledge that it's dirty and needs > to be fixed as soon as you (or someone else) provide the necessary devel > packages (most likely the xulrunner??), and probably fill even a bug for > this or something. Or, wait until the problem is fixed (which could > however take quite a long time) and accept the package after. And since Fedora's default GUI mail client, Evolution, supports GPG, I'd probably recommend using that for now. Yes, I did mean XULRunner. From steve at nexusuk.org Sun Jun 3 20:10:14 2007 From: steve at nexusuk.org (Steve Hill) Date: Sun, 3 Jun 2007 21:10:14 +0100 (BST) Subject: Audacious - Illegal Instruction (Livna) In-Reply-To: <20070529234634.6370359f@lain.camperquake.de> References: <420592.40595.qm@web52406.mail.re2.yahoo.com> <20070529234634.6370359f@lain.camperquake.de> Message-ID: On Tue, 29 May 2007, Ralf Ertzinger wrote: > OK, that confirms it. Expect a new build soonish. The new build appears to work well - thank you. -- - Steve xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence From greno at verizon.net Sun Jun 3 20:12:01 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 03 Jun 2007 16:12:01 -0400 Subject: kernel-devel packages Message-ID: <46632091.3090401@verizon.net> I need to install kernel-devel for my running fc6 kernel which is 2.6.19-1.2895.fc6 but yum insists that the only kernel-devel available is for 2.6.20-1.2952.fc6 How do I get access via yum to the correct kernel-devel for my kernel? From denis at poolshark.org Sun Jun 3 20:23:25 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 03 Jun 2007 22:23:25 +0200 Subject: Headsup new (incompatible) libgnomedb and libgda have hit rawhide In-Reply-To: <4663209F.5050204@hhs.nl> References: <4663209F.5050204@hhs.nl> Message-ID: <4663233D.2050401@poolshark.org> Hans de Goede wrote: > Hi all, > > A bit late, as I was surprised with rawhide switching to F8 mode so > soon, but here is a headsup, or more a heads after about a big leap in > the libgda and libgnomedb versions, libgda and libgnomedb in Fedora have > long been at the 1.9.100 unstable / testing version, as gnumeric needed > something newer then the latest stable and stopped working with anything > newer then 1.9.100 . > > However libgda and libgnomedb upstream have finally released a new > stable version and a contributer has been so good as to provide a patch > to gnumeric to make gnumeric work with this version. > > So a couple of days ago libgda-3.0.1 and libgnomedb-3.0.0 have hit > rawhide, together with a gnumeric 1.6.3 update which works with these > new versions. > > AFAIK gnumeric is the only user, but if not then please fix your > packages to work with these new stable releases. The only other users i know of are glom and libgdamm, but both use the previous 1.2 stable release that is packaged seperately (compat-libgda-1.2.4). Glom has an unstable branch that works with libgda 3.0, so i think both glom and libgdamm are likely to move to libgda 3 before we hit F-8. I'll EOL compat-libgda-1.2.4 when that happens. From debarshi.ray at gmail.com Sun Jun 3 20:23:45 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 4 Jun 2007 01:53:45 +0530 Subject: kernel-devel packages In-Reply-To: <46632091.3090401@verizon.net> References: <46632091.3090401@verizon.net> Message-ID: <3170f42f0706031323t1d407889u832134d9f18078ec@mail.gmail.com> > How do I get access via yum to the correct kernel-devel for my kernel? Instead of: # yum install kernel-devel try out something like: # yum install kernel-devel- Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From denis at poolshark.org Sun Jun 3 20:30:37 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 03 Jun 2007 22:30:37 +0200 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <466306D2.5020402@redhat.com> References: <1180881734.3701.19.camel@pc-notebook> <4663058F.6010309@FamilleCollet.com> <466306D2.5020402@redhat.com> Message-ID: <466324ED.5060305@poolshark.org> Christopher Aillon wrote: > Remi Collet wrote: >> Result of my research before submitting this. >> >> Mandriva : 1 SRPMS = 3 RPMS >> mozilla-thunderbird (without langpack)=> >> + mozilla-thunderbird >> + mozilla-thunderbird-devel >> + mozilla-thunderbird-enigmail >> >> OpenSuse : 1 SRPMS = 1 RPMS >> MozillaThunderbird => MozillaThunderbird (thunderbird + enigmail) > > And I know that both of these approaches have been frowned upon by > upstream. And why should we care about that ? Don't we have a stronger commitment to end users than to upstream projects ? From greno at verizon.net Sun Jun 3 20:39:40 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 03 Jun 2007 16:39:40 -0400 Subject: kernel-devel packages In-Reply-To: <3170f42f0706031323t1d407889u832134d9f18078ec@mail.gmail.com> References: <46632091.3090401@verizon.net> <3170f42f0706031323t1d407889u832134d9f18078ec@mail.gmail.com> Message-ID: <4663270C.4010607@verizon.net> Debarshi 'Rishi' Ray wrote: >> How do I get access via yum to the correct kernel-devel for my kernel? > > Instead of: > # yum install kernel-devel > try out something like: > # yum install kernel-devel- Thanks, I tried that but still nothing. yum install kernel-devel-2.6.19-1.2895 zip/nada/nothing From alan at redhat.com Sun Jun 3 20:40:24 2007 From: alan at redhat.com (Alan Cox) Date: Sun, 3 Jun 2007 16:40:24 -0400 Subject: An idea for RPM -> License Agreement support In-Reply-To: References: Message-ID: <20070603204024.GA25869@devserv.devel.redhat.com> On Wed, May 30, 2007 at 09:26:39PM +0800, Hikaru Amano wrote: > it would be useful to Third Parties if RPM have the ability to ask for > License Agreement before installing their package. I'm not a lawyer > but I believe this is useful in legal related stuff when distributing > softwares. I have seen a few RPM that are stored .bin just for the > sake of license agreement (Sun Java is the easiest example) and with > RPM having (optional) license agreement before installation , this > would reduce their worries bout licensing when packaging app for > Linux. RPM supports remote install and scripted installs. As such it cannot support license agreements while installing. Instead vendors with a clue arrange that when you first execute the program it explains the license and asks you for agreement. Alan From mclasen at redhat.com Sun Jun 3 20:40:10 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 03 Jun 2007 16:40:10 -0400 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <466324ED.5060305@poolshark.org> References: <1180881734.3701.19.camel@pc-notebook> <4663058F.6010309@FamilleCollet.com> <466306D2.5020402@redhat.com> <466324ED.5060305@poolshark.org> Message-ID: <1180903210.3465.6.camel@localhost.localdomain> On Sun, 2007-06-03 at 22:30 +0200, Denis Leroy wrote: > > And I know that both of these approaches have been frowned upon by > > upstream. > > And why should we care about that ? Don't we have a stronger commitment > to end users than to upstream projects ? We care because we active participants in many of the upstream projects, and are interested in good relations. From sundaram at fedoraproject.org Sun Jun 3 20:51:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 02:21:18 +0530 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <466324ED.5060305@poolshark.org> References: <1180881734.3701.19.camel@pc-notebook> <4663058F.6010309@FamilleCollet.com> <466306D2.5020402@redhat.com> <466324ED.5060305@poolshark.org> Message-ID: <466329C6.6020808@fedoraproject.org> Denis Leroy wrote: > Christopher Aillon wrote: >> Remi Collet wrote: >>> Result of my research before submitting this. >>> >>> Mandriva : 1 SRPMS = 3 RPMS >>> mozilla-thunderbird (without langpack)=> >>> + mozilla-thunderbird >>> + mozilla-thunderbird-devel >>> + mozilla-thunderbird-enigmail >>> >>> OpenSuse : 1 SRPMS = 1 RPMS >>> MozillaThunderbird => MozillaThunderbird (thunderbird + enigmail) >> >> And I know that both of these approaches have been frowned upon by >> upstream. > > And why should we care about that ? Don't we have a stronger commitment > to end users than to upstream projects ? They are both very related to each other. If you affect your relationship with upstream projects which are our suppliers then our end users will suffer too. Rahul From denis at poolshark.org Sun Jun 3 21:05:36 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 03 Jun 2007 23:05:36 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <46620EE5.6030707@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> <46620EE5.6030707@hhs.nl> Message-ID: <46632D20.90009@poolshark.org> Hans de Goede wrote: > Rahul Sundaram wrote: >> Ralf Corsepius wrote: >>> On Sat, 2007-06-02 at 13:30 +0530, Rahul Sundaram wrote: >>>> Toshio Kuratomi wrote: >>>>> On Fri, 2007-06-01 at 20:32 +0530, Rahul Sundaram wrote: >>>>>> Hans de Goede wrote: >>>>>>> Not true many reviewers review on the latest stable, it says >>>>>>> nowhere that a review should be done on rawhide. >>>>>> Review is about guidelines and nowhere in the guideline does it >>>>>> even say that the fucntionality of the package should be tested. >>>>>> When I suggested that it be added I got back a knee jerk reaction >>>>>> to participate in reviews myself. >>>>>> >>>>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines:: >>>>> >>>>> - SHOULD: The reviewer should test that the package functions as >>>>> described. A package should not segfault instead of running, for >>>>> example. >>>> I suggested that it the "SHOULD" be changed to "MUST". A package >>>> that doesnt even start shouldnt be getting past reviews. >>> 1. packages never start, applications do. >> >> Pendantic waste. >> >>> 2. many applications, when being cluelessly used, only mean they have a >>> functional "usage()" >> >> Which covers base functionality. >> > > Ralf wrote in reply to this: " - You apparently don't have any > clues about what you are talking about." > > I do not agree with the beep, but let me stress the point: > "You apparently don't have any clues about what you are talking about." > > What Ralf means with: > >> 2. many applications, when being cluelessly used, only mean they have a > >> functional "usage()" > > And which should be fully understandable by anyone who claims to have > enough domain knowledge to discuss and decide policies, is that if a > reviewer just runs app foo like this: > foo > > That changes then are large the user will see something like: > usage: foo [opt] or > > Which sure does NOT cover basic functionality. Right :-). Actually all it proves is that the dynamic libraries loaded correctly. i.e. something that's already guaranteed to happen. The things to stress are code coverage, basic functionality, and especially: anything that interacts with the OS/dekstop such as - opening/saving file - printing - anything that hooks with some Gnome (or KDE) services (keyrings, search, proxy settings, ...) - config files. are they saved in the right place, and reloaded correctly ? Where in the wiki should we put this information, Packaging/ReviewGuidelines ? From greno at verizon.net Sun Jun 3 21:21:33 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 03 Jun 2007 17:21:33 -0400 Subject: kernel-devel packages In-Reply-To: <4663270C.4010607@verizon.net> References: <46632091.3090401@verizon.net> <3170f42f0706031323t1d407889u832134d9f18078ec@mail.gmail.com> <4663270C.4010607@verizon.net> Message-ID: <466330DD.6010404@verizon.net> Ok, I tried loading the 2.6.20-1.2952.fc6 kernel and it crashes on my server with an "unknown bus timing" error. Every 2.6.20 kernel so far is unable to run on my hardware. So I'm stuck at 2.6.19. I've opened a bug on this some time ago. But I don't see anything happening with it. Now, I need a package that has a dep for kernel-devel and it won't install because yum cannot find kernel-devel for the 2.6.19-1.2895 kernel. How do I get access to the kernel-devel for my running kernel? Gerry Reno wrote: > yum install kernel-devel-2.6.19-1.2895 > zip/nada/nothing > From mmcgrath at redhat.com Sun Jun 3 21:23:07 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 03 Jun 2007 16:23:07 -0500 Subject: Passwords Shouldn't Go Over http In-Reply-To: <20070603195632.GA6804@rednote.net> References: <20070603195632.GA6804@rednote.net> Message-ID: <4663313B.4000403@redhat.com> Janina Sajka wrote: > I'm shocked, actually, that my login to > http://fedoraproject.org/wiki/BugsAndFeatureRequests is going http and > not https. Bad, bad bad. > > We're aware and are already working on it. -Mike From mail at robertoragusa.it Sun Jun 3 21:44:33 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Sun, 03 Jun 2007 23:44:33 +0200 Subject: kernel-devel packages In-Reply-To: <466330DD.6010404@verizon.net> References: <46632091.3090401@verizon.net> <3170f42f0706031323t1d407889u832134d9f18078ec@mail.gmail.com> <4663270C.4010607@verizon.net> <466330DD.6010404@verizon.net> Message-ID: <46633641.8090601@robertoragusa.it> Gerry Reno wrote: > Ok, I tried loading the 2.6.20-1.2952.fc6 kernel and it crashes on my > server with an "unknown bus timing" error. Every 2.6.20 kernel so far > is unable to run on my hardware. So I'm stuck at 2.6.19. I've opened a > bug on this some time ago. But I don't see anything happening with it. > > Now, I need a package that has a dep for kernel-devel and it won't > install because yum cannot find kernel-devel for the 2.6.19-1.2895 > kernel. How do I get access to the kernel-devel for my running kernel? Packages in "updates" are deleted from mirrors when new updates come out and this approach, while avoiding having 5 slightly different versions of openoffice in the repository, causes the sort of problem you are having. Any way, if you're lucky there could be a obsolete/broken mirror somewhere with old packages. In fact, your rpm appears to be present here: http://fedora.ugm.ac.id/updates/6/i386/ I found it by googling kernel-devel-2.6.19-1.2895 rpm "index of" Best regards. -- Roberto Ragusa mail at robertoragusa.it From greno at verizon.net Sun Jun 3 21:55:08 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 03 Jun 2007 17:55:08 -0400 Subject: kernel-devel packages In-Reply-To: <46633641.8090601@robertoragusa.it> References: <46632091.3090401@verizon.net> <3170f42f0706031323t1d407889u832134d9f18078ec@mail.gmail.com> <4663270C.4010607@verizon.net> <466330DD.6010404@verizon.net> <46633641.8090601@robertoragusa.it> Message-ID: <466338BC.3040502@verizon.net> Roberto Ragusa wrote: > Gerry Reno wrote: > >> Ok, I tried loading the 2.6.20-1.2952.fc6 kernel and it crashes on my >> server with an "unknown bus timing" error. Every 2.6.20 kernel so far >> is unable to run on my hardware. So I'm stuck at 2.6.19. I've opened a >> bug on this some time ago. But I don't see anything happening with it. >> >> Now, I need a package that has a dep for kernel-devel and it won't >> install because yum cannot find kernel-devel for the 2.6.19-1.2895 >> kernel. How do I get access to the kernel-devel for my running kernel? >> > > Packages in "updates" are deleted from mirrors when new updates > come out and this approach, while avoiding having 5 slightly different > versions of openoffice in the repository, causes the sort of problem > you are having. > > Any way, if you're lucky there could be a obsolete/broken mirror > somewhere with old packages. > > In fact, your rpm appears to be present here: > > http://fedora.ugm.ac.id/updates/6/i386/ > > I found it by googling > > kernel-devel-2.6.19-1.2895 rpm "index of" > > Best regards. > > Thanks Roberto. They had the right package. Regards, Gerry From lsof at nodata.co.uk Sun Jun 3 22:01:39 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 04 Jun 2007 00:01:39 +0200 Subject: Automate time zone selection (Was: RFE: use nasa worldwind...) In-Reply-To: <1180729519.7519.35.camel@pc-notebook> References: <448387.4032.qm@web56902.mail.re3.yahoo.com> <1180697702.3637.6.camel@pc-notebook> <20070601191803.GD7580@nostromo.devel.redhat.com> <1180727789.7519.15.camel@pc-notebook> <46607ED8.9020008@redhat.com> <1180729519.7519.35.camel@pc-notebook> Message-ID: <1180908099.9731.1.camel@sb-home> Am Freitag, den 01.06.2007, 22:25 +0200 schrieb Martin Sourada: > On Fri, 2007-06-01 at 22:17 +0200, Christopher Aillon wrote: > > Martin Sourada wrote: > > > Is it? Didn't know that. But, as the problem was in Test 4 (and I have > > > too slow internet here to download final ISOs) and no one other > > > mentioned it and in fact it was when I tested it in QEMU (when I > > > installed it on my notebook I chose English, so it was set right) I > > > think filling a bug is not worth it, at least until F8 Test 1 come out > > > (for Fedora 7 its too late now and for F8 there is plenty of time to fix > > > it if it is really broken). > > > > Without filing a bug, the person responsible for fixing it might not > > know about it. So there's close to zero chance of it being fixed until > > you file a bug. > > > > I know, but also don't want to fill bugs when not necessary. I'll check > it when F8 T1 is out. If it will work then it is OK, if not, I will file > a bug. > > Martin > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Bugzilla isn't only for bugs.. file it anyway. It lessens the chance of forgetting too. In fact, replying to this e-mail is probably as much work as filing a bug. From ottohaliburton at tx.rr.com Sun Jun 3 21:45:52 2007 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Sun, 3 Jun 2007 16:45:52 -0500 Subject: kernel-devel packages In-Reply-To: <466330DD.6010404@verizon.net> Message-ID: <000c01c7a628$8f6f30c0$0201a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Gerry Reno > Sent: Sunday, June 03, 2007 4:22 PM > To: Development discussions related to Fedora Core > Subject: Re: kernel-devel packages > > Ok, I tried loading the 2.6.20-1.2952.fc6 kernel and it crashes on my > server with an "unknown bus timing" error. Every 2.6.20 kernel so far > is unable to run on my hardware. So I'm stuck at 2.6.19. I've opened a > bug on this some time ago. But I don't see anything happening with it. > > Now, I need a package that has a dep for kernel-devel and it won't > install because yum cannot find kernel-devel for the 2.6.19-1.2895 > kernel. How do I get access to the kernel-devel for my running kernel? > > > > Gerry Reno wrote: > > yum install kernel-devel-2.6.19-1.2895 > > zip/nada/nothing > > > go to add/remove programs and click on list and scroll down to kernel and see if it is there and then check it and see if it will install > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From d.jacobfeuerborn at conversis.de Sun Jun 3 22:12:56 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 04 Jun 2007 00:12:56 +0200 Subject: Firewall configuration tool: system-config-firewall In-Reply-To: <46602E12.7080008@redhat.com> References: <46602E12.7080008@redhat.com> Message-ID: <46633CE8.1010706@conversis.de> Thomas Woerner wrote: > Hello, > > system-config-firewall is a new firewall configuration tool, which is > based on system-config-securitylevel and provides enhanced funtionality > and better user guidance. > > Please have a look at: > http://koji.fedoraproject.org/scratch/twoerner/task_22791/ > You will need system-config-firewall and system-config-firewall-tui > packages for your architecture. I'm getting an error when I try to start system-config-firewall: [root at nexus ~]# system-config-firewall Traceback (most recent call last): File "/usr/share/system-config-firewall/system-config-firewall.py", line 12, in import fw_gui File "/usr/share/system-config-firewall/fw_gui.py", line 32, in from fw_config import * File "/usr/share/system-config-firewall/fw_config.py", line 64, in from netconfpkg import NCDeviceList ImportError: No module named netconfpkg Regards, Dennis From greno at verizon.net Sun Jun 3 22:14:52 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 03 Jun 2007 18:14:52 -0400 Subject: kernel-devel packages In-Reply-To: <000c01c7a628$8f6f30c0$0201a8c0@C515816A> References: <000c01c7a628$8f6f30c0$0201a8c0@C515816A> Message-ID: <46633D5C.2050804@verizon.net> Otto Haliburton wrote: > >> -----Original Message----- >> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- >> bounces at redhat.com] On Behalf Of Gerry Reno >> Sent: Sunday, June 03, 2007 4:22 PM >> To: Development discussions related to Fedora Core >> Subject: Re: kernel-devel packages >> >> Ok, I tried loading the 2.6.20-1.2952.fc6 kernel and it crashes on my >> server with an "unknown bus timing" error. Every 2.6.20 kernel so far >> is unable to run on my hardware. So I'm stuck at 2.6.19. I've opened a >> bug on this some time ago. But I don't see anything happening with it. >> >> Now, I need a package that has a dep for kernel-devel and it won't >> install because yum cannot find kernel-devel for the 2.6.19-1.2895 >> kernel. How do I get access to the kernel-devel for my running kernel? >> >> >> >> Gerry Reno wrote: >> >>> yum install kernel-devel-2.6.19-1.2895 >>> zip/nada/nothing >>> >>> > go to add/remove programs and click on list and scroll down to kernel and > see if it is there and then check it and see if it will install > > >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > Thanks Otto, but it's a server - no GUI. I've got the package now. Regards, Gerry From vonbrand at inf.utfsm.cl Sun Jun 3 23:40:40 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 03 Jun 2007 19:40:40 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <46632D20.90009@poolshark.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <1180774583.12595.425.camel@mccallum.corsepiu.local> <4661316A.8000903@fedoraproject.org> <46620EE5.6030707@hhs.nl> <46632D20.90009@poolshark.org> Message-ID: <200706032340.l53Neemc018089@laptop13.inf.utfsm.cl> Denis Leroy wrote: [...] > The things to stress are code coverage, basic functionality, and > especially: anything that interacts with the OS/dekstop such as > - opening/saving file > - printing > - anything that hooks with some Gnome (or KDE) services (keyrings, > search, proxy settings, ...) > - config files. are they saved in the right place, and reloaded > correctly ? Right. A set of (regression) tests for the package. Hopefully maintained upstream (setting this up and keeping it up to date is a /huge/ amount of work!), perhaps supplemented by some local tests by the packager. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jkeating at redhat.com Mon Jun 4 00:41:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 20:41:19 -0400 Subject: Proposal: Automated rebuild script for the buildsys In-Reply-To: <1180895055.14069.7.camel@Diffingo.localdomain> References: <1180895055.14069.7.camel@Diffingo.localdomain> Message-ID: <200706032041.19821.jkeating@redhat.com> On Sunday 03 June 2007 14:24:15 Stewart Adam wrote: > but I was thinking what if there was a list on the buildsys that kept > track of certain packages like these - gnome-python2-gtkmozembed an yelp > would be listed against firefox for example as they both require > gecko-libs. The buildsystem already has in it's database information about what every package Requires and Provides. All that is really missing is logic to query through that information and alert maintainers when a new package lands that will break requirements. Would be nice to have in Koji... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From s.adam at diffingo.com Mon Jun 4 01:16:39 2007 From: s.adam at diffingo.com (Stewart Adam) Date: Sun, 03 Jun 2007 21:16:39 -0400 Subject: Proposal: Automated rebuild script for the buildsys In-Reply-To: <200706032041.19821.jkeating@redhat.com> References: <1180895055.14069.7.camel@Diffingo.localdomain> <200706032041.19821.jkeating@redhat.com> Message-ID: <1180919799.19545.1.camel@Diffingo.localdomain> On Sun, 2007-06-03 at 20:41 -0400, Jesse Keating wrote: > On Sunday 03 June 2007 14:24:15 Stewart Adam wrote: > > The buildsystem already has in it's database information about what every > package Requires and Provides. All that is really missing is logic to query > through that information and alert maintainers when a new package lands that > will break requirements. Would be nice to have in Koji... Is it possible to check out the buildsys scripts in the same way I can check out a package to see what/where modifications would be needed? Stewart From jkeating at redhat.com Mon Jun 4 01:24:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 21:24:09 -0400 Subject: Proposal: Automated rebuild script for the buildsys In-Reply-To: <1180919799.19545.1.camel@Diffingo.localdomain> References: <1180895055.14069.7.camel@Diffingo.localdomain> <200706032041.19821.jkeating@redhat.com> <1180919799.19545.1.camel@Diffingo.localdomain> Message-ID: <200706032124.09956.jkeating@redhat.com> On Sunday 03 June 2007 21:16:39 Stewart Adam wrote: > Is it possible to check out the buildsys scripts in the same way I can > check out a package to see what/where modifications would be needed? > Stewart Koji is opensource. https://hosted.fedoraproject.org/projects/koji -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernie at codewiz.org Mon Jun 4 03:24:33 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sun, 03 Jun 2007 23:24:33 -0400 Subject: Splitting the ncurses RPM Message-ID: <466385F1.8030005@codewiz.org> The ncurses package carries 2MB worth of terminfo database that almost nobody cares to install. Could we move them to a separate ncurses-data package so that space constrained installs could easily get rid of them? The OLPC would certainly remove it, and maybe we could safely remove them from default Fedora installs too. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From bernie at codewiz.org Mon Jun 4 03:37:45 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sun, 03 Jun 2007 23:37:45 -0400 Subject: Using --excludedocs and --excludepath with yum Message-ID: <46638909.3090006@codewiz.org> Is it possible? This would reduce the amount of postprocessing we need to do when building OLPC images. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From andy at smile.org.ua Mon Jun 4 04:17:09 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 4 Jun 2007 07:17:09 +0300 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <46638909.3090006@codewiz.org> References: <46638909.3090006@codewiz.org> Message-ID: <20070604041709.GA4192@serv.smile.org.ua> Hi Bernardo Innocenti! On Sun, Jun 03, 2007 at 11:37:45PM -0400, Bernardo Innocenti wrote next: > Is it possible? I don't know about yum, but you can push %_excludedocs 1 to the rpmmacros. Also, this macro provides too many warnings at install (due to crash info-install in %post). As I remember correctly someone discussed this issue here (or in formed fedora-extras-list) several month ago. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From Matt_Domsch at Dell.com Sun Jun 3 20:29:37 2007 From: Matt_Domsch at Dell.com (Matt Domsch) Date: Sun, 3 Jun 2007 15:29:37 -0500 Subject: Release x86_64 rawhide rebuild in mock status 2007-06-03 Message-ID: <20070603152937.A17627@humbolt.us.dell.com> Release Rawhide-in-Mock Build Results for x86_64 Sun Jun 3 09:09:00 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 4290 Number failed to build: 155 Number expected to fail due to ExclusiveArch or ExcludeArch: 32 Leaving: 123 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 123 ---------------------------------- 7.src.rpm abicheck-1.2-13 (build/make) bugs.michael at gmx.net adaptx-0.9.13-4jpp.1.fc7 (build/make) pcheung at redhat.com airsnort-0.2.7e-11.fc7 (build/make) andreas.bierfert at lowlatency.de alacarte-0.11.3-3.fc7 (build/make) rstrode at redhat.com atitvout-0.4-6 (buildroot) andreas.bierfert at lowlatency.de bluez-utils-3.11-2.fc8 (buildroot) dwmw2 at redhat.com castor-0.9.5-1jpp.7 (build/make) pcheung at redhat.com checkstyle-4.1-4jpp.1.fc7 (buildroot) nsantos at redhat.com chmsee-1.0.0-0.19.beta2.fc8 (buildroot) bbbush.yuan at gmail.com,pertusus at free.fr clearsilver-0.10.4-4.fc8 (build/make) jeff at ocjtech.us,limb at jcomserv.net compat-gcc-32-3.2.3-61 (build/make) jakub at redhat.com compat-gcc-34-3.4.6-7 (build/make) jakub at redhat.com cryptix-3.2.0-9jpp.1 (build/make) mwringe at redhat.com cryptix-asn1-20011119-7jpp.2 (build/make) vivekl at redhat.com csmash-0.6.6-14.fc7 (build/make) matthias at rpmforge.net devhelp-0.14-2.fc8 (buildroot) mbarnes at redhat.com dump-0.4b41-5.fc7 (build/make) atkac at redhat.com em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2 (buildroot) ville.skytta at iki.fi epiphany-2.19.2-2.fc8 (buildroot) caillon at redhat.com epiphany-extensions-2.19.2-1 (buildroot) caillon at redhat.com,peter at thecodergeek.com erlang-R11B-2.4.fc7 (build/make) gemi at bluewin.ch evolution-2.11.2-2.fc8 (buildroot) mbarnes at redhat.com evolution-connector-2.11.2-2.fc8 (buildroot) mbarnes at redhat.com galeon-2.0.3-9.fc7 (buildroot) denis at poolshark.org gcdmaster-1.2.2-1.fc6 (buildroot) denis at poolshark.org gnome-python2-desktop-2.18.0-1.fc7 (build/make) mbarnes at redhat.com gnome-python2-extras-2.14.3-2.fc8 (buildroot) mbarnes at redhat.com gnome-sharp-2.16.0-1.fc6 (build/make) alexl at redhat.com,lxtnow at gmail.com gnotime-2.2.2-7.fc6 (build/make) toshio at tiki-lounge.com gpm-1.20.1-84.fc8 (buildroot) tjanouse at redhat.com grub-0.97-13 (build/make) pjones at redhat.com gstm-1.2-6.fc7 (build/make) splinux at fedoraproject.org gtk-sharp-1.0.10-12.fc7 (build/make) paul at all-the-johnsons.co.uk gtk2-2.11.0-1.fc8 (build/make) mclasen at redhat.com gwget-0.98.2-1.fc7 (build/make) fedora at christoph-wickert.de heartbeat-2.0.8-1.fc7 (build/make) kevin at tummy.com heliodor-0.2.0-1.fc7 (build/make) jwilson at redhat.com,matthias at rpmforge.net hugin-0.6.1-6.fc7 (build/make) bruno at postle.net jakarta-commons-el-1.0-7jpp.1.fc7 (build/make) fnasser at redhat.com jd-1.9.5-0.3.beta070528.fc8.src.rpm jgroups-2.2.9.2-3jpp.2 (build/make) vivekl at redhat.com jogl-1.0.0-5.7.beta5.fc6 (build/make) green at redhat.com junit-3.8.2-3jpp.1.fc7 (build/make) dbhole at redhat.com k3d-0.6.5.0-1.fc7 (build/make) denis at poolshark.org kawa-1.9.0-2.fc7 (build/make) green at redhat.com kazehakase-0.4.7-1.fc8 (buildroot) mtasaka at ioa.s.u-tokyo.ac.jp kdesdk-3.5.6-1.fc7 (build/make) than at redhat.com,rdieter at math.unl.edu kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 (build/make) mbacovsk at redhat.com kyum-0.7.5-4.fc6 (build/make) Jochen at herr-schmitt.de lcdproc-0.5.2-1.fc8 (buildroot) kwizart at gmail.com ldapjdk-4.17-1jpp.7 (build/make) vivekl at redhat.com libgnomedb-3.0.0-1.fc8 (build/make) j.w.r.degoede at hhs.nl libgssapi-0.10-3.fc7 (build/make) steved at redhat.com libpaper-1.1.20-5.fc6 (build/make) tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 (build/make) andreas.bierfert at lowlatency.de linux-atm-2.5.0-1.20050118cvs (build/make) dwmw2 at redhat.com maxima-5.12.0-3.fc8 (buildroot) rdieter at math.unl.edu memtest86+-1.70-1.fc7 (buildroot) wtogami at redhat.com mikmod-3.2.2-2.fc7 (build/make) jnovy at redhat.com mlton-20061107-2.fc7 (buildroot) adam at spicenitz.org mysqlclient10-3.23.58-9.2.1 (buildroot) tgl at redhat.com mysqlclient14-4.1.14-4.2.1 (build/make) tgl at redhat.com nagios-2.7-2.fc8 (build/make) mmcgrath at redhat.com nant-0.85-12.fc7 (build/make) paul at all-the-johnsons.co.uk ncview-1.92e-10.fc7 (build/make) ed at eh3.com netcdf-perl-1.2.3-3.fc8 (build/make) orion at cora.nwra.com nfs-utils-lib-1.0.8-8.fc7 (build/make) steved at redhat.com ntfs-config-1.0-0.2.beta1.fc7 (build/make) lxtnow at gmail.com openhpi-2.8.1-1.fc7 (build/make) pknirsch at redhat.com orpie-1.4.3-5.fc6 (build/make) lists at forevermore.net perl-Crypt-OpenSSL-RSA-0.25-1.fc8 (buildroot) wjhns174 at hardakers.net perl-DBIx-SQLite-Simple-0.34-2.fc8 (buildroot) foolish at guezz.net perl-ExtUtils-CBuilder-0.19-1.fc8 (build/make) jpo at di.uminho.pt perl-Imager-0.58-1.fc8 (buildroot) steve at silug.org perl-Module-Build-0.2808-1.fc8 (build/make) steve at silug.org perl-Module-Install-0.67-1.fc8 (buildroot) steve at silug.org perl-Module-Versions-Report-1.03-1.fc8 (build/make) jpo at di.uminho.pt perl-Net-IPv6Addr-0.2-3.fc8 (buildroot) foolish at guezz.net perl-Pod-Simple-3.05-1.fc8 (build/make) jpo at di.uminho.pt perl-SVN-Mirror-0.73-1.fc8 (build/make) ianburrell at gmail.com perl-Test-WWW-Mechanize-1.12-1.fc6 (build/make) jpo at di.uminho.pt php-extras-5.2.1-1.fc7 (buildroot) dmitry at butskoy.name plplot-5.7.3-2.fc7 (build/make) orion at cora.nwra.com postgresql-jdbc-8.2.504-1jpp.fc7 (build/make) tgl at redhat.com postr-0.5-3.fc7 (build/make) trond.danielsen at gmail.com ppc64-utils-0.11-4.fc7 (buildroot) pnasrat at redhat.com prelink-0.3.10-1 (build/make) jakub at redhat.com prewikka-0.9.8-1.fc7 (build/make) tscherf at redhat.com python-reportlab-2.1-1.fc8 (build/make) bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 (build/make) toshio at tiki-lounge.com rhm-0.1-3.fc7 (build/make) aconway at redhat.com,nsantos at redhat.com rhythmbox-0.11.0-4.fc8 (buildroot) bnocera at redhat.com ruby-gnome2-0.16.0-6.fc8 (buildroot) allisson at gmail.com s3switch-0.0-9.20020912.fc6 (buildroot) paul at xelerance.com scim-bridge-0.4.12-1.fc8 (build/make) phuang at redhat.com,petersen at redhat.com scrip-1.4-6.fc6 (build/make) ed at eh3.com setools-3.1-4.fc7 (build/make) dwalsh at redhat.com snort-2.6.1.3-1.fc7 (build/make) dennis at ausil.us struts-1.2.9-4jpp.6 (build/make) dbhole at redhat.com synce-software-manager-0.9.0-7.fc6 (build/make) andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-8.fc6 (build/make) andreas.bierfert at lowlatency.de syslinux-3.36-4.fc7 (buildroot) pjones at redhat.com sysprof-kmod-1.0.8-1.2.6.21_1.3116.fc7 (buildroot) giallu at gmail.com telepathy-stream-engine-0.3.23-1.fc8 (buildroot) bdpepple at ameritech.net tetex-3.0-39.fc7 (build/make) jnovy at redhat.com valgrind-3.2.3-2 (build/make) jakub at redhat.com velocity-1.4-6jpp.1 (build/make) vivekl at redhat.com x-0.3.0-1.fc7.src.rpm xchat-2.8.2-7.fc8.src.rpm xen-3.1.0-0.rc7.1.fc7 (buildroot) riel at redhat.com xferstats-2.16-14.1 (build/make) than at redhat.com xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser at redhat.com xorg-x11-drv-apm-1.1.1-5.fc8 (buildroot) ajackson at redhat.com xorg-x11-drv-calcomp-1.1.0-2.fc7 (build/make) krh at redhat.com xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) krh at redhat.com xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) krh at redhat.com xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) krh at redhat.com xorg-x11-drv-evdev-1.1.2-3.fc7 (build/make) krh at redhat.com xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) krh at redhat.com xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) krh at redhat.com xsupplicant-1.2.8-1.fc7.1 (build/make) tcallawa at redhat.com yelp-2.18.1-4.fc8 (buildroot) mbarnes at redhat.com With bugs filed: 0 ---------------------------------- -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tcallawa at redhat.com Mon Jun 4 04:18:01 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 03 Jun 2007 23:18:01 -0500 Subject: fedora for ARM In-Reply-To: <20070602183828.GI7445@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> Message-ID: <1180930681.6254.616.camel@localhost.localdomain> On Sat, 2007-06-02 at 14:38 -0400, Dave Jones wrote: > # CONFIG_UTRACE is not set > > note that this will also disable ptrace too afaik. > (I'm aware that there are difficulties of porting utrace to arm). FWIW, we have the same difficulty with sparc32, but I'm almost certainly going to drop support for that arch with F-8. ~spot From greno at verizon.net Mon Jun 4 04:38:33 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 04 Jun 2007 00:38:33 -0400 Subject: F7 install CDROM unrecognized Message-ID: <46639749.5010409@verizon.net> I've been trying to install Fedora 7 today from DVD on a couple workstations and also in a QEMU Guest on an FC6 machine. The install gets stuck everytime when I OK the CDROM installation type screen. It's not recognizing the CDROM drives for some reason and just keeps prompting for driver selection for this install type. Is there some parameter that I need to pass in? I've been working on this for hours and no luck on either machine or with QEMU. From rc040203 at freenet.de Mon Jun 4 04:40:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jun 2007 06:40:14 +0200 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706031721.l53HLJ4O013921@laptop13.inf.utfsm.cl> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> <1180878850.12595.583.camel@mccallum.corsepiu.local> <200706031721.l53HLJ4O013921@laptop13.inf.utfsm.cl> Message-ID: <1180932014.12595.660.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 13:21 -0400, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: > > > On 03.06.2007 15:17, Jesse Keating wrote: > > > > On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: > > > >> Well, see all those discussion that happened when ACLs were added, kjoi > > > >> introduced, the freezes were introduced and bodi put in place. Sure, > > > >> there are always discussions, but all those were quite worse and there > > > >> was a lot of confusion afaics... Don't read fedora-maintainers for a > > > >> week and suddenly you are not aware of how to build or push a package. > > > > So without reading the mailing list for maintainers, > > > > > > A low-traffic fedora-maintainers-announce was requested multiple times > > > as some contributors mentioned that fedora-maintainers is to noisy for > > > them. > > One way traffic is inappropriate for a community project. > > Wrong... in any biggish community there are people who are very into it, > and others more peripherally interested. Well, IMO, maintainers are supposed to be more than peripherally interested and supposed to be interested in changes/decisions on the workflow sooner or later directly affecting them. At least to me, ATM, Fedora is facing the problem of "some anonymous dark circles" drawing "lonesome" decisions and pushing semi-cooked/immature infrastructural tools, apparently without having "wasted much brains" on the consequences their deeds might have. > > > Like it or not, but for some people fedora-maintainers has to much > > > traffic; > > > Then they better should not be maintainers! > > Right. But there are other people interested in maintainance. Yes, we don't need everybody, esp. not "drive-by package bombs" (Which occasionally had been a problem in FE) and don't need "half-hearted maintainers" who only package something because "it's their unloved duty" (which occasionally seems to be a problem with @RH-maintained packages). Ralf From abraxis at telkomsa.net Mon Jun 4 04:56:38 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Mon, 4 Jun 2007 06:56:38 +0200 Subject: pungi error In-Reply-To: <200706030858.33755.jkeating@redhat.com> References: <20070603060025.GA13719@eeyore.32.boerneef.vornavalley> <200706030858.33755.jkeating@redhat.com> Message-ID: <20070604045638.GB13719@eeyore.32.boerneef.vornavalley> On Sun, Jun 03, 2007 at 08:58:33AM -0400, Jesse Keating wrote: > On Sunday 03 June 2007 02:00:25 Neil Thompson wrote: > > This happens with the pungi stalled with F7 as well as pungi-0.3.7-1 pulled > > from updates-testing. ?Any ideas? > > Are you composing i386 on an i386 or x86_64 on an x86_64 or are you doing some > cross thing like i386 on an x86_64 or x86_64 on an i386 (or ppc)? Due to > anaconda tools, composes must happen on the same arch. You can use things > like mock and setarch i386 to be able to compose i386 on x86_64, but not the > opposite. > Nope - I'm running an i386 F7. I am running on an X86_64 processor, but that should should make no difference. -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From jdogalt at yahoo.com Mon Jun 4 05:23:45 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Sun, 3 Jun 2007 22:23:45 -0700 (PDT) Subject: RFE: use nasa worldwind for timezone selection (i.e. my first reaction to F7) In-Reply-To: <20070601191839.GE7580@nostromo.devel.redhat.com> Message-ID: <978999.98455.qm@web56907.mail.re3.yahoo.com> --- Bill Nottingham wrote: > > If you are going to go to that much effort for the thing, why not > take > > it a notch further and just integrate nasa worldwind into the > anaconda. > > That's 16MB more to put in the boot/install images... Not really a problem for the live(cd/dvd/bluray/usbflash) installer case though. (Since clearly in that case, the 16MB is well justified as a cool eye-candy app to have on the livecd for non-installer purposes) -dmc/jdog ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From davej at redhat.com Mon Jun 4 05:41:09 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 4 Jun 2007 01:41:09 -0400 Subject: fedora for ARM In-Reply-To: <1180930681.6254.616.camel@localhost.localdomain> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> Message-ID: <20070604054109.GA4702@redhat.com> On Sun, Jun 03, 2007 at 11:18:01PM -0500, Tom spot Callaway wrote: > On Sat, 2007-06-02 at 14:38 -0400, Dave Jones wrote: > > # CONFIG_UTRACE is not set > > > > note that this will also disable ptrace too afaik. > > (I'm aware that there are difficulties of porting utrace to arm). > > FWIW, we have the same difficulty with sparc32, but I'm almost certainly > going to drop support for that arch with F-8. Normally in this situation I whip out my trusty "Both users will be crushed" gag, but in this case, I think we'd be hard pressed to find two users of that arch. Dave -- http://www.codemonkey.org.uk From lmacken at redhat.com Mon Jun 4 06:20:24 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 4 Jun 2007 02:20:24 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <46603361.2070507@hhs.nl> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <1180708585.3946.6.camel@zebes.localdomain> <46603361.2070507@hhs.nl> Message-ID: <20070604062024.GL13318@tomservo.rochester.rr.com> On Fri, Jun 01, 2007 at 04:55:29PM +0200, Hans de Goede wrote: > Will Woods wrote: > > Let's be a little more clear here - what the QA team actually does for > > packages in updates-testing is *verification*. Check package sanity, > > make sure programs don't segfault on startup, etc. I'm not expecting all > > testers to understand the functions of the > > packages as well as their maintainers. But anyone can tell if you missed > > some deps or your package doesn't start on x86_64. > > 1) I already verify my packages on x86_64 myself That's great. I don't. > 2) starting libs is kinda hard Agreed. Matthias Clasen mentioned on fedora-maintainers how the RHEL errata tool has a field where the engineer is supposed to fill in QA test instructions, which might be a very useful thing for bodhi to have. > 3) Most missing deps are subtile and do not necesarry show when just running > an > app > > It would be more usefull to check build-logs for things like: > -suspicious ./configure failures (due to missing BuildRequires) > -64 bit suspecious compiler output like cast from different size integer to > pointer (this could actually be automated) I just added a 'Build Logs' link to updates in bodhi. luke From shams at orcon.net.nz Sun Jun 3 18:21:50 2007 From: shams at orcon.net.nz (Shams) Date: Mon, 4 Jun 2007 06:21:50 +1200 Subject: Why isn't emacs installed by default Message-ID: Hi, I was just wondering is there any reason that emacs is not selected and installed by default ie. with just the default install options in Anaconda.. Thanks Shams -- From kevin.kofler at chello.at Mon Jun 4 06:29:47 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 4 Jun 2007 06:29:47 +0000 (UTC) Subject: Announcing Quarticurve: Unofficial Bluecurve Qt 4 port Message-ID: Hi everyone, I'm announcing the project I've just spent this night on. Forgive me if this announcement sounds bad, one can't sleep and code at the same time, so I'm pretty tired now. ;-) WARNING: This is an early alpha version (a one-night hack), it is NOT ready for production use yet! See the "Is it stable?" question below. * What is Quarticurve? Quarticurve is a port of Red Hat's Bluecurve widget theme (taken out of redhat-artwork 7.0.0) to Qt 4. (I started from the Qt 3 theme.) This port is NOT endorsed or supported by Red Hat. * Where does the Quarticurve name come from? A contraction of "Quartic" and "curve". Where "curve" comes from should be pretty obvious, as for "Quartic", it contains 'Q', 't' and conveys the idea of '4'. :-) * What license is Quarticurve under? GPL version 2, just as Bluecurve. * Is it stable? Not yet. I don't know about crashes (though I can't exclude them), but there are definitely several rendering glitches needing to be fixed before this is really usable. * I want to test it anyway / send patches, where do I get it? http://www.tigen.org/kevin.kofler/pcprogs/quarticurve.7z (You need p7zip to extract the archive.) * What about the KDM theme? I'll consider porting that to KDE 4 once the Quarticurve widget theme works. * What about the icon theme? That should just need a few symlinks to work fine with KDE 4 (it has some of the needed symlinks already, mostly those required by the icon-naming-spec, but not all, especially those where the KDE 4 name is just the KDE 3 name with dashes instead of underscores), I plan to make a list of the needed symlinks and get that straight upstream into redhat-artwork. * Is this a contribution to the Fedora Project? This is Not a Contribution under the CLA, however it is Free Software under the GPL and can thus be packaged for Fedora like any other GPLed upstream project. (In fact, I plan to submit a package once the annoying rendering glitches are fixed.) Kevin Kofler From lxtnow at gmail.com Mon Jun 4 06:41:45 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Mon, 4 Jun 2007 02:41:45 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <46639749.5010409@verizon.net> References: <46639749.5010409@verizon.net> Message-ID: <62bc09df0706032341u43dbcc82icc81a66fb6abcc84@mail.gmail.com> 2007/6/4, Gerry Reno : > > I've been trying to install Fedora 7 today from DVD on a couple > workstations and also in a QEMU Guest on an FC6 machine. The install > gets stuck everytime when I OK the CDROM installation type screen. It's > not recognizing the CDROM drives for some reason and just keeps > prompting for driver selection for this install type. Is there some > parameter that I need to pass in? I've been working on this for hours > and no luck on either machine or with QEMU. it seem that your copy DVD isn't good. check your image iso and your next DVD copy after the burn. -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Mon Jun 4 06:42:23 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 4 Jun 2007 06:42:23 +0000 (UTC) Subject: Announcing Quarticurve: Unofficial Bluecurve Qt 4 port References: Message-ID: Oops, I wrote: > * What about the KDM theme? > I'll consider porting that to KDE 4 once the Quarticurve widget theme works. I actually meant the KWin theme (window decorations). I really do need some sleep. ;-) Kevin Kofler From wolfy at nobugconsulting.ro Mon Jun 4 06:58:03 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 04 Jun 2007 09:58:03 +0300 Subject: Why isn't emacs installed by default In-Reply-To: References: Message-ID: <4663B7FB.6000602@nobugconsulting.ro> Shams wrote: > Hi, > > I was just wondering is there any reason that emacs is not selected and > installed by default ie. with just the default install options in Anaconda.. > > Maybe because not everybody (me included) wants a second OS installed together with Fedora ? I am more then satisfied with having vim and I would be sad if I would have to chase emacs in the settings in order to remove it. From bernie at codewiz.org Mon Jun 4 07:00:34 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Mon, 04 Jun 2007 03:00:34 -0400 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <20070604041709.GA4192@serv.smile.org.ua> References: <46638909.3090006@codewiz.org> <20070604041709.GA4192@serv.smile.org.ua> Message-ID: <4663B892.1000001@codewiz.org> Andy Shevchenko wrote: > Hi Bernardo Innocenti! > > On Sun, Jun 03, 2007 at 11:37:45PM -0400, Bernardo Innocenti wrote next: > >> Is it possible? > I don't know about yum, but you can push > %_excludedocs 1 > to the rpmmacros. Good idea! Then I could also abuse %_netsharedpath to prune /usr/share/doc and /usr/share/locale. > Also, this macro provides too many warnings at install (due to crash > info-install in %post). As I remember correctly someone discussed this issue > here (or in formed fedora-extras-list) several month ago. That's why I hate packages with scripts. The more we make packages active and smart, the more we end up with a Windows-like installation hell. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From dev at nigelj.com Mon Jun 4 07:03:05 2007 From: dev at nigelj.com (Nigel Jones) Date: Mon, 04 Jun 2007 19:03:05 +1200 Subject: Why isn't emacs installed by default In-Reply-To: References: Message-ID: <4663B929.6050206@nigelj.com> Shams wrote: > Hi, > > I was just wondering is there any reason that emacs is not selected and > installed by default ie. with just the default install options in Anaconda.. > > Thanks > Shams > My guess is that the number of people that don't use it, far outweigh the number of people that do. While some people may find this sad it's an honest truth and it seems pointless to force emacs onto a great deal of the users that don't want it. On a side note, it appears your clock is 12 hours out ;) N.J. From mschwendt.tmp0701.nospam at arcor.de Mon Jun 4 07:14:05 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 4 Jun 2007 09:14:05 +0200 Subject: Bugzilla and updates system? Message-ID: <20070604091405.d4e7c7f1.mschwendt.tmp0701.nospam@arcor.de> Did this come from the new updates system? I wonder why an F7 update changed an already closed FE7 bug and why it dropped the release version? [...] Begin forwarded message: Date: Mon, 4 Jun 2007 00:16:00 -0400 From: bugzilla redhat com To: bugs.michael gmx net Subject: [Bug 240835] Bad Provides interfere with Core and buildsys Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Bad Provides interfere with Core and buildsys https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240835 updates fedoraproject org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |CLOSED Resolution|CURRENTRELEASE |NEXTRELEASE Fixed In Version|2.1.0-22.fc6 |2.1.0 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. From bernie at codewiz.org Mon Jun 4 07:37:44 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Mon, 04 Jun 2007 03:37:44 -0400 Subject: Unwanted RPM dependencies Message-ID: <4663C148.1040909@codewiz.org> (Cc'ing all the relevant package maintainers. sorry if I got someone else by mistake) We could get rid of a few packages on the OLPC in a cleaner way if we could loosen dependencies a little. Some random things I noticed: - cracklib has a hard dependency on pam. Is there a way we could make it optional? - mkinitrd depends on lvm2 and dmraid. Both could easily be made optional. - hal depends on cryptsetup-luks (containing bulky 1.2MB static binary in /sbin) - libuser and GConf2-dbus bring in openldap, which brings in cyrus-sasl Using pristine Fedora packages in OLPC is an advantage for support and upgrades. Also, reducing the minimum install generally benefits other Fedora spins for other small systems. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From jos at xos.nl Mon Jun 4 07:39:45 2007 From: jos at xos.nl (Jos Vos) Date: Mon, 4 Jun 2007 09:39:45 +0200 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <4663B892.1000001@codewiz.org>; from bernie@codewiz.org on Mon, Jun 04, 2007 at 03:00:34AM -0400 References: <46638909.3090006@codewiz.org> <20070604041709.GA4192@serv.smile.org.ua> <4663B892.1000001@codewiz.org> Message-ID: <20070604093945.A7119@xos037.xos.nl> On Mon, Jun 04, 2007 at 03:00:34AM -0400, Bernardo Innocenti wrote: > Andy Shevchenko wrote: > > > Also, this macro provides too many warnings at install (due to crash > > info-install in %post). As I remember correctly someone discussed this issue > > here (or in formed fedora-extras-list) several month ago. > > That's why I hate packages with scripts. The more we make > packages active and smart, the more we end up with a > Windows-like installation hell. I agree, but some "normal" things (like administering info files, ldconfig, and creating package-specific users) are unavoidable. But: the problem with --excludedocs can be solved easily by just checking in %post whether the info files are present or not. Are there no guidelines about this? If not, shouldn't they be made? I've seen (and reported) this problem already in Red Hat Linux 7.3 (!), so not mnuch seems to have improved since then in this area. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From j.w.r.degoede at hhs.nl Mon Jun 4 07:35:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jun 2007 09:35:55 +0200 Subject: Release x86_64 rawhide rebuild in mock status 2007-06-03 In-Reply-To: <20070603152937.A17627@humbolt.us.dell.com> References: <20070603152937.A17627@humbolt.us.dell.com> Message-ID: <4663C0DB.8020006@hhs.nl> Matt Domsch wrote: > Release Rawhide-in-Mock Build Results for x86_64 Sun Jun 3 09:09:00 CDT 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 4290 > Number failed to build: 155 > Number expected to fail due to ExclusiveArch or ExcludeArch: 32 > Leaving: 123 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 123 > ---------------------------------- > 7.src.rpm > libgnomedb-3.0.0-1.fc8 (build/make) j.w.r.degoede at hhs.nl Something weird is going on here, it has build libgda-3.0.1 during the rebuild, but when building libgnomedb, libgda-1.9.100 gets installed into the buildroot, Regards, Hans From pnasrat at redhat.com Mon Jun 4 07:48:36 2007 From: pnasrat at redhat.com (Paul Nasrat) Date: Mon, 04 Jun 2007 08:48:36 +0100 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <46638909.3090006@codewiz.org> References: <46638909.3090006@codewiz.org> Message-ID: <1180943317.27673.16.camel@enki.eridu> On Sun, 2007-06-03 at 23:37 -0400, Bernardo Innocenti wrote: > Is it possible? > > This would reduce the amount of postprocessing > we need to do when building OLPC images. excludedocs can be done using the ability to set macros which are available within the rpm-python api, so you could easily write a plugin to handle this, or use a macro file in /etc/rpm/macros.nodocs or something. Excludepath is essentially a special case (NULL) relocation, and relocations currently aren't supported within rpm-python. Paul From jeevanullas at gmail.com Mon Jun 4 08:16:40 2007 From: jeevanullas at gmail.com (Deependra Shekhawat) Date: Mon, 4 Jun 2007 13:46:40 +0530 Subject: F7 install CDROM unrecognized In-Reply-To: <62bc09df0706032341u43dbcc82icc81a66fb6abcc84@mail.gmail.com> References: <46639749.5010409@verizon.net> <62bc09df0706032341u43dbcc82icc81a66fb6abcc84@mail.gmail.com> Message-ID: <57127b5f0706040116q385a9b54qa4c8a2250ed7ae56@mail.gmail.com> I don't think so. From my experience in #fedora at irc.freenode.net it seems more of like driver problem with libata having some problems. Thanks. On 6/4/07, SmootherFrOgZ wrote: > > > > 2007/6/4, Gerry Reno : > > > > I've been trying to install Fedora 7 today from DVD on a couple > > workstations and also in a QEMU Guest on an FC6 machine. The install > > gets stuck everytime when I OK the CDROM installation type screen. It's > > not recognizing the CDROM drives for some reason and just keeps > > prompting for driver selection for this install type. Is there some > > parameter that I need to pass in? I've been working on this for hours > > and no luck on either machine or with QEMU. > > > it seem that your copy DVD isn't good. check your image iso and your next > DVD copy after the burn. > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora Extras Contributor > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Enjoy Life ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Mon Jun 4 08:26:31 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 04 Jun 2007 10:26:31 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <4663C148.1040909@codewiz.org> References: <4663C148.1040909@codewiz.org> Message-ID: <1180945591.3241.9.camel@perun.kabelta.loc> On Mon, 2007-06-04 at 03:37 -0400, Bernardo Innocenti wrote: > We could get rid of a few packages on the OLPC in a cleaner > way if we could loosen dependencies a little. > > Some random things I noticed: > > - cracklib has a hard dependency on pam. Is there a way > we could make it optional? You mean the other way around - pam has a hard dependency on cracklib. The dependency could be removed but cracklib would be brought in anyway - throug the automatic dependency on libcrack.so. This library (and cracklib-dicts) is required by pam_cracklib module and the only solution would be to make pam_cracklib a subpackage of the main pam package. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From d.lesca at solinos.it Mon Jun 4 08:34:51 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Mon, 04 Jun 2007 10:34:51 +0200 Subject: F7: action when hardware event is generated (ex acpid package) Message-ID: <1180946091.3885.21.camel@lesca.home.solinos.it> What have substitute acpid service in F7? My server system work in 'init 3' mode: Howto I can configure the "substitute of acpid" for execute some action when a hardware event (like poweroff button pressed) is generate from ACPI? Or I must reinstall acpid (yum install acpid)? Many thanks for reply -- Dario Lesca From buildsys at redhat.com Mon Jun 4 08:45:14 2007 From: buildsys at redhat.com (Build System) Date: Mon, 4 Jun 2007 04:45:14 -0400 Subject: rawhide report: 20070604 changes Message-ID: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> New package muine-scrobbler Audioscrobbler plugin for Muine Removed package yum-presto Updated Packages: CGAL-3.3-2.fc8 -------------- * Sat Jun 02 2007 Laurent Rineau - 3.3-2.fc8 - Officiel CGAL-3.3 release - Skip file named "skip_vcproj_auto_generation" Democracy-0.9.5.1-10.fc8 ------------------------ * Sat Jun 02 2007 Thorsten Scherf 0.9.5.1-10 - Updated to handle python 2.5 and a new dbus * Sat Jun 02 2007 Thorsten Scherf 0.9.5.1-9 - new firefox deps WindowMaker-0.92.0-13.fc8 ------------------------- * Sun Jun 03 2007 Andreas Bierfert 0.92.0-13 - fix a menu bug for WPrefs - clean up menu path alleggl-0.4.1-1.fc8 ------------------- * Sun Jun 03 2007 Hans de Goede 0.4.1-1 - New upstream release 0.4.1 final aplus-fsf-4.20.2-18.fc8 ----------------------- * Sun Jun 03 2007 Jochen Schmitt 4.20.2-18 - Correcting Typos (#242304) - Add libtool as a BR * Thu Feb 15 2007 Jochen Schmitt 4.20.2-16 - Remove dependency to automake-1.6 * Wed Feb 14 2007 Jochen Schmitt 4.20.2-14 - A beeter solution for the multilib issue apt-0.5.15lorg3.2-10.fc8 ------------------------ * Sun Jun 03 2007 Axel Thimm - 0.5.15lorg3.2-10 - Make autoupdates a bit more quiet (Pierre Ossman ). asymptote-1.29-2.fc8 -------------------- * Sat Jun 02 2007 Jose Pedro Oliveira - 1.29-2 - Add asy-faq to install-info (#155750). - Add support for vim 7.1. autofs-1:5.0.1-12 ----------------- * Sun Jun 03 2007 Ian Kent - 5.0.1-12 - correct mistake in logic test in wildcard lookup. * Mon May 07 2007 Ian Kent - 5.0.1-10 - fix master map lexer to admit "." in macro values. blobAndConquer-0.91-1.fc8 ------------------------- brasero-0.5.2-4.fc8 ------------------- * Sun Jun 03 2007 Denis Leroy - 0.5.2-4 - Removed beagle support for ppc64 * Tue May 22 2007 Denis Leroy - 0.5.2-3 - Added umask 022 to scriptlets (#230781) * Mon May 21 2007 Denis Leroy - 0.5.2-2 - Rebuild to pick up new totem library dejavu-fonts-2.17-5.fc8 ----------------------- * Sun Jun 03 2007 Nicolas Mailhot ??? 2.17-5 ??? declare DejaVu a valid Bitstream Prima??? substitute fail2ban-0.8.0-8.fc8 -------------------- * Sun Jun 03 2007 Axel Thimm - 0.8.0-8 - Also trigger on non-AllowUsers failures (Jonathan Underwood ). firefox-2.0.0.4-2.fc8 --------------------- * Sun Jun 03 2007 Christopher Aillon 2.0.0.4-2 - Properly clean up threads with newer NSPR * Wed May 30 2007 Christopher Aillon 2.0.0.4-1 - Final version * Wed May 23 2007 Christopher Aillon 2.0.0.4-0.rc3 - Update to 2.0.0.4 RC3 fluxbox-1.0.0-0.2.rc3.fc8 ------------------------- * Sun Jun 03 2007 Andreas Bierfert 1.0.0-0.2.rc3 - fix #242187 gnome-python2-desktop-2.18.0-2.fc8 ---------------------------------- * Sun Jun 03 2007 Matthew Barnes - 2.18.0-2.fc8 - Require metacity-devel, not metacity, for building. - Add patch for GNOME bug #428697 (adapt to API change). gnu-regexp-1.1.4-10jpp.2.fc8 ---------------------------- * Sun Jun 03 2007 Florian La Roche - 1.1.4-10jpp.2 - remove Distribution: tag from .spec file gnu-smalltalk-2.3.5-1.fc8 ------------------------- * Sun Jun 03 2007 Jochen Schmitt 2.3.5-1 - New upstream release * Wed May 30 2007 Jochen Schmitt 2.3.4-4 - Remove references to sigseg lib shiped with the package * Mon May 28 2007 Jochen Schmitt 2.3.4-1 - New upstream release gperf-3.0.3-1.fc8 ----------------- * Sun Jun 03 2007 Florian La Roche - 3.0.3 gsynaptics-0.9.12-2.fc8 ----------------------- * Sun Jun 03 2007 Thorsten Leemhuis - 0.9.12-2 - Use ExclusiveArch just as synaptics does * Sun Jun 03 2007 Thorsten Leemhuis - 0.9.12-1 - Update to 0.9.12 - Add category HardwareSettings to desktop file (#242345) gtk-recordmydesktop-0.3.4-1.fc8.1 --------------------------------- * Sat Jun 02 2007 Sindre Pedersen Bj??rdal - 0.3.4-1 - New version 0.3.4 * Tue Mar 06 2007 Sindre Pedersen Bj??rdal - 0.3.3.1-2 - Preserve timestamps * Mon Mar 05 2007 Sindre Pedersen Bj??rdal - 0.3.3.1-2 - Add missing BR hwbrowser-0.32-1.fc7 -------------------- * Tue Apr 24 2007 Nils Philippsen - 0.32 - merge review (#225892): - desktop file: use "true" instead of "0", don't use obsolete Application category - don't use macros in %changelog - remove hashbang from DeviceList.py libchewing-0.3.0-8.fc8 ---------------------- * Fri Jun 01 2007 Caius Chance - 0.3.0-8.devel - Fixed bz#237916: [chewing] Candidate list (symbol) page change inaccracy. * Fri Apr 20 2007 Caius Chance - 0.3.0-7.fc7 - Fixed bz#237233: Up arrow on candidate list doesn't work. nano-2.0.6-1.fc8 ---------------- * Sun Jun 03 2007 Florian La Roche - 2.0.6-1 - update to 2.0.6 nx-2.1.0-22.fc7 --------------- * Fri Jun 01 2007 Axel Thimm - 2.1.0-22 - Sync with ATrpms' nxfindprovides helper. * Wed May 23 2007 Axel Thimm - 2.1.0-21.1 - Fix typo in nxwrapper.in (PKGEXECDIR -> PKGLIBEXECDIR). * Tue May 22 2007 Axel Thimm - 2.1.0-20 - readded Source11 to filter find-provides from showing libraries that should not be provided to the system. BZ#194652 & 240835. perl-POE-Component-SimpleDBI-1.16-1.fc8 --------------------------------------- * Sun Jun 03 2007 Chris Weyl 1.16-1 - update to 1.16 - add t/ to doc - spec rework for the once and future perl split pgfouine-1.0-2.fc8 ------------------ * Sun Jun 03 2007 Devrim Gunduz - 1.0-2 - Bumped up spec version pidgin-2.0.1-2.fc8 ------------------ * Thu May 31 2007 Stu Tomlinson - 2.0.1-2 - Call g_thread_init early (#241883) - Fix purple-remote syntax error (#241905) * Mon May 28 2007 Stu Tomlinson - 2.0.1-1 - 2.0.1 * Wed May 09 2007 Stu Tomlinson - 2.0.0-3 - Split out Perl plugin support into subpackages - Add Tcl plugin support in a subpackage postgresql-8.2.4-1.fc7 ---------------------- * Tue Apr 24 2007 Tom Lane 8.2.4-1 - Update to PostgreSQL 8.2.4 for CVE-2007-2138, data loss bugs Resolves: #237682 * Wed Feb 14 2007 Karsten Hopp 8.2.3-2 - rebuild with tcl-8.4 * Wed Feb 07 2007 Tom Lane 8.2.3-1 - Update to PostgreSQL 8.2.3 due to regression induced by security fix Resolves: #227522 python-docs-2.5.1-1.fc8 ----------------------- * Sun Jun 03 2007 Florian La Roche - 2.5.1-1 - update to 2.5.1 smart-0.50-46.fc8 ----------------- * Sun Jun 03 2007 Axel Thimm - 0.50-46 - Autodetect pam_stack module at build time. solfege-3.8.0-1.fc8 ------------------- * Mon Jun 04 2007 Sindre Pedersen Bj??rdal - 3.8.0-1 - New major release synaptic-0.57.2-6.fc8 --------------------- * Sun Jun 03 2007 Axel Thimm - 0.57.2-6 - Autodetect pam_stack module at build time. syncekonnector-0.3.2-2.fc8 -------------------------- system-config-nfs-1.3.25-1.fc7 ------------------------------ * Wed Apr 25 2007 Nils Philippsen 1.3.25 - pick up updated language files * Thu Mar 22 2007 Nils Philippsen - update URL * Tue Mar 20 2007 Nils Philippsen - mention that we are upstream - use preferred buildroot - clean buildroot before installing - fix licensing blurb in PO files - require python >= 2.0 instead of python2 taxipilot-0.9.2-1.fc8 --------------------- tclchecker-1.4-2.20061030cvs.fc8 -------------------------------- tcldebugger-1.4-3.20061030cvs.fc8 --------------------------------- tclpro-1.5.0-7.20061030cvs.fc8 ------------------------------ * Sat Jun 02 2007 Wart 1.5.0-7.20061030cvs - Move to a tcl-specific directory for faster loading viewvc-1.0.4-2.fc8 ------------------ * Sun Jun 03 2007 Bojan Smojver - 1.0.4-2 - Avoid import cycle errors (temporary fix) wallpapoz-0.4-2.fc8 ------------------- * Mon Jun 04 2007 Mamoru Tasaka - 0.4-2 - Require xorg-x11-utils (bug 242349) wine-0.9.38-2.fc8 ----------------- * Sun Jun 03 2007 Andreas Bierfert 0.9.38-2 - allow full opt flags again - set ExclusiveArch to i386 for koji to only build i386 * Sat Jun 02 2007 Andreas Bierfert 0.9.38-1 - version upgrade (#242087) - fix menu problem (#220723) - fix BR - clean up desktop file section * Wed May 23 2007 Andreas Bierfert 0.9.37-1 - version upgrade - add BR for xcursor (#240648) - add desktop entry for wineboot (#240683) - add mime handler for msi files (#240682) - minor cleanups wine-docs-0.9.38-1.fc8 ---------------------- * Sun Jun 03 2007 Andreas Bierfert 0.9.38-1 - version upgrade xml-commons-apis12-0:1.2.04-0jpp.4.fc8 -------------------------------------- * Sun Jun 03 2007 Florian La Roche - 0:1.2.04-0jpp.4 - the javadoc subrpm used an undefined macro From dwmw2 at infradead.org Sun Jun 3 16:01:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 03 Jun 2007 17:01:37 +0100 Subject: Don't put new packages through updates-testing In-Reply-To: <1180872298.3218.23.camel@vader.jdub.homelinux.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <1180806380.25232.137.camel@pmac.infradead.org> <1180821475.3218.1.camel@vader.jdub.homelinux.org> <1180857282.25232.145.camel@pmac.infradead.org> <1180872298.3218.23.camel@vader.jdub.homelinux.org> Message-ID: <1180886497.25232.151.camel@pmac.infradead.org> On Sun, 2007-06-03 at 07:04 -0500, Josh Boyer wrote: > Yes, I understand that. You know you can remove them right? No. I wanted to update my private branch of Evolution last week -- the one I've been maintaining for years to make it actually usable for me. My commit failed. How do I fix it? -- dwmw2 From alan at redhat.com Mon Jun 4 08:49:14 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Jun 2007 04:49:14 -0400 Subject: fedora for ARM In-Reply-To: <1180930681.6254.616.camel@localhost.localdomain> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> Message-ID: <20070604084914.GC30973@devserv.devel.redhat.com> On Sun, Jun 03, 2007 at 11:18:01PM -0500, Tom spot Callaway wrote: > On Sat, 2007-06-02 at 14:38 -0400, Dave Jones wrote: > > # CONFIG_UTRACE is not set > > > > note that this will also disable ptrace too afaik. > > (I'm aware that there are difficulties of porting utrace to arm). > > FWIW, we have the same difficulty with sparc32, but I'm almost certainly > going to drop support for that arch with F-8. I thought the goal of Fedora was to track upstream. Alan From alan at redhat.com Mon Jun 4 09:11:46 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Jun 2007 05:11:46 -0400 Subject: Change to U.T.C. based release times In-Reply-To: <155a01c7a558$092a2310$0a00000a@DEAD2> References: <20070602224229.1219ebdb@lain.camperquake.de> <155a01c7a558$092a2310$0a00000a@DEAD2> Message-ID: <20070604091146.GE30973@devserv.devel.redhat.com> On Sat, Jun 02, 2007 at 10:53:13PM +0200, Hans K. Rosbach wrote: > Maybe timings should be specified as ex: "10:00 UTC/GMT" just for clarity. > Atleast it is my understanding that GMT is what most europeans learn to This is confusing - there is no such thing as GMT. GMT is an ex time measurement system. It is no more. It has ticked its last etc..etc We should not use "GMT" because there is no such thing any more. UTC or UT have taken over. Alan From caillon at redhat.com Mon Jun 4 09:11:51 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 05:11:51 -0400 Subject: rawhide report: 20070604 changes In-Reply-To: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> Message-ID: <4663D757.30901@redhat.com> > pidgin-2.0.1-2.fc8 > ------------------ > * Thu May 31 2007 Stu Tomlinson - 2.0.1-2 > - Call g_thread_init early (#241883) Um, this is a bug in GTK+ and you probably don't want to work around the issue by touching threading stuff if you don't have a good reason. I'd recommend reverting the above change and waiting a day or two for GTK+ 2.11.1 From twoerner at redhat.com Mon Jun 4 09:30:52 2007 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 04 Jun 2007 11:30:52 +0200 Subject: Firewall configuration tool: system-config-firewall In-Reply-To: <46633CE8.1010706@conversis.de> References: <46602E12.7080008@redhat.com> <46633CE8.1010706@conversis.de> Message-ID: <4663DBCC.5020706@redhat.com> Hello, here is a new version with some import fixes altogether with pakaging fixes (now noarch, python modules mostly in tui sub package) and fixed requirements: http://koji.fedoraproject.org/scratch/twoerner/task_25448/ Thanks, Thomas Dennis Jacobfeuerborn wrote: > Thomas Woerner wrote: >> Hello, >> >> system-config-firewall is a new firewall configuration tool, which is >> based on system-config-securitylevel and provides enhanced >> funtionality and better user guidance. >> >> Please have a look at: >> http://koji.fedoraproject.org/scratch/twoerner/task_22791/ >> You will need system-config-firewall and system-config-firewall-tui >> packages for your architecture. > > I'm getting an error when I try to start system-config-firewall: > > [root at nexus ~]# system-config-firewall > Traceback (most recent call last): > File "/usr/share/system-config-firewall/system-config-firewall.py", > line 12, in > import fw_gui > File "/usr/share/system-config-firewall/fw_gui.py", line 32, in > from fw_config import * > File "/usr/share/system-config-firewall/fw_config.py", line 64, in > > from netconfpkg import NCDeviceList > ImportError: No module named netconfpkg > > Regards, > Dennis > -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner D-70178 Stuttgart Web : http://www.redhat.de/ From david at lovesunix.net Mon Jun 4 09:37:56 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 04 Jun 2007 11:37:56 +0200 Subject: rawhide report: 20070604 changes In-Reply-To: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> Message-ID: <1180949876.5019.0.camel@dawkins> man, 04 06 2007 kl. 04:45 -0400, skrev Build System: > Removed package yum-presto Wait a second... didn't we just put this fine piece of work in? - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From galibert at pobox.com Mon Jun 4 09:39:55 2007 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 4 Jun 2007 11:39:55 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <4663B929.6050206@nigelj.com> References: <4663B929.6050206@nigelj.com> Message-ID: <20070604093954.GB27020@dspnet.fr.eu.org> On Mon, Jun 04, 2007 at 07:03:05PM +1200, Nigel Jones wrote: > My guess is that the number of people that don't use it, far outweigh > the number of people that do. While some people may find this sad it's > an honest truth and it seems pointless to force emacs onto a great deal > of the users that don't want it. Really? What are your numbers and how did you come to them? Because every linux user I know uses *emacs or vi* except for one that uses nedit. OG. From pertusus at free.fr Mon Jun 4 09:39:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 11:39:18 +0200 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <20070604093945.A7119@xos037.xos.nl> References: <46638909.3090006@codewiz.org> <20070604041709.GA4192@serv.smile.org.ua> <4663B892.1000001@codewiz.org> <20070604093945.A7119@xos037.xos.nl> Message-ID: <20070604093918.GA2856@free.fr> On Mon, Jun 04, 2007 at 09:39:45AM +0200, Jos Vos wrote: > > Are there no guidelines about this? If not, shouldn't they be made? There are, at least now. > I've seen (and reported) this problem already in Red Hat Linux 7.3 (!), > so not mnuch seems to have improved since then in this area. Ville (if I recall well) reported all the issues, and they were blocking the merge review so hopefully everything is solved or will be (in devel). -- Pat From galibert at pobox.com Mon Jun 4 09:42:29 2007 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 4 Jun 2007 11:42:29 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <4663B7FB.6000602@nobugconsulting.ro> References: <4663B7FB.6000602@nobugconsulting.ro> Message-ID: <20070604094228.GC27020@dspnet.fr.eu.org> On Mon, Jun 04, 2007 at 09:58:03AM +0300, Manuel Wolfshant wrote: > Maybe because not everybody (me included) wants a second OS installed > together with Fedora ? > I am more then satisfied with having vim and I would be sad if I would > have to chase emacs in the settings in order to remove it. You may think you're funny, but you have to realize that if emacs goes vi* is next. The desktop seems to be controlled by people with a windows envy. OG. From alan at redhat.com Mon Jun 4 09:49:39 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Jun 2007 05:49:39 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <604aa7910706010952i6906466eo934d57c644bd714@mail.gmail.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <200706011031.47164.jkeating@redhat.com> <1180708682.12595.299.camel@mccallum.corsepiu.local> <46603F7D.1050407@fedoraproject.org> <1180714860.12595.361.camel@mccallum.corsepiu.local> <604aa7910706010952i6906466eo934d57c644bd714@mail.gmail.com> Message-ID: <20070604094939.GA1389@devserv.devel.redhat.com> On Fri, Jun 01, 2007 at 08:52:51AM -0800, Jeff Spaleta wrote: > Rigorous mathematical logic analysis is an extremely poor toolset to > bring to bear on human designed policy structures.... my wife Only if used wrongly 8) Take a look at Systems Theory which is a non-reductionist but rigorous way of thinking about apparently illogical and unstructured behaviour and being able to use tools like logic and mathematics to help model aspects of it. Alan From ben.lewis at benl.co.uk Mon Jun 4 09:52:12 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Mon, 04 Jun 2007 10:52:12 +0100 Subject: Change to U.T.C. based release times In-Reply-To: <20070604091146.GE30973@devserv.devel.redhat.com> References: <20070602224229.1219ebdb@lain.camperquake.de> <155a01c7a558$092a2310$0a00000a@DEAD2> <20070604091146.GE30973@devserv.devel.redhat.com> Message-ID: <4663E0CC.3030307@benl.co.uk> Alan Cox wrote: > On Sat, Jun 02, 2007 at 10:53:13PM +0200, Hans K. Rosbach wrote: > >> Maybe timings should be specified as ex: "10:00 UTC/GMT" just for clarity. >> Atleast it is my understanding that GMT is what most europeans learn to >> > > This is confusing - there is no such thing as GMT. GMT is an ex time > measurement system. It is no more. It has ticked its last etc..etc > > GMT still exists - it is "mean solar time" at Greenwich observatory. > We should not use "GMT" because there is no such thing any more. UTC or UT > have taken over. > > Alan > No, we shouldn't use GMT anymore, that is true. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From ben.lewis at benl.co.uk Mon Jun 4 09:52:48 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Mon, 04 Jun 2007 10:52:48 +0100 Subject: rawhide report: 20070604 changes In-Reply-To: <1180949876.5019.0.camel@dawkins> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180949876.5019.0.camel@dawkins> Message-ID: <4663E0F0.50603@benl.co.uk> David Nielsen wrote: > man, 04 06 2007 kl. 04:45 -0400, skrev Build System: > > >> Removed package yum-presto >> > > Wait a second... didn't we just put this fine piece of work in? > > - David > This baffles me aswell -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From pertusus at free.fr Mon Jun 4 10:06:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 12:06:07 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <20070604094228.GC27020@dspnet.fr.eu.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> Message-ID: <20070604100607.GB2856@free.fr> On Mon, Jun 04, 2007 at 11:42:29AM +0200, Olivier Galibert wrote: > You may think you're funny, but you have to realize that if emacs goes > vi* is next. The desktop seems to be controlled by people with a > windows envy. Indeed, but hopefully with the community involved and the tools in place (pungi) maybe it could be possible to do a spin for other userbases. -- Pat From denis at poolshark.org Mon Jun 4 10:58:35 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 04 Jun 2007 12:58:35 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <20070604093954.GB27020@dspnet.fr.eu.org> References: <4663B929.6050206@nigelj.com> <20070604093954.GB27020@dspnet.fr.eu.org> Message-ID: <4663F05B.2050908@poolshark.org> Olivier Galibert wrote: > On Mon, Jun 04, 2007 at 07:03:05PM +1200, Nigel Jones wrote: >> My guess is that the number of people that don't use it, far outweigh >> the number of people that do. While some people may find this sad it's >> an honest truth and it seems pointless to force emacs onto a great deal >> of the users that don't want it. > > Really? What are your numbers and how did you come to them? Because > every linux user I know uses *emacs or vi* except for one that uses > nedit. how about install 'jed' by default (a lightweight emacs clone, about 950k) and make it use /etc/alternatives/emacs ? At least people dependent on emacs (such as myself) wouldn't be completely helpless on a system that only has vi. From nicolas.mailhot at laposte.net Mon Jun 4 10:47:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 4 Jun 2007 12:47:43 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <20070604100607.GB2856@free.fr> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> Message-ID: <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> Le Lun 4 juin 2007 12:06, Patrice Dumas a ?crit : > On Mon, Jun 04, 2007 at 11:42:29AM +0200, Olivier Galibert wrote: >> You may think you're funny, but you have to realize that if emacs >> goes >> vi* is next. The desktop seems to be controlled by people with a >> windows envy. > > Indeed, but hopefully with the community involved and the tools in > place > (pungi) maybe it could be possible to do a spin for other userbases. emacs and vi upstreams have the choice to update their software if they want to keep it installed by default vi is mostly safe - it's small and has discovered gtk. emacs is going the way of the dodo because it targets 1995-ish desktops, and we've not been shipping those for quite a long time. At one point the hassle of catering for legacy needs outweights legacy software benefits for most users. -- Nicolas Mailhot From triad at df.lth.se Mon Jun 4 11:10:55 2007 From: triad at df.lth.se (Linus Walleij) Date: Mon, 4 Jun 2007 13:10:55 +0200 (CEST) Subject: fedora for ARM In-Reply-To: <20070602032955.GC16918@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> Message-ID: Hi Lennert, your contributions to ARM Linux have not gone unnoticed. Nice to see you here! On Sat, 2 Jun 2007, Lennert Buytenhek wrote: > I'm posting here because I would really really like to get the relevant > diffs merged back into Fedora. The diffs look nice so IMHO should simply be applied, just that you'll probably have to open BZ entries for each and every one of them and push each individual maintainer to just do it... A bit off-topic questions: 1. What is the target system(s) you're using? I for one have a very vague understanding of what lab boards etc may be used for running ARM Fedora. 2. As I understand it you employ the Fedora/x86 style of not using a cross-compiler to build these packages, but rather build them with ARM on ARM. I am aware of some RPM derivatives like those used by MontaVista, that employ a cross-compiler instead. What are your thought on these issues? Have you tested both solutions and come to the conclusion that the all-ARM-enclosed build system is the way to go? Linus From triad at df.lth.se Mon Jun 4 11:18:33 2007 From: triad at df.lth.se (Linus Walleij) Date: Mon, 4 Jun 2007 13:18:33 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <20070604094228.GC27020@dspnet.fr.eu.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> Message-ID: On Mon, 4 Jun 2007, Olivier Galibert wrote: > You may think you're funny, but you have to realize that if emacs goes > vi* is next. Two letter "vi" will not go, because it is part of IEEE 1003.1 which Fedora and RHEL have a strong interest in supporting. Linus From aph at redhat.com Mon Jun 4 11:28:32 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2007 12:28:32 +0100 Subject: Why isn't emacs installed by default In-Reply-To: <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> Message-ID: <18019.63328.207759.405055@zebedee.pink> Nicolas Mailhot writes: > > Le Lun 4 juin 2007 12:06, Patrice Dumas a ?crit : > > On Mon, Jun 04, 2007 at 11:42:29AM +0200, Olivier Galibert wrote: > >> You may think you're funny, but you have to realize that if > >> emacs goes vi* is next. The desktop seems to be controlled by > >> people with a windows envy. > > > > Indeed, but hopefully with the community involved and the tools in > > place > > (pungi) maybe it could be possible to do a spin for other userbases. > > emacs and vi upstreams have the choice to update their software if > they want to keep it installed by default > > vi is mostly safe - it's small and has discovered gtk. > emacs is going the way of the dodo because it targets 1995-ish > desktops, and we've not been shipping those for quite a long time. At > one point the hassle of catering for legacy needs outweights legacy > software benefits for most users. Can you please explain what you are talking about? By "targets 1995-ish desktops," do you mean that emacs lacks pop-up windows, icons, menus, and so, on? Or something else you desire? What do you mean by "update their software"? Do you mean "make it more useful to developers"? Or something else? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From pertusus at free.fr Mon Jun 4 11:39:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 13:39:00 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> Message-ID: <20070604113900.GE2856@free.fr> On Mon, Jun 04, 2007 at 12:47:43PM +0200, Nicolas Mailhot wrote: > > vi is mostly safe - it's small and has discovered gtk. > emacs is going the way of the dodo because it targets 1995-ish > desktops, and we've not been shipping those for quite a long time. At Are you sure? Which desktops are these? It's obvious that those desktops and the corresponding users are not the primary target of fedora, but there is currently a rather diverse offer of desktop in fedora since there, is at least: mwm fvwm icewm fluxbox WindowMaker twm and certainly others. None of them are in the default spin, indeed, and I am certainly not saying that they have an important role in the whole picture and in the innovations, some features are lagging (like automounting, currently, for example), but they are here and it seems to me that, on the contrary, their covering is improving. -- Pat From j.w.r.degoede at hhs.nl Mon Jun 4 11:43:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jun 2007 13:43:39 +0200 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> Message-ID: <4663FAEB.8070807@hhs.nl> Linus Walleij wrote: > > 2. As I understand it you employ the Fedora/x86 style of not using a > cross-compiler to build these packages, but rather build them with ARM > on ARM. I am aware of some RPM derivatives like those used by > MontaVista, that employ a cross-compiler instead. What are your thought > on these issues? Have you tested both solutions and come to the > conclusion that the all-ARM-enclosed build system is the way to go? > In my somewhat limited experience cross-compiling of software which is not designed for that from day one is a big pain, let alone cross-compiling an entire distro! There are indeed some hacks around rpm to make the packahes think they are being build nativly, but what I've seen these are very gross hacks and still break often. Native compiling definitively is the way to go, an alternative might be emulating the native system and building in the emulated system. Regards, Hans From nicolas.mailhot at laposte.net Mon Jun 4 11:59:20 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 4 Jun 2007 13:59:20 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <18019.63328.207759.405055@zebedee.pink> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> Message-ID: <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> Le Lun 4 juin 2007 13:28, Andrew Haley a ?crit : > Can you please explain what you are talking about? By "targets > 1995-ish desktops," do you mean that emacs lacks pop-up windows, > icons, menus, and so, on? Or something else you desire? I mean emacs does not use the current desktop font infrastructure, does not use one of the main GUI desktop toolkits, does not support cleanly i18n & our main encoding (UTF-8), does not integrate with the accessibility infrastructure, does not integrate with the printing infrastructure, and the list goes on and on. That means emacs: 1. is unable to provide a lot of features current desktop users expect (and that's not a question of eye-candy, a terrific amount of work happened on the desktop these past years) 2. depends on a lot of stuff that must be kept working and configured properly just for it. First point is grounds for not being installed by default (already happened). Second point is grounds for ultimately being kicked out of distros altoguether (will take a few more years for the drag to become unbearable) Emacs may join the 21st century in the next decade. Till it does it's squarely aimed at the museum. -- Nicolas Mailhot From ich at frank-schmitt.net Mon Jun 4 12:02:05 2007 From: ich at frank-schmitt.net (Frank Schmitt) Date: Mon, 04 Jun 2007 14:02:05 +0200 Subject: Why isn't emacs installed by default References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> Message-ID: "Nicolas Mailhot" writes: > emacs and vi upstreams have the choice to update their software if > they want to keep it installed by default > > vi is mostly safe - it's small and has discovered gtk. > emacs is going the way of the dodo because it targets 1995-ish > desktops, and we've not been shipping those for quite a long time. At > one point the hassle of catering for legacy needs outweights legacy > software benefits for most users. The current Emacs release supports Gtk 2.0. Your point being? -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From nicolas.mailhot at laposte.net Mon Jun 4 12:05:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 4 Jun 2007 14:05:03 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <20070604113900.GE2856@free.fr> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <20070604113900.GE2856@free.fr> Message-ID: <36980.192.54.193.51.1180958703.squirrel@rousalka.dyndns.org> Le Lun 4 juin 2007 13:39, Patrice Dumas a ?crit : > Are you sure? Which desktops are these? It's obvious that those > desktops > and the corresponding users are not the primary target of fedora, but > there is currently a rather diverse offer of desktop in fedora since > there, is at least: > mwm fvwm icewm fluxbox WindowMaker twm > and certainly others. And how many of those are activelly developped ? How many will stay in Fedora once their packagers are asked to actually maintain the infrastructure they need? You have a vicious circle feature lag -> less users -> less developpers -> static maintenance -> orphan once something requires code adjustment and there's no one to provide it anymore (xorg is seriously thinking of dumping TWM now for example) -- Nicolas Mailhot From andy at warmcat.com Mon Jun 4 12:06:14 2007 From: andy at warmcat.com (Andy Green) Date: Mon, 04 Jun 2007 13:06:14 +0100 Subject: fedora for ARM In-Reply-To: <4663FAEB.8070807@hhs.nl> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> Message-ID: <46640036.8020607@warmcat.com> Hans de Goede wrote: > Linus Walleij wrote: >> >> 2. As I understand it you employ the Fedora/x86 style of not using a >> cross-compiler to build these packages, but rather build them with ARM >> on ARM. I am aware of some RPM derivatives like those used by >> MontaVista, that employ a cross-compiler instead. What are your >> thought >> on these issues? Have you tested both solutions and come to the >> conclusion that the all-ARM-enclosed build system is the way to go? >> > > In my somewhat limited experience cross-compiling of software which is > not designed for that from day one is a big pain, let alone > cross-compiling an entire distro! There are indeed some hacks around rpm > to make the packahes think they are being build nativly, but what I've > seen these are very gross hacks and still break often. > > Native compiling definitively is the way to go, an alternative might be > emulating the native system and building in the emulated system. The way to go IMO is to improve the common packages to work well with crosscompile... ones with recent autoblah on them generally work nice and easily. Fedora itself could do with say being able to build all the arch binaries simply on a single build host too. I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32) here http://octotux.org See http://rpm.octotux.org for the packages. I don't claim the spec files meet any criteria of beauty or utility for Fedora, since I was learning packaging from scratch while I did them, but they do crosscompile. Perl and Python are the holdouts I did not bother to spend more than a day on, since they currently try to use their own target-compiled binaries as part of their build process. -Andy From mlichvar at redhat.com Mon Jun 4 12:06:59 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 4 Jun 2007 14:06:59 +0200 Subject: Splitting the ncurses RPM In-Reply-To: <466385F1.8030005@codewiz.org> References: <466385F1.8030005@codewiz.org> Message-ID: <20070604120659.GA1483@localhost> On Sun, Jun 03, 2007 at 11:24:33PM -0400, Bernardo Innocenti wrote: > The ncurses package carries 2MB worth of terminfo database > that almost nobody cares to install. Could we move them > to a separate ncurses-data package so that space constrained > installs could easily get rid of them? Well, nobody cares until "Error opening terminal" message appears while trying to start an ncurses or slang application. But yes, most of the terminals descriptions could be moved to a subpackage and add it to comps' core group so it's installed by default. The base package would have only few selected descriptions that are widely used. Would that be ok? > The OLPC would certainly remove it, and maybe we could > safely remove them from default Fedora installs too. I'm not sure about removing terminfo from default Fedora install, Users can connect via ssh and use many different terminals. -- Miroslav Lichvar From aph at redhat.com Mon Jun 4 12:12:58 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2007 13:12:58 +0100 Subject: Why isn't emacs installed by default In-Reply-To: <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> Message-ID: <18020.458.214966.294886@zebedee.pink> Nicolas Mailhot writes: > > Le Lun 4 juin 2007 13:28, Andrew Haley a ?crit : > > > Can you please explain what you are talking about? By "targets > > 1995-ish desktops," do you mean that emacs lacks pop-up windows, > > icons, menus, and so, on? Or something else you desire? > > I mean emacs does not use the current desktop font infrastructure, > does not use one of the main GUI desktop toolkits, does not support > cleanly i18n & our main encoding (UTF-8), does not integrate with the > accessibility infrastructure, does not integrate with the printing > infrastructure, and the list goes on and on. > > That means emacs: > 1. is unable to provide a lot of features current desktop users expect > (and that's not a question of eye-candy, a terrific amount of work > happened on the desktop these past years) Well, yes, but on the other hand the desktop is unable to provide a lot of features current emacs users expect. Why is one more important than the other? Why are the expectations of "current desktop users", whomever they may be, more relevant than those of current emacs users? > 2. depends on a lot of stuff that must be kept working and configured > properly just for it. OK, this closer to a sensible argument. What are these things? > Emacs may join the 21st century in the next decade. Till it does it's > squarely aimed at the museum. >From a user's point of view, the important thing is the extent to which using the current desktop font infrastructure, using one of the main GUI desktop toolkits, etc. would enhance emacs. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From denis at poolshark.org Mon Jun 4 12:15:38 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 04 Jun 2007 14:15:38 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <36980.192.54.193.51.1180958703.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <20070604113900.GE2856@free.fr> <36980.192.54.193.51.1180958703.squirrel@rousalka.dyndns.org> Message-ID: <4664026A.1060703@poolshark.org> Nicolas Mailhot wrote: > Le Lun 4 juin 2007 13:39, Patrice Dumas a ?crit : > >> Are you sure? Which desktops are these? It's obvious that those >> desktops >> and the corresponding users are not the primary target of fedora, but >> there is currently a rather diverse offer of desktop in fedora since >> there, is at least: >> mwm fvwm icewm fluxbox WindowMaker twm >> and certainly others. > > And how many of those are activelly developped ? How many will stay in > Fedora once their packagers are asked to actually maintain the > infrastructure they need? > > You have a vicious circle feature lag -> less users -> less > developpers No, the slow developement of emacs has NOTHING to do with its number of users. The only reason is that the technical know-how required to contribute to emacs is quite high, because of the (convoluted) way emacs was designed (knowledge of LISP, enjoyment of self-inflicted suffering, ...). From Matt_Domsch at dell.com Mon Jun 4 12:19:50 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 4 Jun 2007 07:19:50 -0500 Subject: Release x86_64 rawhide rebuild in mock status 2007-06-03 In-Reply-To: <20070603152937.A17627@humbolt.us.dell.com> References: <20070603152937.A17627@humbolt.us.dell.com> Message-ID: <20070604121950.GA9153@lists.us.dell.com> On Sun, Jun 03, 2007 at 03:29:37PM -0500, Matt Domsch wrote: > Release Rawhide-in-Mock Build Results for x86_64 Sun Jun 3 09:09:00 CDT 2007 My apologies. I thought these were rebuilding using a rawhide buildroot, but in fact they were using a Fedora 7 buildroot. So they can be ignored for now. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From dwmw2 at infradead.org Mon Jun 4 12:20:30 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 04 Jun 2007 13:20:30 +0100 Subject: Don't put new packages through updates-testing In-Reply-To: <1180872298.3218.23.camel@vader.jdub.homelinux.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <1180806380.25232.137.camel@pmac.infradead.org> <1180821475.3218.1.camel@vader.jdub.homelinux.org> <1180857282.25232.145.camel@pmac.infradead.org> <1180872298.3218.23.camel@vader.jdub.homelinux.org> Message-ID: <1180959630.25232.312.camel@pmac.infradead.org> On Sun, 2007-06-03 at 07:04 -0500, Josh Boyer wrote: > > Someone already _did_ such things without the maintainers' consent -- my > > packages have ACLs where they didn't have them before. Please, do it the > > other way round and let maintainers _ask_ for ACLs if they actually want > > them. And make them give a _good_ reason too, not just "no teamwork here > > please". > > Yes, I understand that. You know you can remove them right? Now I want to test a liboil fix for bug #242418. Please let me know how I can do it. -- dwmw2 From jwboyer at jdub.homelinux.org Mon Jun 4 12:24:50 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 04 Jun 2007 07:24:50 -0500 Subject: rawhide report: 20070604 changes In-Reply-To: <1180949876.5019.0.camel@dawkins> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180949876.5019.0.camel@dawkins> Message-ID: <1180959890.3218.54.camel@vader.jdub.homelinux.org> On Mon, 2007-06-04 at 11:37 +0200, David Nielsen wrote: > man, 04 06 2007 kl. 04:45 -0400, skrev Build System: > > > Removed package yum-presto > > Wait a second... didn't we just put this fine piece of work in? It has a broken dep on a newer version of deltaprm that isn't in rawhide yet. It will be added back as soon as that is fixed up as I understand it. Remember, this is rawhide. Things disappear for no reason all the time ;) josh From dennis at ausil.us Mon Jun 4 12:45:33 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 4 Jun 2007 07:45:33 -0500 Subject: fedora for ARM In-Reply-To: <20070604054109.GA4702@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <1180930681.6254.616.camel@localhost.localdomain> <20070604054109.GA4702@redhat.com> Message-ID: <200706040745.34055.dennis@ausil.us> Once upon a time Monday 04 June 2007, Dave Jones wrote: > On Sun, Jun 03, 2007 at 11:18:01PM -0500, Tom spot Callaway wrote: > > On Sat, 2007-06-02 at 14:38 -0400, Dave Jones wrote: > > > # CONFIG_UTRACE is not set > > > > > > note that this will also disable ptrace too afaik. > > > (I'm aware that there are difficulties of porting utrace to arm). > > > > FWIW, we have the same difficulty with sparc32, but I'm almost certainly > > going to drop support for that arch with F-8. > > Normally in this situation I whip out my trusty "Both users will be > crushed" gag, but in this case, I think we'd be hard pressed to > find two users of that arch. The scary thing is i know of at least two possibly three. Im sure i can come up with more. Personally I dont own sparc32 only sparc64 Dennis From jsacco at gnome.org Mon Jun 4 12:46:30 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Mon, 04 Jun 2007 08:46:30 -0400 Subject: annoying syslog message from kernel Message-ID: <1180961190.2822.4.camel@rt.jesacco.com> I started seeing these messages Message from syslogd@ at Mon Jun 4 04:40:20 2007 ... plantain kernel: ------------[ cut here ]------------ a while back. Not harmful, but annoying. -Joseph -- jsacco [at] gnome [dot] org From fedora at leemhuis.info Mon Jun 4 12:50:08 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 14:50:08 +0200 Subject: rawhide report: 20070604 changes In-Reply-To: <1180959890.3218.54.camel@vader.jdub.homelinux.org> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180949876.5019.0.camel@dawkins> <1180959890.3218.54.camel@vader.jdub.homelinux.org> Message-ID: <46640A80.2070503@leemhuis.info> On 04.06.2007 14:24, Josh Boyer wrote: > On Mon, 2007-06-04 at 11:37 +0200, David Nielsen wrote: > [...] > Remember, this is rawhide. Things disappear for no reason all the > time ;) Would it's make sense to have a rel-eng mailiglist, a special tag on this mailiglist or something else where other people can see the requests that get made to the releng? Then question like "why did foo vanish" don't come up and people outside of rel-eng could follow the happenings.... CU thl From dtimms at iinet.net.au Mon Jun 4 12:59:16 2007 From: dtimms at iinet.net.au (David Timms) Date: Mon, 04 Jun 2007 22:59:16 +1000 Subject: Unwanted RPM dependencies In-Reply-To: <4663C148.1040909@codewiz.org> References: <4663C148.1040909@codewiz.org> Message-ID: <46640CA4.4090001@iinet.net.au> Bernardo Innocenti wrote: > (Cc'ing all the relevant package maintainers. sorry if > I got someone else by mistake) > > > We could get rid of a few packages on the OLPC in a cleaner > way if we could loosen dependencies a little. > > Some random things I noticed: > > - cracklib has a hard dependency on pam. Is there a way > we could make it optional? > > - mkinitrd depends on lvm2 and dmraid. Both could easily > be made optional. > > - hal depends on cryptsetup-luks (containing bulky 1.2MB > static binary in /sbin) > > - libuser and GConf2-dbus bring in openldap, which brings > in cyrus-sasl > > Using pristine Fedora packages in OLPC is an advantage for > support and upgrades. Also, reducing the minimum install > generally benefits other Fedora spins for other small > systems. Since I also play with older systems with small disks I was going through a minimal install {text mode only} and found that about 15 packages get installed because of grub dependencies: a tree (bottom is what is required by others higher up: {text mode is good for reading} grub | redhat-artwork <--> fedora-logos | | gtk2-engines | | | ____gtk2__________ | /| \ \ \ | / | \ cups-libs hicolor-icon-theme / | \ | \----------\ atk pango libtiff {pango} gnutls {gtk2} | \ \ \ | libthai cairo libjpeg libXft libXcursor libXrandr libX.. / | \ / | / | {libXrender} libpng fontconfig libXrender libXext \ / libX11 At which point it's getting boring ;) and still involves: libXinerama libXau libXdmcp libXext libXi libXfixes I think what the dependency on fedora-logos would be for the boot logo. My idea would be to separately package/sub package fedora-logos-boot or fedora-boot-logos {which provides logos-boot}. This would just have the logo in it, and grub rpm would be modified to require a virtual dependency of logos-boot {this would make it simpler for distro packagers to use an alternate logos-boot package}. I haven't looked at the actual packages yet. My second size concern comes from glibc-common, specifically the /usr/share/locale {283 MB} ( but also and /usr/share/i18n/ 10MB) I notice that there are dependencies listed in comps.xml for what gets installed when a language is chosen {eg dictionary and openoffice translations}. This could be extended to the gazillion locales supported by glibc and fedora. The maybe most commonly installed individual locales could be made into separate packages {guessing ! english french german spanish portuguese ? ?}, and then continent or similar for the rest of the locales {noting that there is often sub-locales for some reqions} {eg african latin-american asian european} ? Installing European would also get the more specific english/french/german loc's. This would actually reduce install time quite a bit - of the 600+ packages that get installed in a base install, the most time seems to be taken by the glibc-common install - and it's installing stuff that depending on your locale you are unlikely to ever use the other 99% of them. I did have a thought on whether there exists a tool that can log/count file accesses on disk, and then provide reports on used v not used files that were installed by rpm ? Such a thing could help in understanding actual usage by applications - and hence what might be better packaging splits. Has someone done that before ? DaveT. From greno at verizon.net Mon Jun 4 13:14:56 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 04 Jun 2007 09:14:56 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <57127b5f0706040116q385a9b54qa4c8a2250ed7ae56@mail.gmail.com> References: <46639749.5010409@verizon.net> <62bc09df0706032341u43dbcc82icc81a66fb6abcc84@mail.gmail.com> <57127b5f0706040116q385a9b54qa4c8a2250ed7ae56@mail.gmail.com> Message-ID: <46641050.2020601@verizon.net> Yes, I've confirmed. I burned a second DVD, verified the checksum after the burn, mounted the disk and made sure I could browse and load from all disk areas, retried install with new DVD and same errors as reported. Fedora 7 Installation is stuck because DVD/CDROM drive is not recognized. Deependra Shekhawat wrote: > I don't think so. From my experience in #fedora at irc.freenode.net > it seems more of like driver problem with > libata having some problems. > > Thanks. > > On 6/4/07, *SmootherFrOgZ* > wrote: > > > > 2007/6/4, Gerry Reno >: > > I've been trying to install Fedora 7 today from DVD on a couple > workstations and also in a QEMU Guest on an FC6 machine. The > install > gets stuck everytime when I OK the CDROM installation type > screen. It's > not recognizing the CDROM drives for some reason and just keeps > prompting for driver selection for this install type. Is > there some > parameter that I need to pass in? I've been working on this > for hours > and no luck on either machine or with QEMU. > > > it seem that your copy DVD isn't good. check your image iso and > your next DVD copy after the burn. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora Extras Contributor > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > Enjoy Life ! From pertusus at free.fr Mon Jun 4 13:16:58 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 15:16:58 +0200 Subject: rawhide report: 20070604 changes In-Reply-To: <46640A80.2070503@leemhuis.info> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180949876.5019.0.camel@dawkins> <1180959890.3218.54.camel@vader.jdub.homelinux.org> <46640A80.2070503@leemhuis.info> Message-ID: <20070604131657.GG2856@free.fr> On Mon, Jun 04, 2007 at 02:50:08PM +0200, Thorsten Leemhuis wrote: > On 04.06.2007 14:24, Josh Boyer wrote: > > On Mon, 2007-06-04 at 11:37 +0200, David Nielsen wrote: > > [...] > > Remember, this is rawhide. Things disappear for no reason all the > > time ;) > > Would it's make sense to have a rel-eng mailiglist, a special tag on > this mailiglist or something else where other people can see the > requests that get made to the releng? Then question like "why did foo > vanish" don't come up and people outside of rel-eng could follow the > happenings.... Isn't there a rel-eng mailing list already? What are we sending our mails to? Maybe it could be opened to the public (read-only). -- Pat From buildsys at fedoraproject.org Mon Jun 4 13:23:57 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 04 Jun 2007 13:23:57 -0000 Subject: Summary - Broken dependencies in Fedora development - 2007-06-04 Message-ID: <20070604132357.3162.24221@extras64.linux.duke.edu> New report for: Axel.Thimm AT ATrpms.net package: synaptic - 0.57.2-6.fc8.i386 from rawhide-development-i386 unresolved deps: libapt-pkg-libc6.5-6.so.2 package: synaptic - 0.57.2-6.fc8.ppc from rawhide-development-ppc unresolved deps: libapt-pkg-libc6.5-6.so.2 package: synaptic - 0.57.2-6.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libapt-pkg-libc6.5-6.so.2()(64bit) package: synaptic - 0.57.2-6.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libapt-pkg-libc6.5-6.so.2()(64bit) ====================================================================== Summary of broken packages (by owner): Axel.Thimm AT ATrpms.net synaptic - 0.57.2-6.fc8.i386 synaptic - 0.57.2-6.fc8.ppc synaptic - 0.57.2-6.fc8.ppc64 synaptic - 0.57.2-6.fc8.x86_64 andreas.bierfert AT lowlatency.de koffice-kexi-driver-pgsql - 1.6.2-3.fc7.i386 koffice-kexi-driver-pgsql - 1.6.2-3.fc7.ppc koffice-kexi-driver-pgsql - 1.6.2-3.fc7.ppc64 koffice-kexi-driver-pgsql - 1.6.2-3.fc7.x86_64 cbalint AT redhat.com gdal - 1.4.1-3.fc7.i386 gdal - 1.4.1-3.fc7.i386 gdal - 1.4.1-3.fc7.ppc gdal - 1.4.1-3.fc7.ppc64 gdal - 1.4.1-3.fc7.x86_64 cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch glest-data - 2.0.0-2.fc7.noarch showimg-pgsql - 0.9.5-12.fc7.i386 showimg-pgsql - 0.9.5-12.fc7.ppc showimg-pgsql - 0.9.5-12.fc7.ppc64 showimg-pgsql - 0.9.5-12.fc7.x86_64 giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 jonathansteffan AT gmail.com revisor - 2.0.3.6-1.fc8.noarch revisor - 2.0.3.6-1.fc8.noarch jwilson AT redhat.com emerald-themes - 0.2.0-1.fc7.noarch karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 kwizart AT gmail.com lcdproc - 0.5.2-1.fc8.i386 lcdproc - 0.5.2-1.fc8.ppc lcdproc - 0.5.2-1.fc8.ppc64 lcdproc - 0.5.2-1.fc8.x86_64 mdehaan AT redhat.com koan - 0.3.1-2.fc7.noarch orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 paul AT city-fan.org bittorrent - 4.4.0-5.fc7.noarch petersen AT redhat.com emacspeak - 26-1.fc8.noarch emacspeak - 26-1.fc8.noarch emacspeak - 26-1.fc8.noarch emacspeak - 26-1.fc8.noarch rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 shahms AT shahms.com python-paramiko - 1.6.4-1.fc7.noarch tcallawa AT redhat.com xsupplicant - 1.2.8-1.fc7.1.i386 xsupplicant - 1.2.8-1.fc7.1.ppc xsupplicant - 1.2.8-1.fc7.1.x86_64 thomas AT apestaart.org python-twisted-conch - 0.7.0-4.fc7.ppc64 tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 ville.skytta AT iki.fi em8300 - 0.16.2-1.fc7.ppc64 kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc kmod-em8300 - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 kmod-em8300-PAE - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 kmod-em8300-kdump - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 kmod-em8300-smp - 0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc walters AT redhat.com bigboard - 0.4.0-2.i386 bigboard - 0.4.0-2.ppc bigboard - 0.4.0-2.ppc64 bigboard - 0.4.0-2.x86_64 ====================================================================== Broken packages in rawhide-development-i386: bigboard-0.4.0-2.i386 requires hippo-canvas-python >= 0:0.2.16 emacspeak-26-1.fc8.noarch requires /usr/bin/tcl gdal-1.4.1-3.fc7.i386 requires libdapserver.so.2 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i586 requires kernel-i586 = 0:2.6.20-1.3104.fc7 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 requires kernel-i686 = 0:2.6.20-1.3104.fc7 kmod-em8300-PAE-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.i686 requires kernel-i686 = 0:2.6.20-1.3104.fc7PAE kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE koffice-kexi-driver-pgsql-1.6.2-3.fc7.i386 requires libpqxx-2.6.8.so lcdproc-0.5.2-1.fc8.i386 requires perl(Geo::METAR) showimg-pgsql-0.9.5-12.fc7.i386 requires libpqxx-2.6.8.so synaptic-0.57.2-6.fc8.i386 requires libapt-pkg-libc6.5-6.so.2 xsupplicant-1.2.8-1.fc7.1.i386 requires libiw.so.28 ====================================================================== Broken packages in rawhide-development-ppc64: ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) bigboard-0.4.0-2.ppc64 requires hippo-canvas-python >= 0:0.2.16 bittorrent-4.4.0-5.fc7.noarch requires python-crypto em8300-0.16.2-1.fc7.ppc64 requires em8300-kmod >= 0:0.16.2 emacspeak-26-1.fc8.noarch requires /usr/bin/tcl emerald-themes-0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 emerald-themes-0.2.0-1.fc7.noarch requires beryl-core >= 0:0.2.0 gdal-1.4.1-3.fc7.ppc64 requires libdapserver.so.2()(64bit) geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 koan-0.3.1-2.fc7.noarch requires syslinux koffice-kexi-driver-pgsql-1.6.2-3.fc7.ppc64 requires libpqxx-2.6.8.so()(64bit) lcdproc-0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 python-paramiko-1.6.4-1.fc7.noarch requires python-crypto >= 0:1.9 python-twisted-conch-0.7.0-4.fc7.ppc64 requires python-crypto resapplet-0.1.1-5.fc7.ppc64 requires system-config-display revisor-2.0.3.6-1.fc8.noarch requires livecd-tools rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) showimg-pgsql-0.9.5-12.fc7.ppc64 requires libpqxx-2.6.8.so()(64bit) synaptic-0.57.2-6.fc8.ppc64 requires libapt-pkg-libc6.5-6.so.2()(64bit) wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in rawhide-development-ppc: bigboard-0.4.0-2.ppc requires hippo-canvas-python >= 0:0.2.16 emacspeak-26-1.fc8.noarch requires /usr/bin/tcl gdal-1.4.1-3.fc7.ppc requires libdapserver.so.2 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc requires kernel-ppc = 0:2.6.20-1.3104.fc7 kmod-em8300-smp-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.ppc requires kernel-ppc = 0:2.6.20-1.3104.fc7smp koffice-kexi-driver-pgsql-1.6.2-3.fc7.ppc requires libpqxx-2.6.8.so lcdproc-0.5.2-1.fc8.ppc requires perl(Geo::METAR) revisor-2.0.3.6-1.fc8.noarch requires livecd-tools showimg-pgsql-0.9.5-12.fc7.ppc requires libpqxx-2.6.8.so synaptic-0.57.2-6.fc8.ppc requires libapt-pkg-libc6.5-6.so.2 xsupplicant-1.2.8-1.fc7.1.ppc requires libiw.so.28 ====================================================================== Broken packages in rawhide-development-x86_64: bigboard-0.4.0-2.x86_64 requires hippo-canvas-python >= 0:0.2.16 emacspeak-26-1.fc8.noarch requires /usr/bin/tcl gdal-1.4.1-3.fc7.i386 requires libdapserver.so.2 gdal-1.4.1-3.fc7.x86_64 requires libdapserver.so.2()(64bit) gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-em8300-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3104.fc7 kmod-em8300-kdump-0.16.2-0.2.6.20_1.3104.fc7.1.rc2.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3104.fc7kdump kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump koffice-kexi-driver-pgsql-1.6.2-3.fc7.x86_64 requires libpqxx-2.6.8.so()(64bit) lcdproc-0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) showimg-pgsql-0.9.5-12.fc7.x86_64 requires libpqxx-2.6.8.so()(64bit) synaptic-0.57.2-6.fc8.x86_64 requires libapt-pkg-libc6.5-6.so.2()(64bit) xsupplicant-1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) From pertusus at free.fr Mon Jun 4 13:14:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 15:14:55 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <36980.192.54.193.51.1180958703.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <20070604113900.GE2856@free.fr> <36980.192.54.193.51.1180958703.squirrel@rousalka.dyndns.org> Message-ID: <20070604131455.GF2856@free.fr> On Mon, Jun 04, 2007 at 02:05:03PM +0200, Nicolas Mailhot wrote: > > Le Lun 4 juin 2007 13:39, Patrice Dumas a ?crit : > > > Are you sure? Which desktops are these? It's obvious that those > > desktops > > and the corresponding users are not the primary target of fedora, but > > there is currently a rather diverse offer of desktop in fedora since > > there, is at least: > > mwm fvwm icewm fluxbox WindowMaker twm > > and certainly others. > > And how many of those are activelly developped ? How many will stay in At least fvwm icewm fluxbox. twm and mwm seems to be almost dead, I don't know at all about WindowMaker. And fvwm icewm fluxbox are following, at least partially the freedesktop norms. > Fedora once their packagers are asked to actually maintain the > infrastructure they need? That's a good question, but I hope that it won't need that much work, since those environments are (in general) lightweight and simple. > You have a vicious circle feature lag -> less users -> less > developpers -> static maintenance -> orphan once something requires > code adjustment and there's no one to provide it anymore (xorg is > seriously thinking of dumping TWM now for example) It is not clear to me that there are less users for simple desktops. There are much less in term of percentage, sure, but in absolute number it is far from clear. Moreover other distros are more light desktop friendly (this corresponding sometime to different userbases) so upstream may still be more actively supported there. In any case, I think that the lagging features are not that dramatic and my personal opinion is that things have improved dramatically with regard with the situation that prevailed before Extras existed. Now we have much more dockapps, much more window managers, and things like pyxdg or perl-File-MimeInfo, or like conky. Even though there were no users before Extras existed, there were potential users that hadn't a way to show their interest in for those environment, now things are much better. So in fedora we have clearly seen the opposite direction. TWM is a bad example since there are many substitutes that are still maintained, like fvwm or fluxbox. Still I agree that the userbases are reduced, those environments have to follow where the innovations are (in kde and gnome in general), but as I said otherwise, their simplicity leads to less development needed in general. -- Pat From jkeating at redhat.com Mon Jun 4 13:24:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 09:24:00 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <46641050.2020601@verizon.net> References: <46639749.5010409@verizon.net> <57127b5f0706040116q385a9b54qa4c8a2250ed7ae56@mail.gmail.com> <46641050.2020601@verizon.net> Message-ID: <200706040924.03868.jkeating@redhat.com> On Monday 04 June 2007 09:14:56 Gerry Reno wrote: > Yes, I've confirmed. ?I burned a second DVD, verified the checksum after > the burn, mounted the disk and made sure I could browse and load from > all disk areas, retried install with new DVD and same errors as > reported. ?Fedora 7 Installation is stuck because DVD/CDROM drive is not > recognized. You may need the qemu from Fedora 7 to be able to run it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From greno at verizon.net Mon Jun 4 13:30:38 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 04 Jun 2007 09:30:38 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <200706040924.03868.jkeating@redhat.com> References: <46639749.5010409@verizon.net> <57127b5f0706040116q385a9b54qa4c8a2250ed7ae56@mail.gmail.com> <46641050.2020601@verizon.net> <200706040924.03868.jkeating@redhat.com> Message-ID: <466413FE.4090801@verizon.net> Jesse, this is on real machines as well, not just in QEMU. Jesse Keating wrote: > On Monday 04 June 2007 09:14:56 Gerry Reno wrote: > >> Yes, I've confirmed. I burned a second DVD, verified the checksum after >> the burn, mounted the disk and made sure I could browse and load from >> all disk areas, retried install with new DVD and same errors as >> reported. Fedora 7 Installation is stuck because DVD/CDROM drive is not >> recognized. >> > > You may need the qemu from Fedora 7 to be able to run it. > > From jkeating at redhat.com Mon Jun 4 13:31:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 09:31:19 -0400 Subject: rawhide report: 20070604 changes In-Reply-To: <20070604131657.GG2856@free.fr> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <46640A80.2070503@leemhuis.info> <20070604131657.GG2856@free.fr> Message-ID: <200706040931.19495.jkeating@redhat.com> On Monday 04 June 2007 09:16:58 Patrice Dumas wrote: > Isn't there a rel-eng mailing list already? What are we sending our > mails to? Maybe it could be opened to the public (read-only). Right now it's an alias that goes to various rel-eng type people. I wanted it to just be a ticket like target, not a discussion area, discussion should happen on fedora-devel or fedora-maintainers. I'd rather not use the wiki for rel-eng tasks if possible, and our ticketing system is just a spampot. I'm open for other suggestions. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 13:34:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 09:34:56 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <1180886497.25232.151.camel@pmac.infradead.org> References: <46601BAF.8000507@hhs.nl> <1180872298.3218.23.camel@vader.jdub.homelinux.org> <1180886497.25232.151.camel@pmac.infradead.org> Message-ID: <200706040934.57101.jkeating@redhat.com> On Sunday 03 June 2007 12:01:37 David Woodhouse wrote: > No. I wanted to update my private branch of Evolution last week -- the > one I've been maintaining for years to make it actually usable for me. > My commit failed. How do I fix it? You ask mbarnes to update or remove the acls. If we were using a distributed SCM this wouldn't be a problem. Someday... (soon) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 13:40:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 09:40:02 -0400 Subject: pungi error In-Reply-To: <20070604045638.GB13719@eeyore.32.boerneef.vornavalley> References: <20070603060025.GA13719@eeyore.32.boerneef.vornavalley> <200706030858.33755.jkeating@redhat.com> <20070604045638.GB13719@eeyore.32.boerneef.vornavalley> Message-ID: <200706040940.02819.jkeating@redhat.com> On Monday 04 June 2007 00:56:38 Neil Thompson wrote: > Nope - I'm running an i386 F7. ?I am running on an X86_64 processor, but > that should should make no difference. Can you post up your configs and full logs? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 13:41:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 09:41:02 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <466413FE.4090801@verizon.net> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> Message-ID: <200706040941.02738.jkeating@redhat.com> On Monday 04 June 2007 09:30:38 Gerry Reno wrote: > Jesse, this is on real machines as well, not just in QEMU. Some pata is not greatly supported with the new libata stuff, and you may have to select the driver manually, if it is listed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Jun 4 13:45:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 4 Jun 2007 15:45:47 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> Message-ID: <23308.192.54.193.51.1180964747.squirrel@rousalka.dyndns.org> Le Lun 4 juin 2007 14:02, Frank Schmitt a ?crit : > The current Emacs release supports Gtk 2.0. Your point being? In the main text buffer too? Or just for menus with a custom text widjet -- Nicolas Mailhot From mclasen at redhat.com Mon Jun 4 13:42:11 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 04 Jun 2007 09:42:11 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <20070604062024.GL13318@tomservo.rochester.rr.com> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <1180707503.12595.290.camel@mccallum.corsepiu.local> <1180708585.3946.6.camel@zebes.localdomain> <46603361.2070507@hhs.nl> <20070604062024.GL13318@tomservo.rochester.rr.com> Message-ID: <1180964531.3573.4.camel@dhcp83-186.boston.redhat.com> On Mon, 2007-06-04 at 02:20 -0400, Luke Macken wrote: > On Fri, Jun 01, 2007 at 04:55:29PM +0200, Hans de Goede wrote: > > Will Woods wrote: > > > Let's be a little more clear here - what the QA team actually does for > > > packages in updates-testing is *verification*. Check package sanity, > > > make sure programs don't segfault on startup, etc. I'm not expecting all > > > testers to understand the functions of the > > > packages as well as their maintainers. But anyone can tell if you missed > > > some deps or your package doesn't start on x86_64. > > > > 1) I already verify my packages on x86_64 myself > > That's great. I don't. > > > 2) starting libs is kinda hard > > Agreed. Matthias Clasen mentioned on fedora-maintainers how the > RHEL errata tool has a field where the engineer is supposed to > fill in QA test instructions, which might be a very useful thing for > bodhi to have. > Actually, having a concrete enough comment will already give quite a few hints for testing, even for a library. Like: "This update of libfoo fixes a problem that could lead to crashes of application bar, as reported in bug 123456." From galibert at pobox.com Mon Jun 4 13:53:40 2007 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 4 Jun 2007 15:53:40 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <23308.192.54.193.51.1180964747.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <23308.192.54.193.51.1180964747.squirrel@rousalka.dyndns.org> Message-ID: <20070604135340.GB60513@dspnet.fr.eu.org> On Mon, Jun 04, 2007 at 03:45:47PM +0200, Nicolas Mailhot wrote: > > Le Lun 4 juin 2007 14:02, Frank Schmitt a ?crit : > > > The current Emacs release supports Gtk 2.0. Your point being? > > In the main text buffer too? Or just for menus with a custom text widjet Of course a custom text widget. The rendering capability of *emacs is similar to that of a typesetting word processor or a web browser. Or do you mean you're going to require Firefox and OpenOffice to use the gtk text widget too for their main display? OG. From khc at pm.waw.pl Mon Jun 4 13:53:54 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Mon, 04 Jun 2007 15:53:54 +0200 Subject: fedora for ARM In-Reply-To: <4663FAEB.8070807@hhs.nl> (Hans de Goede's message of "Mon, 04 Jun 2007 13:43:39 +0200") References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> Message-ID: Hans de Goede writes: > In my somewhat limited experience cross-compiling of software which is > not designed for that from day one is a big pain, let alone > cross-compiling an entire distro! It depends. I, for example, cross-compile all the stuff on PC, but this PC (x86_64) is able to run simple ARM binaries (needed by configure scripts etc) using binfmt+ssh to a real ARM machine. Even without chroot is works fine, with chroot it would probably be almost automatic. The scripts think I'm doing native builds. I assume one could use an emulator instead of ssh. -- Krzysztof Halasa From buildsys at fedoraproject.org Mon Jun 4 13:58:43 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 4 Jun 2007 09:58:43 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-04 Message-ID: <20070604135843.2A237152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 33 apt-0.5.15lorg3.2-10.fc6 bigloo-3.0a-2.fc6 blobAndConquer-0.91-1.fc6 NEW calcurse-1.8-2.fc6 : Text-based personal organizer chmsee-1.0.0-0.18.beta2.fc6 clearsilver-0.10.4-4.fc6 fail2ban-0.8.0-8.fc6 gnome-vfs2-obexftp-0.2-7.fc6 gtkmozembedmm-1.4.2.cvs20060817-9.fc6 koan-0.4.0-1.fc6 NEW libkdcraw-0.1.0-2.fc6 : A library for decoding RAW picture files NEW onesixtyone-0.3.2-3.fc6 : An efficient SNMP scanner openvrml-0.16.4-3.fc6 perl-Class-C3-0.18-1.fc6 perl-Data-Alias-1.05-1.fc6 perl-Event-1.09-1.fc6 perl-Gtk2-TrayIcon-0.06-1.fc6 NEW perl-Net-Write-1.00-2.fc6 : A portable interface to open and send raw data to network perl-POE-Component-Server-SOAP-1.11-1.fc6 perl-POE-Component-SimpleDBI-1.16-1.fc6 perl-POE-Component-SSLify-0.08-1.fc6 perl-Sub-Exporter-0.974-1.fc6 php-pear-HTTP-Request-1.4.1-1.fc6 (!) phpPgAdmin-4.1.2-1.fc6 : INVALID rebuild, not published! NEW postgresql-pgpool-II-1.1-1.fc6 : Pgpool is a connection pooling/replication server for PostgreSQL rrdtool-1.2.23-5.fc6 (!) seq24-0.8.7-6.fc6 : INVALID rebuild, not published! smart-0.50-46.fc6 synaptic-0.57.2-6.fc6 NEW telepathy-mission-control-4.22-2.fc6 : Central control for Telepathy connection manager NEW trac-webadmin-0.1.2-0.3.dev_r4429.fc6 : Web interface for administration of Trac NEW vtkdata-5.0.3-6.fc6 : Example data file for VTK zabbix-1.4-2.fc6 Packages built and released for Fedora Extras 5: 18 apt-0.5.15lorg3.2-10.fc5 clearsilver-0.10.4-4.fc5 fail2ban-0.8.0-8.fc5 mod_nss-1.0.7-1.fc5 perl-Class-C3-0.18-1.fc5 perl-Data-Alias-1.05-1.fc5 perl-Gtk2-TrayIcon-0.06-1.fc5 perl-JSON-XS-1.22-1.fc5 perl-POE-Component-Server-SOAP-1.11-1.fc5 perl-POE-Component-SimpleDBI-1.16-1.fc5 perl-POE-Component-SSLify-0.08-1.fc5 perl-Sub-Exporter-0.974-1.fc5 php-pear-HTTP-Request-1.4.1-1.fc5 phpPgAdmin-4.1.2-1.fc5 NEW postgresql-pgpool-II-1.1-1.fc5 : Pgpool is a connection pooling/replication server for PostgreSQL smart-0.50-46.fc5 VLGothic-fonts-20070507-1.fc5 NEW vtkdata-5.0.3-6.fc5 : Example data file for VTK Changes in Fedora Extras 6: apt-0.5.15lorg3.2-10.fc6 ------------------------ * Sun Jun 03 2007 Axel Thimm - 0.5.15lorg3.2-10 - Make autoupdates a bit more quiet (Pierre Ossman ). bigloo-3.0a-2.fc6 ----------------- * Fri Jun 01 2007 Gerard Milmeister - 3.0a-2 - remove java ssl since it does not build with libgcj * Fri Jun 01 2007 Gerard Milmeister - 3.0a-1 - new version 3.0a blobAndConquer-0.91-1.fc6 ------------------------- * Sun Jun 03 2007 Hans de Goede 0.91-1 - New upstream release 0.91-1 - Drop upstreamed patches calcurse-1.8-2.fc6 ------------------ * Wed May 30 2007 Nigel Jones 1.8-2 - Minor touchups to spec file * Wed May 23 2007 Nigel Jones 1.8-1 - Initial SPEC file chmsee-1.0.0-0.18.beta2.fc6 --------------------------- * Sat Jun 02 2007 bbbush - 1.0.0-0.18.beta2 - update for firefox 1.5.0.12 and 2.0.0.4 clearsilver-0.10.4-4.fc6 ------------------------ * Fri Jun 01 2007 Jeffrey C. Ollie - 0.10.4-4 - Minor cleanups * Fri Jun 01 2007 Jesse Keating - 0.10.4-3.1 - Disable java subpackages on el4 fail2ban-0.8.0-8.fc6 -------------------- * Sun Jun 03 2007 Axel Thimm - 0.8.0-8 - Also trigger on non-AllowUsers failures (Jonathan Underwood ). gnome-vfs2-obexftp-0.2-7.fc6 ---------------------------- * Sat Jun 02 2007 - Bastien Nocera - 0.2-7 - Fix crash when we can't connect through an rfcomm socket, reported by Olivier Fourdan gtkmozembedmm-1.4.2.cvs20060817-9.fc6 ------------------------------------- * Sat Jun 02 2007 Haikel Guemar - 1.4.2.cvs20060817-9 - rebuilt against firefox-devel-1.5.0.12 * Fri Mar 09 2007 Haikel Guemar - 1.4.2.cvs20060817-8 - Rebuilt against firefox-devel-1.5.0.10 * Fri Dec 22 2006 Haikel Guemar - 1.4.2.cvs20060817-7 - Rebuilt against firefox-devel-1.5.0.9 koan-0.4.0-1.fc6 ---------------- * Thu May 31 2007 Michael DeHaan - 0.4.0-1 - Upstream changes (see CHANGELOG) libkdcraw-0.1.0-2.fc6 --------------------- * Tue May 29 2007 Marcin Garski 0.1.0-2 - Add pkgconfig as devel Requires - Change Source0 URL * Tue May 08 2007 Marcin Garski 0.1.0-1 - Initial specfile onesixtyone-0.3.2-3.fc6 ----------------------- * Wed May 23 2007 Sindre Pedersen Bj?rdal - 0.3.2-3 - Add patch to really call proper flags, promise * Tue May 22 2007 Sindre Pedersen Bj?rdal - 0.3.2-2 - Change make to really call proper flags openvrml-0.16.4-3.fc6 --------------------- * Fri Jun 01 2007 Braden McDaniel - 0.16.4-3 - Updated firefox dependency to 1.5.0.12. perl-Class-C3-0.18-1.fc6 ------------------------ * Fri Jun 01 2007 Chris Weyl 0.18-1 - update to 0.18 * Wed May 09 2007 Chris Weyl 0.17-1 - update to 0.17 - BR Class::C3::XS perl-Data-Alias-1.05-1.fc6 -------------------------- * Fri Jun 01 2007 Chris Weyl 1.05-1 - update to 1.05 * Fri May 04 2007 Chris Weyl 1.04-1 - update to 1.04 - add t/ to %doc - perl splittage BR's added * Mon Mar 19 2007 Chris Weyl 1.03-1 - update to 1.03 perl-Event-1.09-1.fc6 --------------------- * Fri Jun 01 2007 Chris Weyl 1.09-1 - update to 1.09 - add t/ to doc perl-Gtk2-TrayIcon-0.06-1.fc6 ----------------------------- * Sat Jun 02 2007 Chris Weyl 0.06-1 - update to 0.06 - add t/ to doc perl-Net-Write-1.00-2.fc6 ------------------------- * Sat May 26 2007 Sindre Pedersen Bj?rdal - 1.00-2 - Add examples dir as documentation - Add missing BRs for tests - Fix licensing * Sat May 05 2007 Sindre Pedersen Bj?rdal - 1.00-1 - Initial build perl-POE-Component-Server-SOAP-1.11-1.fc6 ----------------------------------------- * Sat Jun 02 2007 Chris Weyl 1.11-1 - update to 1.11 - add t/ to doc perl-POE-Component-SimpleDBI-1.16-1.fc6 --------------------------------------- * Sun Jun 03 2007 Chris Weyl 1.16-1 - update to 1.16 - add t/ to doc - spec rework for the once and future perl split perl-POE-Component-SSLify-0.08-1.fc6 ------------------------------------ * Fri Jun 01 2007 Chris Weyl 0.08-1 - update to 0.08 perl-Sub-Exporter-0.974-1.fc6 ----------------------------- * Fri Jun 01 2007 Chris Weyl 0.974-1 - update to 0.974 php-pear-HTTP-Request-1.4.1-1.fc6 --------------------------------- * Sat Jun 02 2007 Christopher Stone 1.4.1-1 - Upstream sync (bz #242212) - Use sed instead of dos2unix phpPgAdmin-4.1.2-1.fc6 ---------------------- * Fri Jun 01 2007 Devrim Gunduz 4.1.2-1 - Update to 4.1.2 - Fix for Red Hat Bugzilla #241489 postgresql-pgpool-II-1.1-1.fc6 ------------------------------ * Sat Jun 02 2007 Devrim Gunduz 1.1-1 - Update to 1.1 - added --disable-rpath configure parameter. - Chowned sample conf files, so that they can work with pgpoolAdmin. rrdtool-1.2.23-5.fc6 -------------------- * Mon May 21 2007 Jarod Wilson 1.2.23-5 - BR: ruby so %ruby_sitearch gets set * Mon May 21 2007 Jarod Wilson 1.2.23-4 - Build ruby bindings * Thu May 03 2007 Jarod Wilson 1.2.23-3 - Disable php bits on ppc64 for now, they fail to build * Thu May 03 2007 Jarod Wilson 1.2.23-2 - Add BR: perl-devel for Fedora 7 and later * Tue May 01 2007 Jarod Wilson 1.2.23-1 - New upstream release * Tue May 01 2007 Jarod Wilson 1.2.21-1 - New upstream release seq24-0.8.7-6.fc6 ----------------- * Thu Oct 05 2006 Christian Iseli 0.8.7-6 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 smart-0.50-46.fc6 ----------------- * Sun Jun 03 2007 Axel Thimm - 0.50-46 - Autodetect pam_stack module at build time. synaptic-0.57.2-6.fc6 --------------------- * Sun Jun 03 2007 Axel Thimm - 0.57.2-6 - Autodetect pam_stack module at build time. telepathy-mission-control-4.22-2.fc6 ------------------------------------ * Sat Jun 02 2007 Sindre Pedersen Bj?rdal - 4.22-2 - Add missing requires on -devel package * Sat May 26 2007 Sindre Pedersen Bj?rdal - 4.22-1 - Initial build trac-webadmin-0.1.2-0.3.dev_r4429.fc6 ------------------------------------- * Sat Jun 02 2007 Jesse Keating - 0.1.2-0.3.dev_r4429 - and python-setuptools * Sat Jun 02 2007 Jesse Keating - 0.1.2-0.2.dev_r4429 - We require trac to run. * Fri Jun 01 2007 Jesse Keating - 0.1.2-0.1.dev_r4429 - Initial build vtkdata-5.0.3-6.fc6 ------------------- * Sun Apr 15 2007 Axel Thimm - 5.0.3-6 - Update to 5.0.3. zabbix-1.4-2.fc6 ---------------- * Wed May 30 2007 Jarod Wilson 1.4-2 - Add placeholder zabbix.conf.php * Tue May 29 2007 Jarod Wilson 1.4-1 - New upstream release * Fri Mar 30 2007 Jarod Wilson 1.1.7-1 - New upstream release Changes in Fedora Extras 5: apt-0.5.15lorg3.2-10.fc5 ------------------------ * Sun Jun 03 2007 Axel Thimm - 0.5.15lorg3.2-10 - Make autoupdates a bit more quiet (Pierre Ossman ). clearsilver-0.10.4-4.fc5 ------------------------ * Fri Jun 01 2007 Jeffrey C. Ollie - 0.10.4-4 - Minor cleanups * Fri Jun 01 2007 Jesse Keating - 0.10.4-3.1 - Disable java subpackages on el4 fail2ban-0.8.0-8.fc5 -------------------- * Sun Jun 03 2007 Axel Thimm - 0.8.0-8 - Also trigger on non-AllowUsers failures (Jonathan Underwood ). mod_nss-1.0.7-1.fc5 ------------------- * Fri Jun 01 2007 Rob Crittenden 1.0.7-1 - Update to 1.0.7 - Remove Requires for nss and nspr since those are handled automatically by versioned libraries - Updated URL and Source to reference directory.fedoraproject.org perl-Class-C3-0.18-1.fc5 ------------------------ * Fri Jun 01 2007 Chris Weyl 0.18-1 - update to 0.18 * Wed May 09 2007 Chris Weyl 0.17-1 - update to 0.17 - BR Class::C3::XS perl-Data-Alias-1.05-1.fc5 -------------------------- * Fri Jun 01 2007 Chris Weyl 1.05-1 - update to 1.05 * Fri May 04 2007 Chris Weyl 1.04-1 - update to 1.04 - add t/ to %doc - perl splittage BR's added * Mon Mar 19 2007 Chris Weyl 1.03-1 - update to 1.03 perl-Gtk2-TrayIcon-0.06-1.fc5 ----------------------------- * Sat Jun 02 2007 Chris Weyl 0.06-1 - update to 0.06 - add t/ to doc * Thu Aug 31 2006 Chris Weyl 0.03-3 - bump for mass rebuild perl-JSON-XS-1.22-1.fc5 ----------------------- * Fri Jun 01 2007 Chris Weyl 1.22-1 - update to 1.22 perl-POE-Component-Server-SOAP-1.11-1.fc5 ----------------------------------------- * Sat Jun 02 2007 Chris Weyl 1.11-1 - update to 1.11 - add t/ to doc perl-POE-Component-SimpleDBI-1.16-1.fc5 --------------------------------------- * Sun Jun 03 2007 Chris Weyl 1.16-1 - update to 1.16 - add t/ to doc - spec rework for the once and future perl split perl-POE-Component-SSLify-0.08-1.fc5 ------------------------------------ * Fri Jun 01 2007 Chris Weyl 0.08-1 - update to 0.08 * Sun May 06 2007 Chris Weyl 0.07-1 - update to 0.07 - add t/ to %doc - some spec rework due to perl splittage perl-Sub-Exporter-0.974-1.fc5 ----------------------------- * Fri Jun 01 2007 Chris Weyl 0.974-1 - update to 0.974 php-pear-HTTP-Request-1.4.1-1.fc5 --------------------------------- * Sat Jun 02 2007 Christopher Stone 1.4.1-1 - Upstream sync (bz #242212) - Use sed instead of dos2unix phpPgAdmin-4.1.2-1.fc5 ---------------------- * Fri Jun 01 2007 Devrim Gunduz 4.1.2-1 - Update to 4.1.2 - Fix for Red Hat Bugzilla #241489 postgresql-pgpool-II-1.1-1.fc5 ------------------------------ * Sat Jun 02 2007 Devrim Gunduz 1.1-1 - Update to 1.1 - added --disable-rpath configure parameter. - Chowned sample conf files, so that they can work with pgpoolAdmin. smart-0.50-46.fc5 ----------------- * Sun Jun 03 2007 Axel Thimm - 0.50-46 - Autodetect pam_stack module at build time. VLGothic-fonts-20070507-1.fc5 ----------------------------- * Sat Jun 02 2007 Ryo Dairiki - 20070507-1 - Update to 20070507 vtkdata-5.0.3-6.fc5 ------------------- * Sun Apr 15 2007 Axel Thimm - 5.0.3-6 - Update to 5.0.3. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From ajackson at redhat.com Mon Jun 4 13:56:43 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 04 Jun 2007 09:56:43 -0400 Subject: koji weirdness In-Reply-To: <1180639944.21359.14.camel@burren.boston.redhat.com> References: <465A8F08.90708@hhs.nl> <200705280941.51943.jkeating@redhat.com> <465BDE48.9010606@hhs.nl> <200705290633.56160.jkeating@redhat.com> <1180639944.21359.14.camel@burren.boston.redhat.com> Message-ID: <1180965403.8453.14.camel@localhost.localdomain> On Thu, 2007-05-31 at 15:32 -0400, Mike Bonnet wrote: > I just checked in an alternate chain-build implementation to > Makefile.common, based on a target we were using internally (and have > tested rather extensively). Update your common/ directories and run > "make help" to see the chain-build usage. > > You specify the packages that the current package depends on using the > CHAIN= parameter to "make chain-build". The packages specified in the > CHAIN= parameter will be checked out into a temp directory and "make > cvsurl" will be called to get their CVS URL (this will reference the > latest tag that was applied to the package on the current branch, and > that tag must not have been built in Koji already). The CVS URLs from > each CHAIN= package and the current package will be used to generate the > appropriate koji command-line to build each package in order (the > current package will be built last, and should not appear in the CHAIN= > parameter). This appears to stick a : between every target in the CHAIN, which means the build system will stall between every one. Would it be possible to get like a 'make expert-chain' that lets you specify the stall points explicitly? Otherwise, if I need to rebuild all X drivers for a new server ABI, I'll be waiting on ~40 stall points. - ajax From skvidal at linux.duke.edu Mon Jun 4 13:59:14 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 04 Jun 2007 09:59:14 -0400 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <46638909.3090006@codewiz.org> References: <46638909.3090006@codewiz.org> Message-ID: <1180965554.3406.0.camel@rivendell> On Sun, 2007-06-03 at 23:37 -0400, Bernardo Innocenti wrote: > Is it possible? > > This would reduce the amount of postprocessing > we need to do when building OLPC images. Docs frequently include licenses. Are you sure you're allowed to do that if you're redistributing the olpc image? -sv From greno at verizon.net Mon Jun 4 13:59:23 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 04 Jun 2007 09:59:23 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <200706040941.02738.jkeating@redhat.com> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> <200706040941.02738.jkeating@redhat.com> Message-ID: <46641ABB.3070004@verizon.net> I have not found a driver yet from the list that works. I've selected all the ones for the chipsets, any that looked generic, and just others at random. No luck yet. Jesse Keating wrote: > On Monday 04 June 2007 09:30:38 Gerry Reno wrote: > >> Jesse, this is on real machines as well, not just in QEMU. >> > > Some pata is not greatly supported with the new libata stuff, and you may have > to select the driver manually, if it is listed. > > From jkeating at redhat.com Mon Jun 4 13:57:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 09:57:11 -0400 Subject: Bugzilla and updates system? In-Reply-To: <20070604091405.d4e7c7f1.mschwendt.tmp0701.nospam@arcor.de> References: <20070604091405.d4e7c7f1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706040957.12083.jkeating@redhat.com> On Monday 04 June 2007 03:14:05 Michael Schwendt wrote: > Did this come from the new updates system? I wonder why an F7 update > changed an already closed FE7 bug and why it dropped the release > version? Show Bug Activity shows that Kevin Kofler closed the bug. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Mon Jun 4 14:05:44 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 04 Jun 2007 10:05:44 -0400 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <46638909.3090006@codewiz.org> References: <46638909.3090006@codewiz.org> Message-ID: <1180965945.3406.2.camel@rivendell> On Sun, 2007-06-03 at 23:37 -0400, Bernardo Innocenti wrote: > Is it possible? > > This would reduce the amount of postprocessing > we need to do when building OLPC images. Docs frequently include licenses. Are you sure you're allowed to do that if you're redistributing the olpc image? -sv From nicolas.mailhot at laposte.net Mon Jun 4 14:06:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 4 Jun 2007 16:06:45 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <18020.458.214966.294886@zebedee.pink> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> Message-ID: <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> Le Lun 4 juin 2007 14:12, Andrew Haley a ?crit : > Nicolas Mailhot writes: > > > > Le Lun 4 juin 2007 13:28, Andrew Haley a ?crit : > > > > > Can you please explain what you are talking about? By "targets > > > 1995-ish desktops," do you mean that emacs lacks pop-up windows, > > > icons, menus, and so, on? Or something else you desire? > > > > I mean emacs does not use the current desktop font infrastructure, > > does not use one of the main GUI desktop toolkits, does not support > > cleanly i18n & our main encoding (UTF-8), does not integrate with > the > > accessibility infrastructure, does not integrate with the printing > > infrastructure, and the list goes on and on. > > > > That means emacs: > > 1. is unable to provide a lot of features current desktop users > expect > > (and that's not a question of eye-candy, a terrific amount of work > > happened on the desktop these past years) > > Well, yes, but on the other hand the desktop is unable to provide a > lot of features current emacs users expect. Why is one more important > than the other? Why are the expectations of "current desktop users", > whomever they may be, more relevant than those of current emacs users? If you want to be part of the default desktop install you have to implement the default desktop expectations & rules. If you don't want to target the default desktop, you don't get installed with the desktop, that's as simple as that. You may be installed with something else (Fedora emacs spin, for example) but you don't piggy-back on another group when you don't share its objectives and make more work for it. > > 2. depends on a lot of stuff that must be kept working and > configured > > properly just for it. > > OK, this closer to a sensible argument. What are these things? > > > Emacs may join the 21st century in the next decade. Till it does it's > > squarely aimed at the museum. > > From a user's point of view, the important thing is the extent to > which using the current desktop font infrastructure, using one of the > main GUI desktop toolkits, etc. would enhance emacs. I won't enter in this argument. A lot of code was written for other apps and their users/maintainers seem to think it's useful for something (and a lot of those people were emacs users till they gave up on it) Suffice to say if you refuse to use the same stuff as everyone else, you get to maintain the stuff you're the only major user of. And suddenly lagging does not seem to be the low-effort choice anymore. -- Nicolas Mailhot From lxtnow at gmail.com Mon Jun 4 14:14:39 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Mon, 4 Jun 2007 10:14:39 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <46641ABB.3070004@verizon.net> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> <200706040941.02738.jkeating@redhat.com> <46641ABB.3070004@verizon.net> Message-ID: <62bc09df0706040714w5220196akb1138979b0717e84@mail.gmail.com> 2007/6/4, Gerry Reno : > > I have not found a driver yet from the list that works. I've selected > all the ones for the chipsets, any that looked generic, and just others > at random. No luck yet. So, you'll have to find and import the good one. Or hardly stuff, think about a netinstall. ps: strange, i fallen on the same error but it came from my media which is not good (read error during the "driver loading" and in this case fails to find my DVD drive) Jesse Keating wrote: > > On Monday 04 June 2007 09:30:38 Gerry Reno wrote: > > > >> Jesse, this is on real machines as well, not just in QEMU. > >> > > > > Some pata is not greatly supported with the new libata stuff, and you > may have > > to select the driver manually, if it is listed. > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajackson at redhat.com Mon Jun 4 14:12:18 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 04 Jun 2007 10:12:18 -0400 Subject: fedora for ARM In-Reply-To: <20070602032955.GC16918@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> Message-ID: <1180966338.8453.19.camel@localhost.localdomain> On Sat, 2007-06-02 at 05:29 +0200, Lennert Buytenhek wrote: > Recently, I produced an unofficial (but-seems-to-work-all-right) port > of FC6 to the ARM architecture (after having ported FC2/3/4 to ARM in > the past): > > http://ftp.linux.org.uk/pub/linux/arm/fedora/ > > The current set of diffs[*][**] is available for inspection here: > > http://ftp.linux.org.uk/pub/linux/arm/fedora/diffs/ The X stuff looks mostly sane, I'll start folding these in. For F7 I changed most of the ExclusiveArch lines to ExcludeArch, so many of the spec changes won't be an issue anymore. Thanks for doing this! - ajax From mschwendt.tmp0701.nospam at arcor.de Mon Jun 4 14:19:51 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 4 Jun 2007 16:19:51 +0200 Subject: Bugzilla and updates system? In-Reply-To: <200706040957.12083.jkeating@redhat.com> References: <20070604091405.d4e7c7f1.mschwendt.tmp0701.nospam@arcor.de> <200706040957.12083.jkeating@redhat.com> Message-ID: <20070604161951.10d9b638.mschwendt.tmp0701.nospam@arcor.de> On Mon, 4 Jun 2007 09:57:11 -0400, Jesse Keating wrote: > On Monday 04 June 2007 03:14:05 Michael Schwendt wrote: > > Did this come from the new updates system? I wonder why an F7 update > > changed an already closed FE7 bug and why it dropped the release > > version? > > Show Bug Activity shows that Kevin Kofler closed the bug. No. Look again. But it doesn't matter anymore, since it has been confirmed that bodhi plays with bugzilla tickets, regardless of whether they are closed already. From nicolas.mailhot at laposte.net Mon Jun 4 14:21:02 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 4 Jun 2007 16:21:02 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <20070604131455.GF2856@free.fr> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <20070604113900.GE2856@free.fr> <36980.192.54.193.51.1180958703.squirrel@rousalka.dyndns.org> <20070604131455.GF2856@free.fr> Message-ID: <34455.192.54.193.51.1180966862.squirrel@rousalka.dyndns.org> Le Lun 4 juin 2007 15:14, Patrice Dumas a ?crit : > Still I agree that the userbases are reduced, those environments > have to follow where the innovations are (in kde and gnome in > general), but as I said otherwise, their simplicity leads to less development > needed in general. Less development maybe but not less maintenance when you reach the point they don't use the same libs as everyone else. That's when problems begin generaly. -- Nicolas Mailhot From andy at warmcat.com Mon Jun 4 14:21:45 2007 From: andy at warmcat.com (Andy Green) Date: Mon, 04 Jun 2007 15:21:45 +0100 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> Message-ID: <46641FF9.90404@warmcat.com> Krzysztof Halasa wrote: > Hans de Goede writes: > >> In my somewhat limited experience cross-compiling of software which is >> not designed for that from day one is a big pain, let alone >> cross-compiling an entire distro! > > It depends. I, for example, cross-compile all the stuff on PC, but > this PC (x86_64) is able to run simple ARM binaries (needed by > configure scripts etc) using binfmt+ssh to a real ARM machine. > Even without chroot is works fine, with chroot it would probably > be almost automatic. The scripts think I'm doing native builds. > > I assume one could use an emulator instead of ssh. I also went through that process with an ssh-based "execution proxy", but as I did more packages I found that later configure scripts generated by newer autotools try running less or no test programs on the target. For example some older configure scripts ran wanted to compile and run test apps to find out sizeof(int), newer ones work it out without having to run anything on the target. Therefore I now try to regenerate the configure script from configure.in using newer autotools as the first move when the dist configure script had problems for crosscompiling. -Andy From nicolas.mailhot at laposte.net Mon Jun 4 14:24:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 4 Jun 2007 16:24:10 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <20070604135340.GB60513@dspnet.fr.eu.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <23308.192.54.193.51.1180964747.squirrel@rousalka.dyndns.org> <20070604135340.GB60513@dspnet.fr.eu.org> Message-ID: <52887.192.54.193.51.1180967050.squirrel@rousalka.dyndns.org> Le Lun 4 juin 2007 15:53, Olivier Galibert a ?crit : > On Mon, Jun 04, 2007 at 03:45:47PM +0200, Nicolas Mailhot wrote: >> >> Le Lun 4 juin 2007 14:02, Frank Schmitt a ?crit : >> >> > The current Emacs release supports Gtk 2.0. Your point being? >> >> In the main text buffer too? Or just for menus with a custom text >> widjet > > Of course a custom text widget. The rendering capability of *emacs is > similar to that of a typesetting word processor or a web browser. Or > do you mean you're going to require Firefox and OpenOffice to use the > gtk text widget too for their main display? Those apps take care of the deps needed by their main text widget. And their text widget integrates cleanly with the rest of the desktop. -- Nicolas Mailhot From jkeating at redhat.com Mon Jun 4 14:22:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 10:22:28 -0400 Subject: Bugzilla and updates system? In-Reply-To: <20070604161951.10d9b638.mschwendt.tmp0701.nospam@arcor.de> References: <20070604091405.d4e7c7f1.mschwendt.tmp0701.nospam@arcor.de> <200706040957.12083.jkeating@redhat.com> <20070604161951.10d9b638.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706041022.28255.jkeating@redhat.com> On Monday 04 June 2007 10:19:51 Michael Schwendt wrote: > No. Look again. Oops, looked at the last item, didn't see stuff before that. > But it doesn't matter anymore, since it has been confirmed that bodhi > plays with bugzilla tickets, regardless of whether they are closed > already. Indeed, probably just needs a little logic around what state the bug is in before hand. Hurray for making it slower :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon Jun 4 14:22:50 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 04 Jun 2007 09:22:50 -0500 Subject: rawhide report: 20070604 changes In-Reply-To: <46640A80.2070503@leemhuis.info> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180949876.5019.0.camel@dawkins> <1180959890.3218.54.camel@vader.jdub.homelinux.org> <46640A80.2070503@leemhuis.info> Message-ID: <1180966970.2978.0.camel@zod.rchland.ibm.com> On Mon, 2007-06-04 at 14:50 +0200, Thorsten Leemhuis wrote: > On 04.06.2007 14:24, Josh Boyer wrote: > > On Mon, 2007-06-04 at 11:37 +0200, David Nielsen wrote: > > [...] > > Remember, this is rawhide. Things disappear for no reason all the > > time ;) > > Would it's make sense to have a rel-eng mailiglist, a special tag on > this mailiglist or something else where other people can see the > requests that get made to the releng? Then question like "why did foo > vanish" don't come up and people outside of rel-eng could follow the > happenings.... It was done at the request of the maintainer. For full disclosure, the email chain is below. josh On Sunday 03 June 2007 10:24:37 Jonathan Dieter wrote: > Please block yum-presto-0.3.10-1.fc8 from Rawhide as one of its > dependencies (deltarpm-3.4-2) isn't in Rawhide yet. This has been blocked. Please remember to request we unblock it when deltarpm is ready. -- Jesse Keating Release Engineer: Fedora From pertusus at free.fr Mon Jun 4 14:28:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 16:28:37 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <34455.192.54.193.51.1180966862.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <20070604113900.GE2856@free.fr> <36980.192.54.193.51.1180958703.squirrel@rousalka.dyndns.org> <20070604131455.GF2856@free.fr> <34455.192.54.193.51.1180966862.squirrel@rousalka.dyndns.org> Message-ID: <20070604142837.GL2856@free.fr> On Mon, Jun 04, 2007 at 04:21:02PM +0200, Nicolas Mailhot wrote: > > Le Lun 4 juin 2007 15:14, Patrice Dumas a ?crit : > > > Still I agree that the userbases are reduced, those environments > > have to follow where the innovations are (in kde and gnome in > > general), but as I said otherwise, their simplicity leads to less > development > > needed in general. > > Less development maybe but not less maintenance when you reach the > point they don't use the same libs as everyone else. That's when > problems begin generaly. In general those apps are only based on X, so that's not too problematic, even though sometime at least some apps are based on old widget libs, and then things may indeed become problematic, like what happens for lesstif and motif based apps. There is also libdockapp, but it is very light. As a side note some of the apps that are very usefull in those environments are based on gtk (but not on gnome). -- Pat From linux_4ever at yahoo.com Mon Jun 4 14:22:54 2007 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 4 Jun 2007 07:22:54 -0700 (PDT) Subject: Unwanted RPM dependencies In-Reply-To: <46640CA4.4090001@iinet.net.au> Message-ID: <645152.43134.qm@web51511.mail.re2.yahoo.com> >I did have a thought on whether there exists a tool that can log/count >file accesses on disk, and then provide reports on used v not used files >that were installed by rpm ? auditctl -a always,exit -S open -F success=1 (You'd want to the rule to /etc/audit/audit.rules for it to take effect after booting.) Then to get the file usage summary report: aureport --start this-month --file --summary --success There are many attempts to open a file that doesn't exist, so you'd only want to get the successful ones. This will take some disk space to record what is accessed a lot. I think by default, the audit system will only occupy 32mb. You may need to increase that. -Steve ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From katzj at redhat.com Mon Jun 4 14:30:40 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 10:30:40 -0400 Subject: Traffic on fedora-maintainers (Was Re: The community has lost control...) In-Reply-To: <4662C3DC.7010906@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> Message-ID: <1180967441.9788.4.camel@erebor.boston.redhat.com> On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: > On 03.06.2007 15:17, Jesse Keating wrote: > > On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: > >> Well, see all those discussion that happened when ACLs were added, kjoi > >> introduced, the freezes were introduced and bodi put in place. Sure, > >> there are always discussions, but all those were quite worse and there > >> was a lot of confusion afaics... Don't read fedora-maintainers for a > >> week and suddenly you are not aware of how to build or push a package. > > So without reading the mailing list for maintainers, > > A low-traffic fedora-maintainers-announce was requested multiple times > as some contributors mentioned that fedora-maintainers is to noisy for > them. Some Red-Hat-engineers blocked that so long and hard that people > that wanted it got frustrated and didn't drive that idea further in the > past months. > > Like it or not, but for some people fedora-maintainers has to much > traffic; so they just skim over it and easily miss important announcements. The problem is that -maintainers was supposed to cut down on the traffic from -devel.[1] But a lot of people end up posting there because they think it'll be lower traffic and thus be seen, thus discussion ensues[2] and then it's too much traffic. Unless that changes, an -announce list is going to have the same problem. It's a sucky problem, but I really don't think more lists is the answer :-/ Instead, better and more consistent use of our existing lists. Jeremy [1] Which it mostly does... [2] And some of the discussion ends up being the badly needed clarification on a change and so people would have to wade into a thread _somewhere_ From bob.chiodini at nasa.gov Mon Jun 4 14:36:07 2007 From: bob.chiodini at nasa.gov (Bob Chiodini) Date: Mon, 04 Jun 2007 10:36:07 -0400 Subject: annoying syslog message from kernel In-Reply-To: <1180961190.2822.4.camel@rt.jesacco.com> References: <1180961190.2822.4.camel@rt.jesacco.com> Message-ID: <46642357.7040209@nasa.gov> Joseph Sacco wrote: > I started seeing these messages > > Message from syslogd@ at Mon Jun 4 04:40:20 2007 ... > plantain kernel: ------------[ cut here ]------------ > > > a while back. Not harmful, but annoying. > > > -Joseph > > Joseph, From the upstream source (2.6.21). Is there a message following indicating the address of the bug? This message is sourced from lib/bug.c and should be followed by some more info. Either " Badness at ..." or "Kernel BUG at ...". BTW: Joseph, Sorry about the multiple replies. My email address was out of date on the list server. Bob... From katzj at redhat.com Mon Jun 4 14:50:40 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 10:50:40 -0400 Subject: Broken deps in Fedora 7 In-Reply-To: <1180793919.25232.121.camel@pmac.infradead.org> References: <20070602104114.e9d8c66e.mschwendt.tmp0701.nospam@arcor.de> <200706021007.30552.jkeating@redhat.com> <1180793919.25232.121.camel@pmac.infradead.org> Message-ID: <1180968640.9788.13.camel@erebor.boston.redhat.com> On Sat, 2007-06-02 at 15:18 +0100, David Woodhouse wrote: > On Sat, 2007-06-02 at 10:07 -0400, Jesse Keating wrote: > > revisor-2.0.3.6-1.fc7.src.rpm -> livecd-tools(ppc) Probably needs to > > have an %ifnarch ppc ppc64 around the livecd-tools requirement. I've > > pinged the revisor guys. > > I provided the basics of ppc support for livecd-tools a few weeks ago. Yes, and like we discussed then, I held off on doing any reorg/committing until after getting F7 out the door to avoid breaking the tools used for building the release. I'll be getting to that probably sometime this week. Assuming I managet to get through reading mail at some point :-) Jeremy From alan at redhat.com Mon Jun 4 14:52:39 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Jun 2007 10:52:39 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <46641ABB.3070004@verizon.net> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> <200706040941.02738.jkeating@redhat.com> <46641ABB.3070004@verizon.net> Message-ID: <20070604145239.GD24880@devserv.devel.redhat.com> On Mon, Jun 04, 2007 at 09:59:23AM -0400, Gerry Reno wrote: > I have not found a driver yet from the list that works. I've selected > all the ones for the chipsets, any that looked generic, and just others > at random. No luck yet. What hardware ? From katzj at redhat.com Mon Jun 4 15:01:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 11:01:07 -0400 Subject: rawhide report: 20070601 changes In-Reply-To: <1180808607.4028.7.camel@pensja.lam.pl> References: <200706020524.l525OU7X002727@porkchop.devel.redhat.com> <1180808607.4028.7.camel@pensja.lam.pl> Message-ID: <1180969267.9788.25.camel@erebor.boston.redhat.com> On Sat, 2007-06-02 at 20:23 +0200, Leszek Matok wrote: > Dnia 02-06-2007, sob o godzinie 09:58 -0700, darrell pfeifer napisa?(a): > > 4) Java (the Sun version) segfaulted > On my system, QuakeForge (compiled by me 4 days ago, when development > was an almost-F7) segfaults in memset() (run from > _dl_map_object_from_fd() trying to map a shared library) when I try to > run it, also "ldd `which nq-glx`" is crashing, but "/lib/ld-linux.so.2 > `nq-glx`" runs the game. Weird. mono apps similarly based on tomboy's failure to start this morning on my laptop; haven't gotten to actually debugging it yet. Anyone filed it in bugzilla? Jeremy From greno at verizon.net Mon Jun 4 15:15:09 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 04 Jun 2007 11:15:09 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <20070604145239.GD24880@devserv.devel.redhat.com> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> <200706040941.02738.jkeating@redhat.com> <46641ABB.3070004@verizon.net> <20070604145239.GD24880@devserv.devel.redhat.com> Message-ID: <46642C7D.3070107@verizon.net> Smolt profile: http://smolt.fedoraproject.org/show?UUID=ab65ac7d-1e79-4479-b7bf-14f4936b6e2a Alan Cox wrote: > On Mon, Jun 04, 2007 at 09:59:23AM -0400, Gerry Reno wrote: > >> I have not found a driver yet from the list that works. I've selected >> all the ones for the chipsets, any that looked generic, and just others >> at random. No luck yet. >> > > What hardware ? > > From tromey at redhat.com Mon Jun 4 14:59:21 2007 From: tromey at redhat.com (Tom Tromey) Date: Mon, 04 Jun 2007 08:59:21 -0600 Subject: Why isn't emacs installed by default In-Reply-To: <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Mon\, 4 Jun 2007 16\:06\:45 +0200 \(CEST\)") References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> Message-ID: >>>>> "Nicolas" == Nicolas Mailhot writes: >> > 2. depends on a lot of stuff that must be kept working and >> configured >> > properly just for it. >> >> OK, this closer to a sensible argument. What are these things? Nicolas, I notice you didn't answer the most relevant question in Andrew's note -- what are these things that must be kept working just for Emacs? I read through your list and some of it seems reasonable (Emacs has its own accessibility approach, AIUI -- not my area), but some doesn't (print infrastructure? I think Emacs forks lpr or whatever). That asked (again), I don't see what the big deal is. Is somebody proposing dropping Emacs or something like that? Do most developers actually care what is in the default install? I already have to yum install a ton of things to get a usable system; adding Emacs to that list will be an annoyance, but only a minor one. Tom From katzj at redhat.com Mon Jun 4 15:25:26 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 11:25:26 -0400 Subject: Why isn't emacs installed by default In-Reply-To: References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> Message-ID: <1180970726.9788.28.camel@erebor.boston.redhat.com> On Mon, 2007-06-04 at 08:59 -0600, Tom Tromey wrote: > That asked (again), I don't see what the big deal is. Is somebody > proposing dropping Emacs or something like that? Do most developers > actually care what is in the default install? I already have to yum > install a ton of things to get a usable system; adding Emacs to that > list will be an annoyance, but only a minor one. FWIW, emacs hasn't been installed by default in quite a while. So there really isn't any change here. The main question was why _isn't_ it installed by default, and I think that's been pretty well answered. Jeremy From katzj at redhat.com Mon Jun 4 15:29:44 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 11:29:44 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <4663C148.1040909@codewiz.org> References: <4663C148.1040909@codewiz.org> Message-ID: <1180970984.9788.32.camel@erebor.boston.redhat.com> On Mon, 2007-06-04 at 03:37 -0400, Bernardo Innocenti wrote: > - mkinitrd depends on lvm2 and dmraid. Both could easily > be made optional. The problem is that if this were made optional, then they wouldn't be guaranteed to be installed prior to the kernel which leads to big problems with initrd creation in the kernel's %post. Generally speaking, this is a problem that could really do with some people looking into a solution as it happens more and more... and the hacks are not entirely ideal. Ideas to rpm-maint-list at rpm.org :) > - hal depends on cryptsetup-luks (containing bulky 1.2MB > static binary in /sbin) cryptsetup-luks should drop its static binary and move libcryptsetup to be in /%{_lib} instead of %{_libdir} Jeremy From katzj at redhat.com Mon Jun 4 15:34:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 11:34:13 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <46640CA4.4090001@iinet.net.au> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> Message-ID: <1180971253.9788.38.camel@erebor.boston.redhat.com> On Mon, 2007-06-04 at 22:59 +1000, David Timms wrote: > My second size concern comes from glibc-common, specifically the > /usr/share/locale {283 MB} ( but also and /usr/share/i18n/ 10MB) > > I notice that there are dependencies listed in comps.xml for what gets > installed when a language is chosen {eg dictionary and openoffice > translations}. This could be extended to the gazillion locales supported > by glibc and fedora. The maybe most commonly installed individual > locales could be made into separate packages {guessing ! english french > german spanish portuguese ? ?}, and then continent or similar for the > rest of the locales {noting that there is often sub-locales for some > reqions} {eg african latin-american asian european} ? Installing > European would also get the more specific english/french/german loc's. And your tradeoff is that instead you have X packages more worth of metadata to download to discover packages/updates. Plus more space spent on the rpmdb, etc. Splitting things like this out is a losing battle that really ends up costing more in the long-term that it helps. Not to mention that this stuff in comps is at best a crude hack that has all kinds of weird side effects and user interactions. Note that you can have RPM not install properly "tagged" locale files not installed by setting the %_install_langs rpm macro. But your tradeoff by doing this is you won't be able to use deltarpms and to add locale support later, you have to entirely reinstall packages. Jeremy From katzj at redhat.com Mon Jun 4 15:38:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 11:38:07 -0400 Subject: rawhide report: 20070604 changes In-Reply-To: <1180959890.3218.54.camel@vader.jdub.homelinux.org> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180949876.5019.0.camel@dawkins> <1180959890.3218.54.camel@vader.jdub.homelinux.org> Message-ID: <1180971487.9788.43.camel@erebor.boston.redhat.com> On Mon, 2007-06-04 at 07:24 -0500, Josh Boyer wrote: > On Mon, 2007-06-04 at 11:37 +0200, David Nielsen wrote: > > man, 04 06 2007 kl. 04:45 -0400, skrev Build System: > > > > > Removed package yum-presto > > > > Wait a second... didn't we just put this fine piece of work in? > > It has a broken dep on a newer version of deltaprm that isn't in rawhide > yet. It will be added back as soon as that is fixed up as I understand > it. > > Remember, this is rawhide. Things disappear for no reason all the > time ;) ... although I think that just having the broken dep in rawhide for a day or so may well have been the better approach. Or just untagging the new build. Blocking the entire package was probably a little overkill. Jeremy From ville.skytta at iki.fi Mon Jun 4 15:41:40 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 4 Jun 2007 18:41:40 +0300 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <20070604093945.A7119@xos037.xos.nl> References: <46638909.3090006@codewiz.org> <4663B892.1000001@codewiz.org> <20070604093945.A7119@xos037.xos.nl> Message-ID: <200706041841.40457.ville.skytta@iki.fi> On Monday 04 June 2007, Jos Vos wrote: > But: the problem with --excludedocs can be solved easily by just > checking in %post whether the info files are present or not. That's not enough for read only /usr/share setups (eg. NFS mounted, %_netsharedpath ones). From fedora at leemhuis.info Mon Jun 4 15:41:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:41:55 +0200 Subject: Don't put new packages through updates-testing In-Reply-To: <200706040934.57101.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <1180872298.3218.23.camel@vader.jdub.homelinux.org> <1180886497.25232.151.camel@pmac.infradead.org> <200706040934.57101.jkeating@redhat.com> Message-ID: <466432C3.9060906@leemhuis.info> On 04.06.2007 15:34, Jesse Keating wrote: > On Sunday 03 June 2007 12:01:37 David Woodhouse wrote: >> No. I wanted to update my private branch of Evolution last week -- the >> one I've been maintaining for years to make it actually usable for me. >> My commit failed. How do I fix it? > You ask mbarnes to update or remove the acls. If we were using a distributed > SCM this wouldn't be a problem. Someday... (soon) Sorry to bother, but I'd like to understand this. Wouldn't we even with a distributed SCM have a kind of "master repo" on a central server [with backups ;-) ] somewhere? I would further assume that for "important" packages only the maintainers and some other important people can pull in changes into that master repo? Thus there would be ACLs on "that master repo" as well? Or am I missing something fundamental here? /me is confused Cu thl From ville.skytta at iki.fi Mon Jun 4 15:46:26 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 4 Jun 2007 18:46:26 +0300 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <20070604093918.GA2856@free.fr> References: <46638909.3090006@codewiz.org> <20070604093945.A7119@xos037.xos.nl> <20070604093918.GA2856@free.fr> Message-ID: <200706041846.26913.ville.skytta@iki.fi> On Monday 04 June 2007, Patrice Dumas wrote: > On Mon, Jun 04, 2007 at 09:39:45AM +0200, Jos Vos wrote: > > > I've seen (and reported) this problem already in Red Hat Linux 7.3 (!), > > so not mnuch seems to have improved since then in this area. > > Ville (if I recall well) reported all the issues, All that I could find, yes :) > and they were blocking > the merge review so hopefully everything is solved or will be (in devel). I think F7 is already in a pretty good shape wrt. this, certainly *much* better than earlier releases. Of those I found and reported half a year or so ago, only gmp-devel remains unfixed (#223692). From fedora at leemhuis.info Mon Jun 4 15:52:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:52:09 +0200 Subject: Traffic on fedora-maintainers (Was Re: The community has lost control...) In-Reply-To: <1180967441.9788.4.camel@erebor.boston.redhat.com> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> <1180967441.9788.4.camel@erebor.boston.redhat.com> Message-ID: <46643529.1000909@leemhuis.info> On 04.06.2007 16:30, Jeremy Katz wrote: > On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: >> On 03.06.2007 15:17, Jesse Keating wrote: >>> On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: >>>> Well, see all those discussion that happened when ACLs were added, kjoi >>>> introduced, the freezes were introduced and bodi put in place. Sure, >>>> there are always discussions, but all those were quite worse and there >>>> was a lot of confusion afaics... Don't read fedora-maintainers for a >>>> week and suddenly you are not aware of how to build or push a package. >>> So without reading the mailing list for maintainers, >> A low-traffic fedora-maintainers-announce was requested multiple times >> as some contributors mentioned that fedora-maintainers is to noisy for >> them. Some Red-Hat-engineers blocked that so long and hard that people >> that wanted it got frustrated and didn't drive that idea further in the >> past months. >> >> Like it or not, but for some people fedora-maintainers has to much >> traffic; so they just skim over it and easily miss important announcements. > > The problem is that -maintainers was supposed to cut down on the traffic > from -devel.[1] But a lot of people end up posting there because they > think it'll be lower traffic and thus be seen, thus discussion ensues[2] > and then it's too much traffic. Unless that changes, an -announce list > is going to have the same problem. > > It's a sucky problem, but I really don't think more lists is the > answer :-/ Instead, better and more consistent use of our existing > lists. The proposal for the mailing list reorganisation still stands and IMHO addresses the problem by reshuffling lists a bit. The outcome is less list in total. But as I said: still waiting for new hardware. CU thl From ville.skytta at iki.fi Mon Jun 4 15:53:34 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 4 Jun 2007 18:53:34 +0300 Subject: F7 install CDROM unrecognized In-Reply-To: <46642C7D.3070107@verizon.net> References: <46639749.5010409@verizon.net> <20070604145239.GD24880@devserv.devel.redhat.com> <46642C7D.3070107@verizon.net> Message-ID: <200706041853.35242.ville.skytta@iki.fi> On Monday 04 June 2007, Gerry Reno wrote: > Smolt profile: > http://smolt.fedoraproject.org/show?UUID=ab65ac7d-1e79-4479-b7bf-14f4936b6e >2a My F7 experiences with an HPT370A which you seem to have too: https://bugzilla.redhat.com/242270 Smolt profile: http://smolt.fedoraproject.org/show?UUID=187100ac-e3c5-4556-b1be-582c0c54734b From jkeating at redhat.com Mon Jun 4 15:51:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 11:51:05 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <466432C3.9060906@leemhuis.info> References: <46601BAF.8000507@hhs.nl> <200706040934.57101.jkeating@redhat.com> <466432C3.9060906@leemhuis.info> Message-ID: <200706041151.05913.jkeating@redhat.com> On Monday 04 June 2007 11:41:55 Thorsten Leemhuis wrote: > Sorry to bother, but I'd like to understand this. > > Wouldn't we even with a distributed SCM have a kind of "master repo" on > a central server [with backups ;-) ] somewhere? I would further assume > that for "important" packages only the maintainers and some other > important people can pull in changes into that master repo? Thus there > would be ACLs on "that master repo" as well? > > Or am I missing something fundamental here? With a distributed SCM, all David Woodhouse would have to do would be say 'git pull' to update his local clone to the upstream module, filtering in the upstream changes with his downstream changes. He wouldn't _have_ to track his changes in the upstream repo, he could track it in any repo he wanted to since a clone of a distributed SCM is a standalone repo itself. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 15:53:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 11:53:48 -0400 Subject: rawhide report: 20070604 changes In-Reply-To: <1180971487.9788.43.camel@erebor.boston.redhat.com> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180959890.3218.54.camel@vader.jdub.homelinux.org> <1180971487.9788.43.camel@erebor.boston.redhat.com> Message-ID: <200706041153.48272.jkeating@redhat.com> On Monday 04 June 2007 11:38:07 Jeremy Katz wrote: > ;) > > ... although I think that just having the broken dep in rawhide for a > day or so may well have been the better approach. ?Or just untagging the > new build. ?Blocking the entire package was probably a little overkill. Hrm, I didn't realize there were older builds and thus approved the request to just block yum-presto. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buytenh at wantstofly.org Mon Jun 4 16:01:58 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Mon, 4 Jun 2007 18:01:58 +0200 Subject: fedora for ARM In-Reply-To: <1180966338.8453.19.camel@localhost.localdomain> References: <20070602032955.GC16918@xi.wantstofly.org> <1180966338.8453.19.camel@localhost.localdomain> Message-ID: <20070604160158.GB4696@xi.wantstofly.org> On Mon, Jun 04, 2007 at 10:12:18AM -0400, Adam Jackson wrote: > > Recently, I produced an unofficial (but-seems-to-work-all-right) port > > of FC6 to the ARM architecture (after having ported FC2/3/4 to ARM in > > the past): > > > > http://ftp.linux.org.uk/pub/linux/arm/fedora/ > > > > The current set of diffs[*][**] is available for inspection here: > > > > http://ftp.linux.org.uk/pub/linux/arm/fedora/diffs/ > > The X stuff looks mostly sane, I'll start folding these in. Thanks! Probably about one third of our diffs is X diffs, so this shaves off a lot. > For F7 I changed most of the ExclusiveArch lines to ExcludeArch, > so many of the spec changes won't be an issue anymore. Right. 99% of the ARM X diffs is just ExclusiveArch changes, and there I kind of took the blunt approach and just used the set of servers that alpha uses. The only two 'real' patches in the X area for ARM are: 1/ xorg-x11-proto-devel not installing XLbx.h and friends anymore, causing libXext to fail to build (not ARM-specific, and I'm pretty sure that this would not be an issue anymore post-FC6.) 2/ xorg-x11-server needs some minor ifdef changes for ARM[*], which have been floating around since at least the FC2 days, but I must admit that I'm not sure what the upstream status is of this. I.e. this is one of the very very few diffs in our set that is not related to Fedora packaging of which I'm not sure whether we ever submitted it upstream or not. (I'll get the rest of our patches rebased to F8 asap.) > Thanks for doing this! Thanks for your help! thanks, Lennert [*] ftp://ftp.linux.org.uk/pub/linux/arm/fedora/diffs/xorg-x11-server-1.1.1-47.8.fc6/xorg-server-1.1.1-arm-iopl.patch From galibert at pobox.com Mon Jun 4 16:03:21 2007 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 4 Jun 2007 18:03:21 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> Message-ID: <20070604160321.GA89414@dspnet.fr.eu.org> On Mon, Jun 04, 2007 at 04:06:45PM +0200, Nicolas Mailhot wrote: > Suffice to say if you refuse to use the same stuff as everyone else, [...] Once again, an unproven and highly debatable assertion. Numbers and methodology to obtain them please? OG. From greno at verizon.net Mon Jun 4 16:05:47 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 04 Jun 2007 12:05:47 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <200706041853.35242.ville.skytta@iki.fi> References: <46639749.5010409@verizon.net> <20070604145239.GD24880@devserv.devel.redhat.com> <46642C7D.3070107@verizon.net> <200706041853.35242.ville.skytta@iki.fi> Message-ID: <4664385B.9010105@verizon.net> Ville, Also check out: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234283 BTW, these little Abit HPT boards have made great file and web servers for us. I have over a dozen of these and they are all running strong. When I needed them to go faster I just added more memory. You can't beat em. The problems I encountered all started with the 2.6.20 kernel series. Have not been able to load a 2.6.20 kernel yet on these without an immediate crash. Regards, Gerry Ville Skytt? wrote: > On Monday 04 June 2007, Gerry Reno wrote: > >> Smolt profile: >> http://smolt.fedoraproject.org/show?UUID=ab65ac7d-1e79-4479-b7bf-14f4936b6e >> 2a >> > > My F7 experiences with an HPT370A which you seem to have too: > https://bugzilla.redhat.com/242270 > > Smolt profile: > http://smolt.fedoraproject.org/show?UUID=187100ac-e3c5-4556-b1be-582c0c54734b > > From aph at redhat.com Mon Jun 4 16:09:34 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2007 17:09:34 +0100 Subject: Why isn't emacs installed by default In-Reply-To: <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> Message-ID: <18020.14654.999307.373027@zebedee.pink> Nicolas Mailhot writes: > > Le Lun 4 juin 2007 14:12, Andrew Haley a ?crit : > > Nicolas Mailhot writes: > > > > > > Le Lun 4 juin 2007 13:28, Andrew Haley a ?crit : > > > > From a user's point of view, the important thing is the extent to > > which using the current desktop font infrastructure, using one of the > > main GUI desktop toolkits, etc. would enhance emacs. > > I won't enter in this argument. Well, it's the only argument that is at all persuasive from the point of view of an upstream maintainer. "Use this cool stuff and emacs will be better, because ..." is a hell of a lot more persuasive than "Use this cool stuff or we'll kill emacs." > A lot of code was written for other apps and their > users/maintainers seem to think it's useful for something (and a > lot of those people were emacs users till they gave up on it) I've never before heard of anyone giving up emacs, but I'll take your word for it that such people exist. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From jima at beer.tclug.org Mon Jun 4 16:14:58 2007 From: jima at beer.tclug.org (Jima) Date: Mon, 4 Jun 2007 11:14:58 -0500 (CDT) Subject: fedora for ARM In-Reply-To: <20070604054109.GA4702@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> <20070604054109.GA4702@redhat.com> Message-ID: On Mon, 4 Jun 2007, Dave Jones wrote: > On Sun, Jun 03, 2007 at 11:18:01PM -0500, Tom spot Callaway wrote: > > FWIW, we have the same difficulty with sparc32, but I'm almost certainly > > going to drop support for that arch with F-8. > > Normally in this situation I whip out my trusty "Both users will be > crushed" gag, but in this case, I think we'd be hard pressed to > find two users of that arch. One. But I'm also somewhat involved in maintenance. Jima From pertusus at free.fr Mon Jun 4 16:14:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 18:14:34 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <1180970984.9788.32.camel@erebor.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <1180970984.9788.32.camel@erebor.boston.redhat.com> Message-ID: <20070604161434.GN2856@free.fr> On Mon, Jun 04, 2007 at 11:29:44AM -0400, Jeremy Katz wrote: > > cryptsetup-luks should drop its static binary and move libcryptsetup to > be in /%{_lib} instead of %{_libdir} At least move it to -static, but I guess it will be done as part of the merge review. -- Pat From jima at beer.tclug.org Mon Jun 4 16:17:34 2007 From: jima at beer.tclug.org (Jima) Date: Mon, 4 Jun 2007 11:17:34 -0500 (CDT) Subject: fedora for ARM In-Reply-To: <20070604084914.GC30973@devserv.devel.redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> <20070604084914.GC30973@devserv.devel.redhat.com> Message-ID: On Mon, 4 Jun 2007, Alan Cox wrote: > On Sun, Jun 03, 2007 at 11:18:01PM -0500, Tom spot Callaway wrote: >> FWIW, we have the same difficulty with sparc32, but I'm almost certainly >> going to drop support for that arch with F-8. > > I thought the goal of Fedora was to track upstream. What upstream? Jima From pertusus at free.fr Mon Jun 4 16:16:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 18:16:44 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <18020.14654.999307.373027@zebedee.pink> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> <18020.14654.999307.373027@zebedee.pink> Message-ID: <20070604161620.GO2856@free.fr> On Mon, Jun 04, 2007 at 05:09:34PM +0100, Andrew Haley wrote: > > I've never before heard of anyone giving up emacs, but I'll take your > word for it that such people exist. I gave up emacs for vi ;-). But it still find emacs nice... -- Pat From rc040203 at freenet.de Mon Jun 4 16:18:00 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Jun 2007 18:18:00 +0200 Subject: Traffic on fedora-maintainers (Was Re: The community has lost control...) In-Reply-To: <1180967441.9788.4.camel@erebor.boston.redhat.com> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> <4662C3DC.7010906@leemhuis.info> <1180967441.9788.4.camel@erebor.boston.redhat.com> Message-ID: <1180973881.27239.24.camel@mccallum.corsepiu.local> On Mon, 2007-06-04 at 10:30 -0400, Jeremy Katz wrote: > On Sun, 2007-06-03 at 15:36 +0200, Thorsten Leemhuis wrote: > > On 03.06.2007 15:17, Jesse Keating wrote: > > > On Sunday 03 June 2007 02:48:35 Thorsten Leemhuis wrote: > > >> Well, see all those discussion that happened when ACLs were added, kjoi > > >> introduced, the freezes were introduced and bodi put in place. Sure, > > >> there are always discussions, but all those were quite worse and there > > >> was a lot of confusion afaics... Don't read fedora-maintainers for a > > >> week and suddenly you are not aware of how to build or push a package. > > > So without reading the mailing list for maintainers, > > > > A low-traffic fedora-maintainers-announce was requested multiple times > > as some contributors mentioned that fedora-maintainers is to noisy for > > them. Some Red-Hat-engineers blocked that so long and hard that people > > that wanted it got frustrated and didn't drive that idea further in the > > past months. > > > > Like it or not, but for some people fedora-maintainers has to much > > traffic; so they just skim over it and easily miss important announcements. > > The problem is that -maintainers was supposed to cut down on the traffic > from -devel.[1] The crux is procedures, workflow, fixes, changes, bux, hacks, tricks etc. to release management, buildsystem etc. which affect all maintainers ATM or RSN. I don't think the public devel@ list is appropriate for this. devel@ could be appropriate for discussions on development of a "future release management system" and similar. > It's a sucky problem, but I really don't think more lists is the > answer :-/ Instead, better and more consistent use of our existing > lists. Right, but cf. what I wrote above. Ralf From jwboyer at jdub.homelinux.org Mon Jun 4 15:32:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 04 Jun 2007 10:32:17 -0500 Subject: F7 install CDROM unrecognized In-Reply-To: <46642C7D.3070107@verizon.net> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> <200706040941.02738.jkeating@redhat.com> <46641ABB.3070004@verizon.net> <20070604145239.GD24880@devserv.devel.redhat.com> <46642C7D.3070107@verizon.net> Message-ID: <1180971137.2978.7.camel@zod.rchland.ibm.com> On Mon, 2007-06-04 at 11:15 -0400, Gerry Reno wrote: > Smolt profile: > http://smolt.fedoraproject.org/show?UUID=ab65ac7d-1e79-4479-b7bf-14f4936b6e2a Excellent! This is one of the great things about smolt that I hope we see propagate to the Fedora userbase. josh From alan at redhat.com Mon Jun 4 16:21:14 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Jun 2007 12:21:14 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <4664385B.9010105@verizon.net> References: <46639749.5010409@verizon.net> <20070604145239.GD24880@devserv.devel.redhat.com> <46642C7D.3070107@verizon.net> <200706041853.35242.ville.skytta@iki.fi> <4664385B.9010105@verizon.net> Message-ID: <20070604162114.GA10170@devserv.devel.redhat.com> On Mon, Jun 04, 2007 at 12:05:47PM -0400, Gerry Reno wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234283 > BTW, these little Abit HPT boards have made great file and web servers > for us. I have over a dozen of these and they are all running strong. > When I needed them to go faster I just added more memory. You can't > beat em. The problems I encountered all started with the 2.6.20 kernel > series. Have not been able to load a 2.6.20 kernel yet on these without > an immediate crash. I've passed this bug on to Sergei the upstream author of those changes in case he has any suggestions. FC7 uses a different set of disk drivers however. From alan at redhat.com Mon Jun 4 16:23:18 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Jun 2007 12:23:18 -0400 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> <20070604084914.GC30973@devserv.devel.redhat.com> Message-ID: <20070604162318.GB10170@devserv.devel.redhat.com> On Mon, Jun 04, 2007 at 11:17:34AM -0500, Jima wrote: > > What upstream? The upstream of the various projects (eg the kernel). From buytenh at wantstofly.org Mon Jun 4 16:27:11 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Mon, 4 Jun 2007 18:27:11 +0200 Subject: fedora for ARM In-Reply-To: <20070604162318.GB10170@devserv.devel.redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> <20070604084914.GC30973@devserv.devel.redhat.com> <20070604162318.GB10170@devserv.devel.redhat.com> Message-ID: <20070604162711.GA5802@xi.wantstofly.org> On Mon, Jun 04, 2007 at 12:23:18PM -0400, Alan Cox wrote: > > What upstream? > > The upstream of the various projects (eg the kernel). I could be wrong here, but I seem to recall very very vaguely that the upstream kernel was also going into the direction of dropping sparc32? From davidz at redhat.com Mon Jun 4 16:30:33 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 04 Jun 2007 12:30:33 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <4663C148.1040909@codewiz.org> References: <4663C148.1040909@codewiz.org> Message-ID: <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> On Mon, 2007-06-04 at 03:37 -0400, Bernardo Innocenti wrote: > - mkinitrd depends on lvm2 and dmraid. Both could easily > be made optional. You most probably don't need mkinitrd on OLPC as the kernel got all the drivers built-in and IIRC OLPC don't even use the initrd (when I was working on it, it didn't). So you could have some OLPC specific package that provides mkinitrd and symlinks /sbin/mkinitrd -> /bin/true or something. > - hal depends on cryptsetup-luks (containing bulky 1.2MB > static binary in /sbin) Probably cryptsetup doesn't need to be linked statically anymore; Peter Jones would know. Either way, if you don't expose LUKS encrypted stuff in the UI I guess you can just drop the cryptsetup dep from hal since it will gracefully recover and just throw and error if Crypto.Setup() is called. David From jspaleta at gmail.com Mon Jun 4 16:34:28 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 4 Jun 2007 08:34:28 -0800 Subject: Why isn't emacs installed by default In-Reply-To: <20070604093954.GB27020@dspnet.fr.eu.org> References: <4663B929.6050206@nigelj.com> <20070604093954.GB27020@dspnet.fr.eu.org> Message-ID: <604aa7910706040934x3e45d697m459a12fcfba33391@mail.gmail.com> On 6/4/07, Olivier Galibert wrote: > Really? What are your numbers and how did you come to them? Because > every linux user I know uses *emacs or vi* except for one that uses > nedit. Rather than fall into the pointless trap of "everyone I personally know' uses application foo" .... here are some suggestive numbers from mugshot. Mugshot does include Emacs in its application stats as a text editor. Searching for 'text editor' in mugshot's application db and you get this: gedit sits at #6 with 1,863 mugshot users emacs sits at #21 with 482 vim sits at #30 with 327 kate sits at #70 with 80 inkscape sits at #40 with 191 and for comparison the leading IDE is eclipse is #25 with 439 and open office writer sits at #15 with 1,023 -jef"I use emacs, but I do not want to see it in the default install"spaleta From aph at redhat.com Mon Jun 4 16:34:40 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Jun 2007 17:34:40 +0100 Subject: Why isn't emacs installed by default In-Reply-To: <20070604161620.GO2856@free.fr> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> <18020.14654.999307.373027@zebedee.pink> <20070604161620.GO2856@free.fr> Message-ID: <18020.16160.511660.479731@zebedee.pink> Patrice Dumas writes: > On Mon, Jun 04, 2007 at 05:09:34PM +0100, Andrew Haley wrote: > > > > I've never before heard of anyone giving up emacs, but I'll take your > > word for it that such people exist. > > I gave up emacs for vi ;-). I knew that I was going to regret that comment almost as soon as I sent it. :-) OK people, I beleieve it. All you ex-emacs users don't have to reply... > But it still find emacs nice... Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From pertusus at free.fr Mon Jun 4 16:37:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 18:37:03 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <18020.16160.511660.479731@zebedee.pink> References: <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> <18020.14654.999307.373027@zebedee.pink> <20070604161620.GO2856@free.fr> <18020.16160.511660.479731@zebedee.pink> Message-ID: <20070604163703.GP2856@free.fr> On Mon, Jun 04, 2007 at 05:34:40PM +0100, Andrew Haley wrote: > Patrice Dumas writes: > > On Mon, Jun 04, 2007 at 05:09:34PM +0100, Andrew Haley wrote: > > > > > > I've never before heard of anyone giving up emacs, but I'll take your > > > word for it that such people exist. > > > > I gave up emacs for vi ;-). > > I knew that I was going to regret that comment almost as soon as I > sent it. :-) It was too tempting, sorry. I know this is bad, but still... ;-) -- Pat From sundaram at fedoraproject.org Mon Jun 4 16:37:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 22:07:48 +0530 Subject: Why isn't emacs installed by default In-Reply-To: <18020.14654.999307.373027@zebedee.pink> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> <18020.14654.999307.373027@zebedee.pink> Message-ID: <46643FDC.60301@fedoraproject.org> Andrew Haley wrote: > Nicolas Mailhot writes: > > > > Le Lun 4 juin 2007 14:12, Andrew Haley a ?crit : > > > Nicolas Mailhot writes: > > > > > > > > Le Lun 4 juin 2007 13:28, Andrew Haley a ?crit : > > > > > > From a user's point of view, the important thing is the extent to > > > which using the current desktop font infrastructure, using one of the > > > main GUI desktop toolkits, etc. would enhance emacs. > > > > I won't enter in this argument. > > Well, it's the only argument that is at all persuasive from the point > of view of an upstream maintainer. "Use this cool stuff and emacs > will be better, because ..." is a hell of a lot more persuasive than > "Use this cool stuff or we'll kill emacs." Nobody killed emacs. It is in the repository. Just not installed by default and hasn't been for a long time now. XMMS was dropped before from the default set because it was relying on GTK1 which made it the only default desktop application that didn't support the internalization and accessibility features. If applications don't get the improvements users expect in modern desktop sometime or the other these applications are likely to be sidelined. Not saying that Emacs is in such a position now though. Rahul From caillon at redhat.com Mon Jun 4 17:15:33 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 13:15:33 -0400 Subject: Don't put new packages through updates-testing In-Reply-To: <1180959630.25232.312.camel@pmac.infradead.org> References: <46601BAF.8000507@hhs.nl> <200706010947.31608.jkeating@redhat.com> <46603203.3090001@hhs.nl> <466034EE.3070004@fedoraproject.org> <1180726721.19774.62.camel@localhost.localdomain> <46612390.7030302@fedoraproject.org> <20070602082017.GB11101@free.fr> <46612EAC.30806@fedoraproject.org> <20070602112528.b12f8a6b.mschwendt.tmp0701.nospam@arcor.de> <46613791.5030809@fedoraproject.org> <20070602115021.737b6139.mschwendt.tmp0701.nospam@arcor.de> <46613E78.1010703@fedoraproject.org> <20070602122839.ed9d9b34.mschwendt.tmp0701.nospam@arcor.de> <46614A83.7080004@fedoraproject.org> <20070602132836.6faadd10.mschwendt.tmp0701.nospam@arcor.de> <1180806380.25232.137.camel@pmac.infradead.org> <1180821475.3218.1.camel@vader.jdub.homelinux.org> <1180857282.25232.145.camel@pmac.infradead.org> <1180872298.3218.23.camel@vader.jdub.homelinux.org> <1180959630.25232.312.camel@pmac.infradead.org> Message-ID: <466448B5.7090307@redhat.com> David Woodhouse wrote: > Now I want to test a liboil fix for bug #242418. Please let me know how > I can do it. make changes locally add ExclusiveArch: foo if testing arch specific changes. make test-srpm koji build --scratch dist-fc7-updates-candidate foo.srpm From jspaleta at gmail.com Mon Jun 4 17:42:08 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 4 Jun 2007 09:42:08 -0800 Subject: The community has lost control... (Was: Re: Don't put new packages through updates-testing) In-Reply-To: <200706030917.12070.jkeating@redhat.com> References: <46601BAF.8000507@hhs.nl> <46626443.6020804@leemhuis.info> <200706030917.12070.jkeating@redhat.com> Message-ID: <604aa7910706041042m65634f5dq3038d5d875249da4@mail.gmail.com> On 6/3/07, Jesse Keating wrote: > Seriously I think it's rather impossible to make a > change and have people be prepared for that change if said people never read > appropriate mailing lists or monitor wiki pages. What I could really use (other than a cheeseburger thrown into a blender so I could eat it without experiencing the pain of chewing) is a single wiki page aimed at contributors that acted like a dated notice board, so that I can be trained to call the contents of that wikipage on a regular basis and then follow links from there to learn more. To be quite honest, the wiki isn't particularly helpful without reading the mailinglists, there's no obvious place in the wiki for contributors to go to see "new" information, so there's no obvious single page to monitor. http://fedoraproject.org/wiki/PackageMaintainers should be that place, but as you can tell there no mention of bodhi for example. Nor is there an at a glance way for me to tell if any of the guidance documents listed under Resources have been updated recently. So there's no way to know if my personal understanding of the guidance has grown stale, unless I individually monitor a group of existing pages for changes. But that's not really all that useful for 'new' things like Bodhi or Koji which first show up in the wiki as new pages, which I have no a-priori knowledge of. -jef"Niether Koji nor Bodhi are mentioned on http://fedoraproject.org/wiki/PackageMaintainers/Join still"spaleta From ajackson at redhat.com Mon Jun 4 17:44:12 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 04 Jun 2007 13:44:12 -0400 Subject: fedora for ARM In-Reply-To: <20070604160158.GB4696@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <1180966338.8453.19.camel@localhost.localdomain> <20070604160158.GB4696@xi.wantstofly.org> Message-ID: <1180979052.8453.63.camel@localhost.localdomain> On Mon, 2007-06-04 at 18:01 +0200, Lennert Buytenhek wrote: > On Mon, Jun 04, 2007 at 10:12:18AM -0400, Adam Jackson wrote: > > For F7 I changed most of the ExclusiveArch lines to ExcludeArch, > > so many of the spec changes won't be an issue anymore. > > Right. 99% of the ARM X diffs is just ExclusiveArch changes, and > there I kind of took the blunt approach and just used the set of > servers that alpha uses. Yeah, those are already fixed in F7, afaik. > The only two 'real' patches in the X area for ARM are: > > 1/ xorg-x11-proto-devel not installing XLbx.h and friends anymore, > causing libXext to fail to build (not ARM-specific, and I'm > pretty sure that this would not be an issue anymore post-FC6.) I thought I'd fixed this already. Will re-check. > 2/ xorg-x11-server needs some minor ifdef changes for ARM[*], which > have been floating around since at least the FC2 days, but I must > admit that I'm not sure what the upstream status is of this. It doesn't look like it made it into xserver 1.3. Some of the diff hunks needed correcting since other arches had been added to them, but for the most part it was still needed. It's trivially correct, I'll commit it upstream. - ajax From steve at nexusuk.org Mon Jun 4 17:47:10 2007 From: steve at nexusuk.org (Steve Hill) Date: Mon, 4 Jun 2007 18:47:10 +0100 (BST) Subject: F7 - CPU fan at full speed after resume Message-ID: I'm running Fedora 7 on my Acer TravelMate 6413 notebook. If I suspend to RAM and then resume immediately everything is fine, but if I leave it suspended for a while (over night, for example) then when it resumes the CPU fan comes on at full speed and stays on indefinately. Hibernating and then resuming returns the fan to it's correct behaviour. After a bit of Googling I have tried kicking the fan's ACPI driver by doing: echo -n 3 >/proc/acpi/fan/FAN0/state echo -n 0 >/proc/acpi/fan/FAN0/state The first "echo" line, setting it to D3, produces an error: -bash: echo: write error: Exec format error However, despite the error, dmesg shows: ACPI: Transitioning device [FAN0] to D3 ACPI: Transitioning device [FAN0] to D3 No error is generated for the second "echo" line, setting it to D0, and nothing is logged in dmesg. In any case, it seems to have no effect on the fan's behaviour. Is there anything I can do to kick the fan back into it's correct (temperature controlled) behaviour? -- - Steve xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence From pjones at redhat.com Mon Jun 4 17:49:12 2007 From: pjones at redhat.com (Peter Jones) Date: Mon, 04 Jun 2007 13:49:12 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> Message-ID: <46645098.5040105@redhat.com> David Zeuthen wrote: >> - hal depends on cryptsetup-luks (containing bulky 1.2MB >> static binary in /sbin) > > Probably cryptsetup doesn't need to be linked statically anymore; Peter > Jones would know. Yeah, I don't think it needs to be. I guess I should just remove the static build in the package itself. -- Peter From notting at redhat.com Mon Jun 4 17:55:50 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 Jun 2007 13:55:50 -0400 Subject: Why isn't emacs installed by default In-Reply-To: <604aa7910706040934x3e45d697m459a12fcfba33391@mail.gmail.com> References: <4663B929.6050206@nigelj.com> <20070604093954.GB27020@dspnet.fr.eu.org> <604aa7910706040934x3e45d697m459a12fcfba33391@mail.gmail.com> Message-ID: <20070604175550.GC3696@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > Mugshot does include Emacs in its application stats as a text editor. > Searching for 'text editor' in mugshot's application db and you get > this: > gedit sits at #6 with 1,863 mugshot users > emacs sits at #21 with 482 > vim sits at #30 with 327 > kate sits at #70 with 80 > inkscape sits at #40 with 191 Inkscape as the default text editor! Sounds like fun. Bill, another entry in the 'neither' camp... From nicolas.mailhot at laposte.net Mon Jun 4 17:58:42 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 04 Jun 2007 19:58:42 +0200 Subject: Why isn't emacs installed by default In-Reply-To: References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> Message-ID: <1180979922.15415.24.camel@rousalka.dyndns.org> Le lundi 04 juin 2007 ? 08:59 -0600, Tom Tromey a ?crit : > >>>>> "Nicolas" == Nicolas Mailhot writes: > > >> > 2. depends on a lot of stuff that must be kept working and > >> configured > >> > properly just for it. > >> > >> OK, this closer to a sensible argument. What are these things? > > Nicolas, I notice you didn't answer the most relevant question in > Andrew's note -- what are these things that must be kept working just > for Emacs? Legacy font system is a big one. Emacs is about its last big user, and compounds the problem with special needs (not just plain "Fixed" like about every other straggler) (That may have changed, I haven't run emacs in ages) > I read through your list and some of it seems reasonable > (Emacs has its own accessibility approach, AIUI -- not my area), but > some doesn't (print infrastructure? I think Emacs forks lpr or > whatever). And we've been moving away from lpr since lpr-ng was sidelined in favour of cups (lpr-ng was a terrific lpr system compared to the cups emulation. cups was chosen because lpr was not the target) > That asked (again), I don't see what the big deal is. Is somebody > proposing dropping Emacs or something like that? Someone objected to emacs not being in the defaults anymore. I just explained the process by which an app gets self-sidelined. And then emacs people piled more questions, like I had to justify a process that was happening without any special intervention of mine. You're right, and I'll stop responding now. -- 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 jima at beer.tclug.org Mon Jun 4 18:01:57 2007 From: jima at beer.tclug.org (Jima) Date: Mon, 4 Jun 2007 13:01:57 -0500 (CDT) Subject: fedora for ARM In-Reply-To: <20070604162711.GA5802@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> <20070604084914.GC30973@devserv.devel.redhat.com> <20070604162318.GB10170@devserv.devel.redhat.com> <20070604162711.GA5802@xi.wantstofly.org> Message-ID: On Mon, 4 Jun 2007, Lennert Buytenhek wrote: > On Mon, Jun 04, 2007 at 12:23:18PM -0400, Alan Cox wrote: >>> What upstream? >> >> The upstream of the various projects (eg the kernel). > > I could be wrong here, but I seem to recall very very vaguely that > the upstream kernel was also going into the direction of dropping > sparc32? Sort of. There's no kernel maintainer for sparc32 anymore. The code's still there, it just suffers bit-rot over time (aside from when davem is nice and fixes bugs there, which isn't his role). Which was my point; there isn't really an active upstream for sparc32 for us to track. People having an issue with this fact are welcome to contribute their time to keeping sparc32 alive. I've been one of the strongest proponents, and even I can accept when I'm fighting a losing battle. :-( Jima From nicolas.mailhot at laposte.net Mon Jun 4 18:11:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 04 Jun 2007 20:11:58 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <46640CA4.4090001@iinet.net.au> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> Message-ID: <1180980718.15415.29.camel@rousalka.dyndns.org> Le lundi 04 juin 2007 ? 22:59 +1000, David Timms a ?crit : > Since I also play with older systems with small disks I was going > through a minimal install {text mode only} and found that about 15 > packages get installed because of grub dependencies: a tree (bottom is > what is required by others higher up: {text mode is good for reading} > > grub > | > redhat-artwork <--> fedora-logos If the grub screen gets un-themed as discussed recently all this will be history. -- 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 obi at unixkiste.org Mon Jun 4 18:17:11 2007 From: obi at unixkiste.org (Stefan Held) Date: Mon, 04 Jun 2007 20:17:11 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <1180980718.15415.29.camel@rousalka.dyndns.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> Message-ID: <1180981031.10913.3.camel@workstation.unixkiste.local> Am Montag, den 04.06.2007, 20:11 +0200 schrieb Nicolas Mailhot: > If the grub screen gets un-themed as discussed recently all this will be > history. What would be the benefit of an unthemed grub? Would the solution with isolated grub graphics harm anyone? -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From nicolas.mailhot at laposte.net Mon Jun 4 18:21:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 04 Jun 2007 20:21:25 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <1180981031.10913.3.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> Message-ID: <1180981285.15415.38.camel@rousalka.dyndns.org> Le lundi 04 juin 2007 ? 20:17 +0200, Stefan Held a ?crit : > Am Montag, den 04.06.2007, 20:11 +0200 schrieb Nicolas Mailhot: > > > If the grub screen gets un-themed as discussed recently all this will be > > history. > > What would be the benefit of an unthemed grub? Not scaring users that do not care about bootloaders, and don't enjoy magnificent vga-16 effects -- 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 sundaram at fedoraproject.org Mon Jun 4 18:22:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 23:52:25 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1180981031.10913.3.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> Message-ID: <46645861.8080602@fedoraproject.org> Stefan Held wrote: > Am Montag, den 04.06.2007, 20:11 +0200 schrieb Nicolas Mailhot: > >> If the grub screen gets un-themed as discussed recently all this will be >> history. > > What would be the benefit of an unthemed grub? > > Would the solution with isolated grub graphics harm anyone? See Better Startup in http://fedoraproject.org/wiki/Releases/8/FeatureList Rahul From jkeating at redhat.com Mon Jun 4 18:21:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 14:21:51 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <1180981031.10913.3.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> Message-ID: <200706041421.51808.jkeating@redhat.com> On Monday 04 June 2007 14:17:11 Stefan Held wrote: > Would the solution with isolated grub graphics harm anyone? We have something of a mandate to keep all the trademarked content in one package, fedora-logos. Thus fedora-logos tends to be required by a lot of things, but since it drops files into application directories, fedora-logos itself requires many things so that there are no unowned directories or so that the right application owns it's directories. This is perhaps one case where we can forgo the policy on directory ownership. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From obi at unixkiste.org Mon Jun 4 18:28:06 2007 From: obi at unixkiste.org (Stefan Held) Date: Mon, 04 Jun 2007 20:28:06 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <1180981285.15415.38.camel@rousalka.dyndns.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <1180981285.15415.38.camel@rousalka.dyndns.org> Message-ID: <1180981686.10913.7.camel@workstation.unixkiste.local> Am Montag, den 04.06.2007, 20:21 +0200 schrieb Nicolas Mailhot: > Not scaring users that do not care about bootloaders, and don't enjoy > magnificent vga-16 effects Isn't the boot loader the first thing a user gets an eye on? What do i often hear? The first impression counts? -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From obi at unixkiste.org Mon Jun 4 18:30:17 2007 From: obi at unixkiste.org (Stefan Held) Date: Mon, 04 Jun 2007 20:30:17 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <46645861.8080602@fedoraproject.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <46645861.8080602@fedoraproject.org> Message-ID: <1180981817.10913.9.camel@workstation.unixkiste.local> Am Montag, den 04.06.2007, 23:52 +0530 schrieb Rahul Sundaram: > See Better Startup in > > http://fedoraproject.org/wiki/Releases/8/FeatureList > The upstream work on mode-setting in the kernel Can you explain why we should have a fancy eye candy start up system but no graphics in the Boot Loader which is way before the kernel gets a chance to do fancy stuff? > Rahul Stefan -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From obi at unixkiste.org Mon Jun 4 18:30:50 2007 From: obi at unixkiste.org (Stefan Held) Date: Mon, 04 Jun 2007 20:30:50 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <200706041421.51808.jkeating@redhat.com> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> Message-ID: <1180981850.10913.11.camel@workstation.unixkiste.local> Am Montag, den 04.06.2007, 14:21 -0400 schrieb Jesse Keating: > This is perhaps one case where we can forgo the policy on directory ownership. +1 -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sundaram at fedoraproject.org Mon Jun 4 18:34:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Jun 2007 00:04:17 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1180981817.10913.9.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <46645861.8080602@fedoraproject.org> <1180981817.10913.9.camel@workstation.unixkiste.local> Message-ID: <46645B29.80500@fedoraproject.org> Stefan Held wrote: > Am Montag, den 04.06.2007, 23:52 +0530 schrieb Rahul Sundaram: > >> See Better Startup in >> >> http://fedoraproject.org/wiki/Releases/8/FeatureList >> > > The upstream work on mode-setting in the kernel > > > Can you explain why we should have a fancy eye candy start up system but > no graphics in the Boot Loader which is way before the kernel gets a > chance to do fancy stuff? Read the spec completely. It doesn't use grub. Rahul From obi at unixkiste.org Mon Jun 4 18:52:52 2007 From: obi at unixkiste.org (Stefan Held) Date: Mon, 04 Jun 2007 20:52:52 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <46645B29.80500@fedoraproject.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <46645861.8080602@fedoraproject.org> <1180981817.10913.9.camel@workstation.unixkiste.local> <46645B29.80500@fedoraproject.org> Message-ID: <1180983172.10913.24.camel@workstation.unixkiste.local> Am Dienstag, den 05.06.2007, 00:04 +0530 schrieb Rahul Sundaram: > Read the spec completely. It doesn't use grub. Did you read it? If i read the spec something like that comes to my mind: Patch Grub to shut up until somebody presses a key! Or: What? Who needs more than one Operating System? Please dont show we have more than one installed, we shall rule them all. The User could fear it. (How many guys do you think will press a key to see what is happening?) Patch all the other fancy stuff, fill the initrd with fancy graphics and bootoptions. Seriously. Ram is cheap nowadays. Which leads me to the question: What happens if there is no drm gfx or not enough ram to do this fancy stunt? Do we have to patch mkinitrd to detect the possibilities of the hardware? Will there be a --please-no-boot-gui switch to disable all this? Will we have a grub.conf option which reverts it to normal behavior? > Rahul Don't get me wrong. I Love the Idea of having a machine which boots like the hell, looks fancy but please, do it right. I don't love the idea to have a computer which boots fast and then tells me later via GTK Window: One Service could not be started. Please look into the System log to get a clue what has gone wrong. I've had such a Operating System before. Is this REALLY the right way to go? Stefan -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From gunchev at gmail.com Mon Jun 4 18:58:39 2007 From: gunchev at gmail.com (Doncho N. Gunchev) Date: Mon, 4 Jun 2007 21:58:39 +0300 Subject: Why isn't emacs installed by default In-Reply-To: <604aa7910706040934x3e45d697m459a12fcfba33391@mail.gmail.com> References: <20070604093954.GB27020@dspnet.fr.eu.org> <604aa7910706040934x3e45d697m459a12fcfba33391@mail.gmail.com> Message-ID: <200706042158.39785.gunchev@gmail.com> On Monday 2007-06-04 19:34:28 Jeff Spaleta wrote: > On 6/4/07, Olivier Galibert wrote: > > Really? What are your numbers and how did you come to them? Because > > every linux user I know uses *emacs or vi* except for one that uses > > nedit. > > > Rather than fall into the pointless trap of "everyone I personally > know' uses application foo" .... here are some suggestive numbers from > mugshot. > > Mugshot does include Emacs in its application stats as a text editor. > Searching for 'text editor' in mugshot's application db and you get > this: > gedit sits at #6 with 1,863 mugshot users > emacs sits at #21 with 482 > vim sits at #30 with 327 > kate sits at #70 with 80 > inkscape sits at #40 with 191 > > and for comparison the leading IDE is eclipse is #25 with 439 > and open office writer sits at #15 with 1,023 > > -jef"I use emacs, but I do not want to see it in the default install"spaleta > linuxquestions.org - Text Editor of the Year (2006) http://www.linuxquestions.org/questions/showthread.php?t=514955 vi/vim 639 38.42% Kate 277 16.66% gedit 190 11.43% nano 160 9.62% KWrite 124 7.46% emacs/xemacs 114 6.86% Midnight Commander Editor mcedit 43 2.59% pico 31 1.86% Nedit 23 1.38% jEdit 24 1.44% Scite 21 1.26% joe 17 1.02% "Voters: 1663" - too less to draw a conclusion, but still something :-( I use mcedit, kate and can survive on vi only, but don't ask for mc in the default install. -- Regards, Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu From sundaram at fedoraproject.org Mon Jun 4 18:59:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Jun 2007 00:29:57 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1180983172.10913.24.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <46645861.8080602@fedoraproject.org> <1180981817.10913.9.camel@workstation.unixkiste.local> <46645B29.80500@fedoraproject.org> <1180983172.10913.24.camel@workstation.unixkiste.local> Message-ID: <4664612D.5060908@fedoraproject.org> Stefan Held wrote: > Am Dienstag, den 05.06.2007, 00:04 +0530 schrieb Rahul Sundaram: > >> Read the spec completely. It doesn't use grub. > > Did you read it? > Of course. > If i read the spec something like that comes to my mind: > > Patch Grub to shut up until somebody presses a key! > > Or: > > What? Who needs more than one Operating System? Please dont show we have > more than one installed, we shall rule them all. The User could fear it. There is no need to panic. Of course there will be some sort of menu if the user does press a key but it doesn't necessary have to be grub that provides that. If you have more questions you should contact the owners list to clarify their intentions or add questions in a comments section in the wiki. Rahul From pertusus at free.fr Mon Jun 4 18:59:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 20:59:25 +0200 Subject: rpms/cryptsetup-luks/devel cryptsetup-luks.spec,1.32,1.33 In-Reply-To: <200706041830.l54IUveC014072@cvs-int.fedora.redhat.com> References: <200706041830.l54IUveC014072@cvs-int.fedora.redhat.com> Message-ID: <20070604185924.GA2831@free.fr> On Mon, Jun 04, 2007 at 02:30:57PM -0400, Peter Jones wrote: > Author: pjones > > -%configure --enable-static > -LDADD=-all-static make %{?_smp_mflags} > +%configure > +make You should keep %{?_smp_mflags}, and so use make %{?_smp_mflags} -- Pat From dtimms at iinet.net.au Mon Jun 4 19:04:08 2007 From: dtimms at iinet.net.au (David Timms) Date: Tue, 05 Jun 2007 05:04:08 +1000 Subject: Unwanted RPM dependencies In-Reply-To: <645152.43134.qm@web51511.mail.re2.yahoo.com> References: <645152.43134.qm@web51511.mail.re2.yahoo.com> Message-ID: <46646228.9080201@iinet.net.au> Steve G wrote: >> I did have a thought on whether there exists a tool that can log/count >> file accesses on disk, and then provide reports on used v not used files >> that were installed by rpm ? > > auditctl -a always,exit -S open -F success=1 > > (You'd want to the rule to /etc/audit/audit.rules for it to take effect after > booting.) Then to get the file usage summary report: > > aureport --start this-month --file --summary --success > > There are many attempts to open a file that doesn't exist, so you'd only want to > get the successful ones. This will take some disk space to record what is > accessed a lot. I think by default, the audit system will only occupy 32mb. You > may need to increase that. > Thanks Steve, I'll take a look. DaveT. From dtimms at iinet.net.au Mon Jun 4 19:30:45 2007 From: dtimms at iinet.net.au (David Timms) Date: Tue, 05 Jun 2007 05:30:45 +1000 Subject: Unwanted RPM dependencies - grub v logos In-Reply-To: <200706041421.51808.jkeating@redhat.com> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> Message-ID: <46646865.5080107@iinet.net.au> Jesse Keating wrote: > On Monday 04 June 2007 14:17:11 Stefan Held wrote: >> Would the solution with isolated grub graphics harm anyone? > > We have something of a mandate to keep all the trademarked content in one > package, fedora-logos. Thus fedora-logos tends to be required by a lot of > things, but since it drops files into application directories, fedora-logos > itself requires many things so that there are no unowned directories or so > that the right application owns it's directories. This is perhaps one case > where we can forgo the policy on directory ownership. Given the wiki information noted by Rahul about the direction startup is planned to take, and what I would see as some risk in the "bits" required being ready in time, we could make the changes to grub and fedora-logos now and get it out there, when the risk is low - a long time to prove the changes are fine. If something better comes along before T1 { 20 July 2007 F8 Test1 development freeze 1 August 2007 F8 Test1 release 20 August 2007 F8 FEATURE freeze } then that would supersede the change I was suggesting. Perhaps there has already been major development in this area, if not, it seems rather tight to achieve in 6 or 10 weeks will be enough time. Anyway, I don't think I mentioned that I'm putting my hand up for the packaging if there is at least a chance it will be used, I'd rather not waste time though if there is going to be an outright "no" to the suggestion ? DaveT. From ajackson at redhat.com Mon Jun 4 19:35:21 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 04 Jun 2007 15:35:21 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <46645B29.80500@fedoraproject.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <46645861.8080602@fedoraproject.org> <1180981817.10913.9.camel@workstation.unixkiste.local> <46645B29.80500@fedoraproject.org> Message-ID: <1180985721.8453.73.camel@localhost.localdomain> On Tue, 2007-06-05 at 00:04 +0530, Rahul Sundaram wrote: > Stefan Held wrote: > > Am Montag, den 04.06.2007, 23:52 +0530 schrieb Rahul Sundaram: > > > >> See Better Startup in > >> > >> http://fedoraproject.org/wiki/Releases/8/FeatureList > >> > > > > The upstream work on mode-setting in the kernel > > > > > > Can you explain why we should have a fancy eye candy start up system but > > no graphics in the Boot Loader which is way before the kernel gets a > > chance to do fancy stuff? > > Read the spec completely. It doesn't use grub. Close. It doesn't display grub by default. We're not changing bootloaders. - ajax From sundaram at fedoraproject.org Mon Jun 4 19:50:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Jun 2007 01:20:45 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1180985721.8453.73.camel@localhost.localdomain> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <46645861.8080602@fedoraproject.org> <1180981817.10913.9.camel@workstation.unixkiste.local> <46645B29.80500@fedoraproject.org> <1180985721.8453.73.camel@localhost.localdomain> Message-ID: <46646D15.1020907@fedoraproject.org> Adam Jackson wrote: > On Tue, 2007-06-05 at 00:04 +0530, Rahul Sundaram wrote: >> Stefan Held wrote: >>> Am Montag, den 04.06.2007, 23:52 +0530 schrieb Rahul Sundaram: >>> >>>> See Better Startup in >>>> >>>> http://fedoraproject.org/wiki/Releases/8/FeatureList >>>> >>> >>> The upstream work on mode-setting in the kernel >>> >>> >>> Can you explain why we should have a fancy eye candy start up system but >>> no graphics in the Boot Loader which is way before the kernel gets a >>> chance to do fancy stuff? >> Read the spec completely. It doesn't use grub. > > Close. It doesn't display grub by default. We're not changing > bootloaders. Yep. I should have added "menu" at the end. Rahul From dwmw2 at infradead.org Mon Jun 4 20:25:20 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 04 Jun 2007 21:25:20 +0100 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <1180930681.6254.616.camel@localhost.localdomain> <20070604084914.GC30973@devserv.devel.redhat.com> <20070604162318.GB10170@devserv.devel.redhat.com> <20070604162711.GA5802@xi.wantstofly.org> Message-ID: <1180988720.25232.378.camel@pmac.infradead.org> On Mon, 2007-06-04 at 13:01 -0500, Jima wrote: > Sort of. There's no kernel maintainer for sparc32 anymore. The code's > still there, it just suffers bit-rot over time (aside from when davem is > nice and fixes bugs there, which isn't his role). Which was my point; > there isn't really an active upstream for sparc32 for us to track. Out of interest, is sparc32 really so different from sparc64 that it makes sense to have separate architecture code in the kernel rather than just a single arch/sparc? -- dwmw2 From dtimms at iinet.net.au Mon Jun 4 20:38:00 2007 From: dtimms at iinet.net.au (David Timms) Date: Tue, 05 Jun 2007 06:38:00 +1000 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <1180971253.9788.38.camel@erebor.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> Message-ID: <46647828.5060205@iinet.net.au> Jeremy Katz wrote: > On Mon, 2007-06-04 at 22:59 +1000, David Timms wrote: >> My second size concern comes from glibc-common, specifically the >> /usr/share/locale {283 MB} ( but also and /usr/share/i18n/ 10MB) >> >> I notice that there are dependencies listed in comps.xml for what gets >> installed when a language is chosen {eg dictionary and openoffice >> translations}. This could be extended to the gazillion locales supported >> by glibc and fedora. The maybe most commonly installed individual >> locales could be made into separate packages {guessing ! english french >> german spanish portuguese ? ?}, and then continent or similar for the >> rest of the locales {noting that there is often sub-locales for some >> reqions} {eg african latin-american asian european} ? Installing >> European would also get the more specific english/french/german loc's. > > And your tradeoff is that instead you have X packages more worth of > metadata to download to discover packages/updates. Let's say X was 10, would that be reasonable ? > Plus more space spent on the rpmdb, etc. Is it that inefficient ? Is 1 package with n referenced files have {significantly} less rpmdb usage than say 10 pack's with the same n/10 files each ? Doesn't not having to update and track a smaller subset of files require less resources {storage/rpmdb/.rpm/headers}? > Splitting things like this out is a losing > battle that really ends up costing more in the long-term that it helps. Why is it worth it for openoffice ? or the dictionaries ? > Not to mention that this stuff in comps is at best a crude hack that has > all kinds of weird side effects and user interactions. What would the future perfect situation for these linkages be ? to go away ? How would you go about it then ? Make it not possible ? > Note that you can have RPM not install properly "tagged" locale files > not installed by setting the %_install_langs rpm macro. Can the installer do this ? I have already told the installer I want language X and other support for lang Y-m. Should the installer be setting this macro before it starts installing stuff ? How much quicker could the install be if it the installer didn't have to install the locale/language support a user doesn't want or need ? And all future package operations use the setting, whether from rpm/yum/pirut ? This sounds like it could be the way to go about it for the general user case ? > But your > tradeoff by doing this is you won't be able to use deltarpms Isn't this at the whole .rpm package level anyway ? or is it using the rpmdb on disk as the reference ? if so why would deltarpms not need to track the macro setting you mention {and not install the guff you don't want or need}. > and to add > locale support later, you have to entirely reinstall packages. Enhancement request for rpm coming along the lines of...? rpm -Uvh --lang-support "Turkish" or "All" Let the user have control. DaveT. From kevin.kofler at chello.at Mon Jun 4 20:59:19 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 4 Jun 2007 20:59:19 +0000 (UTC) Subject: Testing update announcements References: <1180708088.3946.1.camel@zebes.localdomain> Message-ID: Will Woods redhat.com> writes: > This was a mistake - AFAIK bodhi should be sending announcements for new > packages in updates-testing from now on. lmacken also said he could > resend the announcements for the already-pushed ones, when he gets > around to it. Those still don't appear to get through. Out of the last push, only the announcement for Luke Macken's own python-sqlobject testing update made it through, not any of the others. The announcements for some stable updates are also missing. Kevin Kofler From mcepl at redhat.com Mon Jun 4 20:48:23 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 04 Jun 2007 22:48:23 +0200 Subject: Why isn't emacs installed by default References: Message-ID: On 2007-06-03, 18:21 GMT, Shams wrote: > I was just wondering is there any reason that emacs is not > selected and installed by default ie. with just the default > install options in Anaconda.. vi is required by POSIX, emacs is not? Matej (hating emacs as much as vim, both suck IMHO) From katzj at redhat.com Mon Jun 4 21:03:29 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Jun 2007 17:03:29 -0400 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <46647828.5060205@iinet.net.au> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> Message-ID: <1180991009.9788.99.camel@erebor.boston.redhat.com> On Tue, 2007-06-05 at 06:38 +1000, David Timms wrote: > Jeremy Katz wrote: > > On Mon, 2007-06-04 at 22:59 +1000, David Timms wrote: > >> My second size concern comes from glibc-common, specifically the > >> /usr/share/locale {283 MB} ( but also and /usr/share/i18n/ 10MB) > >> > >> I notice that there are dependencies listed in comps.xml for what gets > >> installed when a language is chosen {eg dictionary and openoffice > >> translations}. This could be extended to the gazillion locales supported > >> by glibc and fedora. The maybe most commonly installed individual > >> locales could be made into separate packages {guessing ! english french > >> german spanish portuguese ? ?}, and then continent or similar for the > >> rest of the locales {noting that there is often sub-locales for some > >> reqions} {eg african latin-american asian european} ? Installing > >> European would also get the more specific english/french/german loc's. > > > > And your tradeoff is that instead you have X packages more worth of > > metadata to download to discover packages/updates. > Let's say X was 10, would that be reasonable ? It's more like 40. Or 60. Because doing it by region doesn't really help much -- languages are spoken across regions and trying to pigeon hole them like that just doesn't work. Times however many packages this is done for. It gets big _fast_. > > Plus more space spent on the rpmdb, etc. > Is it that inefficient ? Is 1 package with n referenced files have > {significantly} less rpmdb usage than say 10 pack's with the same n/10 > files each ? Doesn't not having to update and track a smaller subset of > files require less resources {storage/rpmdb/.rpm/headers}? You end up having to track more copies of, eg, changelog data and other things that are "common" across a src.rpm set. And yes, that's pretty costly. > > Splitting things like this out is a losing > > battle that really ends up costing more in the long-term that it helps. > Why is it worth it for openoffice ? or the dictionaries ? The argument for OOo was that downloading the 200M (at the time) package was extremely painful. Hopefully as we move towards integrating presto, that can be less of a reason. The total size of the OOo langpack packages right now is 525M. Although part of that, iirc, was the way that OOo bundles up its help and translations being ... less than entirely efficient :) For dictionaries, the argument is that they are maintained separately upstream as separate projects with their own release schedules, etc. Which is relatively reasonable > > Not to mention that this stuff in comps is at best a crude hack that has > > all kinds of weird side effects and user interactions. > What would the future perfect situation for these linkages be ? to go > away ? How would you go about it then ? Make it not possible ? Yes. Because even though the intentions seem reasonable enough, doing it in a sane way just isn't. At least, that's where I've come to after trying three different times. > > Note that you can have RPM not install properly "tagged" locale files > > not installed by setting the %_install_langs rpm macro. > Can the installer do this ? I have already told the installer I want > language X and other support for lang Y-m. Should the installer be > setting this macro before it starts installing stuff ? We used to set it. And then people asked how to add support for a language after the install. And the answer was basically "you can't". So we don't do that anymore. I'd be open to having a way of setting it from, eg, kickstart which is much more likely to be being used in these sorts of "small footprint" situations. > How much quicker > could the install be if it the installer didn't have to install the > locale/language support a user doesn't want or need ? It really wasn't that substantial of a change here. > And all future > package operations use the setting, whether from rpm/yum/pirut ? > This sounds like it could be the way to go about it for the general user > case ? You can set it, but again, it's definitely not the thing you want to do by default. > > But your > > tradeoff by doing this is you won't be able to use deltarpms > Isn't this at the whole .rpm package level anyway ? or is it using the > rpmdb on disk as the reference ? if so why would deltarpms not need to > track the macro setting you mention {and not install the guff you don't > want or need}. deltarpms work by taking the bits you have on disk + the deltarpm and combining them to recreate the update rpm. If you've opted not to put some of those bits on the disk, then it can't recreate the update RPM. > > and to add > > locale support later, you have to entirely reinstall packages. > Enhancement request for rpm coming along the lines of...? > rpm -Uvh --lang-support "Turkish" or "All" > Let the user have control. How is rpm supposed to know where to get those packages from? They may not even be _available_ to install anymore. That's why this path is such madness Jeremy From kevin.kofler at chello.at Mon Jun 4 21:01:26 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 4 Jun 2007 21:01:26 +0000 (UTC) Subject: F7 updates repo contains -debuginfo packages Message-ID: The F7 updates repository lists some -debuginfo packages in its repodata. (I've seen them showing up as "new packages" in Synaptic.) Aren't those supposed to be in a separate debug/ directory with its own metadata? Kevin Kofler From jkeating at redhat.com Mon Jun 4 21:06:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 17:06:07 -0400 Subject: F7 updates repo contains -debuginfo packages In-Reply-To: References: Message-ID: <200706041706.11053.jkeating@redhat.com> On Monday 04 June 2007 17:01:26 Kevin Kofler wrote: > The F7 updates repository lists some -debuginfo packages in its repodata. > (I've seen them showing up as "new packages" in Synaptic.) Aren't those > supposed to be in a separate debug/ directory with its own metadata? We're fixing that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 21:06:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 17:06:53 -0400 Subject: Testing update announcements In-Reply-To: References: <1180708088.3946.1.camel@zebes.localdomain> Message-ID: <200706041706.53892.jkeating@redhat.com> On Monday 04 June 2007 16:59:19 Kevin Kofler wrote: > Those still don't appear to get through. Out of the last push, only the > announcement for Luke Macken's own python-sqlobject testing update made it > through, not any of the others. The announcements for some stable updates > are also missing. Small bug with trying to change them to come "from" the maintainer. Not every maintainer is subscribed to the list with their @fedoraproject.org address so mails were bouncing. Going back to updates at fp.o for now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Mon Jun 4 21:11:12 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 4 Jun 2007 17:11:12 -0400 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <46647828.5060205@iinet.net.au> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> Message-ID: <20070604211111.GJ4033@devserv.devel.redhat.com> On Tue, Jun 05, 2007 at 06:38:00AM +1000, David Timms wrote: > Jeremy Katz wrote: > >On Mon, 2007-06-04 at 22:59 +1000, David Timms wrote: > >>My second size concern comes from glibc-common, specifically the > >>/usr/share/locale {283 MB} ( but also and /usr/share/i18n/ 10MB) glibc-common doesn't have that amount of data in /usr/share/locale, only approx. 2.7MB. The only large thing about glibc-common is /usr/lib/locale/locale-archive (~ 80MB) and that would be a terribly bad idea to split it up, as many locales in that archive share the bigger data files, so if you split it up, it will only occupy many times more disk space. Unlike FC6 which duplicated the locales (there were /usr/lib/locale/*_* subdirectories and the same content packed in /usr/lib/locale/locale-archive, so it occupied ~ 160MB), in F7 it occupies only half of the FC6 size. > >Note that you can have RPM not install properly "tagged" locale files > >not installed by setting the %_install_langs rpm macro. > Can the installer do this ? I have already told the installer I want > language X and other support for lang Y-m. Should the installer be > setting this macro before it starts installing stuff ? How much quicker > could the install be if it the installer didn't have to install the > locale/language support a user doesn't want or need ? And all future > package operations use the setting, whether from rpm/yum/pirut ? > This sounds like it could be the way to go about it for the general user > case ? anaconda used to do that for years but stopped doing so a few years ago because the disadvantages (not being able to get at the additional locales not chosen at install time easily) overweight the advantages (diskspace is cheap). In OLPC or on boxes you know you will never need anything but a few selected locales you can set %_install_langs, e.g. from kickstart. Jakub From caillon at redhat.com Mon Jun 4 21:09:29 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 17:09:29 -0400 Subject: Testing update announcements In-Reply-To: <200706041706.53892.jkeating@redhat.com> References: <1180708088.3946.1.camel@zebes.localdomain> <200706041706.53892.jkeating@redhat.com> Message-ID: <46647F89.6060701@redhat.com> Jesse Keating wrote: > Small bug with trying to change them to come "from" the maintainer. Not every > maintainer is subscribed to the list with their @fedoraproject.org > address so mails were bouncing. Going back to updates at fp.o for now. I didn't realize I even had this e-mail address available to me. Please tell me more. From kevin.kofler at chello.at Mon Jun 4 21:23:50 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 4 Jun 2007 21:23:50 +0000 (UTC) Subject: Testing update announcements References: <1180708088.3946.1.camel@zebes.localdomain> <200706041706.53892.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > Small bug with trying to change them to come "from" the maintainer. Not > every maintainer is subscribed to the list with their > fedoraproject.org address so mails were bouncing. Going back to updates > fp.o for now. Could it somehow be possible to whitelist mails from Bodhi similarly to how mails coming in through the GMane gateway are? For example, I'm not subscribed to this list at all, yet I can post through GMane (I'm using the web interface). Kevin Kofler From sundaram at fedoraproject.org Mon Jun 4 21:49:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Jun 2007 03:19:44 +0530 Subject: Testing update announcements In-Reply-To: <46647F89.6060701@redhat.com> References: <1180708088.3946.1.camel@zebes.localdomain> <200706041706.53892.jkeating@redhat.com> <46647F89.6060701@redhat.com> Message-ID: <466488F8.4030009@fedoraproject.org> Christopher Aillon wrote: > Jesse Keating wrote: >> Small bug with trying to change them to come "from" the maintainer. >> Not every maintainer is subscribed to the list with their >> @fedoraproject.org address so mails were bouncing. Going >> back to updates at fp.o for now. > > I didn't realize I even had this e-mail address available to me. Please > tell me more. Everybody who has a Fedora account automatically gets a @fedoraproject.org alias. Rahul From valent.turkovic at gmail.com Mon Jun 4 21:51:38 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 4 Jun 2007 23:51:38 +0200 Subject: Fedora 8 Schedule In-Reply-To: <200706012154.13871.gunchev@gmail.com> References: <16de708d0706010553y31ad2d9are2fa95c04296639b@mail.gmail.com> <200706012154.13871.gunchev@gmail.com> Message-ID: <64b14b300706041451j53fcd071sc71266ec543dba70@mail.gmail.com> > Ha-ha, in this case can we translate it as '?????' (Rakia) in the release notes > for our Bulgarian users? :-D (sorry, couldn't stop myself) > LOL :) Then it is very, very similar for Croatian users: "Rakija" :))) -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From caillon at redhat.com Mon Jun 4 22:03:29 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 18:03:29 -0400 Subject: Testing update announcements In-Reply-To: <466488F8.4030009@fedoraproject.org> References: <1180708088.3946.1.camel@zebes.localdomain> <200706041706.53892.jkeating@redhat.com> <46647F89.6060701@redhat.com> <466488F8.4030009@fedoraproject.org> Message-ID: <46648C31.1030402@redhat.com> Rahul Sundaram wrote: > Christopher Aillon wrote: >> Jesse Keating wrote: >>> Small bug with trying to change them to come "from" the maintainer. >>> Not every maintainer is subscribed to the list with their >>> @fedoraproject.org address so mails were bouncing. Going >>> back to updates at fp.o for now. >> >> I didn't realize I even had this e-mail address available to me. >> Please tell me more. > > Everybody who has a Fedora account automatically gets a > @fedoraproject.org alias. Sorry, but that doesn't tell me anything more than Jesse said. Please try again. This time with classic hits such as "How to Use It" From sundaram at fedoraproject.org Mon Jun 4 22:08:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Jun 2007 03:38:58 +0530 Subject: Testing update announcements In-Reply-To: <46648C31.1030402@redhat.com> References: <1180708088.3946.1.camel@zebes.localdomain> <200706041706.53892.jkeating@redhat.com> <46647F89.6060701@redhat.com> <466488F8.4030009@fedoraproject.org> <46648C31.1030402@redhat.com> Message-ID: <46648D7A.10909@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Christopher Aillon wrote: >>> Jesse Keating wrote: >>>> Small bug with trying to change them to come "from" the maintainer. >>>> Not every maintainer is subscribed to the list with their >>>> @fedoraproject.org address so mails were bouncing. Going >>>> back to updates at fp.o for now. >>> >>> I didn't realize I even had this e-mail address available to me. >>> Please tell me more. >> >> Everybody who has a Fedora account automatically gets a >> @fedoraproject.org alias. > > Sorry, but that doesn't tell me anything more than Jesse said. Please > try again. This time with classic hits such as "How to Use It" Ok. When you signed up as a contributor to Fedora, you had to create a user name at https://admin.fedoraproject.org/accounts/. You also had a specify your email id after which you got an email and signed your CLA with your gpg key. Right? Now if anyone sends a email to the account name @ fedoraproject.org you would get email to the email id you signed up with in the account system. Is that more clear? Rahul From shams at orcon.net.nz Mon Jun 4 10:07:37 2007 From: shams at orcon.net.nz (Shams) Date: Mon, 4 Jun 2007 22:07:37 +1200 Subject: Bug: Fedora doesn't close DVD drive door Message-ID: Hi, When I shutdown Fedora 7 it doesn't close the DVD drive door automatically and the door is left open. Same problem persisted with Fedora 6. However if I reboot then the DVD drive door does get closed automatically. Thanks Shams -- From tmz at pobox.com Mon Jun 4 22:12:46 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 4 Jun 2007 18:12:46 -0400 Subject: Testing update announcements In-Reply-To: References: <1180708088.3946.1.camel@zebes.localdomain> <200706041706.53892.jkeating@redhat.com> Message-ID: <20070604221246.GA22038@psilocybe.teonanacatl.org> Kevin Kofler wrote: > Jesse Keating redhat.com> writes: >> Small bug with trying to change them to come "from" the maintainer. >> Not every maintainer is subscribed to the list with their >> fedoraproject.org address so mails were bouncing. >> Going back to updates fp.o for now. > > Could it somehow be possible to whitelist mails from Bodhi similarly > to how mails coming in through the GMane gateway are? For example, > I'm not subscribed to this list at all, yet I can post through GMane > (I'm using the web interface). It ought to be relatively easy to sync the list of emails for fedora account holders with those allowed to post to the announce list without being a member of that list. With a little chunk of python this could be rolled into a withlist script (withlist is part of mailman). The emails from the accounts system would need to be synced/added to the accept_these_nonmembers property for the announce list. Of course, on the list of things to do, I doubt this is near the top for the infrastructure folks (who must all be damn good jugglers. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The man who can make hard things easy is the educator -- Ralph Waldo Emerson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From caillon at redhat.com Mon Jun 4 22:11:58 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 18:11:58 -0400 Subject: Testing update announcements In-Reply-To: <46648D7A.10909@fedoraproject.org> References: <1180708088.3946.1.camel@zebes.localdomain> <200706041706.53892.jkeating@redhat.com> <46647F89.6060701@redhat.com> <466488F8.4030009@fedoraproject.org> <46648C31.1030402@redhat.com> <46648D7A.10909@fedoraproject.org> Message-ID: <46648E2E.8070202@redhat.com> Rahul Sundaram wrote: > Ok. When you signed up as a contributor to Fedora, you had to create a > user name at https://admin.fedoraproject.org/accounts/. You also had a > specify your email id after which you got an email and signed your CLA > with your gpg key. Right? Now if anyone sends a email to the account > name @ fedoraproject.org you would get email to the email id you signed > up with in the account system. Is that more clear? Awww, no IMAP/storage. Oh well. From chasd at silveroaks.com Mon Jun 4 22:33:17 2007 From: chasd at silveroaks.com (chasd) Date: Mon, 4 Jun 2007 17:33:17 -0500 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <20070603200930.68EF0734AD@hormel.redhat.com> References: <20070603200930.68EF0734AD@hormel.redhat.com> Message-ID: <7BAFE5F9-5213-40C6-9077-4432F76F598E@silveroaks.com> Christopher Aillon wrote: > Yes, I did mean XULRunner. I thought that XULRunner was likely to be "private" for Firefox 3, at least by the Mozilla XULRunner Roadmap. Or is that limitation mainly on other platforms ? Charles Dostale From poelstra at redhat.com Mon Jun 4 22:40:43 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 04 Jun 2007 15:40:43 -0700 Subject: Upcoming FESCo Election In-Reply-To: <1180627394.5867.2.camel@lincoln> References: <1180627394.5867.2.camel@lincoln> Message-ID: <466494EB.1010300@redhat.com> Brian Pepple said the following on 05/31/2007 09:03 AM Pacific Time: > Hi All! > > It's that time of year again. Everyone that wants to be in the next > FESCo needs to nominate him/herself for it by June 12, 2007 0:00 UTC; > that self-nomination should contain some information's like "Mission > Statement, Past work summary and Future plans". > > Please place your nomination on this page in the wiki: > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations > > The actual election will start on Thursday, June 14, 2007 0:01 UTC and > will last until Sunday, June 24, 2007 23:59 UTC. The results will be > posted to the fedora-devel list. The first meeting of the "new" FESCo > will be on Thursday, July 05, 2007 on #fedora-meeting at 17:00 UTC. A > new chair will be elected there by the new members. > > For more information regarding the election, please refer to this: > http://fedoraproject.org/wiki/Extras/Policy/FESCoElections > > > Thanks, > /B > Forgive me if I am wrong, but I cannot find any information on the wiki that explains *exactly* what FESCO does or what it is responsible for. Thus, I'm not sure whether it is something I or other people would want to become involved with. Can someone provide a URL or add a new wiki page? Thanks, John From zaitcev at redhat.com Mon Jun 4 22:47:44 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 4 Jun 2007 15:47:44 -0700 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> Message-ID: <20070604154744.543b041d.zaitcev@redhat.com> On Mon, 4 Jun 2007 13:10:55 +0200 (CEST), Linus Walleij wrote: > 1. What is the target system(s) you're using? I for one have a very vague > understanding of what lab boards etc may be used for running ARM > Fedora. This was my question too. I attended a talk by Deepak Saxena a month ago and it looked like there's no clear leader anymore, like Netwinder used to be. What are these RPMs for? OpenMoko? Palm? Are these systems even binary compatible in the user mode? -- Pete From webmaster at aus-city.com Mon Jun 4 22:55:32 2007 From: webmaster at aus-city.com (David Cottle) Date: Tue, 05 Jun 2007 08:55:32 +1000 Subject: kernel 1PPS support was in FC6 and now not in F7 Message-ID: <46649864.6090101@aus-city.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Background. I was running FC6 for about 6 months, with the stock kernel (not xen). I also use a serial GPS, with gpsd to generate time source for ntp. I was running selinux enforcing, but had ntpd running without selinux by modifying its policy in the selinux policy gui. The GPS has the DCD line driven by the GPS 1PPS output. If I did a ntpq -p, it showed ntp was happily locked primarily to *SHM(1) GPS1 which is the 1PPS accuracy, and then secondary to +SHM(0) GPS which is the non 1PPS output, then then pool servers. Now the question and problem. I upgraded to F7 and gps stopped. Firstly there is no selinux policy anymore for the ntpd daemon, so I now run permissive rather than enforcing. That got ntp using the gps via gpsd again. However it refuses to work 1PPS. I put in a bug to fedora bugzilla and I am told all the kernels were never compiled with 1PPS. If this is the case how was it working happily in FC6 with a stock kernel. If I removed the DCD line ntpq -p then completely dropped the SHM(1) GPS1 and went to SHM(0) GPS as * So I want to ask that the 1PPS be put back into the F7 kernel as it was there in FC6, so why take it away? Also the selinux-policy needs to let you disable selinux against the ntpd daemon, so you can run enforcing. Thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGZJhki1lOcz5YUMgRAtSVAKCcBLzP5/1mH7eM9tulx0yYA1ET5QCfYtoB jLsJmHdeHgtSiTPTu3XEo2c= =Mj/+ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: webmaster.vcf Type: text/x-vcard Size: 120 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 23:31:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 19:31:19 -0400 Subject: Testing update announcements In-Reply-To: <46648E2E.8070202@redhat.com> References: <46648D7A.10909@fedoraproject.org> <46648E2E.8070202@redhat.com> Message-ID: <200706041931.22973.jkeating@redhat.com> On Monday 04 June 2007 18:11:58 Christopher Aillon wrote: > Awww, no IMAP/storage. ?Oh well. Correct, it's just an alias. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From greno at verizon.net Tue Jun 5 00:34:39 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 04 Jun 2007 20:34:39 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <46642C7D.3070107@verizon.net> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> <200706040941.02738.jkeating@redhat.com> <46641ABB.3070004@verizon.net> <20070604145239.GD24880@devserv.devel.redhat.com> <46642C7D.3070107@verizon.net> Message-ID: <4664AF9F.1050608@verizon.net> QEMU hardware profile: The QEMU PC System emulator simulates the following peripherals: * i440FX host PCI bridge and PIIX3 PCI to ISA bridge * Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non standard modes). * PS/2 mouse and keyboard * 2 PCI IDE interfaces with hard disk and CD-ROM support * Floppy disk * NE2000 PCI network adapters * Serial ports * Creative SoundBlaster 16 sound card * ENSONIQ AudioPCI ES1370 sound card * Adlib(OPL2) - Yamaha YM3812 compatible chip * PCI UHCI USB controller and a virtual USB hub. SMP is supported with up to 255 CPUs. Note that adlib is only available when QEMU was configured with -enable-adlib QEMU uses the PC BIOS from the Bochs project and the Plex86/Bochs LGPL VGA BIOS. QEMU uses YM3812 emulation by Tatsuyuki Satoh Gerry Reno wrote: > > Smolt profile: > http://smolt.fedoraproject.org/show?UUID=ab65ac7d-1e79-4479-b7bf-14f4936b6e2a > > > > Alan Cox wrote: >> On Mon, Jun 04, 2007 at 09:59:23AM -0400, Gerry Reno wrote: >>> I have not found a driver yet from the list that works. I've >>> selected all the ones for the chipsets, any that looked generic, and >>> just others at random. No luck yet. >> >> What hardware ? >> > From bpepple at fedoraproject.org Tue Jun 5 01:53:48 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 21:53:48 -0400 Subject: FESCo Meeting Summary for 2007-05-31 Message-ID: <1181008428.2819.0.camel@kennedy> 2007 May 31 FESCo Meeting Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Tom Callaway (spot) * Rex Dieter (rdieter) * Christian Iseli (c4chris) * Josh Boyer (jwb) * Warren Togami (warren) * == Summary == Various Static Libs * FESCo approved the proposal for a blanket exception for packages which link against flex's libfl.a * FESCo voted against a proposal for linking ipsvd statically against dietlibc. * FESCo voted against a proposal against statically link libgcrypt into gaim-otr. ACL's * Long discussion on how to solve some of our problems with the usage of acl's, which prevent people from fixing simple things like evr problems. * For the interim, until a more permanent solution is implemented, tibbs & nirik have been given cvsadmin access, and if there are other Fedora contributors that commonly help out with such issue, and wish to also be given access please contact FESCo. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bernie at codewiz.org Tue Jun 5 02:52:41 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Mon, 04 Jun 2007 22:52:41 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> Message-ID: <4664CFF9.90606@codewiz.org> David Zeuthen wrote: > On Mon, 2007-06-04 at 03:37 -0400, Bernardo Innocenti wrote: >> - mkinitrd depends on lvm2 and dmraid. Both could easily >> be made optional. > > You most probably don't need mkinitrd on OLPC as the kernel got all the > drivers built-in and IIRC OLPC don't even use the initrd (when I was > working on it, it didn't). So you could have some OLPC specific package > that provides mkinitrd and symlinks /sbin/mkinitrd -> /bin/true or > something. We need mkinitrd because you can also boot from usb with the ext3 image. The contents of jffs2 and ext3 images should be identical to simplify distribution. And by the way, the kernel depends on mkinitrd so we can't remove it without breaking RPM deps. We try to avoid kludges as much as possible because it makes life very hard when updating the system with tools like yum. > Probably cryptsetup doesn't need to be linked statically anymore; Peter > Jones would know. Good. But, why do we need *any* static binary in the first place? I don't buy the robustness argument: a 1MB binary is equally subject to corruption than a smaller binary plus a 1MB library. Also, I dismiss the argument that today's computers have huge hard drives anyway so let's waste them. Bigger hard drives are meant to hold more data, not the same amount of data stored in inefficient formats. And any way, Linux is also being used with constrained systems where 256MB of flash storage is luxury. Some binaries we may wont to relink dynamically: - /sbin/e2fsck (dynamic on debian) - /sbin/dmsetup.static (dynamic on debian) - /sbin/insmod.static (dynamic on debian) - /sbin/ldconfig (yes, even this one!) And what is /sbin/sln? It's part of glibc, but it's not documented anywhere. Can we kick it out? Also, the /sbin/tc and /sbin/ip binaries are quite big despite being dynamically linked and stripped. Anybody knows why? > Either way, if you don't expose LUKS encrypted stuff > in the UI I guess you can just drop the cryptsetup dep from hal since it > will gracefully recover and just throw and error if Crypto.Setup() is > called. I'm not a platform developer, but from what I hear, we'd prefer such changes to happen in Fedora, so we do not need to maintain too many forked packages in the OLPC repo. All Fedora users will benefit from a smaller installation set anyway. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From tonynelson at georgeanelson.com Tue Jun 5 03:50:11 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 4 Jun 2007 23:50:11 -0400 Subject: CDs from DVD with Pungi almost works Message-ID: Because of the requests on fedora-list for CDs for F7, I'm trying to get Pungi to create CDs from the DVD, and I think it almost works. I'll need some help if I'm to get it to work. My basic procedure is to make a Pungi config file and a yum.conf that will use the loopback-mounted DVD ISO file as the source of packages and other info. That seems to work. The DVD repodata was not suitable because the "media:" URLs weren't understood, so I used createrepo to make new repodata and pointed the yum.conf to it. Is there a way to use the DVD's repodata? Do I need to monkey-patch urlopen()? The DVD's comps.xml does not include all the packages on the DVD. 19 are omitted, including anaconda-runtime, which causes buildinstall to fail (?). In any event, at "Building images...", upd-instroot, mk-images, and makestamp.py were missing, and later ".discinfo doesn't exist in the unified tree, not splitting". Should those 19 packages have been in comps.xml? Is there some way to add them to the process without writing a comps.xml? -- ____________________________________________________________________ TonyN.:' ' From lemenkov at gmail.com Tue Jun 5 04:01:19 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 5 Jun 2007 04:01:19 +0000 (UTC) Subject: annoying syslog message from kernel References: <1180961190.2822.4.camel@rt.jesacco.com> Message-ID: Joseph Sacco gnome.org> writes: > > I started seeing these messages > > Message from syslogd at Mon Jun 4 04:40:20 2007 ... > plantain kernel: ------------[ cut here ]------------ > > a while back. Not harmful, but annoying. It looks more harmful at closer look, actually. If you inspect your /var/log/messages you'll see something like: ================================= Jun 5 07:49:48 Sulaco kernel: ------------[ cut here ]------------ Jun 5 07:49:48 Sulaco kernel: Badness at kernel/softirq.c:138 Jun 5 07:49:48 Sulaco kernel: Call Trace: Jun 5 07:49:48 Sulaco kernel: [DA18BBD0] [C0008AB0] show_stack+0x50/0x184 (unreliable) Jun 5 07:49:48 Sulaco kernel: [DA18BBF0] [C012072C] report_bug+0x84/0xc8 Jun 5 07:49:48 Sulaco kernel: [DA18BC00] [C02B1A2C] __kprobes_text_start+0x154/0x538 Jun 5 07:49:48 Sulaco kernel: [DA18BC50] [C0013280] ret_from_except_full+0x0/0x4c Jun 5 07:49:48 Sulaco kernel: --- Exception: 700 at local_bh_enable+0x28/0x8c Jun 5 07:49:48 Sulaco kernel: LR = cond_resched_softirq+0x58/0x80 Jun 5 07:49:48 Sulaco kernel: [DA18BD10] [24002428] 0x24002428 (unreliable) Jun 5 07:49:48 Sulaco kernel: [DA18BD20] [C02B0344] cond_resched_softirq+0x58/0x80 Jun 5 07:49:48 Sulaco kernel: [DA18BD30] [C0231D30] release_sock+0x54/0xac Jun 5 07:49:48 Sulaco kernel: [DA18BD50] [C0269B20] tcp_sendmsg+0xac0/0xbf8 Jun 5 07:49:48 Sulaco kernel: [DA18BDB0] [C028666C] inet_sendmsg+0x60/0x74 Jun 5 07:49:48 Sulaco kernel: [DA18BDD0] [C022ED68] sock_aio_write+0x114/0x130 Jun 5 07:49:48 Sulaco kernel: [DA18BE30] [C008FF38] do_sync_write+0xb8/0x10c Jun 5 07:49:48 Sulaco kernel: [DA18BEF0] [C0090B10] vfs_write+0x104/0x1c8 Jun 5 07:49:48 Sulaco kernel: [DA18BF10] [C00911AC] sys_write+0x4c/0x8c Jun 5 07:49:48 Sulaco kernel: [DA18BF40] [C0012C24] ret_from_syscall+0x0/0x38 Jun 5 07:49:48 Sulaco kernel: --- Exception: c01 at 0x1fabb098 Jun 5 07:49:48 Sulaco kernel: LR = 0x2002b430 Jun 5 07:50:13 Sulaco gconfd (petro-1954): GConf server is not in use, shutting down. Jun 5 07:50:13 Sulaco gconfd (petro-1954): Exiting ================================= I also encountered this nasty behavior. From poelstra at redhat.com Tue Jun 5 04:19:18 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 04 Jun 2007 21:19:18 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-04 Message-ID: <4664E446.8060704@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jun-04 Please make corrections and clarifications to the wiki page. == Spam-o-matic for rawhide == * the tool that generated the broken deps report at the end of the old rawhide emails * DECISION: * notting is going to get 'spam-o-matic' working for rawhide reports again * including a full report of broken deps at the bottom of rawhide report mails like before the merge, and specific individual mails to maintainers with broken deps. * f13 will let mike schwendnt know that this is coming. == Updates policy == * DECISION: * rel-eng is proposing to FESCo that Update tool defaults to pushing to updates-testing * Maintainer has option to "skip testing" and can do so without an "approver" roadblock. * UPdate gets marked as "hot" somehow visually so that releng / qa can look over before pushing if necessary == Signing unsigned 7 packages == * DECSISON: * To do some final Fedora 7 tree maintenance, replace unsigned packages with signed versions * chmod 644 all the files (not dirs). * Test with cached yum metadata to see what happens, push to mirror master, alert mirrors. * Leave the i486/586/686/athlon stuff alone, fix those by updates. == Disable tagged builds from srpms in koji == * DECISION: * Koji's little know ability to accept builds for tags directly from srpms rather than CVS checkouts will be disabled * This will prevent people from getting builds into collections that aren't managed in CVS. * This will NOT disrupt admins ability to bootstrap new arches. == Freeze Policy == * DECISION: * Defer to a subsequent meeting * Discuss release Freeze Requirments * determine what they are * document them * determine how to best manage them * get input from QA * Start discussion on fedora-maintainers-list the write up results into a wiki page == IRC Transcript == From kevin.kofler at chello.at Tue Jun 5 04:32:31 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 5 Jun 2007 04:32:31 +0000 (UTC) Subject: Announcing Quarticurve: Unofficial Bluecurve Qt 4 port References: Message-ID: I just uploaded a version which is pretty much usable. Tab widgets need some work (fixing display glitches for tabs at the top and bottom, handling horizontal tabs instead of throwing those at the QCleanlooksStyle base class), there's a glitch with the dropdown pushbutton in the Qt Designer "New" dialog and there might be some remaining off-by-one issues left (Qt 3 defined height and width as width = right - left + 1 and height = bottom - top + 1, Qt 4 instead uses height and width natively and defines right and bottom by those equations for compatibility reasons, which doesn't work that well because it means Qt 4 code now has a different idea of the size of the rectangle than ported Qt 3 code, causing these off-by-one errors), but other than that, it works pretty well now. Of course, it could also use some cleanups, like using QStyleOption more consistently instead of peeking into widgets to get the needed information. I also added a readme with installation instructions for those who want to try it out. Same URL: http://www.tigen.org/kevin.kofler/pcprogs/quarticurve.7z Kevin Kofler From abraxis at telkomsa.net Tue Jun 5 05:18:10 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Tue, 5 Jun 2007 07:18:10 +0200 Subject: pungi error In-Reply-To: <200706040940.02819.jkeating@redhat.com> References: <20070603060025.GA13719@eeyore.32.boerneef.vornavalley> <200706030858.33755.jkeating@redhat.com> <20070604045638.GB13719@eeyore.32.boerneef.vornavalley> <200706040940.02819.jkeating@redhat.com> Message-ID: <20070605051809.GD13719@eeyore.32.boerneef.vornavalley> On Mon, Jun 04, 2007 at 09:40:02AM -0400, Jesse Keating wrote: > On Monday 04 June 2007 00:56:38 Neil Thompson wrote: > > Nope - I'm running an i386 F7. ?I am running on an X86_64 processor, but > > that should should make no difference. > > Can you post up your configs and full logs? > For anyone else watching, logs/configs sent directly to Jesse as the file was too big for the list. -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From vnpenguin at vnoss.org Tue Jun 5 05:23:52 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Tue, 5 Jun 2007 07:23:52 +0200 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: Message-ID: On 6/5/07, Tony Nelson wrote: > Because of the requests on fedora-list for CDs for F7, I'm trying to get > Pungi to create CDs from the DVD, and I think it almost works. I'll need > some help if I'm to get it to work. > > My basic procedure is to make a Pungi config file and a yum.conf that will > use the loopback-mounted DVD ISO file as the source of packages and other > info. That seems to work. > > The DVD repodata was not suitable because the "media:" URLs weren't > understood, so I used createrepo to make new repodata and pointed the > yum.conf to it. Is there a way to use the DVD's repodata? Do I need to > monkey-patch urlopen()? Just umount the DVD if it has mounted automatically. And then re mount it under /media/DVD for example. It works well for me :-) -- http://vnoss.org From aoliva at redhat.com Tue Jun 5 00:41:28 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 04 Jun 2007 21:41:28 -0300 Subject: Why isn't emacs installed by default In-Reply-To: <604aa7910706040934x3e45d697m459a12fcfba33391@mail.gmail.com> (Jeff Spaleta's message of "Mon\, 4 Jun 2007 08\:34\:28 -0800") References: <4663B929.6050206@nigelj.com> <20070604093954.GB27020@dspnet.fr.eu.org> <604aa7910706040934x3e45d697m459a12fcfba33391@mail.gmail.com> Message-ID: On Jun 4, 2007, "Jeff Spaleta" wrote: > Mugshot does include Emacs in its application stats as a text editor. Heresy! :-) Emacs is not a text editor. It just plays one on TV. Seriously, there are people who us it as a text editor only, but that's like saying that a computer is just a typewriter. Personally, I just use it as an IDE, a programmable calculator, an e-mail reader and for some limited web browsing, but I know some people use it for IRC and many other needs as well. Try that with gedit, vim, kate, jed or even eclipse ;-) Ok, eclipse is programmable and extensible too, so that one might stand a chance ;-) As for the others, they are indeed just text editors. Sorry, it just makes me sad when people compare Emacs with text editors. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From pertusus at free.fr Tue Jun 5 06:58:13 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 5 Jun 2007 08:58:13 +0200 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <4664CFF9.90606@codewiz.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> Message-ID: <20070605065813.GA5736@free.fr> On Mon, Jun 04, 2007 at 10:52:41PM -0400, Bernardo Innocenti wrote: > - /sbin/ldconfig (yes, even this one!) I am not sure, but wouldn't that be a bit dangerous? What would be the gains? -- Pat From jdieter at gmail.com Tue Jun 5 07:46:22 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 05 Jun 2007 10:46:22 +0300 Subject: rawhide report: 20070604 changes In-Reply-To: <200706041153.48272.jkeating@redhat.com> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <1180959890.3218.54.camel@vader.jdub.homelinux.org> <1180971487.9788.43.camel@erebor.boston.redhat.com> <200706041153.48272.jkeating@redhat.com> Message-ID: <1181029582.3566.1.camel@jndwidescreen.lesbg.loc> On Mon, 2007-06-04 at 11:53 -0400, Jesse Keating wrote: > Hrm, I didn't realize there were older builds and thus approved the request to > just block yum-presto. And this is probably my fault as I'm still new to package maintenance and wasn't sure what the proper steps were to fix the failed dependency problem. Next time (which there hopefully won't be), I'll ask for the new version with broken dependencies to be pulled and the old version to be left. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Tue Jun 5 07:49:34 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 5 Jun 2007 09:49:34 +0200 Subject: "core" Message-ID: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> Hello alll, I just saw that some apache dir listings show a small bomb if a directory is named "core". For the next rename of directories we might want to move "core" again to something else then. E.g. look at: http://www.jur-linux.org/download/fedora/ regards, Florian La Roche From Axel.Thimm at ATrpms.net Tue Jun 5 08:24:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 10:24:25 +0200 Subject: "core" In-Reply-To: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> References: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> Message-ID: <20070605082425.GE23972@neu.nirvana> On Tue, Jun 05, 2007 at 09:49:34AM +0200, Florian La Roche wrote: > I just saw that some apache dir listings show a small bomb if a > directory is named "core". That's ugly (but it's there since FC1). It would have to be fixed in the apache conf to only assume files to be core dumps, not directories. > For the next rename of directories we might want to move "core" > again to something else then. Which next rename? There is no "core" in the current Fedora >= 7 hierarchy and the old one needs to stay that way. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jun 5 08:25:53 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 5 Jun 2007 10:25:53 +0200 Subject: First impressions of a system update with yum In-Reply-To: <1180688318.2556.11.camel@localhost.localdomain> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <20070601105241.35b741bc@python3.es.egwn.lan> <1180688318.2556.11.camel@localhost.localdomain> Message-ID: <20070605102553.20ceb611@python3.es.egwn.lan> Richard Hughes wrote : > On Fri, 2007-06-01 at 10:52 +0200, Matthias Saou wrote: > > I just need to get S3 working again, as I wanted to start fresh and > > removed all the kernel boot options I had in case they weren't useful > > anymore... > > If you are talking about s3 (suspend), see > http://people.freedesktop.org/~hughsient/quirk/ That page was incredibly helpful. I actually understood what all those different "quirks" did! :-) For my Dell "Latitude X1", which is not yet in the F7 HAL files, I had to enable the --quirk-vbe-post quirk, as otherwise the screen never turned on. With FC6 I was using the i810 Xorg driver, with 855resolution to be able to get the native 1280x768 resolution, I had to hack my way through the ACPI scripts to get S3 working (tg3 was causing trouble at some point), and the LCD backlight never turned on properly on resume, I had to always press Fn+Up to increase the brightness for it to light up completely again. With F7, I switched to the "intel" modesetting driver (also removed 855resolution), added the "power_management.quirk.vbe_post" key to true in a string="Latitude X1" section of the Dell HAL file, and it all just works now! Awesome! :-) I had a last question, though : The Dell models seem to be identified with system.hardware.product contains="Foo". This seems like a pretty bad idea, since it would be contains="X1" in this case, and will/would match a future Dell "Latitude X10" laptop... It would seem wiser to use string="Latitude X1", even though it would be partly redundant with the earlier prefix="Latitude". Or maybe there is a suffix="Bar"? Matthias PS: Congratulations on your diploma, Richard ;-) -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.50 0.32 0.29 From hughsient at gmail.com Tue Jun 5 08:53:42 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 05 Jun 2007 09:53:42 +0100 Subject: First impressions of a system update with yum In-Reply-To: <20070605102553.20ceb611@python3.es.egwn.lan> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <20070601105241.35b741bc@python3.es.egwn.lan> <1180688318.2556.11.camel@localhost.localdomain> <20070605102553.20ceb611@python3.es.egwn.lan> Message-ID: <1181033622.2504.5.camel@work> On Tue, 2007-06-05 at 10:25 +0200, Matthias Saou wrote: > Richard Hughes wrote : > > > On Fri, 2007-06-01 at 10:52 +0200, Matthias Saou wrote: > > > I just need to get S3 working again, as I wanted to start fresh and > > > removed all the kernel boot options I had in case they weren't useful > > > anymore... > > > > If you are talking about s3 (suspend), see > > http://people.freedesktop.org/~hughsient/quirk/ > > That page was incredibly helpful. I actually understood what all those > different "quirks" did! :-) Good :-) I'll continue to add content as required. Soon multimedia keyboard will be quirks in hal-info and the same site will be used to make keyboards just work in the future. > For my Dell "Latitude X1", which is not yet in the F7 HAL files, I had > to enable the --quirk-vbe-post quirk, as otherwise the screen never > turned on. Cool. > With F7, I switched to the "intel" modesetting driver (also removed > 855resolution), added the "power_management.quirk.vbe_post" key to true > in a string="Latitude X1" section of the Dell HAL file, and it all just > works now! Awesome! :-) Cool. > I had a last question, though : The Dell models seem to be identified > with system.hardware.product contains="Foo". This seems like a pretty > bad idea, since it would be contains="X1" in this case, and will/would > match a future Dell "Latitude X10" laptop... It would seem wiser to use > string="Latitude X1", even though it would be partly redundant with the > earlier prefix="Latitude". Or maybe there is a suffix="Bar"? There is such a thing: You can either use suffix or just use string for the whole text. I would be very appreciative if you could generate a patch and sent it to the mailing list. I'm glad things are now working. Richard. From alan at redhat.com Tue Jun 5 09:07:18 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 5 Jun 2007 05:07:18 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <4664AF9F.1050608@verizon.net> References: <46639749.5010409@verizon.net> <200706040924.03868.jkeating@redhat.com> <466413FE.4090801@verizon.net> <200706040941.02738.jkeating@redhat.com> <46641ABB.3070004@verizon.net> <20070604145239.GD24880@devserv.devel.redhat.com> <46642C7D.3070107@verizon.net> <4664AF9F.1050608@verizon.net> Message-ID: <20070605090718.GB3570@devserv.devel.redhat.com> On Mon, Jun 04, 2007 at 08:34:39PM -0400, Gerry Reno wrote: > QEMU hardware profile: > The QEMU PC System emulator simulates the following peripherals: > > * i440FX host PCI bridge and PIIX3 PCI to ISA bridge The qemu emulation was not good enough for libata last time I looked into this From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jun 5 09:43:24 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 5 Jun 2007 11:43:24 +0200 Subject: "core" In-Reply-To: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> References: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> Message-ID: <20070605114324.744c8759@python3.es.egwn.lan> Florian La Roche wrote : > I just saw that some apache dir listings show a small > bomb if a directory is named "core". For the next > rename of directories we might want to move "core" > again to something else then. This should be fixed with the core+extras merge. :-D Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.48 0.54 0.65 From neugens at limasoftware.net Tue Jun 5 10:14:12 2007 From: neugens at limasoftware.net (Mario Torre) Date: Tue, 05 Jun 2007 12:14:12 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> Message-ID: <1181038452.3174.6.camel@nirvana.limasoftware.net> Il giorno lun, 04/06/2007 alle 16.06 +0200, Nicolas Mailhot ha scritto: > If you want to be part of the default desktop install you have to > implement the default desktop expectations & rules. Emacs and Vi should be in for one reason. If it was not for them, none of the nice things you love from a modern Linux distribution were possible... They are system tools, not desktop gadgets, IMNSHO, of course. Moreover, if I'm not wrong, Emacs is no the default even when you choose the "developer" options, this is weird for me. Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From nicolas.mailhot at laposte.net Tue Jun 5 10:20:50 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Jun 2007 12:20:50 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <1181038452.3174.6.camel@nirvana.limasoftware.net> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <18019.63328.207759.405055@zebedee.pink> <5567.192.54.193.51.1180958360.squirrel@rousalka.dyndns.org> <18020.458.214966.294886@zebedee.pink> <16579.192.54.193.51.1180966005.squirrel@rousalka.dyndns.org> <1181038452.3174.6.camel@nirvana.limasoftware.net> Message-ID: <39556.192.54.193.51.1181038850.squirrel@rousalka.dyndns.org> Le Mar 5 juin 2007 12:14, Mario Torre a ?crit : > Il giorno lun, 04/06/2007 alle 16.06 +0200, Nicolas Mailhot ha > scritto: > >> If you want to be part of the default desktop install you have to >> implement the default desktop expectations & rules. > > Emacs and Vi should be in for one reason. If it was not for them, none > of the nice things you love from a modern Linux distribution were > possible... Loads of stuff in that category we don't install by default either. -- Nicolas Mailhot From buildsys at redhat.com Tue Jun 5 10:23:08 2007 From: buildsys at redhat.com (Build System) Date: Tue, 5 Jun 2007 06:23:08 -0400 Subject: rawhide report: 20070605 changes Message-ID: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> New package bottlerocket Utilities to use the FireCracker X10 kit New package ftplib Library of FTP routines New package hippo-canvas A canvas widget New package perl-GD-Barcode Create barcode image with GD Updated Packages: apr-1.2.8-7 ----------- * Mon Jun 04 2007 Joe Orton 1.2.8-7 - drop %check section entirely; inappropriate to run in build env. * Fri Mar 30 2007 Joe Orton 1.2.8-6 - merge review (#225253): drop .a archive; drop use of CC/CXX, use BuildRequires; drop old Conflicts; URL reference for Source * Thu Mar 22 2007 Joe Orton 1.2.8-5 - drop the doxygen documentation (which causes multilib conflicts) atk-1.19.3-1.fc8 ---------------- * Mon Jun 04 2007 Matthias Clasen - 1.19.3-1 - Update to 1.19.3 atlas-3.6.0-12.fc8 ------------------ * Mon Jun 04 2007 Orion Poplawski 3.6.0-12 - Rebuild for ppc64 bigboard-0.4.2-1 ---------------- * Mon Jun 04 2007 Colin Walters - 0.4.2-1 - update * Fri Jun 01 2007 Colin Walters - 0.4.1-1 - update bind-31:9.4.1-5.fc8 ------------------- * Mon Jun 04 2007 Adam Tkac 31:9.4.1-5.fc8 - very minor compatibility change in bind-chroot-admin (line 215) - enabled IDN support by default and don't distribute IDN libraries - specfile cleanup - add dynamic directory to /var/named. This directory will be primarily used for dynamic DNS zones. ENABLE_ZONE_WRITE and SELinux's named_write_master_zones no longer exist checkpolicy-2.0.3-1.fc8 ----------------------- * Thu Apr 12 2007 Dan Walsh - 2.0.3-1 - Latest update from NSA * Merged fix for segfault on duplicate require of sensitivity from Caleb Case. * Merged fix for dead URLs in checkpolicy man pages from Dan Walsh. clearsilver-0.10.4-5.fc8 ------------------------ * Mon Jun 04 2007 Jeffrey C. Ollie - 0.10.4-5 - Add BR perl-devel for fedora > 6 cryptsetup-luks-1.0.3-5.fc8 --------------------------- * Mon Jun 04 2007 Peter Jones - 1.0.3-5 - Don't build static any more. devhelp-0.14-3.fc8 ------------------ * Mon Jun 04 2007 - Bastien Nocera - 0.14-3 - Rebuild against new libwnck echo-icon-theme-0.2-4.20070427wiki.fc8 -------------------------------------- * Mon Jun 04 2007 Luya Tshimbalanga - 0.2.4.20070427wiki - New snapshot eel2-2.19.3-1.fc8 ----------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 em8300-kmod-0.16.2-7.2.6.21_1.3194.fc7 -------------------------------------- * Sun Jun 03 2007 Ville Skytt?? - 0.16.2-7 - Disable PAE-debug for now (#227533). * Thu May 24 2007 Ville Skytt?? - Rebuild for kernel 2.6.21-1.3194.fc7. * Wed May 23 2007 Ville Skytt?? - Rebuild for kernel 2.6.21-1.3190.fc7. emacspeak-26-2.fc8 ------------------ * Mon Jun 04 2007 Jens Petersen - 26-2 - update emacspeak-tcl-pkgreq-tclx.patch for espeak script eog-2.19.3-1.fc8 ---------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 evolution-data-server-1.11.3-1.fc8 ---------------------------------- * Mon Jun 04 2007 Matthew Barnes - 1.11.3-1.fc8 - Update to 1.11.3 - Remove patch for GNOME bug #415922 (fixed upstream). * Thu May 31 2007 Matthew Barnes - 1.11.2-3.fc8 - Revise patch for GNOME bug #376991 to fix RH bug #241974. * Mon May 21 2007 Matthew Barnes - 1.11.2-2.fc8 - Store account passwords in GNOME Keyring. file-roller-2.19.2-1.fc8 ------------------------ * Mon Jun 04 2007 Matthias Clasen - 2.19.2-1 - Update to 2.19.2 gail-1.19.3-1.fc8 ----------------- * Mon Jun 04 2007 Matthias Clasen - 1.19.3-1 - Update to 1.19.3 gcalctool-5.19.3-1.fc8 ---------------------- * Mon Jun 04 2007 Matthias Clasen - 5.19.3-1 - Update to 5.19.3 glib2-2.13.3-1.fc8 ------------------ * Mon Jun 04 2007 Matthias Clasen - 2.13.3-1 - Update to 2.13.3 gnome-desktop-2.19.3.1-1.fc8 ---------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3.1-1 - Update to 2.19.3.1 * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 gnome-games-extra-data-2.19.1-1 ------------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.1-1 - Update to 2.19.1 gnome-mag-0.14.5-1.fc8 ---------------------- * Mon Jun 04 2007 Matthias Clasen - 0.14.5-1 - Update to 0.14.5 gnome-menus-2.19.3-1.fc8 ------------------------ * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 gnome-panel-2.19.3-2.fc8 ------------------------ * Mon Jun 04 2007 Matthias Clasen - 2.19.3-2 - Rebuild against new libwnck * Mon Jun 04 2007 - Bastien Nocera - 2.19.3-1 - Update to 2.19.3 gnome-session-2.19.3-1.fc8 -------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 - Drop upstreamed patch gnome-speech-0.4.13-1.fc8 ------------------------- * Mon Jun 04 2007 Matthias Clasen - 0.4.13 - Update to 0.4.13 gnome-system-monitor-2.19.3-1.fc8 --------------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 gnome-themes-2.19.3-1.fc8 ------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 gok-1.2.2-3.fc8 --------------- * Mon Jun 04 2007 Matthias Clasen - 1.2.2-3 - Rebuild against new libwnck * Sat Apr 21 2007 Matthias Clasen - 1.2.2-2 - Move api docs to -devel - Some file list cleanups gtk2-2.11.1-1.fc8 ----------------- * Mon Jun 04 2007 Matthias Clasen - 1.11.1-1 - Update to 2.11.1 - Update patches gtk2-engines-2.11.1-1.fc8 ------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.11.1-1 - Update to 2.11.1 gtkhtml3-3.15.3-1.fc8 --------------------- * Mon Jun 04 2007 Matthew Barnes - 3.15.3-1.fc8 - Update to 3.15.3 * Fri May 18 2007 Matthew Barnes - 3.15.2-1.fc8 - Update to 3.15.2 * Mon Apr 09 2007 Matthew Barnes - 3.14.1-1.fc7 - Update to 3.14.1 - Add -Wdeclaration-after-statement to strict build settings. gzip-1.3.12-1.fc8 ----------------- * Mon Jun 04 2007 Ivana Varekova - 1.3.12-1 - update to 1.3.12 kernel-2.6.21-1.3206.fc8 ------------------------ * Mon Jun 04 2007 Dave Jones - Allow kdump to read /proc/kcore. (#241362) * Mon Jun 04 2007 Dave Jones - 2.6.22-rc3-git7 * Mon Jun 04 2007 Dave Jones - Remove some warning switches. koffice-1.6.3-1.fc8 ------------------- * Fri Jun 01 2007 Rex Dieter 1.6.3-1 - koffice-1.6.3 less-394-10.fc8 --------------- * Mon Jun 04 2007 Ivana Vraekova - 394-10 - Resolves: #242077 remove "-" option from lesspipe.sh script libgtop2-2.19.3-1.fc8 --------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 libnotify-0.4.4-4.fc8 --------------------- * Mon Jun 04 2007 Matthias Clasen - 0.4.4-4 - Re-add notification-daemon requirement * Mon Jun 04 2007 Matthias Clasen - 0.4.4-3 - Temporarily remove the notification-daemon requires for bootstrapping liboil-0.3.12-3.fc8 ------------------- * Mon Jun 04 2007 - Bastien Nocera - 0.3.12-3 - Add patch from David Woodhouse to allow building on ppc64 systems (#242418) * Mon Jun 04 2007 Christopher Aillon - 0.3.12-2 - ExcludeArch: ppc64 for now as it fails to build (#242418) * Mon Jun 04 2007 Christopher Aillon - 0.3.12-1 - Update to 0.3.12 libpqxx-2.6.8-5.fc7 ------------------- * Wed Dec 06 2006 Rex Dieter 2.6.8-5 - re-enable visibility patch (bummer, still needed) * Wed Dec 06 2006 Rex Dieter 2.6.8-4 - respin for postgresql - drop visibility patch * Wed Oct 04 2006 Rex Dieter 2.6.8-3 - respin libwnck-2.19.3-2.fc8 -------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.3-2 - Require startup-notification-devel in the -devel package * Mon Jun 04 2007 - Bastien Nocera - 2.19.3-1 - Update to 2.19.3 - Update viewport patch liferea-1.2.16-1.fc8 -------------------- * Mon Jun 04 2007 Brian Pepple - 1.2.16-1 - Update to 1.2.16. logwatch-7.3.6-2.fc8 -------------------- * Mon Jun 04 2007 Ivana Varekova 7.3.6-2 - fix secure script - Resolves: #242201 fix named service man-pages-2.51-3.fc8 -------------------- * Mon Jun 04 2007 Stepan Kasal - 2.51-3 - Add man-pages-2.51-nscd-conf.patch, fixes #204596 - Fix typos, man-pages-2.51-typos.patch * Thu May 31 2007 Ivana Varekova 2.51-2 - remove mount page patch - fix mmap patch * Wed May 30 2007 Ivana Varekova 2.51-1 - update to 2.51 metacity-2.19.8-1.fc8 --------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.8-1 - Update to 2.19.8 nemiver-0.4.0-1.fc8 ------------------- * Sun Jun 03 2007 Peter Gordon - 0.4.0-1 - Update to new upstream release (0.4.0) netcdf-perl-1.2.3-4.fc8 ----------------------- * Mon Jun 04 2007 - Orion Poplawski - 1.2.3-4 - Change perl BR to perl-devel notification-daemon-0.3.7-3.fc8 ------------------------------- * Mon Jun 04 2007 - Bastien Nocera - 0.3.7-3 - Rebuild with new libwnck openbox-3.3.1-7.fc8 ------------------- * Mon Jun 04 2007 Peter Gordon - 3.3.1-7 - Own %{_datadir}/gnome/wm-properties instead of depending on gnome-session in order to reduce dependency bloat. (Resolves bug 242339; thanks to Miroslav Lichvar for the bug report.) openhpi-2.8.1-2.fc8 ------------------- * Mon Jun 04 2007 Phil Knirsch - 2.8.1-2.fc7 - Fixed missing e2fsprogs-devel and openssl-devel build requires pam-0.99.7.1-6.fc8 ------------------ * Thu Apr 26 2007 Tomas Mraz 0.99.7.1-6 - pam_namespace: better document behavior on failure (#237249) - pam_unix: split out passwd change to a new helper binary (#236316) - pam_namespace: add support for temporary logons (#241226) * Fri Apr 13 2007 Tomas Mraz 0.99.7.1-5 - pam_selinux: improve context change auditing (#234781) - pam_namespace: fix parsing config file with unknown users (#234513) * Fri Mar 23 2007 Tomas Mraz 0.99.7.1-4 - pam_console: always decrement use count (#230823) - pam_namespace: use raw context for poly dir name (#227345) - pam_namespace: truncate long poly dir name (append hash) (#230120) - we don't patch any po files anymore pango-1.17.2-1.fc8 ------------------ * Mon Jun 04 2007 Matthias Clasen - 1.17.2-1 - Update to 1.17.2 perl-Archive-Tar-1.32-1.fc8 --------------------------- * Mon Jun 04 2007 Robin Norwood - 1.32-1 - Upgrade to latest upstream version: 1.32 perl-Carp-Clan-5.9-1.fc8 ------------------------ * Mon Jun 04 2007 Robin Norwood - 5.9-1 - Update to latest CPAN version: 5.9 - Upstream Makefile.PL prompts for user input to include Object::Deadly as a prerequisite. We don't ship Object::Deadly, so just comment out the prompt. perl-File-RsyncP-0.68-1.fc8 --------------------------- * Mon Jun 04 2007 Mike McGrath - 0.68-1 - Upstream released new version policycoreutils-2.0.19-4.fc8 ---------------------------- * Mon Jun 04 2007 Dan Walsh 2.0.19-4 - Fix setfiles -c to make it work * Mon Jun 04 2007 Dan Walsh 2.0.19-3 - Fix french translation to not crash system-config-selinux pykickstart-1.2-1.fc8 --------------------- * Mon Jun 04 2007 Chris Lumens - 1.2-1 - Fix harddrive install method error checking (#232492). - Set authentication information from the input line to preserve quoting (#241657). - Allow included files to be given by URL. - Fix typo in user --iscrypted option. python-crypto-2.0.1-8 --------------------- * Mon Jun 04 2007 David Woodhouse - 2.0.1-8 - Fix libdir handling so it works on more arches than x86_64 python-telepathy-0.13.12-1.fc8 ------------------------------ * Mon Jun 04 2007 Brian Pepple - 0.13.12-1 - Update to 0.13.12. revelation-0.4.11-3.fc8 ----------------------- * Mon Jun 04 2007 Thorsten Leemhuis 0.4.11-3 - Rebuild to build for ppc64 as well rhpl-0.208-2 ------------ * Mon Jun 04 2007 Jeremy Katz - 0.208-2 - rebuild for new wireless-tools * Thu May 24 2007 Jeremy Katz - 0.208-1 - revert some of the unicode changes so that we're more sane (#241246, #241077) - Fix Bulgarian phonetic keyboard layout (clumens) * Mon May 21 2007 Jeremy Katz - 0.207-1 - Fix so that stdout/stderr have a reasonable encoding (#240787) scim-1.4.6-4.fc8 ---------------- * Tue Jun 05 2007 Jens Petersen - 1.4.6-4 - drop scim_panel_gtk-settle-toolbar-after-drag.patch since it interferes with user toolbar placement (reported by Ryo Dairiki) * Wed May 30 2007 Jens Petersen - 1.4.6-3 - save the hotkey for lang in initial-locale-hotkey-186861.patch again * Tue May 29 2007 Jens Petersen - 1.4.6-2 - fix initial-locale-hotkey-186861.patch to read system hotkey config correctly (reported by Eugene Teo, #241629) scim-bridge-0.4.12-2.fc8 ------------------------ * Mon Jun 04 2007 Jens Petersen - update scim requires and buildrequires to 1.4.6 scribes-0.3.2.6-1.fc8 --------------------- * Sun Jun 03 2007 Peter Gordon - 0.3.2.6-1 - Update to new upstream release (0.3.2.6). scribes-templates-20070602-1.fc8 -------------------------------- * Mon Jun 04 2007 Peter Gordon - 20070602-1 - Update to new upstream templates tarball (2007-06-02), including updated templates for LaTeX, Perl, PHP, and VHDL. synaptic-0.57.2-7.fc8 --------------------- * Mon Jun 04 2007 Axel Thimm - 0.57.2-7 - Rebuild against the latest apt which encodes glibc's version in its library name. totem-2.19.4-2.fc8 ------------------ * Mon Jun 04 2007 - Bastien Nocera - 2.19.4-1 - Update to 2.19.4 vte-0.16.5-1.fc8 ---------------- * Mon Jun 04 2007 Behdad Esfahbod 0.16.5-1 - Update to 0.16.5 wpa_supplicant-1:0.5.7-3.fc7 ---------------------------- * Mon Jun 04 2007 Dan Williams - 0.5.7-3 - Fix buffer overflow by removing syslog patch (#rh242455) wxMaxima-0.7.2-2.fc8 -------------------- * Mon Jun 04 2007 Rex Dieter 0.7.2-2 - +ExcludeArch, deployable only where maxima exists xorg-x11-drv-nv-2.0.96-2.fc8 ---------------------------- * Mon Jun 04 2007 Adam Jackson 2.0.96-2 - Meaningless version bump. * Fri May 18 2007 Adam Jackson 2.0.96-1 - nv 2.0.96. Add rudimentary dual-head support for pre-G80 cards. xorg-x11-drv-vesa-1.3.0-8.fc8 ----------------------------- * Thu May 31 2007 Adam Jackson 1.3.0-8 - vesa-1.3.0-mode-heuristics.patch: Fix a typo that would crash on some cards. (#241491) * Wed May 09 2007 Adam Jackson 1.3.0-6 - Re-add the sync range hack. (#235066) * Tue Mar 20 2007 Adam Jackson 1.3.0-5 - vesa-1.3.0-mode-heuristics.patch: If strict intersection of VBE and EDID modes leaves no modes remaining after validation, try again with just range and VBE checks. Replaces earlier range-hack and validmode patches. xorg-x11-server-1.3.0.0-7.fc8 ----------------------------- * Mon Jun 04 2007 Adam Jackson 1.3.0.0-7 - xserver-1.3.0-randrama-no-zero-screens.patch: For RANDR 1.2's fake Xinerama info, don't report Xinerama as being active if there are no RANDR 1.2 CRTCs active for that screen. (#234567) - xserver-1.3.0-arm-iopl.patch: Add __arm__ conditionals to many #ifdefs. yumex-1.9.8-2.0.fc8 ------------------- * Mon Jun 04 2007 Tim Lauridsen - 1.9.8-2.0 - Development Release 1.9.8-2.0 - Forgot to update changelog * Mon Jun 04 2007 Tim Lauridsen - 1.9.8-1.0 - Development Release 1.9.8-1.0 From jkeating at redhat.com Tue Jun 5 10:42:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:42:40 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <20070605090718.GB3570@devserv.devel.redhat.com> References: <46639749.5010409@verizon.net> <4664AF9F.1050608@verizon.net> <20070605090718.GB3570@devserv.devel.redhat.com> Message-ID: <200706050642.40487.jkeating@redhat.com> On Tuesday 05 June 2007 05:07:18 Alan Cox wrote: > The qemu emulation was not good enough for libata last time I looked into > this I've done many successful installs in KVM/Qemu for Fedora 7 testing. Is KVM/qemu different in the hardware it provides to the system than pure qemu? Or maybe it's just that the kvm/qemu in 7 is new enough that it /does/ work with libata? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 10:44:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:44:30 -0400 Subject: Why isn't emacs installed by default In-Reply-To: References: Message-ID: <200706050644.30574.jkeating@redhat.com> On Sunday 03 June 2007 14:21:50 Shams wrote: > I was just wondering is there any reason that emacs is not selected and > installed by default ie. with just the default install options in > Anaconda.. Simple. If you know you want emacs, you can install it by checking the box, or installing it after with yum. Users who don't know about it are not likely to understand what 'emacs' is and run it. At least that's my opinion. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From neugens at limasoftware.net Tue Jun 5 10:48:22 2007 From: neugens at limasoftware.net (Mario Torre) Date: Tue, 05 Jun 2007 12:48:22 +0200 Subject: Why isn't emacs installed by default In-Reply-To: <52887.192.54.193.51.1180967050.squirrel@rousalka.dyndns.org> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <23308.192.54.193.51.1180964747.squirrel@rousalka.dyndns.org> <20070604135340.GB60513@dspnet.fr.eu.org> <52887.192.54.193.51.1180967050.squirrel@rousalka.dyndns.org> Message-ID: <1181040502.3174.11.camel@nirvana.limasoftware.net> Il giorno lun, 04/06/2007 alle 16.24 +0200, Nicolas Mailhot ha scritto: > > Of course a custom text widget. The rendering capability of *emacs is > > similar to that of a typesetting word processor or a web browser. Or > > do you mean you're going to require Firefox and OpenOffice to use the > > gtk text widget too for their main display? > > Those apps take care of the deps needed by their main text widget. And > their text widget integrates cleanly with the rest of the desktop. I don't really agree they always do, for example, see how Firefox renders its widgets. Scroll bars never match the desktop theme, menu don't even wobble when Compiz is enable, and the form widgets... well, they simply are aliens... Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From jkeating at redhat.com Tue Jun 5 10:47:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:47:30 -0400 Subject: rawhide report: 20070604 changes In-Reply-To: <1181029582.3566.1.camel@jndwidescreen.lesbg.loc> References: <200706040845.l548jEmw031674@porkchop.devel.redhat.com> <200706041153.48272.jkeating@redhat.com> <1181029582.3566.1.camel@jndwidescreen.lesbg.loc> Message-ID: <200706050647.30191.jkeating@redhat.com> On Tuesday 05 June 2007 03:46:22 Jonathan Dieter wrote: > On Mon, 2007-06-04 at 11:53 -0400, Jesse Keating wrote: > > Hrm, I didn't realize there were older builds and thus approved the > > request to just block yum-presto. > > And this is probably my fault as I'm still new to package maintenance > and wasn't sure what the proper steps were to fix the failed dependency > problem. > > Next time (which there hopefully won't be), I'll ask for the new version > with broken dependencies to be pulled and the old version to be left. > > Jonathan No worries, we don't exactly make it clear (: I'm hoping to flesh out some Wiki docs on what you can ask releng to do and what the consequences are. FWIW I've unblocked the package, and untagged the latest build so that now rawhide will pick up yum-presto-0.3.9-1.fc7 which should mesh with deltarpm-3.4-1.fc7 that is also in rawhide. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 10:50:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:50:17 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: Message-ID: <200706050650.17730.jkeating@redhat.com> On Monday 04 June 2007 23:50:11 Tony Nelson wrote: > The DVD's comps.xml does not include all the packages on the DVD. ?19 are > omitted, including anaconda-runtime, which causes buildinstall to fail (?). > In any event, at "Building images...", upd-instroot, mk-images, and > makestamp.py were missing, and later ".discinfo doesn't exist in the > unified tree, not splitting". ?Should those 19 packages have been in > comps.xml? ?Is there some way to add them to the process without writing a > comps.xml? If you're using pungi on Fedora 7 comps is not used to determine what packages get onto the media. The manifest file does. In the case of Fedora 7 there is an /etc/pungi/f7-fedora.manifest file shipped, as well as an /etc/pungi/f7-fedora.i386/x86_64/ppc file that can be slightly modified to make CD isos. Just uncomment and lower the cdsize variable and increase the discs variable. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Tue Jun 5 10:55:25 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 05 Jun 2007 12:55:25 +0200 Subject: revisor in f7 In-Reply-To: <57127b5f0705290416h235ca290y5a0178c56bfcb3eb@mail.gmail.com> References: <57127b5f0705280903o546c2221me1fc0f67814c4759@mail.gmail.com> <604aa7910705281026o19168832q9fcf9a3ecb143a75@mail.gmail.com> <57127b5f0705290416h235ca290y5a0178c56bfcb3eb@mail.gmail.com> Message-ID: <4665411D.7000902@kanarip.com> Deependra Shekhawat wrote: > There are no builds in koji for revisor. > There have been builds in koji for revisor now, and it is in the repositories. Kind regards, Jeroen van Meeuwen -kanarip From jeevanullas at gmail.com Tue Jun 5 11:07:36 2007 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Tue, 05 Jun 2007 16:37:36 +0530 Subject: revisor in f7 In-Reply-To: <4665411D.7000902@kanarip.com> References: <57127b5f0705280903o546c2221me1fc0f67814c4759@mail.gmail.com> <604aa7910705281026o19168832q9fcf9a3ecb143a75@mail.gmail.com> <57127b5f0705290416h235ca290y5a0178c56bfcb3eb@mail.gmail.com> <4665411D.7000902@kanarip.com> Message-ID: <1181041656.3216.0.camel@localhost.localdomain> On Tue, 2007-06-05 at 12:55 +0200, Jeroen van Meeuwen wrote: > Deependra Shekhawat wrote: > > There are no builds in koji for revisor. > > > > There have been builds in koji for revisor now, and it is in the > repositories. > Yes I am using it. Really great tool. I am experimenting on getting a minimal live image on usb with some window manager. Maybe below 256MB but I think it's not possible. Let's see. Thanks once again. > Kind regards, > > Jeroen van Meeuwen > -kanarip > From ajackson at redhat.com Tue Jun 5 11:23:35 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 05 Jun 2007 07:23:35 -0400 Subject: "core" In-Reply-To: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> References: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> Message-ID: <1181042615.8453.81.camel@localhost.localdomain> On Tue, 2007-06-05 at 09:49 +0200, Florian La Roche wrote: > Hello alll, > > I just saw that some apache dir listings show a small > bomb if a directory is named "core". For the next > rename of directories we might want to move "core" > again to something else then. Apache has done this by default since approximately 1994. - ajax From alan at redhat.com Tue Jun 5 11:27:16 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 5 Jun 2007 07:27:16 -0400 Subject: F7 install CDROM unrecognized In-Reply-To: <200706050642.40487.jkeating@redhat.com> References: <46639749.5010409@verizon.net> <4664AF9F.1050608@verizon.net> <20070605090718.GB3570@devserv.devel.redhat.com> <200706050642.40487.jkeating@redhat.com> Message-ID: <20070605112716.GA10432@devserv.devel.redhat.com> On Tue, Jun 05, 2007 at 06:42:40AM -0400, Jesse Keating wrote: > I've done many successful installs in KVM/Qemu for Fedora 7 testing. Is > KVM/qemu different in the hardware it provides to the system than pure qemu? > Or maybe it's just that the kvm/qemu in 7 is new enough that it /does/ work > with libata? No idea. Everyone seems to have their own forks of qemu, Xen especially. Most qemu forks get ATA pretty much right but have real trouble handling ATAPI especially ATAPI DMA. This causes us to see HSM errors and log the fact the drive has gone bananas From markmc at redhat.com Tue Jun 5 11:32:52 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 05 Jun 2007 12:32:52 +0100 Subject: Xen failure in mock-x86_64 [was Re: Release x86_64 rawhide rebuild in mock status 2007-06-03] In-Reply-To: <20070603152937.A17627@humbolt.us.dell.com> References: <20070603152937.A17627@humbolt.us.dell.com> Message-ID: <1181043173.8055.29.camel@blaa> Hey, On Sun, 2007-06-03 at 15:29 -0500, Matt Domsch wrote: > Release Rawhide-in-Mock Build Results for x86_64 Sun Jun 3 09:09:00 CDT 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > xen-3.1.0-0.rc7.1.fc7 (buildroot) riel at redhat.com This build failure is because of: "No Package Found for /usr/include/gnu/stubs-32.h" which in turn is caused by the "*-devel.i?86" exclude in yum's mock config. Xen requires glibc-devel.i386 even on x86_84 because it needs to build the 32 bit BIOS firmware for HVM. Suggestions welcome, I've filed a bug here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242661 Thanks, Mark. From vnpenguin at vnoss.org Tue Jun 5 11:48:30 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Tue, 5 Jun 2007 13:48:30 +0200 Subject: CDs from DVD with Pungi almost works In-Reply-To: <200706050650.17730.jkeating@redhat.com> References: <200706050650.17730.jkeating@redhat.com> Message-ID: A small question about pungi: Why used space in Volume name when build iso file ? Something like "%s-%s-%s-DVD" is not better ? Thanks, -- http://vnoss.org From jkeating at redhat.com Tue Jun 5 12:11:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 08:11:39 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <200706050650.17730.jkeating@redhat.com> Message-ID: <200706050811.42294.jkeating@redhat.com> On Tuesday 05 June 2007 07:48:30 Vnpenguin wrote: > A small question about pungi: Why used space in Volume name when build > iso file ? > Something like "%s-%s-%s-DVD" is not better ? Why does space matter? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mlichvar at redhat.com Tue Jun 5 12:26:19 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 5 Jun 2007 14:26:19 +0200 Subject: Orphans: openbox, obconf, obmenu In-Reply-To: <1180819457.27569.16.camel@tuxhugs> References: <1180819457.27569.16.camel@tuxhugs> Message-ID: <20070605122619.GB5002@localhost> On Sat, Jun 02, 2007 at 02:24:17PM -0700, Peter Gordon wrote: > With the 3.4 Preview releases of Openbox as well as related obconf and > obmenu releases, I'm officially putting these three packages into Orphan > status. I'm a long time openbox user and I'm willing to take the packages. -- Miroslav Lichvar From ajackson at redhat.com Tue Jun 5 12:24:22 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 05 Jun 2007 08:24:22 -0400 Subject: koji weirdness In-Reply-To: <1180965403.8453.14.camel@localhost.localdomain> References: <465A8F08.90708@hhs.nl> <200705280941.51943.jkeating@redhat.com> <465BDE48.9010606@hhs.nl> <200705290633.56160.jkeating@redhat.com> <1180639944.21359.14.camel@burren.boston.redhat.com> <1180965403.8453.14.camel@localhost.localdomain> Message-ID: <1181046262.8453.89.camel@localhost.localdomain> On Mon, 2007-06-04 at 09:56 -0400, Adam Jackson wrote: > This appears to stick a : between every target in the CHAIN, which means > the build system will stall between every one. Would it be possible to > get like a 'make expert-chain' that lets you specify the stall points > explicitly? In fact, rather than just ask for it, here's a patch that does what I want. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: chain-build-expert.patch Type: text/x-patch Size: 1450 bytes Desc: not available URL: From rc040203 at freenet.de Tue Jun 5 12:39:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jun 2007 14:39:15 +0200 Subject: fedora for ARM In-Reply-To: <4663FAEB.8070807@hhs.nl> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> Message-ID: <1181047155.27239.100.camel@mccallum.corsepiu.local> On Mon, 2007-06-04 at 13:43 +0200, Hans de Goede wrote: > Linus Walleij wrote: > > > > 2. As I understand it you employ the Fedora/x86 style of not using a > > cross-compiler to build these packages, but rather build them with ARM > > on ARM. I am aware of some RPM derivatives like those used by > > MontaVista, that employ a cross-compiler instead. What are your thought > > on these issues? Have you tested both solutions and come to the > > conclusion that the all-ARM-enclosed build system is the way to go? > > > > In my somewhat limited experience cross-compiling of software which is not > designed for that from day one is a big pain, let alone cross-compiling an > entire distro! Is there an existing, binary distributed target-distro? If yes, then using a sys-rooted cross-compiler in combination with prebuilt binaries is a fairly simple escape. This quite helpful when only wanting to occasionally build a couple of packages (or when not having permanent access to the target systems), while another sources supply most target binaries. I for one apply this for building target binaries for target OSes I don't use myself. > There are indeed some hacks around rpm to make the packahes > think they are being build nativly, but what I've seen these are very gross > hacks and still break often. Well, RH's rpm and redhat-rpm-config are grossly broken when it comes to cross-building rpms. Many things work once you kick redhat-rpm-config out :( > Native compiling definitively is the way to go, This is only applicable for sufficiently performing targets. Esp. for low end targets this is close to impossible. > an alternative might be > emulating the native system and building in the emulated system. With a few exceptions, in practice, this is rarely applicable, esp. when it comes to "less mainstream" targets. Ralf From jeevanullas at gmail.com Tue Jun 5 12:43:17 2007 From: jeevanullas at gmail.com (Deependra Shekhawat) Date: Tue, 5 Jun 2007 18:13:17 +0530 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1179677432.2633.4.camel@localhost.localdomain> References: <1179326006.14246.44.camel@localhost.localdomain> <57127b5f0705200025r79fc31e7uf8dc4fd5326cb4b2@mail.gmail.com> <1179671307.2583.0.camel@localhost.localdomain> <57127b5f0705200842j67ca4971mb039399973e043c9@mail.gmail.com> <1179677432.2633.4.camel@localhost.localdomain> Message-ID: <57127b5f0706050543j36d0bde2g6dd270266e889e24@mail.gmail.com> On 5/20/07, Richard Hughes wrote: > > On Sun, 2007-05-20 at 21:12 +0530, Deependra Shekhawat wrote: > > Hi, > > > > This laptop model is not mentioned in the fdi i saw for lenovo. only R > > series and Tseries thinkpad are there. Don't you think support for the > > lenovo 3000{N,Y,} series laptop is needed? Yes, please read the rest of the website and submit an entry if you can > get suspend to work. Warning, I have a Lenovo 3000 N100, and it is > currently unsuspendable, which I'm currently debugging. I think it needs > some sort of northbridge quirk in the kernel, but I have to trace how > Windows XP makes it work. See my blog for details. Hi, Is there any update on this for fedora7 final. Is suspend/hibernate working now. Richard. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Enjoy Life ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at fedoraproject.org Tue Jun 5 12:43:11 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 05 Jun 2007 12:43:11 -0000 Subject: Summary - Broken dependencies in Fedora development - 2007-06-05 Message-ID: <20070605124311.9770.99831@extras64.linux.duke.edu> New report for: fedora AT deadbabylon.de package: devilspie - 0.20.2-1.fc7.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: devilspie - 0.20.2-1.fc7.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: devilspie - 0.20.2-1.fc7.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.18()(64bit) package: devilspie - 0.20.2-1.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) ====================================================================== New report for: rstrode AT redhat.com package: gnome-applets - 1:2.18.0-8.fc8.i386 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18 package: gnome-applets - 1:2.18.0-8.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: gnome-applets - 1:2.18.0-8.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: gnome-applets - 1:2.18.0-8.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.18()(64bit) package: gnome-applets - 1:2.18.0-8.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) ====================================================================== New report for: krh AT redhat.com package: compiz - 0.3.6-8.fc7.i386 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18 package: compiz - 0.3.6-8.fc7.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: compiz - 0.3.6-8.fc7.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: compiz - 0.3.6-8.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) ====================================================================== New report for: mbarnes AT redhat.com package: gnome-python2-libwnck - 2.18.0-2.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: gnome-python2-libwnck - 2.18.0-2.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: gnome-python2-libwnck - 2.18.0-2.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.18()(64bit) package: gnome-python2-libwnck - 2.18.0-2.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) ====================================================================== New report for: jwilson AT redhat.com package: bdock - 0.2.0-1.fc7.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: bdock - 0.2.0-1.fc7.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: bdock - 0.2.0-1.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) package: emerald - 0.2.0-1.fc7.i386 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18 package: emerald - 0.2.0-1.fc7.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: emerald - 0.2.0-1.fc7.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: emerald - 0.2.0-1.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) package: heliodor - 0.2.0-1.fc7.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: heliodor - 0.2.0-1.fc7.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: heliodor - 0.2.0-1.fc7.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) ====================================================================== New report for: davidz AT redhat.com package: gnome-power-manager - 2.19.2-1.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.18 package: gnome-power-manager - 2.19.2-1.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.18 package: gnome-power-manager - 2.19.2-1.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.18()(64bit) package: gnome-power-manager - 2.19.2-1.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.18()(64bit) ====================================================================== Summary of broken packages (by owner): cbalint AT redhat.com gdal - 1.4.1-3.fc7.i386 (2 days) gdal - 1.4.1-3.fc7.i386 (2 days) gdal - 1.4.1-3.fc7.ppc (2 days) gdal - 1.4.1-3.fc7.ppc64 (2 days) gdal - 1.4.1-3.fc7.x86_64 (2 days) cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (2 days) davidz AT redhat.com gnome-power-manager - 2.19.2-1.fc8.i386 gnome-power-manager - 2.19.2-1.fc8.ppc gnome-power-manager - 2.19.2-1.fc8.ppc64 gnome-power-manager - 2.19.2-1.fc8.x86_64 dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (2 days) fedora AT deadbabylon.de devilspie - 0.20.2-1.fc7.i386 devilspie - 0.20.2-1.fc7.ppc devilspie - 0.20.2-1.fc7.ppc64 devilspie - 0.20.2-1.fc7.x86_64 gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (2 days) glest-data - 2.0.0-2.fc7.noarch (2 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 (2 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 (2 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (2 days) kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 (2 days) kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (2 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (2 days) jonathansteffan AT gmail.com revisor - 2.0.3.6-1.fc8.noarch (2 days) revisor - 2.0.3.6-1.fc8.noarch (2 days) jwilson AT redhat.com bdock - 0.2.0-1.fc7.i386 bdock - 0.2.0-1.fc7.ppc bdock - 0.2.0-1.fc7.x86_64 emerald - 0.2.0-1.fc7.i386 emerald - 0.2.0-1.fc7.i386 emerald - 0.2.0-1.fc7.ppc emerald - 0.2.0-1.fc7.x86_64 emerald-themes - 0.2.0-1.fc7.noarch (2 days) heliodor - 0.2.0-1.fc7.i386 heliodor - 0.2.0-1.fc7.ppc heliodor - 0.2.0-1.fc7.x86_64 karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (2 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (2 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (2 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (2 days) krh AT redhat.com compiz - 0.3.6-8.fc7.i386 compiz - 0.3.6-8.fc7.i386 compiz - 0.3.6-8.fc7.ppc compiz - 0.3.6-8.fc7.x86_64 kwizart AT gmail.com lcdproc - 0.5.2-1.fc8.i386 (2 days) lcdproc - 0.5.2-1.fc8.ppc (2 days) lcdproc - 0.5.2-1.fc8.ppc64 (2 days) lcdproc - 0.5.2-1.fc8.x86_64 (2 days) mbarnes AT redhat.com gnome-python2-libwnck - 2.18.0-2.fc8.i386 gnome-python2-libwnck - 2.18.0-2.fc8.ppc gnome-python2-libwnck - 2.18.0-2.fc8.ppc64 gnome-python2-libwnck - 2.18.0-2.fc8.x86_64 mdehaan AT redhat.com koan - 0.3.1-2.fc7.noarch (2 days) orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 (2 days) rstrode AT redhat.com gnome-applets - 1:2.18.0-8.fc8.i386 gnome-applets - 1:2.18.0-8.fc8.i386 gnome-applets - 1:2.18.0-8.fc8.ppc gnome-applets - 1:2.18.0-8.fc8.ppc64 gnome-applets - 1:2.18.0-8.fc8.x86_64 rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (2 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (2 days) tcallawa AT redhat.com xsupplicant - 1.2.8-1.fc7.1.i386 (2 days) xsupplicant - 1.2.8-1.fc7.1.ppc (2 days) xsupplicant - 1.2.8-1.fc7.1.x86_64 (2 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (2 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc ====================================================================== Broken packages in rawhide-development-i386: bdock-0.2.0-1.fc7.i386 requires libwnck-1.so.18 compiz-0.3.6-8.fc7.i386 requires libwnck-1.so.18 devilspie-0.20.2-1.fc7.i386 requires libwnck-1.so.18 emerald-0.2.0-1.fc7.i386 requires libwnck-1.so.18 gdal-1.4.1-3.fc7.i386 requires libdapserver.so.2 gnome-applets-1:2.18.0-8.fc8.i386 requires libwnck-1.so.18 gnome-power-manager-2.19.2-1.fc8.i386 requires libwnck-1.so.18 gnome-python2-libwnck-2.18.0-2.fc8.i386 requires libwnck-1.so.18 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 heliodor-0.2.0-1.fc7.i386 requires libwnck-1.so.18 kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE-0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug-0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc-0.5.2-1.fc8.i386 requires perl(Geo::METAR) xsupplicant-1.2.8-1.fc7.1.i386 requires libiw.so.28 ====================================================================== Broken packages in rawhide-development-ppc64: ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) devilspie-0.20.2-1.fc7.ppc64 requires libwnck-1.so.18()(64bit) emerald-themes-0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 emerald-themes-0.2.0-1.fc7.noarch requires beryl-core >= 0:0.2.0 gdal-1.4.1-3.fc7.ppc64 requires libdapserver.so.2()(64bit) geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-applets-1:2.18.0-8.fc8.ppc64 requires libwnck-1.so.18()(64bit) gnome-power-manager-2.19.2-1.fc8.ppc64 requires libwnck-1.so.18()(64bit) gnome-python2-libwnck-2.18.0-2.fc8.ppc64 requires libwnck-1.so.18()(64bit) kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump-0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan-0.3.1-2.fc7.noarch requires syslinux lcdproc-0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display revisor-2.0.3.6-1.fc8.noarch requires livecd-tools rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ====================================================================== Broken packages in rawhide-development-ppc: bdock-0.2.0-1.fc7.ppc requires libwnck-1.so.18 compiz-0.3.6-8.fc7.ppc requires libwnck-1.so.18 devilspie-0.20.2-1.fc7.ppc requires libwnck-1.so.18 emerald-0.2.0-1.fc7.ppc requires libwnck-1.so.18 gdal-1.4.1-3.fc7.ppc requires libdapserver.so.2 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-applets-1:2.18.0-8.fc8.ppc requires libwnck-1.so.18 gnome-power-manager-2.19.2-1.fc8.ppc requires libwnck-1.so.18 gnome-python2-libwnck-2.18.0-2.fc8.ppc requires libwnck-1.so.18 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 heliodor-0.2.0-1.fc7.ppc requires libwnck-1.so.18 kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp-0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc-0.5.2-1.fc8.ppc requires perl(Geo::METAR) revisor-2.0.3.6-1.fc8.noarch requires livecd-tools xsupplicant-1.2.8-1.fc7.1.ppc requires libiw.so.28 ====================================================================== Broken packages in rawhide-development-x86_64: bdock-0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) compiz-0.3.6-8.fc7.i386 requires libwnck-1.so.18 compiz-0.3.6-8.fc7.x86_64 requires libwnck-1.so.18()(64bit) devilspie-0.20.2-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) emerald-0.2.0-1.fc7.i386 requires libwnck-1.so.18 emerald-0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) gdal-1.4.1-3.fc7.i386 requires libdapserver.so.2 gdal-1.4.1-3.fc7.x86_64 requires libdapserver.so.2()(64bit) gnome-applets-1:2.18.0-8.fc8.i386 requires libwnck-1.so.18 gnome-applets-1:2.18.0-8.fc8.x86_64 requires libwnck-1.so.18()(64bit) gnome-power-manager-2.19.2-1.fc8.x86_64 requires libwnck-1.so.18()(64bit) gnome-python2-libwnck-2.18.0-2.fc8.x86_64 requires libwnck-1.so.18()(64bit) gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 heliodor-0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug-0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump-0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc-0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) xsupplicant-1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) From kanarip at kanarip.com Tue Jun 5 12:48:46 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 05 Jun 2007 14:48:46 +0200 Subject: [Fresh FC7 on x86_64] In-Reply-To: <7240929a0e6ece220e1e5b26588a9d80@afm-koeln.de> References: <7240929a0e6ece220e1e5b26588a9d80@afm-koeln.de> Message-ID: <46655BAE.3060600@kanarip.com> P. Martinez wrote: > Hello, > > i have done an fresh install on > a x86_64 system. After all i found > a lot of .i386 rpm installed. In my > case over 128 packages. > I also noticed that they interfere > with x86_64 packages (over written > manual's or bin's). I prefer a clean, > one arch installation. > After a de-installation of all .i386 > rpm's and successive reinstallation > some x86_64 packages. I can say/do > rpm -qaV with less response. > > I haven't follow the multilib > discussion but is this intentional? > > Thanks anyway for this > mature F(C) release. > > Paulo > I don't know about this all that much but could you maybe try and do an install with media created by Revisor? We have no multilib dependency resolving yet but we do set compatible archs. I'm curious as to whether we (Revisor) does anything wrong with not doing the multilib magic. Thank you in advance, Jeroen van Meeuwen -kanarip From hughsient at gmail.com Tue Jun 5 12:53:27 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 05 Jun 2007 13:53:27 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <57127b5f0706050543j36d0bde2g6dd270266e889e24@mail.gmail.com> References: <1179326006.14246.44.camel@localhost.localdomain> <57127b5f0705200025r79fc31e7uf8dc4fd5326cb4b2@mail.gmail.com> <1179671307.2583.0.camel@localhost.localdomain> <57127b5f0705200842j67ca4971mb039399973e043c9@mail.gmail.com> <1179677432.2633.4.camel@localhost.localdomain> <57127b5f0706050543j36d0bde2g6dd270266e889e24@mail.gmail.com> Message-ID: <1181048007.15192.13.camel@work> On Tue, 2007-06-05 at 18:13 +0530, Deependra Shekhawat wrote: > > Is there any update on this for fedora7 final. Is suspend/hibernate > working now. On Lenovo 3k hardware no, I've been very busy. I've been working hard on the multimedia keys stuff. Richard. From jsacco at gnome.org Tue Jun 5 13:03:12 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Tue, 05 Jun 2007 09:03:12 -0400 Subject: annoying syslog message from kernel In-Reply-To: References: <1180961190.2822.4.camel@rt.jesacco.com> Message-ID: <1181048592.8779.6.camel@rt.jesacco.com> You are correct... I also see the "Badness at kernel/softirq.c:138" message. Another thing... On occasion the system, Powermac with dual G4 processors, fails to boot because of a "spinlock" problem on CPU0. Hmmm... I wonder if these two events are related. -Joseph ========================================================================= On Tue, 2007-06-05 at 04:01 +0000, Peter Lemenkov wrote: > Joseph Sacco gnome.org> writes: > > > > > I started seeing these messages > > > > Message from syslogd at Mon Jun 4 04:40:20 2007 ... > > plantain kernel: ------------[ cut here ]------------ > > > > a while back. Not harmful, but annoying. > > It looks more harmful at closer look, actually. If you inspect your > /var/log/messages you'll see something like: > > ================================= > Jun 5 07:49:48 Sulaco kernel: ------------[ cut here ]------------ > Jun 5 07:49:48 Sulaco kernel: Badness at kernel/softirq.c:138 > Jun 5 07:49:48 Sulaco kernel: Call Trace: > Jun 5 07:49:48 Sulaco kernel: [DA18BBD0] [C0008AB0] show_stack+0x50/0x184 > (unreliable) > Jun 5 07:49:48 Sulaco kernel: [DA18BBF0] [C012072C] report_bug+0x84/0xc8 > Jun 5 07:49:48 Sulaco kernel: [DA18BC00] [C02B1A2C] > __kprobes_text_start+0x154/0x538 > Jun 5 07:49:48 Sulaco kernel: [DA18BC50] [C0013280] > ret_from_except_full+0x0/0x4c > Jun 5 07:49:48 Sulaco kernel: --- Exception: 700 at local_bh_enable+0x28/0x8c > Jun 5 07:49:48 Sulaco kernel: LR = cond_resched_softirq+0x58/0x80 > Jun 5 07:49:48 Sulaco kernel: [DA18BD10] [24002428] 0x24002428 (unreliable) > Jun 5 07:49:48 Sulaco kernel: [DA18BD20] [C02B0344] > cond_resched_softirq+0x58/0x80 > Jun 5 07:49:48 Sulaco kernel: [DA18BD30] [C0231D30] release_sock+0x54/0xac > Jun 5 07:49:48 Sulaco kernel: [DA18BD50] [C0269B20] tcp_sendmsg+0xac0/0xbf8 > Jun 5 07:49:48 Sulaco kernel: [DA18BDB0] [C028666C] inet_sendmsg+0x60/0x74 > Jun 5 07:49:48 Sulaco kernel: [DA18BDD0] [C022ED68] sock_aio_write+0x114/0x130 > Jun 5 07:49:48 Sulaco kernel: [DA18BE30] [C008FF38] do_sync_write+0xb8/0x10c > Jun 5 07:49:48 Sulaco kernel: [DA18BEF0] [C0090B10] vfs_write+0x104/0x1c8 > Jun 5 07:49:48 Sulaco kernel: [DA18BF10] [C00911AC] sys_write+0x4c/0x8c > Jun 5 07:49:48 Sulaco kernel: [DA18BF40] [C0012C24] ret_from_syscall+0x0/0x38 > Jun 5 07:49:48 Sulaco kernel: --- Exception: c01 at 0x1fabb098 > Jun 5 07:49:48 Sulaco kernel: LR = 0x2002b430 > Jun 5 07:50:13 Sulaco gconfd (petro-1954): GConf server is not in use, shutting > down. > Jun 5 07:50:13 Sulaco gconfd (petro-1954): Exiting > > ================================= > > I also encountered this nasty behavior. > -- joseph_sacco [at] comcast [dot] net -- jsacco [at] gnome [dot] org From davidz at redhat.com Tue Jun 5 13:08:34 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 05 Jun 2007 09:08:34 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <4664CFF9.90606@codewiz.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> Message-ID: <1181048914.21330.9.camel@dhcp83-66.boston.redhat.com> On Mon, 2007-06-04 at 22:52 -0400, Bernardo Innocenti wrote: > The contents of jffs2 and ext3 images should be identical > to simplify distribution. Wasn't a goal when I wrote the OLPC build system (it was, however, a goal to create four separate images aka streams (devel/non-devel msdos-partitioned-ext3-for-usb-sticks/jffs2). I appreciate that goals change however, I'm not active in the OLPC project anymore. > And by the way, the kernel depends on mkinitrd so we can't remove > it without breaking RPM deps. I was proposing to create an empty dummy RPM package with Provides: mkinitrd and also one symlink /sbin/mkinitrd -> /bin/true. If I were to do the OLPC build system all over again, I'd have one such RPM for dropping deps that way. Not super nice, but effective. > > Probably cryptsetup doesn't need to be linked statically anymore; Peter > > Jones would know. > > Good. But, why do we need *any* static binary in the first > place? Historical reasons, don't ask. > Also, I dismiss the argument that today's computers have > huge hard drives anyway so let's waste them. Bigger hard > drives are meant to hold more data, not the same amount of > data stored in inefficient formats. Take it easy, it's not like I'm disagreeing with you. > Some binaries we may wont to relink dynamically: > > - /sbin/e2fsck (dynamic on debian) > - /sbin/dmsetup.static (dynamic on debian) > - /sbin/insmod.static (dynamic on debian) > - /sbin/ldconfig (yes, even this one!) Yes, in 99.999% of all cases (that's five nines for you), it's absolutely unnecessary to have any static binaries at all in the default Fedora install. If you had read the archives of fedora-devel-list (which you Cc'ed yourself) you would have found - a huge discussion on "static linking considered harmful"; started by Ulrich Drepper. Some people have even more extreme points of of view than you. Here's a paper by Ulrich http://people.redhat.com/drepper/no_static_linking.html - that early user space in Fedora is increasingly moving to dynamic linking; that's a good thing; even better if people remember to kill statically linked binaries :-) David From buildsys at fedoraproject.org Tue Jun 5 13:11:33 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 05 Jun 2007 13:11:33 -0000 Subject: Summary - Broken dependencies in Fedora 7 - 2007-06-05 Message-ID: <20070605131133.12023.6863@extras64.linux.duke.edu> New report for: Axel.Thimm AT ATrpms.net package: synaptic - 0.57.2-7.fc7.i386 from fedora-updates-testing-7-i386 unresolved deps: libapt-pkg-libc6.5-6.so.2 package: synaptic - 0.57.2-7.fc7.ppc from fedora-updates-testing-7-ppc unresolved deps: libapt-pkg-libc6.5-6.so.2 package: synaptic - 0.57.2-7.fc7.ppc64 from fedora-updates-testing-7-ppc64 unresolved deps: libapt-pkg-libc6.5-6.so.2()(64bit) package: synaptic - 0.57.2-7.fc7.x86_64 from fedora-updates-testing-7-x86_64 unresolved deps: libapt-pkg-libc6.5-6.so.2()(64bit) ====================================================================== New report for: kwizart AT gmail.com package: lcdproc - 0.5.2-1.fc7.i386 from fedora-updates-testing-7-i386 unresolved deps: perl(Geo::METAR) package: lcdproc - 0.5.2-1.fc7.ppc from fedora-updates-testing-7-ppc unresolved deps: perl(Geo::METAR) package: lcdproc - 0.5.2-1.fc7.ppc64 from fedora-updates-testing-7-ppc64 unresolved deps: perl(Geo::METAR) package: lcdproc - 0.5.2-1.fc7.x86_64 from fedora-updates-testing-7-x86_64 unresolved deps: perl(Geo::METAR) ====================================================================== Summary of broken packages (by owner): Axel.Thimm AT ATrpms.net synaptic - 0.57.2-7.fc7.i386 synaptic - 0.57.2-7.fc7.ppc synaptic - 0.57.2-7.fc7.ppc64 synaptic - 0.57.2-7.fc7.x86_64 braden AT endoframe.com openvrml - 0.16.4-2.fc7.i386 (3 days) openvrml - 0.16.4-2.fc7.i386 (3 days) openvrml - 0.16.4-2.fc7.ppc (3 days) openvrml - 0.16.4-2.fc7.ppc64 (3 days) openvrml - 0.16.4-2.fc7.x86_64 (3 days) openvrml-devel - 0.16.4-2.fc7.i386 (3 days) openvrml-devel - 0.16.4-2.fc7.i386 (3 days) openvrml-devel - 0.16.4-2.fc7.ppc (3 days) openvrml-devel - 0.16.4-2.fc7.ppc64 (3 days) openvrml-devel - 0.16.4-2.fc7.x86_64 (3 days) cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (3 days) dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (3 days) fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 (3 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (3 days) glest-data - 2.0.0-2.fc7.noarch (3 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 (3 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 (3 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (3 days) kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 (3 days) kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (3 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (3 days) jonathansteffan AT gmail.com revisor - 2.0.3.6-1.fc7.noarch (3 days) revisor - 2.0.3.6-1.fc7.noarch (3 days) jwilson AT redhat.com emerald-themes - 0.2.0-1.fc7.noarch (3 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (3 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (3 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (3 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (3 days) kwizart AT gmail.com lcdproc - 0.5.2-1.fc7.i386 lcdproc - 0.5.2-1.fc7.ppc lcdproc - 0.5.2-1.fc7.ppc64 lcdproc - 0.5.2-1.fc7.x86_64 mdehaan AT redhat.com koan - 0.4.0-1.fc7.noarch (3 days) orion AT cora.nwra.com netcdf-decoders - 4.1.4-1.fc7.ppc64 (3 days) python-basemap - 0.9.5-1.fc7.ppc64 (3 days) rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 (3 days) rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (3 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (3 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (3 days) tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 (3 days) Democracy - 0.9.5.1-8.fc7.ppc (3 days) Democracy - 0.9.5.1-8.fc7.ppc64 (3 days) Democracy - 0.9.5.1-8.fc7.x86_64 (3 days) ====================================================================== Broken packages in fedora-7-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE openvrml-0.16.4-2.fc7.i386 requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.i386 requires firefox-devel = 0:2.0.0.3 ====================================================================== Broken packages in fedora-7-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) emerald-themes-0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 emerald-themes-0.2.0-1.fc7.noarch requires beryl-core >= 0:0.2.0 geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics netcdf-decoders-4.1.4-1.fc7.ppc64 requires perl(NetCDF) oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core openvrml-0.16.4-2.fc7.ppc64 requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.ppc64 requires firefox-devel = 0:2.0.0.3 python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in fedora-7-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 openvrml-0.16.4-2.fc7.ppc requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.ppc requires firefox-devel = 0:2.0.0.3 ====================================================================== Broken packages in fedora-7-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump openvrml-0.16.4-2.fc7.i386 requires firefox = 0:2.0.0.3 openvrml-0.16.4-2.fc7.x86_64 requires firefox = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.i386 requires firefox-devel = 0:2.0.0.3 openvrml-devel-0.16.4-2.fc7.x86_64 requires firefox-devel = 0:2.0.0.3 ====================================================================== Broken packages in fedora-updates-7-ppc64: revisor-2.0.3.6-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-7-ppc: revisor-2.0.3.6-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-testing-7-i386: lcdproc-0.5.2-1.fc7.i386 requires perl(Geo::METAR) synaptic-0.57.2-7.fc7.i386 requires libapt-pkg-libc6.5-6.so.2 ====================================================================== Broken packages in fedora-updates-testing-7-ppc64: koan-0.4.0-1.fc7.noarch requires syslinux lcdproc-0.5.2-1.fc7.ppc64 requires perl(Geo::METAR) synaptic-0.57.2-7.fc7.ppc64 requires libapt-pkg-libc6.5-6.so.2()(64bit) ====================================================================== Broken packages in fedora-updates-testing-7-ppc: lcdproc-0.5.2-1.fc7.ppc requires perl(Geo::METAR) synaptic-0.57.2-7.fc7.ppc requires libapt-pkg-libc6.5-6.so.2 ====================================================================== Broken packages in fedora-updates-testing-7-x86_64: lcdproc-0.5.2-1.fc7.x86_64 requires perl(Geo::METAR) synaptic-0.57.2-7.fc7.x86_64 requires libapt-pkg-libc6.5-6.so.2()(64bit) From greno at verizon.net Tue Jun 5 13:18:57 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 05 Jun 2007 09:18:57 -0400 Subject: vde2 - package submission Message-ID: <466562C1.6030802@verizon.net> I have been wanting to see a VDE2 package for Fedora for a while now and so I took a little time to write a spec file for it. I have used it to build fc6 i386 (my platform) RPMS/SRPM. Not sure if the fedora-devel list is where I should submit these but I would like to contribute these to Fedora as I think in light of increased QEMU usage that this would be of interest to the general community and is a good candidate for having it included in Fedora directly. Gerry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: README.fedora URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vde2.spec URL: From tonynelson at georgeanelson.com Tue Jun 5 13:23:55 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 09:23:55 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: Message-ID: At 7:23 AM +0200 6/5/07, Vnpenguin wrote: >On 6/5/07, Tony Nelson wrote: >> Because of the requests on fedora-list for CDs for F7, I'm trying to get >> Pungi to create CDs from the DVD, and I think it almost works. I'll need >> some help if I'm to get it to work. >> >> My basic procedure is to make a Pungi config file and a yum.conf that will >> use the loopback-mounted DVD ISO file as the source of packages and other >> info. That seems to work. >> >> The DVD repodata was not suitable because the "media:" URLs weren't >> understood, so I used createrepo to make new repodata and pointed the >> yum.conf to it. Is there a way to use the DVD's repodata? Do I need to >> monkey-patch urlopen()? > >Just umount the DVD if it has mounted automatically. And then re mount >it under /media/DVD for example. It works well for me :-) I "use the loopback-mounted DVD ISO file." Loopback mounting is not automatic. -- ____________________________________________________________________ TonyN.:' ' From tonynelson at georgeanelson.com Tue Jun 5 13:22:02 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 09:22:02 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: <200706050650.17730.jkeating@redhat.com> References: <200706050650.17730.jkeating@redhat.com> Message-ID: At 6:50 AM -0400 6/5/07, Jesse Keating wrote: >On Monday 04 June 2007 23:50:11 Tony Nelson wrote: >> The DVD's comps.xml does not include all the packages on the DVD. 19 are >> omitted, including anaconda-runtime, which causes buildinstall to fail (?). >> In any event, at "Building images...", upd-instroot, mk-images, and >> makestamp.py were missing, and later ".discinfo doesn't exist in the >> unified tree, not splitting". Should those 19 packages have been in >> comps.xml? Is there some way to add them to the process without writing a >> comps.xml? > >If you're using pungi on Fedora 7 No. The goal is to help people who can't use a DVD upgrade using CDs, so I and they will be using FC6 to split the F7 DVD with the Pungi from 6. >comps is not used to determine what packages >get onto the media. The manifest file does. In the case of Fedora 7 there >is an /etc/pungi/f7-fedora.manifest file shipped, as well as >an /etc/pungi/f7-fedora.i386/x86_64/ppc file that can be slightly modified >to make CD isos. Just uncomment and lower the cdsize variable and increase >the discs variable. Where is this .manifest file shipped? There are no .manifest files on the DVD. -- ____________________________________________________________________ TonyN.:' ' From mclasen at redhat.com Tue Jun 5 13:27:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Jun 2007 09:27:35 -0400 Subject: "core" In-Reply-To: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> References: <20070605074934.GA3624@dudweiler.stuttgart.redhat.com> Message-ID: <1181050055.3455.0.camel@dhcp83-186.boston.redhat.com> On Tue, 2007-06-05 at 09:49 +0200, Florian La Roche wrote: > Hello alll, > > I just saw that some apache dir listings show a small > bomb if a directory is named "core". For the next > rename of directories we might want to move "core" > again to something else then. > > E.g. look at: > http://www.jur-linux.org/download/fedora/ Why not just configure apache to do the right thing ? From nicolas.mailhot at laposte.net Tue Jun 5 13:32:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Jun 2007 15:32:35 +0200 (CEST) Subject: Why isn't emacs installed by default In-Reply-To: <1181040502.3174.11.camel@nirvana.limasoftware.net> References: <4663B7FB.6000602@nobugconsulting.ro> <20070604094228.GC27020@dspnet.fr.eu.org> <20070604100607.GB2856@free.fr> <43338.192.54.193.51.1180954063.squirrel@rousalka.dyndns.org> <23308.192.54.193.51.1180964747.squirrel@rousalka.dyndns.org> <20070604135340.GB60513@dspnet.fr.eu.org> <52887.192.54.193.51.1180967050.squirrel@rousalka.dyndns.org> <1181040502.3174.11.camel@nirvana.limasoftware.net> Message-ID: <50483.192.54.193.51.1181050355.squirrel@rousalka.dyndns.org> Le Mar 5 juin 2007 12:48, Mario Torre a ?crit : >> Those apps take care of the deps needed by their main text widget. >> And >> their text widget integrates cleanly with the rest of the desktop. > > I don't really agree they always do, for example, see how Firefox > renders its widgets. Scroll bars never match the desktop theme, menu > don't even wobble when Compiz is enable, and the form widgets... well, > they simply are aliens... Compared to emacs they're almost siblings. -- Nicolas Mailhot From mschwendt.tmp0701.nospam at arcor.de Tue Jun 5 13:42:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 5 Jun 2007 15:42:21 +0200 Subject: vde2 - package submission In-Reply-To: <466562C1.6030802@verizon.net> References: <466562C1.6030802@verizon.net> Message-ID: <20070605154221.948ac6fa.mschwendt.tmp0701.nospam@arcor.de> On Tue, 05 Jun 2007 09:18:57 -0400, Gerry Reno wrote: > I have been wanting to see a VDE2 package for Fedora for a while now > and so I took a little time to write a spec file for it. I have used it > to build fc6 i386 (my platform) RPMS/SRPM. Not sure if the fedora-devel > list is where I should submit these but I would like to contribute these > to Fedora as I think in light of increased QEMU usage that this would be > of interest to the general community and is a good candidate for having > it included in Fedora directly. > > Gerry A few findings: > Requires: libc.so.6(GLIBC_2.4), rpmlib(CompressedFileNames) <= 3.0.4-1, libc.so.6(GLIBC_2.1), libc.so.6(GLIBC_2.0), libvde2, libc.so.6(GLIBC_2.1.3), rtld(GNU_HASH), rpmlib(PayloadFilesHavePrefix) <= 4.0-1, libvdeplug.so.2, libc.so.6(GLIBC_2.3), libc.so.6(GLIBC_2.3.4) > Drop all these. They are automatically found and added by rpm-build. > # do not end description with a ./dot/period Why not? > %package -n %{libname}-devel > Summary: VDE development libraries > Group: Development/Other Requires: %libname = %version-%release is missing here. > %files -n %{libname} > %{_libdir}/libvde*.so.* %defattr is missing here. > %files -n %{libname}-devel %defattr is missing here. > %{_includedir}/libvde*.h > %{_libdir}/libvde*.so > %{_libdir}/libvde*.*a > %{_libdir}/vde2/libvde*.so > %{_libdir}/vde2/libvde*.*a %dir %{_libdir}/vde2 is missing here. The *.*a wildcards ought to be adjusted as not to include static libraries. %post -n %{libname} -p /sbin/ldconfig %postun -n %{libname} -p /sbin/ldconfig are missing. From jwilson at redhat.com Tue Jun 5 13:40:56 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 05 Jun 2007 09:40:56 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <200706050650.17730.jkeating@redhat.com> Message-ID: <466567E8.3040506@redhat.com> Tony Nelson wrote: > At 6:50 AM -0400 6/5/07, Jesse Keating wrote: >> If you're using pungi on Fedora 7 > > No. The goal is to help people who can't use a DVD upgrade using CDs, so I > and they will be using FC6 to split the F7 DVD with the Pungi from 6. You're asking for a world of hurt if you're trying to build F7 CDs using the FC6 pungi. >> comps is not used to determine what packages >> get onto the media. The manifest file does. In the case of Fedora 7 there >> is an /etc/pungi/f7-fedora.manifest file shipped, as well as >> an /etc/pungi/f7-fedora.i386/x86_64/ppc file that can be slightly modified >> to make CD isos. Just uncomment and lower the cdsize variable and increase >> the discs variable. > > Where is this .manifest file shipped? There are no .manifest files on the DVD. Its part of the pungi configs in versions later than the one for FC6. And no, you can't simply build the newer pungi for FC6 either, its got some deps that would need to be brought back as well. Been there, done that, actually, and wouldn't recommend it as something to suggest to end-users wanting to generate CDs from the DVD. I'd just use F7 to build CDs, get the posted somewhere, and get a torrent going. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From greno at verizon.net Tue Jun 5 13:43:49 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 05 Jun 2007 09:43:49 -0400 Subject: vde2 - package submission In-Reply-To: <20070605154221.948ac6fa.mschwendt.tmp0701.nospam@arcor.de> References: <466562C1.6030802@verizon.net> <20070605154221.948ac6fa.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46656895.9030908@verizon.net> Michael Schwendt wrote: > On Tue, 05 Jun 2007 09:18:57 -0400, Gerry Reno wrote: > > >> I have been wanting to see a VDE2 package for Fedora for a while now >> and so I took a little time to write a spec file for it. I have used it >> to build fc6 i386 (my platform) RPMS/SRPM. Not sure if the fedora-devel >> list is where I should submit these but I would like to contribute these >> to Fedora as I think in light of increased QEMU usage that this would be >> of interest to the general community and is a good candidate for having >> it included in Fedora directly. >> >> Gerry >> > > A few findings: > Thanks Michael. I'll make the mods. Gerry From lemenkov at gmail.com Tue Jun 5 13:29:36 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 5 Jun 2007 13:29:36 +0000 (UTC) Subject: PowerPC (was: Re: annoying syslog message from kernel) References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> Message-ID: Joseph Sacco gnome.org> writes: > Another thing... On occasion the system, Powermac with dual G4 > processors, fails to boot because of a "spinlock" problem on CPU0. I've got problems with my bcm43xx (caused by new wi-fi stack) and my PowerPC-based Mac Mini completely loosed ability to play sounds ) > Hmmm... I wonder if these two events are related. Looks like there are some powerpc-related deteriorations in Fedora7 default kernel. From triad at df.lth.se Tue Jun 5 14:04:13 2007 From: triad at df.lth.se (Linus Walleij) Date: Tue, 5 Jun 2007 16:04:13 +0200 (CEST) Subject: fedora for ARM In-Reply-To: <1181047155.27239.100.camel@mccallum.corsepiu.local> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> Message-ID: On Tue, 5 Jun 2007, Ralf Corsepius wrote: > Is there an existing, binary distributed target-distro? Yes this is what MontaVista provides for several target boards, and I guess some board vendors do their own dists as well. They build with RPM (possibly a forked version) using a cross compiler. You can see some of their funny SRPMs at e.g.: https://opensource.motorola.com/sf/frs/do/viewRelease/projects.a910/frs.a910.r57_g_10_06_48r Linus From bernie at codewiz.org Tue Jun 5 14:07:19 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 10:07:19 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <1181048914.21330.9.camel@dhcp83-66.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <1181048914.21330.9.camel@dhcp83-66.boston.redhat.com> Message-ID: <46656E17.5090601@codewiz.org> David Zeuthen wrote: > Wasn't a goal when I wrote the OLPC build system (it was, however, a > goal to create four separate images aka streams (devel/non-devel > msdos-partitioned-ext3-for-usb-sticks/jffs2). I appreciate that goals > change however, I'm not active in the OLPC project anymore. Actually, I'm not really sure the images are identical... But the non-devel stream has been killed off some time ago. > I was proposing to create an empty dummy RPM package with > Provides: mkinitrd Cool, I use exactly the same trick to remove MTAs from servers with qmail. But we can't do that in the ext3 image. And mkinitrd in itself is no big deal. The dependencies on lvm2 and device-mapper can be dropped with minimal changes to the script. >> Also, I dismiss the argument that today's computers have >> huge hard drives anyway so let's waste them. Bigger hard >> drives are meant to hold more data, not the same amount of >> data stored in inefficient formats. > > Take it easy, it's not like I'm disagreeing with you. Sorry, it wasn't directed at you specifically. I was just worried they'd bury me in replies telling system recovery stories where static binaries saved the day ;-) > Yes, in 99.999% of all cases (that's five nines for you), it's > absolutely unnecessary to have any static binaries at all in the default > Fedora install. If you had read the archives of fedora-devel-list (which > you Cc'ed yourself) you would have found > > - a huge discussion on "static linking considered harmful"; started > by Ulrich Drepper. Some people have even more extreme points of > of view than you. Here's a paper by Ulrich > > http://people.redhat.com/drepper/no_static_linking.html I'm a long time subscriber and I remember this thread. But IIRC, it was about local copies of system libraries such as zlib in such as cvs and svn, and originated because the security flaw in zlib required lots of package updates. > - that early user space in Fedora is increasingly moving to > dynamic linking; that's a good thing; even better if people > remember to kill statically linked binaries :-) Now that we're trying to reduce bloat in the OLPC image, it would be nice if the relevant upstream package maintainers could make these changes. I could also come up with patches of my own, but I have less context and no experience with rebuilding these packages. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From giallu at gmail.com Tue Jun 5 14:02:31 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 5 Jun 2007 16:02:31 +0200 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: <1181048007.15192.13.camel@work> References: <1179326006.14246.44.camel@localhost.localdomain> <57127b5f0705200025r79fc31e7uf8dc4fd5326cb4b2@mail.gmail.com> <1179671307.2583.0.camel@localhost.localdomain> <57127b5f0705200842j67ca4971mb039399973e043c9@mail.gmail.com> <1179677432.2633.4.camel@localhost.localdomain> <57127b5f0706050543j36d0bde2g6dd270266e889e24@mail.gmail.com> <1181048007.15192.13.camel@work> Message-ID: On 6/5/07, Richard Hughes wrote: > On Tue, 2007-06-05 at 18:13 +0530, Deependra Shekhawat wrote: > > > > Is there any update on this for fedora7 final. Is suspend/hibernate > > working now. > > On Lenovo 3k hardware no, I've been very busy. I've been working hard on > the multimedia keys stuff. > Is this work easily portable to other laptop brands? Any docs around? From jsacco at gnome.org Tue Jun 5 14:12:39 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Tue, 05 Jun 2007 10:12:39 -0400 Subject: PowerPC (was: Re: annoying syslog message from kernel) In-Reply-To: References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> Message-ID: <1181052759.8779.12.camel@rt.jesacco.com> Adding to that list: * firewire stack is once again borked. * ctl-alt-F8 sends a system with an nvidia geforce2MX card into lala-land. -Joseph ====================================================================== On Tue, 2007-06-05 at 13:29 +0000, Peter Lemenkov wrote: > Joseph Sacco gnome.org> writes: > > > Another thing... On occasion the system, Powermac with dual G4 > > processors, fails to boot because of a "spinlock" problem on CPU0. > > I've got problems with my bcm43xx (caused by new wi-fi stack) and my > > PowerPC-based Mac Mini completely loosed ability to play sounds ) > > > Hmmm... I wonder if these two events are related. > > Looks like there are some powerpc-related deteriorations in Fedora7 default > kernel. > -- joseph_sacco [at] comcast [dot] net -- jsacco [at] gnome [dot] org From jeff at ocjtech.us Tue Jun 5 14:17:50 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 05 Jun 2007 09:17:50 -0500 Subject: Bug: Fedora doesn't close DVD drive door In-Reply-To: References: Message-ID: <1181053070.3910.5.camel@lt21223.campus.dmacc.edu> On Mon, 2007-06-04 at 22:07 +1200, Shams wrote: > > When I shutdown Fedora 7 it doesn't close the DVD drive > door automatically and the door is left open. Same problem > persisted with Fedora 6. > > However if I reboot then the DVD drive door does get closed > automatically. This probably has more to do with the firmware in your DVD drive that it does with Fedora. I suspect that you would see a similar problem no matter what OS you were running. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From darrellpf at gmail.com Tue Jun 5 14:17:12 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 5 Jun 2007 07:17:12 -0700 Subject: rawhide report: 20070605 changes In-Reply-To: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> References: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> Message-ID: > wpa_supplicant-1:0.5.7-3.fc7 > ---------------------------- > * Mon Jun 04 2007 Dan Williams - 0.5.7-3 > - Fix buffer overflow by removing syslog patch (#rh242455) > wpa_supplicant dies with this version, which prevents NetworkManager/wireless from working. It is also a bit of a bug in NetworkMananger since even though I'm not using wpa at all, the death of wpa_supplicant means that NM gives up and no wireless is available. Reverting to 5.7-2 fixes the problem. darrell From tonynelson at georgeanelson.com Tue Jun 5 14:21:24 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 10:21:24 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: <466567E8.3040506@redhat.com> References: <200706050650.17730.jkeating@redhat.com> <466567E8.3040506@redhat.com> Message-ID: At 9:40 AM -0400 6/5/07, Jarod Wilson wrote: >Tony Nelson wrote: >> At 6:50 AM -0400 6/5/07, Jesse Keating wrote: >>> If you're using pungi on Fedora 7 >> >> No. The goal is to help people who can't use a DVD upgrade using CDs, so I >> and they will be using FC6 to split the F7 DVD with the Pungi from 6. > >You're asking for a world of hurt if you're trying to build F7 CDs using >the FC6 pungi. How so? There seems to be a problem with the comps.xml file, which omits 20 packages, some of which are needed. So far no one has addressed my questions, including that one. Will there be other problems? Should those who needs F7 CDs install F7 first? I don't suppose that's much more a slap in the face than having to use Pungi to create the images in the first place. >>> comps is not used to determine what packages >>> get onto the media. The manifest file does. In the case of Fedora 7 there >>> is an /etc/pungi/f7-fedora.manifest file shipped, as well as >>> an /etc/pungi/f7-fedora.i386/x86_64/ppc file that can be slightly modified >>> to make CD isos. Just uncomment and lower the cdsize variable and increase >>> the discs variable. >> >> Where is this .manifest file shipped? There are no .manifest files on >> the DVD. > >Its part of the pungi configs in versions later than the one for FC6. >And no, you can't simply build the newer pungi for FC6 either, its got >some deps that would need to be brought back as well. Been there, done >that, actually, and wouldn't recommend it as something to suggest to >end-users wanting to generate CDs from the DVD. I'd just use F7 to build >CDs, get the posted somewhere, and get a torrent going. Yes, please do! Many people who need to install from CDs will thank you for that! -- ____________________________________________________________________ TonyN.:' ' From jkeating at redhat.com Tue Jun 5 14:20:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 10:20:45 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <200706050650.17730.jkeating@redhat.com> Message-ID: <200706051020.45948.jkeating@redhat.com> On Tuesday 05 June 2007 09:22:02 Tony Nelson wrote: > No. ?The goal is to help people who can't use a DVD upgrade using CDs, so I > and they will be using FC6 to split the F7 DVD with the Pungi from 6. The only way you can compose Fedora 7 from Fedora 6 is through mock, and the mock chroot would have to be populated with Fedora 7 content. > >comps is not used to determine what packages > >get onto the media. ?The manifest file does. ?In the case of Fedora 7 > > there is an /etc/pungi/f7-fedora.manifest file shipped, as well as > >an /etc/pungi/f7-fedora.i386/x86_64/ppc ?file that can be slightly > > modified to make CD isos. ?Just uncomment and lower the cdsize variable > > and increase the discs variable. > > Where is this .manifest file shipped? ?There are no .manifest files on the > DVD. It's shipped in the Fedora 7 pungi package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Jun 5 14:23:34 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 05 Jun 2007 15:23:34 +0100 Subject: PowerPC (was: Re: annoying syslog message from kernel) In-Reply-To: References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> Message-ID: <1181053415.16089.12.camel@hades.cambridge.redhat.com> On Tue, 2007-06-05 at 13:29 +0000, Peter Lemenkov wrote: > Joseph Sacco gnome.org> writes: > > > Another thing... On occasion the system, Powermac with dual G4 > > processors, fails to boot because of a "spinlock" problem on CPU0. > > I've got problems with my bcm43xx (caused by new wi-fi stack) and my You can still use the old bcm43xx 'softmac' driver if it's working better. > PowerPC-based Mac Mini completely loosed ability to play sounds ) Do you have the snd-aoa driver loaded? -- dwmw2 From greno at verizon.net Tue Jun 5 14:32:10 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 05 Jun 2007 10:32:10 -0400 Subject: vde2 - package submission [revised spec] Message-ID: <466573EA.7050504@verizon.net> I have been wanting to see a VDE2 package for Fedora for a while now and so I took a little time to write a spec file for it. I have used it to build fc6 i386 (my platform) RPMS/SRPM. Not sure if the fedora-devel list is where I should submit these but I would like to contribute these to Fedora as I think in light of increased QEMU usage that this would be of interest to the general community and is a good candidate for having it included in Fedora directly. Gerry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: README.fedora URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vde2.spec URL: From jkeating at redhat.com Tue Jun 5 14:39:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 10:39:32 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <466567E8.3040506@redhat.com> Message-ID: <200706051039.32612.jkeating@redhat.com> On Tuesday 05 June 2007 10:21:24 Tony Nelson wrote: > How so? ?There seems to be a problem with the comps.xml file, which omits > 20 packages, some of which are needed. ?So far no one has addressed my > questions, including that one. ?Will there be other problems? > > Should those who needs F7 CDs install F7 first? ?I don't suppose that's > much more a slap in the face than having to use Pungi to create the images > in the first place. The yum api is different, the anaconda-runtime calls are different, the userland tools to generate images that are needed during install are too old to work with the Fedora 7 kernel, pungi itself has had a TON of bugfixes and changes to it in order to properly compose Fedora 7, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tonynelson at georgeanelson.com Tue Jun 5 14:44:26 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 10:44:26 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: <200706051020.45948.jkeating@redhat.com> References: <200706050650.17730.jkeating@redhat.com> <200706051020.45948.jkeating@redhat.com> Message-ID: At 10:20 AM -0400 6/5/07, Jesse Keating wrote: >On Tuesday 05 June 2007 09:22:02 Tony Nelson wrote: >> No. The goal is to help people who can't use a DVD upgrade using CDs, so I >> and they will be using FC6 to split the F7 DVD with the Pungi from 6. > >The only way you can compose Fedora 7 from Fedora 6 is through mock, and the >mock chroot would have to be populated with Fedora 7 content. Pungi doesn't just use the comps.xml list of packages and the given repo to make the install images? It gets some of its content from the running OS? Perhaps what Pungi gets from the running OS could be added to the documentation when that gets written. >> >comps is not used to determine what packages >> >get onto the media. The manifest file does. In the case of Fedora 7 >> > there is an /etc/pungi/f7-fedora.manifest file shipped, as well as >> >an /etc/pungi/f7-fedora.i386/x86_64/ppc file that can be slightly >> > modified to make CD isos. Just uncomment and lower the cdsize variable >> > and increase the discs variable. >> >> Where is this .manifest file shipped? There are no .manifest files on the >> DVD. > >It's shipped in the Fedora 7 pungi package. And apparantly can't be used by a Pungi that runs on FC6. Too bad. Perhaps I'll be able to make do with the comps.xml file on the DVD. (If it won't work, it would help to say how it won't work, because it seems to work.) -- ____________________________________________________________________ TonyN.:' ' From jkeating at redhat.com Tue Jun 5 14:52:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 10:52:31 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <200706051020.45948.jkeating@redhat.com> Message-ID: <200706051052.31933.jkeating@redhat.com> On Tuesday 05 June 2007 10:44:26 Tony Nelson wrote: > Pungi doesn't just use the comps.xml list of packages and the given repo to > make the install images? ?It gets some of its content from the running OS? > Perhaps what Pungi gets from the running OS could be added to the > documentation when that gets written. Pungi reads a manifest file that is of kickstart syntax to determine what to "download". It then has to run some anaconda tools on what it downloads to make them installable. Those anaconda tools must match the version of anaconda that is in the distribution. So you need Fedora 7 anaconda tools to compose Fedora 7, and those tools need other parts of Fedora 7, and so on. I do believe this is documented at https://hosted.fedoraproject.org/projects/pungi but maybe not clear enough, I'm not a docs writer. > >> >comps is not used to determine what packages > >> >get onto the media. ?The manifest file does. ?In the case of Fedora 7 > >> > there is an /etc/pungi/f7-fedora.manifest file shipped, as well as > >> >an /etc/pungi/f7-fedora.i386/x86_64/ppc ?file that can be slightly > >> > modified to make CD isos. ?Just uncomment and lower the cdsize > >> > variable and increase the discs variable. > >> > >> Where is this .manifest file shipped? ?There are no .manifest files on > >> the DVD. > > > >It's shipped in the Fedora 7 pungi package. > > And apparantly can't be used by a Pungi that runs on FC6. ?Too bad. > Perhaps I'll be able to make do with the comps.xml file on the DVD. ?(If it > won't work, it would help to say how it won't work, because it seems to > work.) The resulting iso set will fail. You'll have an install environment of Fedora 7 packages built with Fedora 6 tools that are incompatible. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tonynelson at georgeanelson.com Tue Jun 5 15:23:57 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 11:23:57 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: <200706051052.31933.jkeating@redhat.com> References: <200706051020.45948.jkeating@redhat.com> <200706051052.31933.jkeating@redhat.com> Message-ID: At 10:52 AM -0400 6/5/07, Jesse Keating wrote: >Content-Type: multipart/signed; boundary="nextPart2008544.aiEdq5Lhs6"; > protocol="application/pgp-signature"; micalg=pgp-sha1 >Content-Transfer-Encoding: 7bit > >On Tuesday 05 June 2007 10:44:26 Tony Nelson wrote: >> Pungi doesn't just use the comps.xml list of packages and the given repo to >> make the install images? It gets some of its content from the running OS? >> Perhaps what Pungi gets from the running OS could be added to the >> documentation when that gets written. > >Pungi reads a manifest file that is of kickstart syntax to determine what >to "download". It then has to run some anaconda tools on what it downloads >to make them installable. Those anaconda tools must match the version of >anaconda that is in the distribution. So you need Fedora 7 anaconda tools to >compose Fedora 7, and those tools need other parts of Fedora 7, and so on. I >do believe this is documented at >https://hosted.fedoraproject.org/projects/pungi but maybe not clear enough, >I'm not a docs writer. > >> >> >comps is not used to determine what packages >> >> >get onto the media. The manifest file does. In the case of Fedora 7 >> >> > there is an /etc/pungi/f7-fedora.manifest file shipped, as well as >> >> >an /etc/pungi/f7-fedora.i386/x86_64/ppc file that can be slightly >> >> > modified to make CD isos. Just uncomment and lower the cdsize >> >> > variable and increase the discs variable. >> >> >> >> Where is this .manifest file shipped? There are no .manifest files on >> >> the DVD. >> > >> >It's shipped in the Fedora 7 pungi package. >> >> And apparantly can't be used by a Pungi that runs on FC6. Too bad. >> Perhaps I'll be able to make do with the comps.xml file on the DVD. (If it >> won't work, it would help to say how it won't work, because it seems to >> work.) > >The resulting iso set will fail. You'll have an install environment of Fedora >7 packages built with Fedora 6 tools that are incompatible. OK. I'll give up now. No F7 CDs from me. Perhaps someone else will do it with jigdo. -- ____________________________________________________________________ TonyN.:' ' From tonynelson at georgeanelson.com Tue Jun 5 15:23:58 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 11:23:58 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: <200706051039.32612.jkeating@redhat.com> References: <466567E8.3040506@redhat.com> <200706051039.32612.jkeating@redhat.com> Message-ID: At 10:39 AM -0400 6/5/07, Jesse Keating wrote: >On Tuesday 05 June 2007 10:21:24 Tony Nelson wrote: >> How so? There seems to be a problem with the comps.xml file, which omits >> 20 packages, some of which are needed. So far no one has addressed my >> questions, including that one. Will there be other problems? >> >> Should those who needs F7 CDs install F7 first? I don't suppose that's >> much more a slap in the face than having to use Pungi to create the images >> in the first place. > >The yum api is different, the anaconda-runtime calls are different, the >userland tools to generate images that are needed during install are too old >to work with the Fedora 7 kernel, pungi itself has had a TON of bugfixes and >changes to it in order to properly compose Fedora 7, etc... OK, too bad, no CDs for F7 from me then. Perhaps someone else will do it with jigdo. -- ____________________________________________________________________ TonyN.:' ' From kevin.kofler at chello.at Tue Jun 5 15:29:48 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 5 Jun 2007 15:29:48 +0000 (UTC) Subject: Announcing Quarticurve: Unofficial Bluecurve Qt 4 port References: Message-ID: And now I uploaded another version: > Tab widgets need some work (fixing display glitches for tabs at the top and > bottom, Fixed. > handling [horizontally-positioned vertical] tabs instead of throwing those at > the QCleanlooksStyle base class), Done. > there's a glitch with the dropdown pushbutton in the Qt Designer "New" dialog Fixed. > and there might be some remaining off-by-one issues left I fixed the ones I noticed, as well as a couple of other rendering glitches. So now I'd consider the new version of at least beta quality. If you're desperately looking for a common widget style across GTK+ 2, Qt 3 and Qt 4 (and there's even an old GTK+ 1 version if you still use that, it's in the FC5 redhat-artwork SRPM under art/gtk/Bluecurve1), Bluecurve and Quarticurve are probably what you're looking for. If on the other hand you always hated Bluecurve, then why are you still reading this thread? :-) Quarticurve is designed to look like Bluecurve, it is NOT a fork aiming at "modernizing" the style, whatever that means, so any suggestions aiming at changing how the style looks are not welcome. ;-) (You're of course welcome to base your own style on Quarticurve though, that's what the GPL is for.) > Same URL: > http://www.tigen.org/kevin.kofler/pcprogs/quarticurve.7z Kevin Kofler From jkeating at redhat.com Tue Jun 5 15:28:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 11:28:19 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <200706051052.31933.jkeating@redhat.com> Message-ID: <200706051128.19820.jkeating@redhat.com> On Tuesday 05 June 2007 11:23:57 Tony Nelson wrote: > OK. ?I'll give up now. ?No F7 CDs from me. You do realize that the Fedora 7 i686 LiveCD is installable right? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Tue Jun 5 15:32:30 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 05 Jun 2007 15:32:30 +0000 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1180725932.31759.9.camel@rivendell> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> <1180661733.28298.15.camel@neutron> <1180721609.3946.51.camel@zebes.localdomain> <1180725932.31759.9.camel@rivendell> Message-ID: <1181057550.18981.67.camel@metroid.rdu.redhat.com> On Fri, 2007-06-01 at 15:25 -0400, seth vidal wrote: > On Fri, 2007-06-01 at 14:13 -0400, Will Woods wrote: > > Oh definitely. In fact, that's the main reason *I* care about this > > feature. Live-ish upgrades would be a cool feature and save our users > > some time, but making system upgrades easier to script is the icing on > > the cake for me. > > > > But how do we get around all the mess? Items like: > > - ext3->ext4 conversion > - lvm format changes > - dev->udev > - etc. etc. Dude, I'm well aware of the issues involved. I said "Live-ish" because I know Debian-style live upgrades aren't possible - which is why we don't support them. However, I believe we can improve the upgrade process to the point where the single-command, fire-and-forget upgrade is possible. That's what people are really asking for when they ask for "Live upgrades". Obviously you're going to have to reboot at some point to get into the newly-upgraded system, so I don't really think people care if you reboot *before* upgrading the kernel or *after*, so long as it's minimally interactive. Okay, so. The upgrade process currently goes something like this: 0. boot into installer 1. download new repo info 2. download all new packages 3. upgrade all new packages 4. reboot into new system Debian just ignores step 0, and runs with the old kernel and live filesystems. Bad mojo. I'm not at all suggesting that we do that. The problems I'm trying to solve are related but separate: 1. It could be easier to get to step 0. Currently you need to to burn a DVD or boot.iso/rescue CD or manually munge grub.conf to boot into the installer. 2. Step 2 (necessarily) takes a long time, so network upgrades spend most of their time stuck in the installer waiting for packages to download. To tackle the first problem, we just need a simple script that will grab the kernel/initrd from media or a mirror and munge your pre-existing grub.conf (trivial using grubby) to boot into it. Furthermore this tool could ask a couple questions about where you're installing from - the amount of information needed for an upgrade is minimal. If we gather this before booting into the installer, we can do a fully-automatic upgrade. As for the second problem, what I'm proposing is a simple re-ordering of a couple of the steps: 1. download new repo info 2. download all new packages 0. boot into installer 3. upgrade all new packages 4. reboot into new system So now we spend a minimal amount of time in the installer, *and* the upgrade is fully automatic, *and* we're still doing upgrades The Right Way. Does this sound like a reasonable plan of attack? -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jun 5 15:40:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 11:40:55 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181057550.18981.67.camel@metroid.rdu.redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> Message-ID: <200706051140.55877.jkeating@redhat.com> On Tuesday 05 June 2007 11:32:30 Will Woods wrote: > 1. download new repo info > 2. download all new packages > 0. boot into installer > 3. upgrade all new packages > 4. reboot into new system > > So now we spend a minimal amount of time in the installer, *and* the > upgrade is fully automatic, *and* we're still doing upgrades The Right > Way. > > Does this sound like a reasonable plan of attack? Oft times you need the new yum / rpm to appropriately depsolve what is needed for "all the new packages" or maybe even to process the repo info at some point. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Tue Jun 5 15:50:51 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 5 Jun 2007 15:50:51 +0000 (UTC) Subject: Feature idea: package an installer image as a grub entry before F8. References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <46605682.5000706@benl.co.uk> <1180719440.3946.39.camel@zebes.localdomain> <1180661733.28298.15.camel@neutron> <1180721609.3946.51.camel@zebes.localdomain> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> Message-ID: Will Woods redhat.com> writes: > Dude, I'm well aware of the issues involved. I said "Live-ish" because I > know Debian-style live upgrades aren't possible Actually, they are. :-) I've done a few Fedora upgrades using apt-get dist-upgrade: * FC1->FC2 on a Pentium III desktop * FC5->FC6 on a Pentium II laptop * FC6->F7 in a QEMU x86_64 VM on a 32-bit Pentium IV host and they all worked. (FC1->FC2 required running 1 or 2 commands on the command line after the upgrade to deal with the 2.6 kernel, but that was well-documented in the dist-upgrade instructions Seth Vidal (for yum) and Panu Matilainen (for apt) released.) Kevin Kofler From dwmw2 at infradead.org Tue Jun 5 16:13:57 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 05 Jun 2007 17:13:57 +0100 Subject: annoying syslog message from kernel In-Reply-To: <1181048592.8779.6.camel@rt.jesacco.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> Message-ID: <1181060037.16089.30.camel@hades.cambridge.redhat.com> On Tue, 2007-06-05 at 09:03 -0400, Joseph Sacco wrote: > You are correct... I also see the "Badness at kernel/softirq.c:138" > message. Don't top-post. Looks like https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240982 -- dwmw2 From tonynelson at georgeanelson.com Tue Jun 5 16:16:27 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 12:16:27 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: <200706051128.19820.jkeating@redhat.com> References: <200706051052.31933.jkeating@redhat.com> <200706051128.19820.jkeating@redhat.com> Message-ID: At 11:28 AM -0400 6/5/07, Jesse Keating wrote: >On Tuesday 05 June 2007 11:23:57 Tony Nelson wrote: >> OK. I'll give up now. No F7 CDs from me. > >You do realize that the Fedora 7 i686 LiveCD is installable right? Yes. It will only do clean installs, not upgrades, and only contains a small subset of the DVD (itself a small subset of Fedora). People keep asking for install CDs, even after they try the live CD. Some people with only a CD drive could do a hard disk upgrade, so they could use any file splitter and re-assemble the DVD on the install machine. Others would have to repartition in order to have mountable space for the DVD image. Some people can do a yum upgrade. It doesn't matter how unsupported it is if the other choice is to use CDs that don't exist. But other people seem to have machines with a CD drive but no room for a DVD image and no fast Internet connection to the machine they want to upgrade or install on. I don't know if it's really true that buying a DVD drive is too expensive, but some of them say that. -- ____________________________________________________________________ TonyN.:' ' From shantanu_843 at yahoo.co.in Tue Jun 5 16:25:02 2007 From: shantanu_843 at yahoo.co.in (shantanu choudhary) Date: Tue, 5 Jun 2007 17:25:02 +0100 (BST) Subject: broken link in /lib/modules/2.6.21-1.3194.fc7/build Message-ID: <102898.49401.qm@web7604.mail.in.yahoo.com> hello all, i have installed FC7 today itself and it is showing a broken link with /lib/modules/2.6.21-1.3194.fc7/build file i am not able to install madwifi driver and it is even giving error for driver of ipw3945. they are looking for ./config file which is not available there, can u tell me how can i remove this problem regards shantanu --------------------------------- Did you know? You can CHAT without downloading messenger. Know how! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsacco at gnome.org Tue Jun 5 16:26:50 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Tue, 05 Jun 2007 12:26:50 -0400 Subject: annoying syslog message from kernel In-Reply-To: <1181060037.16089.30.camel@hades.cambridge.redhat.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181060037.16089.30.camel@hades.cambridge.redhat.com> Message-ID: <1181060810.3746.0.camel@rt.jesacco.com> Good to learn that "help is on the way"... -Joseph On Tue, 2007-06-05 at 17:13 +0100, David Woodhouse wrote: > On Tue, 2007-06-05 at 09:03 -0400, Joseph Sacco wrote: > > You are correct... I also see the "Badness at kernel/softirq.c:138" > > message. > > Don't top-post. > > Looks like https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240982 > > -- > dwmw2 -- jsacco [at] gnome [dot] org From dwmw2 at infradead.org Tue Jun 5 16:31:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 05 Jun 2007 17:31:31 +0100 Subject: annoying syslog message from kernel In-Reply-To: <1181060810.3746.0.camel@rt.jesacco.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181060037.16089.30.camel@hades.cambridge.redhat.com> <1181060810.3746.0.camel@rt.jesacco.com> Message-ID: <1181061091.16089.32.camel@hades.cambridge.redhat.com> On Tue, 2007-06-05 at 12:26 -0400, Joseph Sacco wrote: > Good to learn that "help is on the way"... Don't top-post. Good to know it's not ppc-specific, too :) -- dwmw2 From lemenkov at gmail.com Tue Jun 5 16:53:32 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 5 Jun 2007 16:53:32 +0000 (UTC) Subject: PowerPC (was: Re: annoying syslog message from kernel) References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181053415.16089.12.camel@hades.cambridge.redhat.com> Message-ID: David Woodhouse infradead.org> writes: > On Tue, 2007-06-05 at 13:29 +0000, Peter Lemenkov wrote: > > Joseph Sacco gnome.org> writes: > > > > > Another thing... On occasion the system, Powermac with dual G4 > > > processors, fails to boot because of a "spinlock" problem on CPU0. > > > > I've got problems with my bcm43xx (caused by new wi-fi stack) and my > > You can still use the old bcm43xx 'softmac' driver if it's working > better. No I can't. Wi-Fi starts working only after I upgraded firmware to v4.80.xxxx and switched from bcm43xx to bcm43xx_mac80211. My default configuration wasn't working at all after "yum upgrade". > > PowerPC-based Mac Mini completely loosed ability to play sounds ) > > Do you have the snd-aoa driver loaded? Yes. I tried to load/unload snd-aoa and/or snd-powermac in every possible combination, but failed. If you interested you may read my quest ) http://lists.infradead.org/pipermail/fedora-ppc/2007-June/000985.html From hughsient at gmail.com Tue Jun 5 16:56:19 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 05 Jun 2007 17:56:19 +0100 Subject: Explaining the new suspend quirks functionality in F7 In-Reply-To: References: <1179326006.14246.44.camel@localhost.localdomain> <57127b5f0705200025r79fc31e7uf8dc4fd5326cb4b2@mail.gmail.com> <1179671307.2583.0.camel@localhost.localdomain> <57127b5f0705200842j67ca4971mb039399973e043c9@mail.gmail.com> <1179677432.2633.4.camel@localhost.localdomain> <57127b5f0706050543j36d0bde2g6dd270266e889e24@mail.gmail.com> <1181048007.15192.13.camel@work> Message-ID: <1181062579.15192.51.camel@work> On Tue, 2007-06-05 at 16:02 +0200, Gianluca Sforna wrote: > On 6/5/07, Richard Hughes wrote: > > On Tue, 2007-06-05 at 18:13 +0530, Deependra Shekhawat wrote: > > > > > > Is there any update on this for fedora7 final. Is suspend/hibernate > > > working now. > > > > On Lenovo 3k hardware no, I've been very busy. I've been working hard on > > the multimedia keys stuff. > > > > Is this work easily portable to other laptop brands? > Any docs around? I'm working on some now. http://people.freedesktop.org/~hughsient/quirk/index.html Richard. From drago01 at gmail.com Tue Jun 5 16:50:50 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 05 Jun 2007 18:50:50 +0200 Subject: rawhide report: 20070605 changes In-Reply-To: References: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> Message-ID: <4665946A.3050308@gmail.com> darrell pfeifer wrote: >> wpa_supplicant-1:0.5.7-3.fc7 >> ---------------------------- >> * Mon Jun 04 2007 Dan Williams - 0.5.7-3 >> - Fix buffer overflow by removing syslog patch (#rh242455) >> > > wpa_supplicant dies with this version, which prevents > NetworkManager/wireless from working. have you also updated networkmanager? From tmz at pobox.com Tue Jun 5 17:00:44 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 5 Jun 2007 13:00:44 -0400 Subject: broken link in /lib/modules/2.6.21-1.3194.fc7/build In-Reply-To: <102898.49401.qm@web7604.mail.in.yahoo.com> References: <102898.49401.qm@web7604.mail.in.yahoo.com> Message-ID: <20070605170044.GA8347@psilocybe.teonanacatl.org> shantanu choudhary wrote: > i have installed FC7 today itself and it is showing a broken link > with /lib/modules/2.6.21-1.3194.fc7/build file i am not able to > install madwifi driver and it is even giving error for driver of > ipw3945. they are looking for ./config file which is not available > there, can u tell me how can i remove this problem Install the kernel-devel package. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Happiness is good health and a bad memory. -- Ingrid Bergman (1917-1982) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From vnpenguin at vnoss.org Tue Jun 5 17:04:43 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Tue, 5 Jun 2007 19:04:43 +0200 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <466567E8.3040506@redhat.com> <200706051039.32612.jkeating@redhat.com> Message-ID: On 6/5/07, Tony Nelson wrote: > > OK, too bad, no CDs for F7 from me then. > > Perhaps someone else will do it with jigdo. > -- Just make One-CD version of F7 with pungi. ISO size is about 685MB (Full Gnome desktop + Graphics + System tools) . Tested install on VMware ok :) Sorry, I have NO bandwidth so I can not upload it. -- http://vnoss.org From jsacco at gnome.org Tue Jun 5 17:09:21 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Tue, 05 Jun 2007 13:09:21 -0400 Subject: annoying syslog message from kernel In-Reply-To: <1181061091.16089.32.camel@hades.cambridge.redhat.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181060037.16089.30.camel@hades.cambridge.redhat.com> <1181060810.3746.0.camel@rt.jesacco.com> <1181061091.16089.32.camel@hades.cambridge.redhat.com> Message-ID: <1181063361.3746.5.camel@rt.jesacco.com> David, My comments are not meant to be mean-spirited or hurtful. I don't go out of my way to aggravate people so I don't understand your problem. Maybe we should take this off line. -Joseph ====================================================================== On Tue, 2007-06-05 at 17:31 +0100, David Woodhouse wrote: > On Tue, 2007-06-05 at 12:26 -0400, Joseph Sacco wrote: > > Good to learn that "help is on the way"... > > Don't top-post. Good to know it's not ppc-specific, too :) > -- jsacco [at] gnome [dot] org From darrellpf at gmail.com Tue Jun 5 17:21:28 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 5 Jun 2007 10:21:28 -0700 Subject: rawhide report: 20070605 changes In-Reply-To: <4665946A.3050308@gmail.com> References: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> <4665946A.3050308@gmail.com> Message-ID: On 6/5/07, dragoran wrote: > darrell pfeifer wrote: > >> wpa_supplicant-1:0.5.7-3.fc7 > >> ---------------------------- > >> * Mon Jun 04 2007 Dan Williams - 0.5.7-3 > >> - Fix buffer overflow by removing syslog patch (#rh242455) > >> > > > > wpa_supplicant dies with this version, which prevents > > NetworkManager/wireless from working. > have you also updated networkmanager? > Yes. The machine is completely up to date from rawhide this morning. I didn't check to see if NetworkManager has an update didn't make it in to today's rawhide though. darrell From jsacco at gnome.org Tue Jun 5 17:23:29 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Tue, 05 Jun 2007 13:23:29 -0400 Subject: annoying syslog message from kernel In-Reply-To: <46659A53.5040307@gmail.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181060037.16089.30.camel@hades.cambridge.redhat.com> <1181060810.3746.0.camel@rt.jesacco.com> <1181061091.16089.32.camel@hades.cambridge.redhat.com> <1181063361.3746.5.camel@rt.jesacco.com> <46659A53.5040307@gmail.com> Message-ID: <1181064209.3746.10.camel@rt.jesacco.com> Oh... Posting protocol... Sorry for the misunderstanding. Be well, -Joseph ========================================================================= On Tue, 2007-06-05 at 19:16 +0200, dragoran wrote: > Joseph Sacco wrote: > > David, > > > > My comments are not meant to be mean-spirited or hurtful. I don't go out > > of my way to aggravate people so I don't understand your problem. > > > > Maybe we should take this off line. > > > > > > -Joseph > > > he just said that you shouln't top post (=place your message above the > original mail). > -- jsacco [at] gnome [dot] org From drago01 at gmail.com Tue Jun 5 17:16:03 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 05 Jun 2007 19:16:03 +0200 Subject: annoying syslog message from kernel In-Reply-To: <1181063361.3746.5.camel@rt.jesacco.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181060037.16089.30.camel@hades.cambridge.redhat.com> <1181060810.3746.0.camel@rt.jesacco.com> <1181061091.16089.32.camel@hades.cambridge.redhat.com> <1181063361.3746.5.camel@rt.jesacco.com> Message-ID: <46659A53.5040307@gmail.com> Joseph Sacco wrote: > David, > > My comments are not meant to be mean-spirited or hurtful. I don't go out > of my way to aggravate people so I don't understand your problem. > > Maybe we should take this off line. > > > -Joseph > he just said that you shouln't top post (=place your message above the original mail). From drago01 at gmail.com Tue Jun 5 17:27:01 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 05 Jun 2007 19:27:01 +0200 Subject: rawhide report: 20070605 changes In-Reply-To: References: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> <4665946A.3050308@gmail.com> Message-ID: <46659CE5.2020007@gmail.com> darrell pfeifer wrote: > On 6/5/07, dragoran wrote: >> darrell pfeifer wrote: >> >> wpa_supplicant-1:0.5.7-3.fc7 >> >> ---------------------------- >> >> * Mon Jun 04 2007 Dan Williams - 0.5.7-3 >> >> - Fix buffer overflow by removing syslog patch (#rh242455) >> >> >> > >> > wpa_supplicant dies with this version, which prevents >> > NetworkManager/wireless from working. >> have you also updated networkmanager? >> > > Yes. The machine is completely up to date from rawhide this morning. I > didn't check to see if NetworkManager has an update didn't make it in > to today's rawhide though. > thats weird: f7: http://koji.fedoraproject.org/koji/buildinfo?buildID=8015 f8: http://koji.fedoraproject.org/koji/buildinfo?buildID=7079 same version; different changelogs and dates... I don't know if the f7 version will work on rawhide (wireless-tools update) but you can try rebuilding the srpm From martin.sourada at seznam.cz Tue Jun 5 17:38:13 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 05 Jun 2007 19:38:13 +0200 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <46631F7C.2060209@redhat.com> References: <1180881734.3701.19.camel@pc-notebook> <4663062B.6010800@redhat.com> <1180900637.2946.6.camel@pc-notebook> <46631F7C.2060209@redhat.com> Message-ID: <1181065093.2916.7.camel@pc-notebook> On Sun, 2007-06-03 at 22:07 +0200, Christopher Aillon wrote: > And since Fedora's default GUI mail client, Evolution, supports GPG, I'd > probably recommend using that for now. Yes, I did mean XULRunner. > I therefore propose two possible solutions to this Package Review Request: 1. open new feature request (if not already opened) in bz for xulrunner and block the review by it. 2. accept the package into fedora and as soon as it is imported to bugzilla open new bug against it which could be either blocked by xulrunner feature request or just left OPEN until xulrunner is imported and thunderbird-enigmail patched against it. What do you {all} think about it? Which approach seems more reasonable to you? Or we should choose yet another one? Thanks your for comments, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From martin.sourada at seznam.cz Tue Jun 5 17:38:13 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 05 Jun 2007 19:38:13 +0200 Subject: PR: thunderbird-enigmail, building own thunderbird inside? In-Reply-To: <46631F7C.2060209@redhat.com> References: <1180881734.3701.19.camel@pc-notebook> <4663062B.6010800@redhat.com> <1180900637.2946.6.camel@pc-notebook> <46631F7C.2060209@redhat.com> Message-ID: <1181065093.2916.7.camel@pc-notebook> On Sun, 2007-06-03 at 22:07 +0200, Christopher Aillon wrote: > And since Fedora's default GUI mail client, Evolution, supports GPG, I'd > probably recommend using that for now. Yes, I did mean XULRunner. > I therefore propose two possible solutions to this Package Review Request: 1. open new feature request (if not already opened) in bz for xulrunner and block the review by it. 2. accept the package into fedora and as soon as it is imported to bugzilla open new bug against it which could be either blocked by xulrunner feature request or just left OPEN until xulrunner is imported and thunderbird-enigmail patched against it. What do you {all} think about it? Which approach seems more reasonable to you? Or we should choose yet another one? Thanks your for comments, Martin -------------- next part -------------- A non-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 Jun 5 18:15:35 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 05 Jun 2007 19:15:35 +0100 Subject: annoying syslog message from kernel In-Reply-To: <1181063361.3746.5.camel@rt.jesacco.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181060037.16089.30.camel@hades.cambridge.redhat.com> <1181060810.3746.0.camel@rt.jesacco.com> <1181061091.16089.32.camel@hades.cambridge.redhat.com> <1181063361.3746.5.camel@rt.jesacco.com> Message-ID: <1181067335.25232.396.camel@pmac.infradead.org> On Tue, 2007-06-05 at 13:09 -0400, Joseph Sacco wrote: > My comments are not meant to be mean-spirited or hurtful. Your comments are neither mean-spirited nor hurtful. They're just in the wrong place :) -- dwmw2 From wwoods at redhat.com Tue Jun 5 18:17:51 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 05 Jun 2007 18:17:51 +0000 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <200706051140.55877.jkeating@redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> Message-ID: <1181067471.14114.2.camel@metroid.rdu.redhat.com> On Tue, 2007-06-05 at 11:40 -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 11:32:30 Will Woods wrote: > > 1. download new repo info > > 2. download all new packages > > 0. boot into installer > > 3. upgrade all new packages > > 4. reboot into new system > > > > So now we spend a minimal amount of time in the installer, *and* the > > upgrade is fully automatic, *and* we're still doing upgrades The Right > > Way. > > > > Does this sound like a reasonable plan of attack? > > Oft times you need the new yum / rpm to appropriately depsolve what is needed > for "all the new packages" or maybe even to process the repo info at some > point. Good point. That's something we'll need to remember if we go forward with this. Luckily yum/rpm/etc. can be fetched and used without needing to boot into the installer environment. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue Jun 5 18:20:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 5 Jun 2007 14:20:55 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181067471.14114.2.camel@metroid.rdu.redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> Message-ID: <20070605182055.GB22587@nostromo.devel.redhat.com> Will Woods (wwoods at redhat.com) said: > Good point. That's something we'll need to remember if we go forward > with this. Luckily yum/rpm/etc. can be fetched and used without needing > to boot into the installer environment. *cough* python abi changes *cough* Bill From ben.lewis at benl.co.uk Tue Jun 5 18:29:48 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Tue, 05 Jun 2007 19:29:48 +0100 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <20070605182055.GB22587@nostromo.devel.redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> Message-ID: <4665AB9C.5080806@benl.co.uk> Bill Nottingham wrote: > Will Woods (wwoods at redhat.com) said: > >> Good point. That's something we'll need to remember if we go forward >> with this. Luckily yum/rpm/etc. can be fetched and used without needing >> to boot into the installer environment. >> > > *cough* python abi changes *cough* > > Bill > > Pull python as well, or is that _too_ simple? -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Tue Jun 5 18:30:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 5 Jun 2007 14:30:02 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <4665AB9C.5080806@benl.co.uk> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> Message-ID: <20070605183002.GE22587@nostromo.devel.redhat.com> Benjamin Lewis (ben.lewis at benl.co.uk) said: > >> Good point. That's something we'll need to remember if we go forward > >> with this. Luckily yum/rpm/etc. can be fetched and used without needing > >> to boot into the installer environment. > > > > *cough* python abi changes *cough* > > Pull python as well, or is that _too_ simple? At that point you're upgrading a sizable portion of your distro before you actually start the updater. Bill From sundaram at fedoraproject.org Tue Jun 5 18:34:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 00:04:09 +0530 Subject: vde2 - package submission [revised spec] In-Reply-To: <466573EA.7050504@verizon.net> References: <466573EA.7050504@verizon.net> Message-ID: <4665ACA1.6060308@fedoraproject.org> Gerry Reno wrote: > I have been wanting to see a VDE2 package for Fedora for a while now > and so I took a little time to write a spec file for it. I have used it > to build fc6 i386 (my platform) RPMS/SRPM. Not sure if the fedora-devel > list is where I should submit these but I would like to contribute these > to Fedora as I think in light of increased QEMU usage that this would be > of interest to the general community and is a good candidate for having > it included in Fedora directly. Please follow the steps outlined in http://fedoraproject.org/wiki/PackageMaintainers/Join. Rahul From jwilson at redhat.com Tue Jun 5 18:48:01 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 05 Jun 2007 14:48:01 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <200706050650.17730.jkeating@redhat.com> <466567E8.3040506@redhat.com> Message-ID: <4665AFE1.3090509@redhat.com> Tony Nelson wrote: > At 9:40 AM -0400 6/5/07, Jarod Wilson wrote: >> Tony Nelson wrote: >> I'd just use F7 to build >> CDs, get the posted somewhere, and get a torrent going. > > Yes, please do! Many people who need to install from CDs will thank you > for that! I wasn't actually offering, I was suggesting how *you* could do it. :) Seriously though, install mock on FC6, then create an F7 mock chroot. Then follow the docs on the pungi site on how to run pungi in a mock chroot. You'll be running the F7 pungi in an F7 chroot, and things should then work fine. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From katzj at redhat.com Tue Jun 5 19:24:12 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Jun 2007 15:24:12 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <20070605183002.GE22587@nostromo.devel.redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> Message-ID: <1181071452.6746.18.camel@aglarond.local> On Tue, 2007-06-05 at 14:30 -0400, Bill Nottingham wrote: > Benjamin Lewis (ben.lewis at benl.co.uk) said: > > >> Good point. That's something we'll need to remember if we go forward > > >> with this. Luckily yum/rpm/etc. can be fetched and used without needing > > >> to boot into the installer environment. > > > > > > *cough* python abi changes *cough* > > > > Pull python as well, or is that _too_ simple? > > At that point you're upgrading a sizable portion of your distro before > you actually start the updater. Especially if new python is built against new glibc which has new features. Jeremy From redhat at olen.net Tue Jun 5 19:42:10 2007 From: redhat at olen.net (Ola Thoresen) Date: Tue, 05 Jun 2007 21:42:10 +0200 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181067471.14114.2.camel@metroid.rdu.redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> Message-ID: <4665BC92.1040404@olen.net> Will Woods wrote: > On Tue, 2007-06-05 at 11:40 -0400, Jesse Keating wrote: > >> On Tuesday 05 June 2007 11:32:30 Will Woods wrote: >> >>> 1. download new repo info >>> 2. download all new packages >>> 0. boot into installer >>> 3. upgrade all new packages >>> 4. reboot into new system >>> >>> So now we spend a minimal amount of time in the installer, *and* the >>> upgrade is fully automatic, *and* we're still doing upgrades The Right >>> Way. >>> >>> Does this sound like a reasonable plan of attack? >>> >> Oft times you need the new yum / rpm to appropriately depsolve what is needed >> for "all the new packages" or maybe even to process the repo info at some >> point. >> > > Good point. That's something we'll need to remember if we go forward > with this. Luckily yum/rpm/etc. can be fetched and used without needing > to boot into the installer environment. > I guess the main issue is to spend as little time as possible inside the installer (to minimize downtime), so if a sizeable portion of the needed rpms can be prefetched before the boot into the installer, we have (probably) still saved quite a lot of time. It will be better than the current situation even if we still need to rerun the depsolving, and maybe download some more packages after the installation has started. I'd still like to have an option to have a break before "0", so I can start the process on a remote machine, and then let it do all the downloading, and just be on site for the actual install (0, 3, 4). Rgds. -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From walters at redhat.com Tue Jun 5 19:04:52 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 05 Jun 2007 15:04:52 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <20070605183002.GE22587@nostromo.devel.redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> Message-ID: <1181070292.3939.3.camel@neutron.verbum.private> On Tue, 2007-06-05 at 14:30 -0400, Bill Nottingham wrote: > At that point you're upgrading a sizable portion of your distro before > you actually start the updater. What if the upgrader tool was actually a self-contained very small Fedora image with glibc, python, yum, etc.? Then the upgrader could chroot into it. Alternatively, couldn't yum and sublibraries just be rebuilt against the earlier Fedora? If you disallowed the yum stack from using new python features that should work. From greno at verizon.net Tue Jun 5 20:03:51 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 05 Jun 2007 16:03:51 -0400 Subject: x86_64: kernel coredumps while init is starting udev In-Reply-To: <74f1adae3a890ec320ab6b14c62eb7fc@afm-koeln.de> References: <74f1adae3a890ec320ab6b14c62eb7fc@afm-koeln.de> Message-ID: <4665C1A7.3030408@verizon.net> P. Martinez wrote: > I have already done a bug report. I just want to ask > if some one have also this? > > Thanks > > P.M. > >> Description of problem: >> >> - I installed FC7 freshly. I choosed an xen kernel etc. >> Hardware is an Dell optiplex 740 (AhtlonX2 / SATA etc.) >> >> After installation i noticed that the normal kernel was >> also installed. I rebooted the machine. >> >> - Kernel core dumps on booting . >> >> Normal kprintf-message are shown. >> >> than init starts : >> >> i see the "fedora welcome" string >> i also see "press I for interactive mode" etc. >> >> shortly after this, kernel core dumps. >> >> i can read something about >> >> "Process (udevd pid 496 , threadinfo etc. pp." >> >> >> Notice: I can boot the kernel-xen !! >> >> >> Version-Release number of selected component (if applicable): >> >> kernel-headers-2.6.21-1.3194.fc7 >> kernel-xen-2.6.20-2925.9.fc7 >> kernel-2.6.21-1.3194.fc7 >> >> How reproducible: >> >> Everytime >> >> Steps to Reproduce: >> >> Reboot the system and boot kernel-2.6.21-1.3194.fc7 >> on a x86_64 machine (my is a dell optiplex 740) >> >> Actual results: >> >> Coredumps while init is starting udev >> >> Expected results: >> >> booting nicely >> >> Additional info: >> >> I can boot the kernel-xen !! > I am also having a boot crash with 2.6.20 kernels on x86. Here is the bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234283 Mine is occuring right when nash runs. It may not be related to what you are seeing but then again it might. Gerry From katzj at redhat.com Tue Jun 5 20:38:02 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Jun 2007 16:38:02 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181070292.3939.3.camel@neutron.verbum.private> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> Message-ID: <1181075882.14383.27.camel@aglarond.local> On Tue, 2007-06-05 at 15:04 -0400, Colin Walters wrote: > On Tue, 2007-06-05 at 14:30 -0400, Bill Nottingham wrote: > > At that point you're upgrading a sizable portion of your distro before > > you actually start the updater. > > What if the upgrader tool was actually a self-contained very small > Fedora image with glibc, python, yum, etc.? Then the upgrader could > chroot into it. Funny, you just described the installer second stage :-) > Alternatively, couldn't yum and sublibraries just be rebuilt against the > earlier Fedora? If you disallowed the yum stack from using new python > features that should work. While we're at it, can we disallow GUI apps from using new GTK features? ;-) More seriously, adding restrictions like this doesn't really help us to improve things for our userbase because we either end up having to reimplement things that appear for the language or do weird hoop-jumping. Jeremy From bernie at codewiz.org Tue Jun 5 20:52:49 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 16:52:49 -0400 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <1180991009.9788.99.camel@erebor.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> <1180991009.9788.99.camel@erebor.boston.redhat.com> Message-ID: <4665CD21.70800@codewiz.org> Jeremy Katz wrote: > It's more like 40. Or 60. Because doing it by region doesn't really > help much -- languages are spoken across regions and trying to pigeon > hole them like that just doesn't work. Times however many packages this > is done for. It gets big _fast_. How about just 1? We make package foo and foo-locale with all locales. Space constrained embedded users and lovers of the C locale would not install them. My mother language is Italian, but I know few users who actually *like* to use Linux with LANG=it. The shell is an English/POSIX environment. Any mixture of it with other languages is actually going to reduce usability for advanced users. And novices usually don't go in the console. Anyway, not a big deal for embedded developers: we could also solve it by setting %_netsharedpath /usr/share/locale in .rpmmacros. > You end up having to track more copies of, eg, changelog data and other > things that are "common" across a src.rpm set. And yes, that's pretty > costly. I always wondered why we never trim or rotate them at some point. We're not running a museum. Full history may be useful for CVS, but for the RPMs we ship, 2-3 years should be a good compromise. > We used to set it. And then people asked how to add support for a > language after the install. And the answer was basically "you can't". > So we don't do that anymore. I'd be open to having a way of setting it > from, eg, kickstart which is much more likely to be being used in these > sorts of "small footprint" situations. AFAIK, MacOSX's installer does that too. And I don't think they have a way to add language support later. Actually, It seems they only made the "install" part easy, as I've not yet understood how to uninstall packages on OSX ;-) > deltarpms work by taking the bits you have on disk + the deltarpm and > combining them to recreate the update rpm. If you've opted not to put > some of those bits on the disk, then it can't recreate the update RPM. If deltas were done on a file by file basis, it would work even with partial installs. How did SuSE address these issues? Anyone knows if they are still using deltarpms in OpenSuSE? -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From kevin.kofler at chello.at Tue Jun 5 20:56:45 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 5 Jun 2007 20:56:45 +0000 (UTC) Subject: Feature idea: package an installer image as a grub entry before F8. References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> Message-ID: Colin Walters redhat.com> writes: > Alternatively, couldn't yum and sublibraries just be rebuilt against the > earlier Fedora? If you disallowed the yum stack from using new python > features that should work. Or we could just use APT-RPM and stop worrying about Python. ;-) Kevin Kofler From nando at ccrma.Stanford.EDU Tue Jun 5 20:59:46 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 05 Jun 2007 13:59:46 -0700 Subject: fc7 i386, yum and explicit dependencies Message-ID: <1181077186.32138.24.camel@cmn3.stanford.edu> Hi all... I must be missing something obvious or I have not noticed this behavior before... I'm in the process of building a bunch of packages for fedora 7 and tried installing them on a brand new i386 install through a meta package (ie: a package that only contains explicit dependencies using Requires: and installs all required packages as a side effect). There _are_ packages missing but yum happily goes ahead and installs the meta package and the dependencies it can find, and ignores the missing dependencies! Is this expected behavior?? A "package-cleanup --problems" does show the missing dependencies. How can yum install something which does not have its dependencies met? It seems to me like a very very basic bug in yum... -- Fernando From bernie at codewiz.org Tue Jun 5 21:02:20 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 17:02:20 -0400 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <20070604211111.GJ4033@devserv.devel.redhat.com> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> <20070604211111.GJ4033@devserv.devel.redhat.com> Message-ID: <4665CF5C.3090104@codewiz.org> Jakub Jelinek wrote: > The only large thing about glibc-common is /usr/lib/locale/locale-archive > (~ 80MB) and that would be a terribly bad idea to split it up, > as many locales in that archive share the bigger data files, so if > you split it up, it will only occupy many times more disk space. > Unlike FC6 which duplicated the locales (there were /usr/lib/locale/*_* > subdirectories and the same content packed in > /usr/lib/locale/locale-archive, so it occupied ~ 160MB), in F7 it occupies > only half of the FC6 size. I did not notice this nice change, but it's good to know! Nevertheless, could we add a glibc-locale for it? Things like the OLPC would most likely drop it. > In OLPC or on boxes you know you will never need anything but a few > selected locales you can set %_install_langs, e.g. from kickstart. Exactly. I think what we're doing now is more crude, but equally effective. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From drago01 at gmail.com Tue Jun 5 21:04:22 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 05 Jun 2007 23:04:22 +0200 Subject: annoying syslog message from kernel In-Reply-To: <1181064209.3746.10.camel@rt.jesacco.com> References: <1180961190.2822.4.camel@rt.jesacco.com> <1181048592.8779.6.camel@rt.jesacco.com> <1181060037.16089.30.camel@hades.cambridge.redhat.com> <1181060810.3746.0.camel@rt.jesacco.com> <1181061091.16089.32.camel@hades.cambridge.redhat.com> <1181063361.3746.5.camel@rt.jesacco.com> <46659A53.5040307@gmail.com> <1181064209.3746.10.camel@rt.jesacco.com> Message-ID: <4665CFD6.5070100@gmail.com> Joseph Sacco wrote: > Oh... Posting protocol... Sorry for the misunderstanding. > > > Be well, > > > -Joseph > you did it again :) write your comments under the quotes like I did now ;) From walters at redhat.com Tue Jun 5 21:10:21 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 05 Jun 2007 17:10:21 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181075882.14383.27.camel@aglarond.local> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> <1181075882.14383.27.camel@aglarond.local> Message-ID: <1181077821.2914.10.camel@neutron.verbum.private> On Tue, 2007-06-05 at 16:38 -0400, Jeremy Katz wrote: > On Tue, 2007-06-05 at 15:04 -0400, Colin Walters wrote: > > On Tue, 2007-06-05 at 14:30 -0400, Bill Nottingham wrote: > > > At that point you're upgrading a sizable portion of your distro > before > > > you actually start the updater. > > > > What if the upgrader tool was actually a self-contained very small > > Fedora image with glibc, python, yum, etc.? Then the upgrader could > > chroot into it. > > Funny, you just described the installer second stage :-) Right; so we know it would work =) Though obviously it is a bit more painful technically which leads to: > While we're at it, can we disallow GUI apps from using new GTK > features? ;-) More seriously, adding restrictions like this doesn't > really help us to improve things for our userbase because we either end > up having to reimplement things that appear for the language or do weird > hoop-jumping. Are we just talking about Python or are there more problematic things? Would it really be so bad to be fixed at Python 2.4? What's so hard to reimplement from Python 2.5 features? From http://www.python.org/download/releases/2.5/highlights/ I don't see much. From martin.sourada at seznam.cz Tue Jun 5 21:10:43 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 05 Jun 2007 23:10:43 +0200 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <1181077186.32138.24.camel@cmn3.stanford.edu> References: <1181077186.32138.24.camel@cmn3.stanford.edu> Message-ID: <1181077843.3072.8.camel@pc-notebook> On Tue, 2007-06-05 at 22:59 +0200, Fernando Lopez-Lezcano wrote: > Hi all... I must be missing something obvious or I have not noticed this > behavior before... > > I'm in the process of building a bunch of packages for fedora 7 and > tried installing them on a brand new i386 install through a meta package > (ie: a package that only contains explicit dependencies using Requires: > and installs all required packages as a side effect). There _are_ > packages missing but yum happily goes ahead and installs the meta > package and the dependencies it can find, and ignores the missing > dependencies! Is this expected behavior?? > > A "package-cleanup --problems" does show the missing dependencies. How > can yum install something which does not have its dependencies met? It > seems to me like a very very basic bug in yum... > > -- Fernando > > Does this happen in CLi or in the gui frontend? I installed several packages throught the gui short after the install and it missed even deps that were in the repos. However, recently I attempted to do "yum update", which failed due to firefox, so I did "yum --exclude=firefox update", which again failed, because some packages that wanted update needed newer firefox. What was however my shock, when I did "yum --exclude firefox update": it updated all packages that had deps on newer firefox, and updated firefox-devel. That broke my epiphany, as it was updated against newer firefox, whilst epiphany-extensions was still for older one and installed firefox was the older one. Luckily I fixed it by running "yum --enablerepo=updates-testing update firefox" which updated all the rest of packages depending on old firefox and firefox itself. I too wonder whether this behaviour is expected, or whether is it a bug. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Tue Jun 5 21:20:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Jun 2007 17:20:51 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181077821.2914.10.camel@neutron.verbum.private> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> <1181075882.14383.27.camel@aglarond.local> <1181077821.2914.10.camel@neutron.verbum.private> Message-ID: <1181078451.14383.50.camel@aglarond.local> On Tue, 2007-06-05 at 17:10 -0400, Colin Walters wrote: > On Tue, 2007-06-05 at 16:38 -0400, Jeremy Katz wrote: > > While we're at it, can we disallow GUI apps from using new GTK > > features? ;-) More seriously, adding restrictions like this doesn't > > really help us to improve things for our userbase because we either end > > up having to reimplement things that appear for the language or do weird > > hoop-jumping. > > Are we just talking about Python or are there more problematic things? > Would it really be so bad to be fixed at Python 2.4? What's so hard to > reimplement from Python 2.5 features? From > http://www.python.org/download/releases/2.5/highlights/ > I don't see much. We actually already have a fair bit of pain to keep yum 3.2 working with python 2.4 and 2.5. Things like the integration of cElementTree and pysqlite both led to API changes that we're carrying compatibility cruft for. The former isn't too bad. The latter regularly makes me want to stab myself repeatedly in the eyes. We're not taking advantage of the new try/except/finally bits which actually hurts quite a bit -- and just trying to emulate or reimplement it _doesn't_ work nearly as well. And even if there wasn't _anything_ in the python 2.4 -> 2.5 transition, that doesn't mean that there hasn't been in the past and won't be in the future. Why would we want to tie the hands of a project like that? And don't forget -- it's not necessarily just python... it could be anything else that we depend on. rpm-python/rpm being high on the list of probables. Jeremy From cweyl at alumni.drew.edu Tue Jun 5 21:46:16 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 5 Jun 2007 14:46:16 -0700 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> Message-ID: <7dd7ab490706051446i1ba125b4hfab6db6e70750a71@mail.gmail.com> On 6/5/07, Kevin Kofler wrote: > Colin Walters redhat.com> writes: > > Alternatively, couldn't yum and sublibraries just be rebuilt against the > > earlier Fedora? If you disallowed the yum stack from using new python > > features that should work. > > Or we could just use APT-RPM and stop worrying about Python. ;-) I've used the apt-get dist-upgrade scenarios you described in another email for quite some time now, across several machines. One such machine sits under a desk 3,000mi away from me now, and has been upgraded this way since FC-1 :) -Chris -- Chris Weyl Ex astris, scientia From walters at redhat.com Tue Jun 5 22:02:49 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 05 Jun 2007 18:02:49 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181078451.14383.50.camel@aglarond.local> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> <1181075882.14383.27.camel@aglarond.local> <1181077821.2914.10.camel@neutron.verbum.private> <1181078451.14383.50.camel@aglarond.local> Message-ID: <1181080969.2914.29.camel@neutron.verbum.private> On Tue, 2007-06-05 at 17:20 -0400, Jeremy Katz wrote: > And even if there wasn't _anything_ in the python 2.4 -> 2.5 transition, > that doesn't mean that there hasn't been in the past and won't be in the > future. Why would we want to tie the hands of a project like that? I was thinking the stack would just be one (Fedora) release back, not forever stuck. In other words you couldn't directly upgrade FC4->FC6. If we made upgrades easy and reliable enough, there would likely be a lot fewer people who cared about skipping versions. But let's assume given your argument and the above that we would need to take the full image approach. It seems that the storyboard architecture would look like: o during development, fedora-upgrader-tool is built containing a base image with shell,glibc,python,yum, etc., similar to anaconda. o fedora released o pirut notices new major upgrade available - executes bittorrent to download fedora-upgrader-tool image or just http download depending on how big the thing is o fedora-upgrader-tool is invoked by pirut o fedora-upgrader-tool loopback mounts /var/lib/fedora-upgrade.img on /var/lib/fedora-upgrade-root, then: - copies the current package list into the root, and executes yum on it? Don't know the lowlevel details here, but the idea is to download all the packages that are necessary for an upgrade * One possible optimization is to bittorrent a base image of the RPMS basically everyone has installed, then yum http download the rest o fedora-upgrader-tool notifies desktop session major upgrade is available, offers reboot o grub.conf modified as appropriate, and things proceed as Will outlined From katzj at redhat.com Tue Jun 5 22:01:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Jun 2007 18:01:07 -0400 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <4665CD21.70800@codewiz.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> <1180991009.9788.99.camel@erebor.boston.redhat.com> <4665CD21.70800@codewiz.org> Message-ID: <1181080867.14383.73.camel@aglarond.local> On Tue, 2007-06-05 at 16:52 -0400, Bernardo Innocenti wrote: > Jeremy Katz wrote: > > It's more like 40. Or 60. Because doing it by region doesn't really > > help much -- languages are spoken across regions and trying to pigeon > > hole them like that just doesn't work. Times however many packages this > > is done for. It gets big _fast_. > > How about just 1? We make package foo and foo-locale with all > locales. > > Space constrained embedded users and lovers of the C locale > would not install them. My mother language is Italian, but I > know few users who actually *like* to use Linux with LANG=it. > The shell is an English/POSIX environment. Any mixture of it > with other languages is actually going to reduce usability for > advanced users. And novices usually don't go in the console. This is an incredibly Western-world-centric view of things that goes over extremely poorly in many other countries. > Anyway, not a big deal for embedded developers: we could > also solve it by setting %_netsharedpath /usr/share/locale > in .rpmmacros. > > > You end up having to track more copies of, eg, changelog data and other > > things that are "common" across a src.rpm set. And yes, that's pretty > > costly. > > I always wondered why we never trim or rotate them at some > point. We're not running a museum. Full history may be > useful for CVS, but for the RPMs we ship, 2-3 years should > be a good compromise. Sure, but 2-3 years can still be a lot of data. > > We used to set it. And then people asked how to add support for a > > language after the install. And the answer was basically "you can't". > > So we don't do that anymore. I'd be open to having a way of setting it > > from, eg, kickstart which is much more likely to be being used in these > > sorts of "small footprint" situations. > > AFAIK, MacOSX's installer does that too. And I don't think > they have a way to add language support later. Actually, > It seems they only made the "install" part easy, as I've > not yet understood how to uninstall packages on OSX ;-) Adding language support later was a very common request. I still see questions about it now that it's relatively easy... at least now, I can give an easy answer ;-) > > deltarpms work by taking the bits you have on disk + the deltarpm and > > combining them to recreate the update rpm. If you've opted not to put > > some of those bits on the disk, then it can't recreate the update RPM. > > If deltas were done on a file by file basis, it would work > even with partial installs. Within the deltarpm, things are done on a file by file basis. But you use the delta + bits on disk to reconstruct the "new" rpm. And then verify it. The idea being that you can then just update the rpm as though you had downloaded the whole thing. Before doing deltarpms, there was a concept called patch rpms which was more "apply the deltas to the files that are there, cross your fingers and hope really hard" ;) That's been abandoned by the SuSE guys in favor of deltarpm because it led to all kinds of problems for them. > How did SuSE address these issues? Anyone knows if they are > still using deltarpms in OpenSuSE? They do. But they also don't support partial installs along these lines. Or at least, if they do, they don't then support using deltarpms later Jeremy From notting at redhat.com Tue Jun 5 22:04:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 5 Jun 2007 18:04:42 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181080969.2914.29.camel@neutron.verbum.private> References: <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> <1181075882.14383.27.camel@aglarond.local> <1181077821.2914.10.camel@neutron.verbum.private> <1181078451.14383.50.camel@aglarond.local> <1181080969.2914.29.camel@neutron.verbum.private> Message-ID: <20070605220442.GA25582@nostromo.devel.redhat.com> Colin Walters (walters at redhat.com) said: > On Tue, 2007-06-05 at 17:20 -0400, Jeremy Katz wrote: > > > And even if there wasn't _anything_ in the python 2.4 -> 2.5 transition, > > that doesn't mean that there hasn't been in the past and won't be in the > > future. Why would we want to tie the hands of a project like that? > > I was thinking the stack would just be one (Fedora) release back, not > forever stuck. In other words you couldn't directly upgrade FC4->FC6. > If we made upgrades easy and reliable enough, there would likely be a > lot fewer people who cared about skipping versions. But it *is* already fairly easy and reliable. Heck, I did a FC5->F7 upgrade last week that worked fine. I think some of it is that we've intentionally steered people away from it when it's really not *that* bad. Bill From katzj at redhat.com Tue Jun 5 22:06:39 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 05 Jun 2007 18:06:39 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <1181080969.2914.29.camel@neutron.verbum.private> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180725932.31759.9.camel@rivendell> <1181057550.18981.67.camel@metroid.rdu.redhat.com> <200706051140.55877.jkeating@redhat.com> <1181067471.14114.2.camel@metroid.rdu.redhat.com> <20070605182055.GB22587@nostromo.devel.redhat.com> <4665AB9C.5080806@benl.co.uk> <20070605183002.GE22587@nostromo.devel.redhat.com> <1181070292.3939.3.camel@neutron.verbum.private> <1181075882.14383.27.camel@aglarond.local> <1181077821.2914.10.camel@neutron.verbum.private> <1181078451.14383.50.camel@aglarond.local> <1181080969.2914.29.camel@neutron.verbum.private> Message-ID: <1181081199.14383.80.camel@aglarond.local> On Tue, 2007-06-05 at 18:02 -0400, Colin Walters wrote: > But let's assume given your argument and the above that we would need to > take the full image approach. It seems that the storyboard architecture > would look like: Pretty much. The "how you discover what packages are necessary to be upgraded" is really the tricky part. You might just want to make a copy of the rpmdb into the magic chroot and then use it as opposed to anything more direct. Then the other big question is where do you store how ever big the size of the updates is, but you could even be clever and do things like asking if you want to store them on like an ipod and then be able to discover the store of packages being there. Jeremy From rdieter at math.unl.edu Tue Jun 5 22:50:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Jun 2007 17:50:16 -0500 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <1181077186.32138.24.camel@cmn3.stanford.edu> References: <1181077186.32138.24.camel@cmn3.stanford.edu> Message-ID: Fernando Lopez-Lezcano wrote: > There _are_ > packages missing but yum happily goes ahead and installs the meta > package and the dependencies it can find, and ignores the missing > dependencies! Is this expected behavior?? No. Concrete example(s)? -- Rex From nando at ccrma.Stanford.EDU Tue Jun 5 22:30:51 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 05 Jun 2007 15:30:51 -0700 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <1181077843.3072.8.camel@pc-notebook> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <1181077843.3072.8.camel@pc-notebook> Message-ID: <1181082651.32138.27.camel@cmn3.stanford.edu> On Tue, 2007-06-05 at 23:10 +0200, Martin Sourada wrote: > On Tue, 2007-06-05 at 22:59 +0200, Fernando Lopez-Lezcano wrote: > > Hi all... I must be missing something obvious or I have not noticed this > > behavior before... > > > > I'm in the process of building a bunch of packages for fedora 7 and > > tried installing them on a brand new i386 install through a meta package > > (ie: a package that only contains explicit dependencies using Requires: > > and installs all required packages as a side effect). There _are_ > > packages missing but yum happily goes ahead and installs the meta > > package and the dependencies it can find, and ignores the missing > > dependencies! Is this expected behavior?? > > > > A "package-cleanup --problems" does show the missing dependencies. How > > can yum install something which does not have its dependencies met? It > > seems to me like a very very basic bug in yum... > > Does this happen in CLi or in the gui frontend? This is happening with a plain simple command line yum invocation... yum install package_name That's it... > I installed several > packages throught the gui short after the install and it missed even > deps that were in the repos. However, recently I attempted to do "yum > update", which failed due to firefox, so I did "yum --exclude=firefox > update", which again failed, because some packages that wanted update > needed newer firefox. What was however my shock, when I did "yum > --exclude firefox update": it updated all packages that had deps on > newer firefox, and updated firefox-devel. That broke my epiphany, as it > was updated against newer firefox, whilst epiphany-extensions was still > for older one and installed firefox was the older one. Luckily I fixed > it by running "yum --enablerepo=updates-testing update firefox" which > updated all the rest of packages depending on old firefox and firefox > itself. > > I too wonder whether this behaviour is expected, or whether is it a bug. Sounds like a bug to me... -- Fernando From bernie at codewiz.org Tue Jun 5 22:45:09 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 18:45:09 -0400 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <1181080867.14383.73.camel@aglarond.local> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> <1180991009.9788.99.camel@erebor.boston.redhat.com> <4665CD21.70800@codewiz.org> <1181080867.14383.73.camel@aglarond.local> Message-ID: <4665E775.1090901@codewiz.org> Jeremy Katz wrote: > This is an incredibly Western-world-centric view of things that goes > over extremely poorly in many other countries. If even the Italians can learn to read English, than anybody can! Ok, seriously: I claim that the language problem is *not* solved by translating error messages only. What about man pages? And filenames? And command names? Those partial translations are only going to make things worse, because you need to make a guess to relate the output with the input in many cases. MS-DOS in Italian was real fun: on some errors, it would print: "(A)nnulla, (R)iprova, (T)ralascia". The first two translate to the familiar (C)ancel and (R)etry. The latter word means something like "Don't bother", and I never got to understand what it does :-) > Adding language support later was a very common request. I still see > questions about it now that it's relatively easy... at least now, I can > give an easy answer ;-) Isn't it as easy as doing "rpm --replacepkgs -F *.rpm" from the Fedora/ directory? > They do. But they also don't support partial installs along these > lines. Or at least, if they do, they don't then support using deltarpms > later You convinced me that it's so impractical that it's not worth offering. Anyway, if I compare what we offer with what the other OSes do, we still give quite a lot of flexibility to the user. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From bernie at codewiz.org Tue Jun 5 22:51:46 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 18:51:46 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070605065813.GA5736@free.fr> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> Message-ID: <4665E902.8010106@codewiz.org> Patrice Dumas wrote: > On Mon, Jun 04, 2007 at 10:52:41PM -0400, Bernardo Innocenti wrote: > >> - /sbin/ldconfig (yes, even this one!) > > I am not sure, but wouldn't that be a bit dangerous? What would be the > gains? Space. And speed. What would be the loss? A broken environment where only ldconfig works, with no shell and no init, is still unusable for recovery. Boot DVDs and USB pens are more user friendly and flexible in these cases. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From alan at redhat.com Tue Jun 5 23:04:38 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 5 Jun 2007 19:04:38 -0400 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <4665E775.1090901@codewiz.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> <1180991009.9788.99.camel@erebor.boston.redhat.com> <4665CD21.70800@codewiz.org> <1181080867.14383.73.camel@aglarond.local> <4665E775.1090901@codewiz.org> Message-ID: <20070605230438.GD29877@devserv.devel.redhat.com> On Tue, Jun 05, 2007 at 06:45:09PM -0400, Bernardo Innocenti wrote: > Ok, seriously: I claim that the language problem is *not* solved > by translating error messages only. What about man pages? > And filenames? And command names? Why not - command names is trickier because of the compat issues but only on a command line. Lots of stuff has full translations. From dr.diesel at gmail.com Tue Jun 5 23:17:06 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 5 Jun 2007 19:17:06 -0400 Subject: Kernel recommendation without the F7 network issue? Message-ID: <2a28d2ab0706051617p51e2a6e6gfda8e00437c0e0e8@mail.gmail.com> Any suggestions for a Kernel to drop back to till the F7 Network issue is resolved? Perhaps the F7T4 Kernel? Thanks Andy From bernie at codewiz.org Tue Jun 5 23:24:23 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 19:24:23 -0400 Subject: Using --excludedocs and --excludepath with yum In-Reply-To: <1180965554.3406.0.camel@rivendell> References: <46638909.3090006@codewiz.org> <1180965554.3406.0.camel@rivendell> Message-ID: <4665F0A7.3050501@codewiz.org> seth vidal wrote: > Docs frequently include licenses. Are you sure you're allowed to do that > if you're redistributing the olpc image? IANAL. How do other embedded distribution address this problem? And, by the way, couldn't Fedora save space by just shipping a single copy of each licens, say, in basesystem? You can easily tell how they map to specific packages with rpm -qi. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From bernie at codewiz.org Tue Jun 5 23:34:30 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 19:34:30 -0400 Subject: Splitting the ncurses RPM In-Reply-To: <20070604120659.GA1483@localhost> References: <466385F1.8030005@codewiz.org> <20070604120659.GA1483@localhost> Message-ID: <4665F306.40609@codewiz.org> Miroslav Lichvar wrote: > But yes, most of the terminals descriptions could be moved to a > subpackage and add it to comps' core group so it's installed by > default. The base package would have only few selected descriptions > that are widely used. > > Would that be ok? It would be perfect, indeed! > I'm not sure about removing terminfo from default Fedora install, > Users can connect via ssh and use many different terminals. Then let's make the default choice broad enough to include any hardware or software terminals shipped with the last 10 years. I'm sure we could _still_ get rid of 95% of that junk. A safe bet could be taking what Debian is also shipping: Eterm Eterm-color -> Eterm ansi cons25 cygwin umb hurd linux mach mach-bold mach-color pcansi rxvt rxvt-basic rxvt-m -> rxvt-basic rxvt-unicode screen screen-bce screen-s screen-w sun vt100 vt102 vt220 vt52 wsvt25 wsvt25m xterm xterm-color xterm-debian xterm-mono xterm-r5 xterm-r6 xterm-vt220 xterm-xfree86 -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From bernie at codewiz.org Tue Jun 5 23:58:25 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 05 Jun 2007 19:58:25 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <1180970984.9788.32.camel@erebor.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <1180970984.9788.32.camel@erebor.boston.redhat.com> Message-ID: <4665F8A1.2030501@codewiz.org> Jeremy Katz wrote: > The problem is that if this were made optional, then they wouldn't be > guaranteed to be installed prior to the kernel which leads to big > problems with initrd creation in the kernel's %post. Heh, I didn't consider this problem... > Generally > speaking, this is a problem that could really do with some people > looking into a solution as it happens more and more... and the hacks are > not entirely ideal. Ideas to rpm-maint-list at rpm.org :) How does the "competition" handle it in the first place? I mean, dpkg, emerge, portage... >> - hal depends on cryptsetup-luks (containing bulky 1.2MB >> static binary in /sbin) > > cryptsetup-luks should drop its static binary and move libcryptsetup to > be in /%{_lib} instead of %{_libdir} Definitely. Who could do this? -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From tonynelson at georgeanelson.com Wed Jun 6 00:16:42 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 20:16:42 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: <4665AFE1.3090509@redhat.com> References: <200706050650.17730.jkeating@redhat.com> <466567E8.3040506@redhat.com> <4665AFE1.3090509@redhat.com> Message-ID: At 2:48 PM -0400 6/5/07, Jarod Wilson wrote: >Tony Nelson wrote: >> At 9:40 AM -0400 6/5/07, Jarod Wilson wrote: >>> Tony Nelson wrote: >>> I'd just use F7 to build >>> CDs, get the posted somewhere, and get a torrent going. >> >> Yes, please do! Many people who need to install from CDs will thank you >> for that! > >I wasn't actually offering, I was suggesting how *you* could do it. :) > >Seriously though, install mock on FC6, then create an F7 mock chroot. >Then follow the docs on the pungi site on how to run pungi in a mock >chroot. You'll be running the F7 pungi in an F7 chroot, and things >should then work fine. I'd think that only the most hard-core Fedora user would go to that much effort. Certainly I'm not going to do it just for fun. Anyone doing all this would need detailed step-by-step instructions, and it would be several times harder than just using Pungi alone. I'm also not sure what you mean by "instructions on the pungi site", as I didn't see any instructions, only a vague plan on how pungi might end up being written. -- ____________________________________________________________________ TonyN.:' ' From tonynelson at georgeanelson.com Wed Jun 6 00:26:34 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 5 Jun 2007 20:26:34 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <466567E8.3040506@redhat.com> <200706051039.32612.jkeating@redhat.com> Message-ID: At 7:04 PM +0200 6/5/07, Vnpenguin wrote: >On 6/5/07, Tony Nelson wrote: >> >> OK, too bad, no CDs for F7 from me then. >> >> Perhaps someone else will do it with jigdo. >> -- > >Just make One-CD version of F7 with pungi. ISO size is about 685MB >(Full Gnome desktop + Graphics + System tools) . Tested install on >VMware ok :) "Just make"? How? I need instructions, before I could do it and write the detailed step-by-step instructions that other users would need. Since the people who need CDs to install F7 probably won't have F7 installed, the instructions must work with only the DVD image. Also the instructions should tell them how to get the rest of the packages on the DVD if the Internet is not available at the machine they're installing / upgrading. >Sorry, I have NO bandwidth so I can not upload it. Gee, same here. I could upload it once, but if I were to host a Torrent it would be at a very very low speed until July, and very slow thereafter. I have "unlimited" DSL and don't want my account terminated. -- ____________________________________________________________________ TonyN.:' ' From nando at ccrma.Stanford.EDU Wed Jun 6 00:49:41 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 05 Jun 2007 17:49:41 -0700 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: References: <1181077186.32138.24.camel@cmn3.stanford.edu> Message-ID: <1181090981.32138.35.camel@cmn3.stanford.edu> On Tue, 2007-06-05 at 17:50 -0500, Rex Dieter wrote: > Fernando Lopez-Lezcano wrote: > > There _are_ > > packages missing but yum happily goes ahead and installs the meta > > package and the dependencies it can find, and ignores the missing > > dependencies! Is this expected behavior?? > > No. Concrete example(s)? It is a rather long install which I just reproduced. Erased all pertinent packages, then: > yum clean all (just in case) > yum install planetccrma-apps After the install goes through (181 packages, see the log in the first attachment to this email) I get this: ---- > package-cleanup --problems Setting up yum Reading local RPM database Processing all local requires Missing dependencies: Package planetccrma-apps requires avifile Package planetccrma-apps requires ayam Package planetccrma-apps requires bristol Package planetccrma-apps requires cinelerra Package planetccrma-apps requires cinepaint Package planetccrma-apps requires ecasound Package planetccrma-apps requires faust Package planetccrma-apps requires faust-pd Package planetccrma-apps requires faust-supercollider Package planetccrma-apps requires gmorgan Package planetccrma-apps requires hydrogen Package planetccrma-apps requires libecasoundc Package planetccrma-apps requires libfishsound Package planetccrma-apps requires libquicktime Package planetccrma-apps requires pd-creb Package planetccrma-apps requires pd-cxc Package planetccrma-apps requires pd-extended Package planetccrma-apps requires pd-fftease Package planetccrma-apps requires pd-flext Package planetccrma-apps requires pd-fluid Package planetccrma-apps requires pd-ggee Package planetccrma-apps requires pd-iemlib Package planetccrma-apps requires pd-syncgrain Package planetccrma-apps requires pd-vasp Package planetccrma-apps requires pd-zexy Package planetccrma-apps requires pyecasound Package planetccrma-apps requires rezound Package planetccrma-apps requires snd Package planetccrma-apps requires snd-motif Package planetccrma-apps requires snd-utils Package planetccrma-apps requires specimen Package planetccrma-apps requires swami Package planetccrma-apps requires tse3 Package hydrogen-drumkits requires hydrogen ---- At this point yum installed a meta package and did not install all the dependencies mentioned in the package. The first time I tried I got really surprised because I _knew_ there were a lot of things missing. If I then do: > rpm -e planetccrma-apps and then try again I get what should have happened in the first place: > yum install planetccrma-apps Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package planetccrma-apps.i386 0:2007.06.05-1.fc7.ccrma set to be updated --> Processing Dependency: libfishsound for package: planetccrma-apps --> Processing Dependency: tse3 for package: planetccrma-apps --> Processing Dependency: libquicktime for package: planetccrma-apps --> Processing Dependency: pd-fftease for package: planetccrma-apps --> Processing Dependency: pd-ggee for package: planetccrma-apps --> Processing Dependency: pd-creb for package: planetccrma-apps --> Processing Dependency: pd-fluid for package: planetccrma-apps --> Processing Dependency: pyecasound for package: planetccrma-apps --> Processing Dependency: pd-vasp for package: planetccrma-apps --> Processing Dependency: bristol for package: planetccrma-apps --> Processing Dependency: specimen for package: planetccrma-apps --> Processing Dependency: pd-flext for package: planetccrma-apps --> Processing Dependency: avifile for package: planetccrma-apps --> Processing Dependency: faust-supercollider for package: planetccrma-apps --> Processing Dependency: swami for package: planetccrma-apps --> Processing Dependency: pd-syncgrain for package: planetccrma-apps --> Processing Dependency: cinepaint for package: planetccrma-apps --> Processing Dependency: pd-cxc for package: planetccrma-apps --> Processing Dependency: ayam for package: planetccrma-apps --> Processing Dependency: ecasound for package: planetccrma-apps --> Processing Dependency: pd-iemlib for package: planetccrma-apps --> Processing Dependency: cinelerra for package: planetccrma-apps --> Processing Dependency: rezound for package: planetccrma-apps --> Processing Dependency: faust for package: planetccrma-apps --> Processing Dependency: snd-motif for package: planetccrma-apps --> Processing Dependency: snd for package: planetccrma-apps --> Processing Dependency: faust-pd for package: planetccrma-apps --> Processing Dependency: pd-zexy for package: planetccrma-apps --> Processing Dependency: gmorgan for package: planetccrma-apps --> Processing Dependency: libecasoundc for package: planetccrma-apps --> Processing Dependency: snd-utils for package: planetccrma-apps --> Processing Dependency: pd-extended for package: planetccrma-apps --> Processing Dependency: hydrogen for package: planetccrma-apps --> Finished Dependency Resolution Error: Missing Dependency: libfishsound is needed by package planetccrma-apps Error: Missing Dependency: tse3 is needed by package planetccrma-apps Error: Missing Dependency: libquicktime is needed by package planetccrma-apps Error: Missing Dependency: pd-fftease is needed by package planetccrma-apps Error: Missing Dependency: pd-ggee is needed by package planetccrma-apps Error: Missing Dependency: pd-creb is needed by package planetccrma-apps Error: Missing Dependency: pd-fluid is needed by package planetccrma-apps Error: Missing Dependency: pyecasound is needed by package planetccrma-apps Error: Missing Dependency: pd-vasp is needed by package planetccrma-apps Error: Missing Dependency: bristol is needed by package planetccrma-apps Error: Missing Dependency: specimen is needed by package planetccrma-apps Error: Missing Dependency: pd-flext is needed by package planetccrma-apps Error: Missing Dependency: avifile is needed by package planetccrma-apps Error: Missing Dependency: faust-supercollider is needed by package planetccrma-apps Error: Missing Dependency: swami is needed by package planetccrma-apps Error: Missing Dependency: pd-syncgrain is needed by package planetccrma-apps Error: Missing Dependency: cinepaint is needed by package planetccrma-apps Error: Missing Dependency: pd-cxc is needed by package planetccrma-apps Error: Missing Dependency: ayam is needed by package planetccrma-apps Error: Missing Dependency: ecasound is needed by package planetccrma-apps Error: Missing Dependency: pd-iemlib is needed by package planetccrma-apps Error: Missing Dependency: cinelerra is needed by package planetccrma-apps Error: Missing Dependency: rezound is needed by package planetccrma-apps Error: Missing Dependency: faust is needed by package planetccrma-apps Error: Missing Dependency: snd-motif is needed by package planetccrma-apps Error: Missing Dependency: snd is needed by package planetccrma-apps Error: Missing Dependency: faust-pd is needed by package planetccrma-apps Error: Missing Dependency: pd-zexy is needed by package planetccrma-apps Error: Missing Dependency: gmorgan is needed by package planetccrma-apps Error: Missing Dependency: libecasoundc is needed by package planetccrma-apps Error: Missing Dependency: snd-utils is needed by package planetccrma-apps Error: Missing Dependency: pd-extended is needed by package planetccrma-apps Error: Missing Dependency: hydrogen is needed by package planetccrma-apps -- Fernando -------------- next part -------------- Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package planetccrma-apps.i386 0:2007.06.05-1.fc7.ccrma set to be updated --> Processing Dependency: ladspa-devel for package: planetccrma-apps --> Processing Dependency: libfishsound for package: planetccrma-apps --> Processing Dependency: pd-fftease for package: planetccrma-apps --> Processing Dependency: pd-fluid for package: planetccrma-apps --> Processing Dependency: audacity for package: planetccrma-apps --> Processing Dependency: jamin for package: planetccrma-apps --> Processing Dependency: csound-jack for package: planetccrma-apps --> Processing Dependency: csound-fltk for package: planetccrma-apps --> Processing Dependency: lilypond for package: planetccrma-apps --> Processing Dependency: jaaa for package: planetccrma-apps --> Processing Dependency: faust-supercollider for package: planetccrma-apps --> Processing Dependency: qarecord for package: planetccrma-apps --> Processing Dependency: miniaudicle for package: planetccrma-apps --> Processing Dependency: pd-syncgrain for package: planetccrma-apps --> Processing Dependency: cinepaint for package: planetccrma-apps --> Processing Dependency: pd-cxc for package: planetccrma-apps --> Processing Dependency: pd-ggee for package: planetccrma-apps --> Processing Dependency: lash for package: planetccrma-apps --> Processing Dependency: liblrdf for package: planetccrma-apps --> Processing Dependency: chuck for package: planetccrma-apps --> Processing Dependency: juce for package: planetccrma-apps --> Processing Dependency: supercollider-world for package: planetccrma-apps --> Processing Dependency: csound-gui for package: planetccrma-apps --> Processing Dependency: fluidsynth for package: planetccrma-apps --> Processing Dependency: stk for package: planetccrma-apps --> Processing Dependency: lilypond-doc for package: planetccrma-apps --> Processing Dependency: ardour2 for package: planetccrma-apps --> Processing Dependency: hydrogen-drumkits for package: planetccrma-apps --> Processing Dependency: ladspa-cmt-plugins for package: planetccrma-apps --> Processing Dependency: seq24 for package: planetccrma-apps --> Processing Dependency: snd-utils for package: planetccrma-apps --> Processing Dependency: qsampler for package: planetccrma-apps --> Processing Dependency: meterbridge for package: planetccrma-apps --> Processing Dependency: muse for package: planetccrma-apps --> Processing Dependency: pd-extended for package: planetccrma-apps --> Processing Dependency: ladspa-fil-plugins for package: planetccrma-apps --> Processing Dependency: tse3 for package: planetccrma-apps --> Processing Dependency: libquicktime for package: planetccrma-apps --> Processing Dependency: pd-creb for package: planetccrma-apps --> Processing Dependency: ladspa-rev-plugins for package: planetccrma-apps --> Processing Dependency: ladspa-swh-plugins for package: planetccrma-apps --> Processing Dependency: ambdec for package: planetccrma-apps --> Processing Dependency: liboggz for package: planetccrma-apps --> Processing Dependency: pyecasound for package: planetccrma-apps --> Processing Dependency: pd-vasp for package: planetccrma-apps --> Processing Dependency: mcontrol for package: planetccrma-apps --> Processing Dependency: pd-flext for package: planetccrma-apps --> Processing Dependency: libgig for package: planetccrma-apps --> Processing Dependency: dssi-examples for package: planetccrma-apps --> Processing Dependency: ladspa-blop-plugins for package: planetccrma-apps --> Processing Dependency: sweep for package: planetccrma-apps --> Processing Dependency: libecasoundc for package: planetccrma-apps --> Processing Dependency: swami for package: planetccrma-apps --> Processing Dependency: amsynth for package: planetccrma-apps --> Processing Dependency: lzo for package: planetccrma-apps --> Processing Dependency: liblo for package: planetccrma-apps --> Processing Dependency: faust-pd for package: planetccrma-apps --> Processing Dependency: snd-motif for package: planetccrma-apps --> Processing Dependency: soundtouch for package: planetccrma-apps --> Processing Dependency: ladspa for package: planetccrma-apps --> Processing Dependency: cm-fomus-sbcl for package: planetccrma-apps --> Processing Dependency: rezound for package: planetccrma-apps --> Processing Dependency: zynaddsubfx for package: planetccrma-apps --> Processing Dependency: jack-rack for package: planetccrma-apps --> Processing Dependency: cm-clm-sbcl for package: planetccrma-apps --> Processing Dependency: hyperspec for package: planetccrma-apps --> Processing Dependency: csound-fluidsynth for package: planetccrma-apps --> Processing Dependency: soundfontcombi for package: planetccrma-apps --> Processing Dependency: jace for package: planetccrma-apps --> Processing Dependency: japa for package: planetccrma-apps --> Processing Dependency: tapiir for package: planetccrma-apps --> Processing Dependency: nyquist for package: planetccrma-apps --> Processing Dependency: kmidimon for package: planetccrma-apps --> Processing Dependency: phat for package: planetccrma-apps --> Processing Dependency: synaptic for package: planetccrma-apps --> Processing Dependency: ladspa-tap-plugins for package: planetccrma-apps --> Processing Dependency: ladspa-mcp-plugins for package: planetccrma-apps --> Processing Dependency: sndobj for package: planetccrma-apps --> Processing Dependency: csound-virtual-keyboard for package: planetccrma-apps --> Processing Dependency: avifile for package: planetccrma-apps --> Processing Dependency: timemachine for package: planetccrma-apps --> Processing Dependency: whysynth-dssi for package: planetccrma-apps --> Processing Dependency: bristol for package: planetccrma-apps --> Processing Dependency: aeolus for package: planetccrma-apps --> Processing Dependency: libsamplerate for package: planetccrma-apps --> Processing Dependency: ats for package: planetccrma-apps --> Processing Dependency: qsynth for package: planetccrma-apps --> Processing Dependency: ladspa-caps-plugins for package: planetccrma-apps --> Processing Dependency: yass for package: planetccrma-apps --> Processing Dependency: xmms-jack for package: planetccrma-apps --> Processing Dependency: ayam for package: planetccrma-apps --> Processing Dependency: vkeybd for package: planetccrma-apps --> Processing Dependency: ecasound for package: planetccrma-apps --> Processing Dependency: raptor for package: planetccrma-apps --> Processing Dependency: blender for package: planetccrma-apps --> Processing Dependency: freqtweak for package: planetccrma-apps --> Processing Dependency: csound-dssi for package: planetccrma-apps --> Processing Dependency: pd-zexy for package: planetccrma-apps --> Processing Dependency: gmorgan for package: planetccrma-apps --> Processing Dependency: jdelay for package: planetccrma-apps --> Processing Dependency: linuxsampler for package: planetccrma-apps --> Processing Dependency: csound-osc for package: planetccrma-apps --> Processing Dependency: hydrogen for package: planetccrma-apps --> Processing Dependency: libsndfile for package: planetccrma-apps --> Processing Dependency: mammut for package: planetccrma-apps --> Processing Dependency: qmidicontrol for package: planetccrma-apps --> Processing Dependency: timidity++ for package: planetccrma-apps --> Processing Dependency: clm-sbcl for package: planetccrma-apps --> Processing Dependency: jackmix for package: planetccrma-apps --> Processing Dependency: hexter-dssi for package: planetccrma-apps --> Processing Dependency: dssi for package: planetccrma-apps --> Processing Dependency: jnoise for package: planetccrma-apps --> Processing Dependency: specimen for package: planetccrma-apps --> Processing Dependency: bitmeter for package: planetccrma-apps --> Processing Dependency: ladspa-vco-plugins for package: planetccrma-apps --> Processing Dependency: fluidsynth-dssi for package: planetccrma-apps --> Processing Dependency: aliki for package: planetccrma-apps --> Processing Dependency: cltl2 for package: planetccrma-apps --> Processing Dependency: dvdauthor for package: planetccrma-apps --> Processing Dependency: pd-iemlib for package: planetccrma-apps --> Processing Dependency: pmidi for package: planetccrma-apps --> Processing Dependency: jack-audio-connection-kit-example-clients for package: planetccrma-apps --> Processing Dependency: qmidiroute for package: planetccrma-apps --> Processing Dependency: cinelerra for package: planetccrma-apps --> Processing Dependency: PVC for package: planetccrma-apps --> Processing Dependency: cmn-sbcl for package: planetccrma-apps --> Processing Dependency: faust for package: planetccrma-apps --> Processing Dependency: ladspa-amb-plugins for package: planetccrma-apps --> Processing Dependency: rosegarden4 for package: planetccrma-apps --> Processing Dependency: snd for package: planetccrma-apps --> Processing Dependency: liblscp for package: planetccrma-apps --> Processing Dependency: slime-sbcl for package: planetccrma-apps --> Processing Dependency: soundtracker for package: planetccrma-apps --> Processing Dependency: cm-sbcl for package: planetccrma-apps --> Processing Dependency: ams for package: planetccrma-apps --> Processing Dependency: galan for package: planetccrma-apps --> Processing Dependency: csound-tk for package: planetccrma-apps --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package ladspa-cmt-plugins.i386 0:1.15-5.fc7.ccrma set to be updated ---> Package rosegarden4.i386 0:1.4.0-1.fc7 set to be updated ---> Package chuck.i386 0:1.2.0.7-2.fc7.ccrma set to be updated ---> Package ats.i386 0:1.0-2.fc7.ccrma set to be updated ---> Package miniaudicle.i386 0:0.1.3.6-2.fc7.ccrma set to be updated ---> Package aliki.i386 0:0.0.3-1.fc7.ccrma set to be updated ---> Package ladspa.i386 0:1.12-8.fc7 set to be updated ---> Package csound-tk.i386 0:5.03.0-13.fc7 set to be updated ---> Package csound-virtual-keyboard.i386 0:5.03.0-13.fc7 set to be updated ---> Package qmidicontrol.i386 0:0.0.1b-3.fc7.ccrma set to be updated ---> Package dvdauthor.i386 0:0.6.14-1.fc7 set to be updated ---> Package jdelay.i386 0:0.0-2.fc7.ccrma set to be updated ---> Package libsndfile.i386 0:1.0.17-1.fc6 set to be updated ---> Package csound-gui.i386 0:5.03.0-13.fc7 set to be updated ---> Package cm-fomus-sbcl.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma set to be updated ---> Package dssi.i386 0:0.9.1-10.fc6 set to be updated ---> Package cm-clm-sbcl.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma set to be updated ---> Package whysynth-dssi.i386 0:20070418-1.fc7 set to be updated ---> Package soundfontcombi.i386 0:0.016-1.fc7.ccrma set to be updated ---> Package timemachine.i386 0:0.3.1-2.fc7.ccrma set to be updated ---> Package muse.i386 1:0.8.1a-2.fc7.ccrma set to be updated ---> Package slime-sbcl.i386 0:2.0-7.fc7.ccrma set to be updated ---> Package nyquist.i386 0:2.36-1.fc7 set to be updated ---> Package supercollider-world.i386 0:2007.03.08-1.fc7.ccrma set to be updated ---> Package yass.i386 0:0.0.2-1.fc7.ccrma set to be updated ---> Package liblo.i386 0:0.23-12.fc7 set to be updated ---> Package sndobj.i386 0:2.6.3-1.fc7.ccrma set to be updated ---> Package bitmeter.i386 0:1.2-2.fc7.ccrma set to be updated ---> Package fluidsynth.i386 0:1.0.7-8.a.fc6 set to be updated ---> Package soundtouch.i386 0:1.3.1-7.fc7 set to be updated ---> Package amsynth.i386 1:1.2.0-1.fc7.ccrma set to be updated ---> Package cltl2.noarch 0:1.0-4.fc7.ccrma set to be updated ---> Package mcontrol.i386 0:0.1.03-1.fc7.ccrma set to be updated ---> Package qarecord.i386 0:0.0.9b-3.fc7.ccrma set to be updated ---> Package japa.i386 0:0.2.1-1.fc7.ccrma set to be updated ---> Package ladspa-caps-plugins.i386 0:0.3.0-3.fc7.ccrma set to be updated ---> Package libsamplerate.i386 0:0.1.2-6.fc6 set to be updated ---> Package lilypond-doc.noarch 0:2.10.13-1.fc7 set to be updated ---> Package liblrdf.i386 0:0.4.0-10.fc6 set to be updated ---> Package qmidiroute.i386 0:0.2.1-3.fc7.ccrma set to be updated ---> Package jnoise.i386 0:0.0-2.fc7.ccrma set to be updated ---> Package tapiir.i386 0:0.7.1-4.fc7.ccrma set to be updated ---> Package csound-fluidsynth.i386 0:5.03.0-13.fc7 set to be updated ---> Package lash.i386 0:0.5.1-11.fc7 set to be updated ---> Package zynaddsubfx.i386 0:2.2.1-14.fc7 set to be updated ---> Package jaaa.i386 0:0.4.2-1.fc7.ccrma set to be updated ---> Package synaptic.i386 0:0.57.2-5.2.fc7 set to be updated ---> Package soundtracker.i386 0:0.6.8-2.fc6 set to be updated ---> Package audacity.i386 0:1.3.2-14.fc7 set to be updated ---> Package mammut.i386 0:0.57-1.fc7.ccrma set to be updated ---> Package ladspa-vco-plugins.i386 0:0.3.0-4.fc7.ccrma set to be updated ---> Package csound-osc.i386 0:5.03.0-13.fc7 set to be updated ---> Package csound-dssi.i386 0:5.03.0-13.fc7 set to be updated ---> Package linuxsampler.i386 0:0.4.0-2.fc7.ccrma set to be updated ---> Package ladspa-swh-plugins.i386 0:0.4.15-8.fc7 set to be updated ---> Package ladspa-amb-plugins.i386 0:0.1.0-1.fc7.ccrma set to be updated ---> Package qsampler.i386 0:0.1.3-3.fc7.ccrma set to be updated ---> Package libgig.i386 0:3.1.0-1.fc7.ccrma set to be updated ---> Package cm-sbcl.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma set to be updated ---> Package csound-jack.i386 0:5.03.0-13.fc7 set to be updated ---> Package liblscp.i386 0:0.4.2-1.fc7.ccrma set to be updated ---> Package phat.i386 0:0.4.0-3.fc7.ccrma set to be updated ---> Package jace.i386 0:0.1.0-1.fc7.ccrma set to be updated ---> Package PVC.i386 0:3.0-2.fc7.ccrma set to be updated ---> Package meterbridge.i386 0:0.9.2-2.fc7.ccrma set to be updated ---> Package lzo.i386 0:2.02-2.fc6 set to be updated ---> Package ladspa-tap-plugins.i386 0:0.7.0-2.fc7.ccrma set to be updated ---> Package ladspa-mcp-plugins.i386 1:0.3.0-3.fc7.ccrma set to be updated ---> Package timidity++.i386 0:2.13.2-1.2.2 set to be updated ---> Package ambdec.i386 0:0.0.1-1.fc7.ccrma set to be updated ---> Package aeolus.i386 0:0.6.6.2-1.fc7.ccrma set to be updated ---> Package raptor.i386 0:1.4.14-3.fc7 set to be updated ---> Package ladspa-rev-plugins.i386 0:0.3.1-2.fc7.ccrma set to be updated ---> Package lilypond.i386 0:2.10.20-1.fc7 set to be updated ---> Package cmn-sbcl.i386 0:2007.05.03-1.fc7.ccrma set to be updated ---> Package fluidsynth-dssi.i386 0:0.9.1-7.fc6 set to be updated ---> Package vkeybd.i386 0:0.1.17a-3.fc7 set to be updated ---> Package ladspa-blop-plugins.i386 0:0.2.8-2.fc7.ccrma set to be updated ---> Package ladspa-fil-plugins.i386 0:0.1.0-1.fc7.ccrma set to be updated ---> Package galan.i386 0:0.3.0-0.beta7.2.fc7.ccrma set to be updated ---> Package ladspa-devel.i386 0:1.12-8.fc7 set to be updated ---> Package seq24.i386 0:0.8.7-6.fc6 set to be updated ---> Package ardour2.i386 0:2.0.2-1.fc7.ccrma set to be updated ---> Package jamin.i386 0:0.95.0-3.fc7.ccrma set to be updated ---> Package dssi-examples.i386 0:0.9.1-10.fc6 set to be updated ---> Package pmidi.i386 0:1.6.0-2.fc7.ccrma set to be updated ---> Package sweep.i386 0:0.9.2-1.fc7 set to be updated ---> Package juce.i386 0:1.41-1.fc7.ccrma set to be updated ---> Package ams.i386 0:1.8.8-0.1.rc2.fc7.ccrma set to be updated ---> Package jack-audio-connection-kit-example-clients.i386 0:0.103.0-0.2.1015.svn.fc7.ccrma set to be updated ---> Package jackmix.i386 0:0.0.3-2.fc7.ccrma set to be updated ---> Package kmidimon.i386 0:0.4.1-2.fc7.ccrma set to be updated ---> Package blender.i386 0:2.44-4.fc7 set to be updated ---> Package xmms-jack.i386 0:0.17-2.fc7.ccrma set to be updated ---> Package clm-sbcl.i386 0:2007.05.03-1.fc7.ccrma set to be updated ---> Package csound-fltk.i386 0:5.03.0-13.fc7 set to be updated ---> Package qsynth.i386 0:0.2.5-6.fc6 set to be updated ---> Package liboggz.i386 0:0.9.4-3.fc6 set to be updated ---> Package hyperspec.noarch 0:6.0-2.fc7.ccrma set to be updated ---> Package jack-rack.i386 0:1.4.5-1.fc7.ccrma set to be updated ---> Package stk.i386 0:4.2.1-2.fc7.ccrma set to be updated ---> Package hydrogen-drumkits.i386 0:2006.03.03-2.fc7.ccrma set to be updated ---> Package hexter-dssi.i386 0:0.6.1-1.fc7 set to be updated ---> Package freqtweak.i386 0:0.6.1-5.fc7.ccrma set to be updated --> Processing Dependency: libwx_baseu_net-2.6.so.0 for package: audacity --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-osc --> Processing Dependency: supercollider-josh-ugens for package: supercollider-world --> Processing Dependency: libwx_gtk2u_core-2.8.so.0(WXU_2.8) for package: miniaudicle --> Processing Dependency: libHalf.so.4 for package: blender --> Processing Dependency: libgdk-1.2.so.0 for package: ats --> Processing Dependency: supercollider-reverb-ugens for package: supercollider-world --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-virtual-keyboard --> Processing Dependency: perl(XML::Twig) for package: rosegarden4 --> Processing Dependency: supercollider-blackrain-ugens for package: supercollider-world --> Processing Dependency: clm = 2007.05.03-1.fc7.ccrma for package: clm-sbcl --> Processing Dependency: libgtk-1.2.so.0 for package: soundtracker --> Processing Dependency: libIlmImf.so.4 for package: blender --> Processing Dependency: libgmodule-1.2.so.0 for package: ats --> Processing Dependency: liblirc_client.so.0 for package: rosegarden4 --> Processing Dependency: libclalsadrv.so.1 for package: jace --> Processing Dependency: supercollider-bhob-ugens for package: supercollider-world --> Processing Dependency: libfluidsynth.so.1 for package: csound-fluidsynth --> Processing Dependency: libwx_gtk2u_adv-2.6.so.0(WXU_2.6) for package: audacity --> Processing Dependency: libwx_baseu_net-2.6.so.0(WXU_2.6) for package: audacity --> Processing Dependency: libfftw3f.so.3 for package: whysynth-dssi --> Processing Dependency: libclthreads.so.2 for package: jaaa --> Processing Dependency: libalut.so.0 for package: blender --> Processing Dependency: libgdk-1.2.so.0 for package: xmms-jack --> Processing Dependency: libfftw3.so.3 for package: zynaddsubfx --> Processing Dependency: libglibmm-2.4.so.1 for package: amsynth --> Processing Dependency: libkdecore.so.4 for package: kmidimon --> Processing Dependency: slime = 2.0-7.fc7.ccrma for package: slime-sbcl --> Processing Dependency: libkwalletclient.so.1 for package: kmidimon --> Processing Dependency: libglib-1.2.so.0 for package: ats --> Processing Dependency: libfftw3f.so.3 for package: jamin --> Processing Dependency: libwx_baseu-2.8.so.0 for package: miniaudicle --> Processing Dependency: libopenal.so.0 for package: blender --> Processing Dependency: cm = 2.11.0-0.1.20070402.cvs.fc7.ccrma for package: cm-sbcl --> Processing Dependency: libclxclient.so.3 for package: aeolus --> Processing Dependency: libkdefx.so.4 for package: kmidimon --> Processing Dependency: xdg-utils for package: csound-gui --> Processing Dependency: libkdeui.so.4 for package: rosegarden4 --> Processing Dependency: libpangomm-1.4.so.1 for package: seq24 --> Processing Dependency: xmms for package: xmms-jack --> Processing Dependency: libclalsadrv.so.1 for package: japa --> Processing Dependency: sbcl >= 1.0.5-1 for package: cm-sbcl --> Processing Dependency: libwx_gtk2u_core-2.6.so.0(WXU_2.6) for package: audacity --> Processing Dependency: supercollider-dewdrop for package: supercollider-world --> Processing Dependency: libwx_baseu-2.8.so.0(WXU_2.8) for package: miniaudicle --> Processing Dependency: libfftw3f.so.3 for package: jace --> Processing Dependency: libgmodule-1.2.so.0 for package: xmms-jack --> Processing Dependency: libsigc-1.2.so.5 for package: freqtweak --> Processing Dependency: cm-fomus for package: cm-fomus-sbcl --> Processing Dependency: libwx_gtk2-2.4.so.0(WXGTK2_2.4) for package: freqtweak --> Processing Dependency: libclthreads.so.2 for package: japa --> Processing Dependency: libwx_baseu-2.6.so.0(WXU_2.6) for package: audacity --> Processing Dependency: libatkmm-1.6.so.1 for package: seq24 --> Processing Dependency: libclthreads.so.2 for package: ambdec --> Processing Dependency: hydrogen for package: hydrogen-drumkits --> Processing Dependency: libclxclient.so.3 for package: yass --> Processing Dependency: libclalsadrv.so.1 for package: aeolus --> Processing Dependency: sbcl >= 1.0.5-1 for package: cmn-sbcl --> Processing Dependency: tk for package: csound-tk --> Processing Dependency: libclxclient.so.3 for package: aliki --> Processing Dependency: supercollider-ambiem for package: supercollider-world --> Processing Dependency: supercollider-mcld-ugens for package: supercollider-world --> Processing Dependency: libpangomm-1.4.so.1 for package: amsynth --> Processing Dependency: libmxml.so.1 for package: zynaddsubfx --> Processing Dependency: libcsound.so.5.1 for package: csound-gui --> Processing Dependency: libtk8.4.so for package: csound-tk --> Processing Dependency: libwx_gtk2u_adv-2.6.so.0 for package: audacity --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-tk --> Processing Dependency: libwx_gtk2u_stc-2.8.so.0(WXU_2.8) for package: miniaudicle --> Processing Dependency: libatkmm-1.6.so.1 for package: amsynth --> Processing Dependency: libfluidsynth.so.1 for package: fluidsynth --> Processing Dependency: supercollider-bbcut2 for package: supercollider-world --> Processing Dependency: libwx_gtk2u_adv-2.8.so.0 for package: miniaudicle --> Processing Dependency: libwx_gtk2u_qa-2.6.so.0 for package: audacity --> Processing Dependency: libDCOP.so.4 for package: kmidimon --> Processing Dependency: libfluidsynth.so.1 for package: fluidsynth-dssi --> Processing Dependency: libsigc-2.0.so.0 for package: amsynth --> Processing Dependency: libfftw3f.so.3 for package: jaaa --> Processing Dependency: libfftw3f.so.3 for package: japa --> Processing Dependency: libkdecore.so.4 for package: rosegarden4 --> Processing Dependency: libwx_baseu-2.6.so.0 for package: audacity --> Processing Dependency: libwx_gtk2u_core-2.6.so.0 for package: audacity --> Processing Dependency: libgdk_pixbuf.so.2 for package: soundtracker --> Processing Dependency: kdebase for package: rosegarden4 --> Processing Dependency: tcl for package: csound-tk --> Processing Dependency: libwx_baseu_xml-2.6.so.0 for package: audacity --> Processing Dependency: libfftw3f.so.3 for package: freqtweak --> Processing Dependency: libSDL_image-1.2.so.0 for package: meterbridge --> Processing Dependency: libclxclient.so.3 for package: jaaa --> Processing Dependency: fluidsynth-libs for package: csound-fluidsynth --> Processing Dependency: libcairomm-1.0.so.1 for package: amsynth --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-dssi --> Processing Dependency: libglibmm-2.4.so.1 for package: seq24 --> Processing Dependency: libwx_gtk2u_adv-2.8.so.0(WXU_2.8) for package: miniaudicle --> Processing Dependency: libsigc-2.0.so.0 for package: seq24 --> Processing Dependency: libclthreads.so.2 for package: jace --> Processing Dependency: libgdk-1.2.so.0 for package: soundtracker --> Processing Dependency: libwx_gtk2-2.4.so.0 for package: freqtweak --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-jack --> Processing Dependency: libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) for package: audacity --> Processing Dependency: libImath.so.4 for package: blender --> Processing Dependency: libgtk-1.2.so.0 for package: ats --> Processing Dependency: libgdkmm-2.4.so.1 for package: seq24 --> Processing Dependency: libgmodule-1.2.so.0 for package: soundtracker --> Processing Dependency: libgtk-1.2.so.0 for package: xmms-jack --> Processing Dependency: supercollider-swingosc for package: supercollider-world --> Processing Dependency: libglib-1.2.so.0 for package: pmidi --> Processing Dependency: libgdkmm-2.4.so.1 for package: amsynth --> Processing Dependency: libkio.so.4 for package: rosegarden4 --> Processing Dependency: libfftw3f.so.3 for package: aliki --> Processing Dependency: libclalsadrv.so.1 for package: jaaa --> Processing Dependency: libportmidi.so.0 for package: cm-sbcl --> Processing Dependency: libclxclient.so.3 for package: japa --> Processing Dependency: sbcl = 1.0.5 for package: slime-sbcl --> Processing Dependency: libwx_gtk2u_core-2.8.so.0 for package: miniaudicle --> Processing Dependency: libcsound.so.5.1 for package: csound-tk --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-fltk --> Processing Dependency: supercollider-redclasses for package: supercollider-world --> Processing Dependency: libgthread-1.2.so.0 for package: soundtracker --> Processing Dependency: supercollider-beqsuite-ugens for package: supercollider-world --> Processing Dependency: tk < 1:8.5 for package: vkeybd --> Processing Dependency: cmn = 2007.05.03-1.fc7.ccrma for package: cmn-sbcl --> Processing Dependency: libkio.so.4 for package: kmidimon --> Processing Dependency: libclthreads.so.2 for package: aliki --> Processing Dependency: libkdeui.so.4 for package: kmidimon --> Processing Dependency: libfribidi.so.0 for package: dvdauthor --> Processing Dependency: libclxclient.so.3 for package: ambdec --> Processing Dependency: /usr/bin/wish for package: vkeybd --> Processing Dependency: mxml >= 2.2 for package: zynaddsubfx --> Processing Dependency: libgtkmm-2.4.so.1 for package: amsynth --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-gui --> Processing Dependency: libwx_gtk2u_html-2.6.so.0(WXU_2.6) for package: audacity --> Processing Dependency: libtk8.4.so for package: vkeybd --> Processing Dependency: libgtkmm-2.4.so.1 for package: seq24 --> Processing Dependency: /usr/bin/wish for package: csound-tk --> Processing Dependency: libwx_gtk2u_xrc-2.6.so.0 for package: audacity --> Processing Dependency: libwx_gtk2u_html-2.6.so.0 for package: audacity --> Processing Dependency: libapt-pkg-libc6.5-6.so.2 for package: synaptic --> Processing Dependency: libfftw3f.so.3 for package: ladspa-swh-plugins --> Processing Dependency: libclthreads.so.2 for package: yass --> Processing Dependency: libclalsadrv.so.1 for package: ams --> Processing Dependency: fluidsynth-libs = 1.0.7-8.a.fc6 for package: fluidsynth --> Processing Dependency: libDCOP.so.4 for package: rosegarden4 --> Processing Dependency: libclthreads.so.2 for package: aeolus --> Processing Dependency: libtcl8.4.so for package: vkeybd --> Processing Dependency: libfluidsynth.so.1 for package: qsynth --> Processing Dependency: supercollider-stk-ugens for package: supercollider-world --> Processing Dependency: libIex.so.4 for package: blender --> Processing Dependency: libkdeprint.so.4 for package: rosegarden4 --> Processing Dependency: libkdesu.so.4 for package: kmidimon --> Processing Dependency: supercollider-midifile for package: supercollider-world --> Processing Dependency: supercollider-mathlib for package: supercollider-world --> Processing Dependency: libtcl8.4.so for package: csound-tk --> Processing Dependency: csound = 5.03.0-13.fc7 for package: csound-fluidsynth --> Processing Dependency: libid3tag.so.0 for package: audacity --> Processing Dependency: libwx_gtk2u_stc-2.8.so.0 for package: miniaudicle --> Processing Dependency: /usr/bin/wish for package: stk --> Processing Dependency: libglib-1.2.so.0 for package: xmms-jack --> Processing Dependency: supercollider-ljpc-classes for package: supercollider-world --> Processing Dependency: libcairomm-1.0.so.1 for package: seq24 --> Processing Dependency: sbcl >= 1.0.5-1 for package: clm-sbcl --> Processing Dependency: supercollider for package: supercollider-world --> Processing Dependency: libartsc.so.0 for package: timidity++ --> Processing Dependency: libclalsadrv.so.1 for package: aliki --> Processing Dependency: libglib-1.2.so.0 for package: soundtracker --> Processing Dependency: perl(Tk) for package: csound-tk --> Processing Dependency: libdvdread.so.3 for package: dvdauthor --> Processing Dependency: tk >= 1:8.4 for package: vkeybd --> Processing Dependency: supercollider-joshpv-ugens for package: supercollider-world --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package portmidi.i386 0:20041117-2.fc7.ccrma set to be updated ---> Package xmms.i386 1:1.2.10-36.fc7 set to be updated ---> Package openal.i386 0:0.0.9-0.9.20060204cvs.fc7 set to be updated ---> Package kdelibs.i386 6:3.5.6-9.fc7 set to be updated ---> Package supercollider-bbcut2.i386 0:2.1-1.fc7.ccrma set to be updated ---> Package supercollider-dewdrop.i386 0:07.0203-1.fc7.ccrma set to be updated ---> Package cmn.i386 0:2007.05.03-1.fc7.ccrma set to be updated ---> Package gdk-pixbuf.i386 1:0.22.0-34.fc7 set to be updated ---> Package supercollider-mcld-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package perl-XML-Twig.noarch 0:3.29-1.fc7 set to be updated ---> Package supercollider-joshpv-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package freealut.i386 0:1.1.0-3.fc7 set to be updated ---> Package compat-wxGTK2.i386 0:2.4.2-21.fc6 set to be updated ---> Package kdebase.i386 6:3.5.6-12.fc7 set to be updated ---> Package SDL_image.i386 0:1.2.5-4.fc7 set to be updated ---> Package slime.i386 0:2.0-7.fc7.ccrma set to be updated ---> Package tcl.i386 1:8.4.13-16.fc7 set to be updated ---> Package supercollider-josh-ugens.i386 1:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package libsigc++.i386 0:1.2.7-4.fc6 set to be updated ---> Package gtkmm24.i386 0:2.10.9-1.fc7 set to be updated ---> Package sbcl.i386 0:1.0.5-1.fc7 set to be updated ---> Package supercollider-reverb-ugens.i386 1:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package cairomm.i386 0:1.2.4-1.fc7 set to be updated ---> Package libdvdread.i386 0:0.9.7-2.fc7 set to be updated ---> Package gtk+.i386 1:1.2.10-57.fc7 set to be updated ---> Package supercollider-redclasses.i386 0:0.0-1.fc7.ccrma set to be updated ---> Package supercollider.i386 0:0.0.20070219-0.2.5866svn.fc7.ccrma set to be updated ---> Package supercollider-stk-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package OpenEXR.i386 0:1.4.0a-3.fc6 set to be updated ---> Package supercollider-ljpc-classes.i386 0:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package lirc.i386 0:0.8.1-1.fc7 set to be updated ---> Package compat-wxGTK26.i386 0:2.6.3-2 set to be updated ---> Package libid3tag.i386 0:0.15.1b-3.fc6 set to be updated ---> Package apt.i386 0:0.5.15lorg3.2-9.fc7 set to be updated ---> Package glib.i386 1:1.2.10-26.fc7 set to be updated ---> Package wxGTK.i386 0:2.8.3-2.fc7 set to be updated ---> Package csound.i386 0:5.03.0-13.fc7 set to be updated ---> Package clthreads.i386 0:2.2.1-1.fc7.ccrma set to be updated ---> Package libsigc++20.i386 0:2.0.17-2 set to be updated ---> Package supercollider-bhob-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package tk.i386 1:8.4.13-5.fc7 set to be updated ---> Package glibmm24.i386 0:2.12.8-1.fc7 set to be updated ---> Package supercollider-midifile.i386 0:0.0-1.fc7.ccrma set to be updated ---> Package supercollider-mathlib.i386 0:0.20070309-1.56svn.fc7.ccrma set to be updated ---> Package supercollider-swingosc.i386 0:0.500-1.fc7.ccrma set to be updated ---> Package clxclient.i386 0:3.3.2-1.fc7.ccrma set to be updated ---> Package arts.i386 8:1.5.6-4.fc7 set to be updated ---> Package xdg-utils.noarch 0:1.0.1-3.fc7 set to be updated ---> Package cm-fomus.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma set to be updated ---> Package cm.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma set to be updated ---> Package supercollider-beqsuite-ugens.i386 1:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package supercollider-blackrain-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma set to be updated ---> Package perl-Tk.i386 0:804.027-11.fc7 set to be updated ---> Package fribidi.i386 0:0.10.7-6.fc7 set to be updated ---> Package fluidsynth-libs.i386 0:1.0.7-8.a.fc6 set to be updated ---> Package mxml.i386 0:2.2.2-7.fc6 set to be updated ---> Package clalsadrv.i386 0:1.2.2-1.fc7.ccrma set to be updated ---> Package fftw.i386 0:3.1.2-3.fc6 set to be updated ---> Package clm.i386 0:2007.05.03-1.fc7.ccrma set to be updated ---> Package supercollider-ambiem.i386 0:0.4-2.fc7.ccrma set to be updated --> Processing Dependency: compat-wxGTK-common = 2.4.2-21.fc6 for package: compat-wxGTK2 --> Processing Dependency: kde-settings-kdm for package: kdebase --> Processing Dependency: apt-config for package: apt --> Processing Dependency: libjasper.so.1 for package: kdelibs --> Processing Dependency: redhat-artwork-kde >= 7.0.0-8 for package: kdebase --> Processing Dependency: libkdnssd.so.1 for package: kdebase --> Processing Dependency: kde-settings for package: kdebase --> Processing Dependency: htdig for package: kdebase --> Processing Dependency: libaudio.so.2 for package: arts --> Processing Dependency: libkdnssd for package: kdelibs --> Processing Dependency: libsensors.so.3 for package: kdebase --> Processing Dependency: libxmms.so.1 for package: xmms --> Processing Dependency: perl(XML::Parser) for package: perl-XML-Twig --> Processing Dependency: kde-settings >= 3.5 for package: kdelibs --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package nas.i386 0:1.9-1.fc7 set to be updated ---> Package fedora-package-config-apt.noarch 0:6.89-6 set to be updated ---> Package kde-settings.noarch 0:3.5-28.fc7.1 set to be updated ---> Package htdig.i386 3:3.2.0b6-11.fc7 set to be updated ---> Package kde-settings-kdm.noarch 0:3.5-28.fc7.1 set to be updated ---> Package redhat-artwork-kde.i386 0:7.0.0-9.fc7 set to be updated ---> Package perl-XML-Parser.i386 0:2.34-6.1.2.2.1 set to be updated ---> Package lm_sensors.i386 0:2.10.3-2.fc7 set to be updated ---> Package kdnssd-avahi.i386 0:0.1.3-0.1.20060713svn.fc6 set to be updated ---> Package xmms-libs.i386 1:1.2.10-36.fc7 set to be updated ---> Package jasper.i386 0:1.900.1-2.fc7 set to be updated ---> Package compat-wxGTK-common.i386 0:2.4.2-21.fc6 set to be updated --> Processing Dependency: libglut.so.3 for package: jasper --> Processing Dependency: libavahi-qt3.so.1 for package: kdnssd-avahi --> Processing Dependency: libmikmod.so.2 for package: xmms-libs --> Processing Dependency: xorg-x11-xdm for package: kde-settings-kdm --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package freeglut.i386 0:2.4.0-11.fc7 set to be updated ---> Package mikmod.i386 0:3.2.2-2.fc7 set to be updated ---> Package xorg-x11-xdm.i386 1:1.1.3-1.fc7 set to be updated ---> Package avahi-qt3.i386 0:0.6.17-1.fc7 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: planetccrma-apps i386 2007.06.05-1.fc7.ccrma planetstage 4.1 k Installing for dependencies: OpenEXR i386 1.4.0a-3.fc6 fedora 416 k PVC i386 3.0-2.fc7.ccrma planetstage 1.8 M SDL_image i386 1.2.5-4.fc7 fedora 43 k aeolus i386 0.6.6.2-1.fc7.ccrma planetstage 169 k aliki i386 0.0.3-1.fc7.ccrma planetstage 322 k ambdec i386 0.0.1-1.fc7.ccrma planetstage 206 k ams i386 1.8.8-0.1.rc2.fc7.ccrma planetstage 444 k amsynth i386 1:1.2.0-1.fc7.ccrma planetstage 269 k apt i386 0.5.15lorg3.2-9.fc7 fedora 979 k ardour2 i386 2.0.2-1.fc7.ccrma planetstage 5.0 M arts i386 8:1.5.6-4.fc7 fedora 1.1 M ats i386 1.0-2.fc7.ccrma planetstage 266 k audacity i386 1.3.2-14.fc7 fedora 2.3 M avahi-qt3 i386 0.6.17-1.fc7 fedora 17 k bitmeter i386 1.2-2.fc7.ccrma planetstage 19 k blender i386 2.44-4.fc7 fedora 9.0 M cairomm i386 1.2.4-1.fc7 fedora 43 k chuck i386 1.2.0.7-2.fc7.ccrma planetstage 1.6 M clalsadrv i386 1.2.2-1.fc7.ccrma planetstage 20 k clm i386 2007.05.03-1.fc7.ccrma planetstage 1.2 M clm-sbcl i386 2007.05.03-1.fc7.ccrma planetstage 1.2 M clthreads i386 2.2.1-1.fc7.ccrma planetstage 13 k cltl2 noarch 1.0-4.fc7.ccrma planetstage 1.7 M clxclient i386 3.3.2-1.fc7.ccrma planetstage 44 k cm i386 2.11.0-0.1.20070402.cvs.fc7.ccrma planetstage 1.9 M cm-clm-sbcl i386 2.11.0-0.1.20070402.cvs.fc7.ccrma planetstage 13 k cm-fomus i386 2.11.0-0.1.20070402.cvs.fc7.ccrma planetstage 2.0 M cm-fomus-sbcl i386 2.11.0-0.1.20070402.cvs.fc7.ccrma planetstage 720 k cm-sbcl i386 2.11.0-0.1.20070402.cvs.fc7.ccrma planetstage 2.6 M cmn i386 2007.05.03-1.fc7.ccrma planetstage 580 k cmn-sbcl i386 2007.05.03-1.fc7.ccrma planetstage 1.1 M compat-wxGTK-common i386 2.4.2-21.fc6 fedora 516 k compat-wxGTK2 i386 2.4.2-21.fc6 fedora 1.7 M compat-wxGTK26 i386 2.6.3-2 fedora 3.5 M csound i386 5.03.0-13.fc7 fedora 913 k csound-dssi i386 5.03.0-13.fc7 fedora 14 k csound-fltk i386 5.03.0-13.fc7 fedora 61 k csound-fluidsynth i386 5.03.0-13.fc7 fedora 9.7 k csound-gui i386 5.03.0-13.fc7 fedora 88 k csound-jack i386 5.03.0-13.fc7 fedora 13 k csound-osc i386 5.03.0-13.fc7 fedora 11 k csound-tk i386 5.03.0-13.fc7 fedora 42 k csound-virtual-keyboard i386 5.03.0-13.fc7 fedora 20 k dssi i386 0.9.1-10.fc6 fedora 46 k dssi-examples i386 0.9.1-10.fc6 fedora 61 k dvdauthor i386 0.6.14-1.fc7 fedora 178 k fedora-package-config-apt noarch 6.89-6 fedora 4.3 k fftw i386 3.1.2-3.fc6 fedora 899 k fluidsynth i386 1.0.7-8.a.fc6 fedora 16 k fluidsynth-dssi i386 0.9.1-7.fc6 fedora 52 k fluidsynth-libs i386 1.0.7-8.a.fc6 fedora 488 k freealut i386 1.1.0-3.fc7 fedora 40 k freeglut i386 2.4.0-11.fc7 fedora 142 k freqtweak i386 0.6.1-5.fc7.ccrma planetstage 306 k fribidi i386 0.10.7-6.fc7 fedora 52 k galan i386 0.3.0-0.beta7.2.fc7.ccrma planetstage 984 k gdk-pixbuf i386 1:0.22.0-34.fc7 fedora 227 k glib i386 1:1.2.10-26.fc7 fedora 138 k glibmm24 i386 2.12.8-1.fc7 fedora 150 k gtk+ i386 1:1.2.10-57.fc7 fedora 923 k gtkmm24 i386 2.10.9-1.fc7 fedora 1.1 M hexter-dssi i386 0.6.1-1.fc7 fedora 175 k htdig i386 3:3.2.0b6-11.fc7 fedora 1.0 M hydrogen-drumkits i386 2006.03.03-2.fc7.ccrma planetstage 12 M hyperspec noarch 6.0-2.fc7.ccrma planetstage 2.2 M jaaa i386 0.4.2-1.fc7.ccrma planetstage 41 k jace i386 0.1.0-1.fc7.ccrma planetstage 747 k jack-audio-connection-kit-example-clients i386 0.103.0-0.2.1015.svn.fc7.ccrma planetstage 39 k jack-rack i386 1.4.5-1.fc7.ccrma planetstage 89 k jackmix i386 0.0.3-2.fc7.ccrma planetstage 107 k jamin i386 0.95.0-3.fc7.ccrma planetstage 565 k japa i386 0.2.1-1.fc7.ccrma planetstage 41 k jasper i386 1.900.1-2.fc7 updates 174 k jdelay i386 0.0-2.fc7.ccrma planetstage 14 k jnoise i386 0.0-2.fc7.ccrma planetstage 14 k juce i386 1.41-1.fc7.ccrma planetstage 3.5 M kde-settings noarch 3.5-28.fc7.1 fedora 13 k kde-settings-kdm noarch 3.5-28.fc7.1 fedora 16 k kdebase i386 6:3.5.6-12.fc7 fedora 28 M kdelibs i386 6:3.5.6-9.fc7 fedora 18 M kdnssd-avahi i386 0.1.3-0.1.20060713svn.fc6 fedora 43 k kmidimon i386 0.4.1-2.fc7.ccrma planetstage 109 k ladspa i386 1.12-8.fc7 fedora 37 k ladspa-amb-plugins i386 0.1.0-1.fc7.ccrma planetstage 23 k ladspa-blop-plugins i386 0.2.8-2.fc7.ccrma planetstage 922 k ladspa-caps-plugins i386 0.3.0-3.fc7.ccrma planetstage 214 k ladspa-cmt-plugins i386 1.15-5.fc7.ccrma planetstage 70 k ladspa-devel i386 1.12-8.fc7 fedora 16 k ladspa-fil-plugins i386 0.1.0-1.fc7.ccrma planetstage 15 k ladspa-mcp-plugins i386 1:0.3.0-3.fc7.ccrma planetstage 30 k ladspa-rev-plugins i386 0.3.1-2.fc7.ccrma planetstage 18 k ladspa-swh-plugins i386 0.4.15-8.fc7 fedora 424 k ladspa-tap-plugins i386 0.7.0-2.fc7.ccrma planetstage 94 k ladspa-vco-plugins i386 0.3.0-4.fc7.ccrma planetstage 18 k lash i386 0.5.1-11.fc7 fedora 174 k libdvdread i386 0.9.7-2.fc7 fedora 66 k libgig i386 3.1.0-1.fc7.ccrma planetstage 724 k libid3tag i386 0.15.1b-3.fc6 fedora 44 k liblo i386 0.23-12.fc7 fedora 33 k liblrdf i386 0.4.0-10.fc6 fedora 26 k liblscp i386 0.4.2-1.fc7.ccrma planetstage 25 k liboggz i386 0.9.4-3.fc6 fedora 61 k libsamplerate i386 0.1.2-6.fc6 fedora 153 k libsigc++ i386 1.2.7-4.fc6 fedora 36 k libsigc++20 i386 2.0.17-2 fedora 50 k libsndfile i386 1.0.17-1.fc6 fedora 230 k lilypond i386 2.10.20-1.fc7 fedora 4.8 M lilypond-doc noarch 2.10.13-1.fc7 fedora 26 M linuxsampler i386 0.4.0-2.fc7.ccrma planetstage 347 k lirc i386 0.8.1-1.fc7 fedora 240 k lm_sensors i386 2.10.3-2.fc7 fedora 512 k lzo i386 2.02-2.fc6 fedora 63 k mammut i386 0.57-1.fc7.ccrma planetstage 1.6 M mcontrol i386 0.1.03-1.fc7.ccrma planetstage 44 k meterbridge i386 0.9.2-2.fc7.ccrma planetstage 515 k mikmod i386 3.2.2-2.fc7 fedora 228 k miniaudicle i386 0.1.3.6-2.fc7.ccrma planetstage 599 k muse i386 1:0.8.1a-2.fc7.ccrma planetstage 2.9 M mxml i386 2.2.2-7.fc6 fedora 46 k nas i386 1.9-1.fc7 fedora 647 k nyquist i386 2.36-1.fc7 fedora 3.0 M openal i386 0.0.9-0.9.20060204cvs.fc7 fedora 150 k perl-Tk i386 804.027-11.fc7 fedora 2.4 M perl-XML-Parser i386 2.34-6.1.2.2.1 fedora 209 k perl-XML-Twig noarch 3.29-1.fc7 fedora 196 k phat i386 0.4.0-3.fc7.ccrma planetstage 195 k pmidi i386 1.6.0-2.fc7.ccrma planetstage 31 k portmidi i386 20041117-2.fc7.ccrma planetstage 185 k qarecord i386 0.0.9b-3.fc7.ccrma planetstage 38 k qmidicontrol i386 0.0.1b-3.fc7.ccrma planetstage 22 k qmidiroute i386 0.2.1-3.fc7.ccrma planetstage 42 k qsampler i386 0.1.3-3.fc7.ccrma planetstage 174 k qsynth i386 0.2.5-6.fc6 fedora 186 k raptor i386 1.4.14-3.fc7 fedora 182 k redhat-artwork-kde i386 7.0.0-9.fc7 fedora 559 k rosegarden4 i386 1.4.0-1.fc7 fedora 6.9 M sbcl i386 1.0.5-1.fc7 fedora 9.0 M seq24 i386 0.8.7-6.fc6 fedora 265 k slime i386 2.0-7.fc7.ccrma planetstage 743 k slime-sbcl i386 2.0-7.fc7.ccrma planetstage 396 k sndobj i386 2.6.3-1.fc7.ccrma planetstage 370 k soundfontcombi i386 0.016-1.fc7.ccrma planetstage 66 k soundtouch i386 1.3.1-7.fc7 fedora 58 k soundtracker i386 0.6.8-2.fc6 fedora 441 k stk i386 4.2.1-2.fc7.ccrma planetstage 3.0 M supercollider i386 0.0.20070219-0.2.5866svn.fc7.ccrma planetstage 2.7 M supercollider-ambiem i386 0.4-2.fc7.ccrma planetstage 38 k supercollider-bbcut2 i386 2.1-1.fc7.ccrma planetstage 148 k supercollider-beqsuite-ugens i386 1:0.20070308-1.64svn.fc7.ccrma planetstage 18 k supercollider-bhob-ugens i386 0.20070308-1.64svn.fc7.ccrma planetstage 44 k supercollider-blackrain-ugens i386 0.20070308-1.64svn.fc7.ccrma planetstage 13 k supercollider-dewdrop i386 07.0203-1.fc7.ccrma planetstage 219 k supercollider-josh-ugens i386 1:0.20070308-1.64svn.fc7.ccrma planetstage 141 k supercollider-joshpv-ugens i386 0.20070308-1.64svn.fc7.ccrma planetstage 32 k supercollider-ljpc-classes i386 0.20070308-1.64svn.fc7.ccrma planetstage 41 k supercollider-mathlib i386 0.20070309-1.56svn.fc7.ccrma planetstage 24 k supercollider-mcld-ugens i386 0.20070308-1.64svn.fc7.ccrma planetstage 33 k supercollider-midifile i386 0.0-1.fc7.ccrma planetstage 9.6 k supercollider-redclasses i386 0.0-1.fc7.ccrma planetstage 36 k supercollider-reverb-ugens i386 1:0.20070308-1.64svn.fc7.ccrma planetstage 19 k supercollider-stk-ugens i386 0.20070308-1.64svn.fc7.ccrma planetstage 118 k supercollider-swingosc i386 0.500-1.fc7.ccrma planetstage 483 k supercollider-world i386 2007.03.08-1.fc7.ccrma planetstage 2.3 k sweep i386 0.9.2-1.fc7 fedora 467 k synaptic i386 0.57.2-5.2.fc7 fedora 1.6 M tapiir i386 0.7.1-4.fc7.ccrma planetstage 162 k tcl i386 1:8.4.13-16.fc7 fedora 1.8 M timemachine i386 0.3.1-2.fc7.ccrma planetstage 84 k timidity++ i386 2.13.2-1.2.2 fedora 9.0 M tk i386 1:8.4.13-5.fc7 fedora 1.2 M vkeybd i386 0.1.17a-3.fc7 fedora 34 k whysynth-dssi i386 20070418-1.fc7 fedora 1.8 M wxGTK i386 2.8.3-2.fc7 fedora 4.3 M xdg-utils noarch 1.0.1-3.fc7 fedora 52 k xmms i386 1:1.2.10-36.fc7 fedora 1.6 M xmms-jack i386 0.17-2.fc7.ccrma planetstage 26 k xmms-libs i386 1:1.2.10-36.fc7 fedora 243 k xorg-x11-xdm i386 1:1.1.3-1.fc7 fedora 131 k yass i386 0.0.2-1.fc7.ccrma planetstage 23 k zynaddsubfx i386 2.2.1-14.fc7 fedora 1.0 M Transaction Summary ============================================================================= Install 181 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 215 M Is this ok [y/N]: Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: libsndfile ##################### [ 1/181] Installing: liblo ##################### [ 2/181] Installing: fftw ##################### [ 3/181] Installing: libsamplerate ##################### [ 4/181] Installing: supercollider ##################### [ 5/181] Installing: csound ##################### [ 6/181] Installing: glib ##################### [ 7/181] Installing: clthreads ##################### [ 8/181] Installing: lash ##################### [ 9/181]install-info: warning: no info dir entry in `/usr/share/info/lash-manual.info' Installing: gtk+ ##################### [ 10/181] Installing: dssi ##################### [ 11/181] Installing: clalsadrv ##################### [ 12/181] Installing: clxclient ##################### [ 13/181] Installing: fluidsynth-libs ##################### [ 14/181] Installing: libsigc++20 ##################### [ 15/181] Installing: sbcl ##################### [ 16/181] Installing: glibmm24 ##################### [ 17/181] Installing: ladspa-swh-plugins ##################### [ 18/181] Installing: libgig ##################### [ 19/181] Installing: raptor ##################### [ 20/181] Installing: liblrdf ##################### [ 21/181] Installing: OpenEXR ##################### [ 22/181] Installing: cairomm ##################### [ 23/181] Installing: tcl ##################### [ 24/181] Installing: tk ##################### [ 25/181] Installing: gtkmm24 ##################### [ 26/181] Installing: linuxsampler ##################### [ 27/181] Installing: ladspa-fil-plugins ##################### [ 28/181] Installing: cm ##################### [ 29/181] Installing: ladspa-rev-plugins ##################### [ 30/181] Installing: ladspa-mcp-plugins ##################### [ 31/181] Installing: liblscp ##################### [ 32/181] Installing: ladspa-vco-plugins ##################### [ 33/181] Installing: ladspa ##################### [ 34/181] Installing: ladspa-cmt-plugins ##################### [ 35/181] Installing: ams ##################### [ 36/181] Installing: ladspa-devel ##################### [ 37/181] Installing: qsampler ##################### [ 38/181] Installing: cm-fomus ##################### [ 39/181] Installing: amsynth ##################### [ 40/181] Installing: seq24 ##################### [ 41/181] Installing: vkeybd ##################### [ 42/181] Installing: stk ##################### [ 43/181] Installing: galan ##################### [ 44/181] Installing: ardour2 ##################### [ 45/181] Installing: jack-rack ##################### [ 46/181] Installing: jamin ##################### [ 47/181] Installing: fluidsynth ##################### [ 48/181] Installing: csound-fluidsynth ##################### [ 49/181] Installing: fluidsynth-dssi ##################### [ 50/181] Installing: qsynth ##################### [ 51/181] Installing: aliki ##################### [ 52/181] Installing: yass ##################### [ 53/181] Installing: japa ##################### [ 54/181] Installing: jaaa ##################### [ 55/181] Installing: ambdec ##################### [ 56/181] Installing: aeolus ##################### [ 57/181] Installing: jace ##################### [ 58/181] Installing: whysynth-dssi ##################### [ 59/181] Installing: csound-dssi ##################### [ 60/181] Installing: dssi-examples ##################### [ 61/181] Installing: hexter-dssi ##################### [ 62/181] Installing: ats ##################### [ 63/181] Installing: gdk-pixbuf ##################### [ 64/181] Installing: soundtracker ##################### [ 65/181] Installing: timemachine ##################### [ 66/181] Installing: pmidi ##################### [ 67/181] Installing: csound-virtual-keyboard ##################### [ 68/181] Installing: csound-osc ##################### [ 69/181] Installing: csound-jack ##################### [ 70/181] Installing: csound-fltk ##################### [ 71/181] Installing: supercollider-bbcut2 ##################### [ 72/181] Installing: supercollider-dewdrop ##################### [ 73/181] Installing: supercollider-redclasses ##################### [ 74/181] Installing: supercollider-midifile ##################### [ 75/181] Installing: supercollider-mathlib ##################### [ 76/181] Installing: supercollider-swingosc ##################### [ 77/181] Installing: supercollider-ambiem ##################### [ 78/181] Installing: mammut ##################### [ 79/181] Installing: sweep ##################### [ 80/181] Installing: chuck ##################### [ 81/181] Installing: jack-audio-connection-kit-ex ##################### [ 82/181] Installing: compat-wxGTK-common ##################### [ 83/181] Installing: compat-wxGTK2 ##################### [ 84/181] Installing: avahi-qt3 ##################### [ 85/181] Installing: hydrogen-drumkits ##################### [ 86/181] Installing: clm ##################### [ 87/181] Installing: clm-sbcl ##################### [ 88/181] Installing: hyperspec ##################### [ 89/181] Installing: xorg-x11-xdm ##################### [ 90/181] Installing: mxml ##################### [ 91/181] Installing: zynaddsubfx ##################### [ 92/181] Installing: liboggz ##################### [ 93/181] Installing: jackmix ##################### [ 94/181] Installing: fribidi ##################### [ 95/181] Installing: juce ##################### [ 96/181] Installing: perl-Tk ##################### [ 97/181] Installing: csound-tk ##################### [ 98/181] Installing: ladspa-blop-plugins ##################### [ 99/181] Installing: supercollider-blackrain-ugen ##################### [100/181] Installing: supercollider-beqsuite-ugens ##################### [101/181] Installing: lilypond ##################### [102/181] Installing: xdg-utils ##################### [103/181] Installing: csound-gui ##################### [104/181] Installing: lm_sensors ##################### [105/181] Installing: mikmod ##################### [106/181] Installing: xmms-libs ##################### [107/181] Installing: xmms ##################### [108/181] Installing: xmms-jack ##################### [109/181] Installing: perl-XML-Parser ##################### [110/181] Installing: perl-XML-Twig ##################### [111/181] Installing: ladspa-tap-plugins ##################### [112/181] Installing: lzo ##################### [113/181] Installing: PVC ##################### [114/181] Installing: phat ##################### [115/181] Installing: ladspa-amb-plugins ##################### [116/181] Installing: supercollider-bhob-ugens ##################### [117/181] Installing: wxGTK ##################### [118/181] Installing: miniaudicle ##################### [119/181] Installing: libid3tag ##################### [120/181] Installing: compat-wxGTK26 ##################### [121/181] Installing: audacity ##################### [122/181] Installing: lirc ##################### [123/181] Installing: supercollider-ljpc-classes ##################### [124/181] Installing: tapiir ##################### [125/181] Installing: jnoise ##################### [126/181] Installing: qmidiroute ##################### [127/181] Installing: lilypond-doc ##################### [128/181] Installing: supercollider-stk-ugens ##################### [129/181] Installing: ladspa-caps-plugins ##################### [130/181] Installing: qarecord ##################### [131/181] Installing: mcontrol ##################### [132/181] Installing: libdvdread ##################### [133/181] Installing: dvdauthor ##################### [134/181] Installing: supercollider-reverb-ugens ##################### [135/181] Installing: cltl2 ##################### [136/181] Installing: soundtouch ##################### [137/181] Installing: libsigc++ ##################### [138/181] Installing: freqtweak ##################### [139/181] Installing: htdig ##################### [140/181] Installing: bitmeter ##################### [141/181] Installing: sndobj ##################### [142/181] Installing: supercollider-josh-ugens ##################### [143/181] Installing: nyquist ##################### [144/181] Installing: muse ##################### [145/181] Installing: slime ##################### [146/181] Installing: slime-sbcl ##################### [147/181] Installing: soundfontcombi ##################### [148/181] Installing: SDL_image ##################### [149/181] Installing: meterbridge ##################### [150/181] Installing: freealut ##################### [151/181] Installing: supercollider-joshpv-ugens ##################### [152/181] Installing: freeglut ##################### [153/181] Installing: jasper ##################### [154/181] Installing: supercollider-mcld-ugens ##################### [155/181] Installing: supercollider-world ##################### [156/181] Installing: jdelay ##################### [157/181] Installing: qmidicontrol ##################### [158/181] Installing: nas ##################### [159/181] Installing: arts ##################### [160/181] Installing: timidity++ ##################### [161/181] Installing: cmn ##################### [162/181] Installing: cmn-sbcl ##################### [163/181] Installing: openal ##################### [164/181] Installing: blender ##################### [165/181] Installing: portmidi ##################### [166/181] Installing: cm-sbcl ##################### [167/181] Installing: cm-fomus-sbcl ##################### [168/181] Installing: cm-clm-sbcl ##################### [169/181] Installing: kdnssd-avahi ##################### [170/181] Installing: apt ##################### [171/181] Installing: synaptic ##################### [172/181] Installing: fedora-package-config-apt ##################### [173/181] Installing: kdelibs ##################### [174/181] Installing: kde-settings ##################### [175/181] Installing: kmidimon ##################### [176/181] Installing: redhat-artwork-kde ##################### [177/181] Installing: kdebase ##################### [178/181] Installing: rosegarden4 ##################### [179/181] Installing: kde-settings-kdm ##################### [180/181] Installing: planetccrma-apps ##################### [181/181] Installed: planetccrma-apps.i386 0:2007.06.05-1.fc7.ccrma Dependency Installed: OpenEXR.i386 0:1.4.0a-3.fc6 PVC.i386 0:3.0-2.fc7.ccrma SDL_image.i386 0:1.2.5-4.fc7 aeolus.i386 0:0.6.6.2-1.fc7.ccrma aliki.i386 0:0.0.3-1.fc7.ccrma ambdec.i386 0:0.0.1-1.fc7.ccrma ams.i386 0:1.8.8-0.1.rc2.fc7.ccrma amsynth.i386 1:1.2.0-1.fc7.ccrma apt.i386 0:0.5.15lorg3.2-9.fc7 ardour2.i386 0:2.0.2-1.fc7.ccrma arts.i386 8:1.5.6-4.fc7 ats.i386 0:1.0-2.fc7.ccrma audacity.i386 0:1.3.2-14.fc7 avahi-qt3.i386 0:0.6.17-1.fc7 bitmeter.i386 0:1.2-2.fc7.ccrma blender.i386 0:2.44-4.fc7 cairomm.i386 0:1.2.4-1.fc7 chuck.i386 0:1.2.0.7-2.fc7.ccrma clalsadrv.i386 0:1.2.2-1.fc7.ccrma clm.i386 0:2007.05.03-1.fc7.ccrma clm-sbcl.i386 0:2007.05.03-1.fc7.ccrma clthreads.i386 0:2.2.1-1.fc7.ccrma cltl2.noarch 0:1.0-4.fc7.ccrma clxclient.i386 0:3.3.2-1.fc7.ccrma cm.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma cm-clm-sbcl.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma cm-fomus.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma cm-fomus-sbcl.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma cm-sbcl.i386 0:2.11.0-0.1.20070402.cvs.fc7.ccrma cmn.i386 0:2007.05.03-1.fc7.ccrma cmn-sbcl.i386 0:2007.05.03-1.fc7.ccrma compat-wxGTK-common.i386 0:2.4.2-21.fc6 compat-wxGTK2.i386 0:2.4.2-21.fc6 compat-wxGTK26.i386 0:2.6.3-2 csound.i386 0:5.03.0-13.fc7 csound-dssi.i386 0:5.03.0-13.fc7 csound-fltk.i386 0:5.03.0-13.fc7 csound-fluidsynth.i386 0:5.03.0-13.fc7 csound-gui.i386 0:5.03.0-13.fc7 csound-jack.i386 0:5.03.0-13.fc7 csound-osc.i386 0:5.03.0-13.fc7 csound-tk.i386 0:5.03.0-13.fc7 csound-virtual-keyboard.i386 0:5.03.0-13.fc7 dssi.i386 0:0.9.1-10.fc6 dssi-examples.i386 0:0.9.1-10.fc6 dvdauthor.i386 0:0.6.14-1.fc7 fedora-package-config-apt.noarch 0:6.89-6 fftw.i386 0:3.1.2-3.fc6 fluidsynth.i386 0:1.0.7-8.a.fc6 fluidsynth-dssi.i386 0:0.9.1-7.fc6 fluidsynth-libs.i386 0:1.0.7-8.a.fc6 freealut.i386 0:1.1.0-3.fc7 freeglut.i386 0:2.4.0-11.fc7 freqtweak.i386 0:0.6.1-5.fc7.ccrma fribidi.i386 0:0.10.7-6.fc7 galan.i386 0:0.3.0-0.beta7.2.fc7.ccrma gdk-pixbuf.i386 1:0.22.0-34.fc7 glib.i386 1:1.2.10-26.fc7 glibmm24.i386 0:2.12.8-1.fc7 gtk+.i386 1:1.2.10-57.fc7 gtkmm24.i386 0:2.10.9-1.fc7 hexter-dssi.i386 0:0.6.1-1.fc7 htdig.i386 3:3.2.0b6-11.fc7 hydrogen-drumkits.i386 0:2006.03.03-2.fc7.ccrma hyperspec.noarch 0:6.0-2.fc7.ccrma jaaa.i386 0:0.4.2-1.fc7.ccrma jace.i386 0:0.1.0-1.fc7.ccrma jack-audio-connection-kit-example-clients.i386 0:0.103.0-0.2.1015.svn.fc7.ccrma jack-rack.i386 0:1.4.5-1.fc7.ccrma jackmix.i386 0:0.0.3-2.fc7.ccrma jamin.i386 0:0.95.0-3.fc7.ccrma japa.i386 0:0.2.1-1.fc7.ccrma jasper.i386 0:1.900.1-2.fc7 jdelay.i386 0:0.0-2.fc7.ccrma jnoise.i386 0:0.0-2.fc7.ccrma juce.i386 0:1.41-1.fc7.ccrma kde-settings.noarch 0:3.5-28.fc7.1 kde-settings-kdm.noarch 0:3.5-28.fc7.1 kdebase.i386 6:3.5.6-12.fc7 kdelibs.i386 6:3.5.6-9.fc7 kdnssd-avahi.i386 0:0.1.3-0.1.20060713svn.fc6 kmidimon.i386 0:0.4.1-2.fc7.ccrma ladspa.i386 0:1.12-8.fc7 ladspa-amb-plugins.i386 0:0.1.0-1.fc7.ccrma ladspa-blop-plugins.i386 0:0.2.8-2.fc7.ccrma ladspa-caps-plugins.i386 0:0.3.0-3.fc7.ccrma ladspa-cmt-plugins.i386 0:1.15-5.fc7.ccrma ladspa-devel.i386 0:1.12-8.fc7 ladspa-fil-plugins.i386 0:0.1.0-1.fc7.ccrma ladspa-mcp-plugins.i386 1:0.3.0-3.fc7.ccrma ladspa-rev-plugins.i386 0:0.3.1-2.fc7.ccrma ladspa-swh-plugins.i386 0:0.4.15-8.fc7 ladspa-tap-plugins.i386 0:0.7.0-2.fc7.ccrma ladspa-vco-plugins.i386 0:0.3.0-4.fc7.ccrma lash.i386 0:0.5.1-11.fc7 libdvdread.i386 0:0.9.7-2.fc7 libgig.i386 0:3.1.0-1.fc7.ccrma libid3tag.i386 0:0.15.1b-3.fc6 liblo.i386 0:0.23-12.fc7 liblrdf.i386 0:0.4.0-10.fc6 liblscp.i386 0:0.4.2-1.fc7.ccrma liboggz.i386 0:0.9.4-3.fc6 libsamplerate.i386 0:0.1.2-6.fc6 libsigc++.i386 0:1.2.7-4.fc6 libsigc++20.i386 0:2.0.17-2 libsndfile.i386 0:1.0.17-1.fc6 lilypond.i386 0:2.10.20-1.fc7 lilypond-doc.noarch 0:2.10.13-1.fc7 linuxsampler.i386 0:0.4.0-2.fc7.ccrma lirc.i386 0:0.8.1-1.fc7 lm_sensors.i386 0:2.10.3-2.fc7 lzo.i386 0:2.02-2.fc6 mammut.i386 0:0.57-1.fc7.ccrma mcontrol.i386 0:0.1.03-1.fc7.ccrma meterbridge.i386 0:0.9.2-2.fc7.ccrma mikmod.i386 0:3.2.2-2.fc7 miniaudicle.i386 0:0.1.3.6-2.fc7.ccrma muse.i386 1:0.8.1a-2.fc7.ccrma mxml.i386 0:2.2.2-7.fc6 nas.i386 0:1.9-1.fc7 nyquist.i386 0:2.36-1.fc7 openal.i386 0:0.0.9-0.9.20060204cvs.fc7 perl-Tk.i386 0:804.027-11.fc7 perl-XML-Parser.i386 0:2.34-6.1.2.2.1 perl-XML-Twig.noarch 0:3.29-1.fc7 phat.i386 0:0.4.0-3.fc7.ccrma pmidi.i386 0:1.6.0-2.fc7.ccrma portmidi.i386 0:20041117-2.fc7.ccrma qarecord.i386 0:0.0.9b-3.fc7.ccrma qmidicontrol.i386 0:0.0.1b-3.fc7.ccrma qmidiroute.i386 0:0.2.1-3.fc7.ccrma qsampler.i386 0:0.1.3-3.fc7.ccrma qsynth.i386 0:0.2.5-6.fc6 raptor.i386 0:1.4.14-3.fc7 redhat-artwork-kde.i386 0:7.0.0-9.fc7 rosegarden4.i386 0:1.4.0-1.fc7 sbcl.i386 0:1.0.5-1.fc7 seq24.i386 0:0.8.7-6.fc6 slime.i386 0:2.0-7.fc7.ccrma slime-sbcl.i386 0:2.0-7.fc7.ccrma sndobj.i386 0:2.6.3-1.fc7.ccrma soundfontcombi.i386 0:0.016-1.fc7.ccrma soundtouch.i386 0:1.3.1-7.fc7 soundtracker.i386 0:0.6.8-2.fc6 stk.i386 0:4.2.1-2.fc7.ccrma supercollider.i386 0:0.0.20070219-0.2.5866svn.fc7.ccrma supercollider-ambiem.i386 0:0.4-2.fc7.ccrma supercollider-bbcut2.i386 0:2.1-1.fc7.ccrma supercollider-beqsuite-ugens.i386 1:0.20070308-1.64svn.fc7.ccrma supercollider-bhob-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma supercollider-blackrain-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma supercollider-dewdrop.i386 0:07.0203-1.fc7.ccrma supercollider-josh-ugens.i386 1:0.20070308-1.64svn.fc7.ccrma supercollider-joshpv-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma supercollider-ljpc-classes.i386 0:0.20070308-1.64svn.fc7.ccrma supercollider-mathlib.i386 0:0.20070309-1.56svn.fc7.ccrma supercollider-mcld-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma supercollider-midifile.i386 0:0.0-1.fc7.ccrma supercollider-redclasses.i386 0:0.0-1.fc7.ccrma supercollider-reverb-ugens.i386 1:0.20070308-1.64svn.fc7.ccrma supercollider-stk-ugens.i386 0:0.20070308-1.64svn.fc7.ccrma supercollider-swingosc.i386 0:0.500-1.fc7.ccrma supercollider-world.i386 0:2007.03.08-1.fc7.ccrma sweep.i386 0:0.9.2-1.fc7 synaptic.i386 0:0.57.2-5.2.fc7 tapiir.i386 0:0.7.1-4.fc7.ccrma tcl.i386 1:8.4.13-16.fc7 timemachine.i386 0:0.3.1-2.fc7.ccrma timidity++.i386 0:2.13.2-1.2.2 tk.i386 1:8.4.13-5.fc7 vkeybd.i386 0:0.1.17a-3.fc7 whysynth-dssi.i386 0:20070418-1.fc7 wxGTK.i386 0:2.8.3-2.fc7 xdg-utils.noarch 0:1.0.1-3.fc7 xmms.i386 1:1.2.10-36.fc7 xmms-jack.i386 0:0.17-2.fc7.ccrma xmms-libs.i386 1:1.2.10-36.fc7 xorg-x11-xdm.i386 1:1.1.3-1.fc7 yass.i386 0:0.0.2-1.fc7.ccrma zynaddsubfx.i386 0:2.2.1-14.fc7 Complete! From spng.yang at gmail.com Wed Jun 6 02:03:20 2007 From: spng.yang at gmail.com (Ken YANG) Date: Wed, 06 Jun 2007 10:03:20 +0800 Subject: new libwnck make emerald fail to start Message-ID: <466615E8.4070101@gmail.com> hi all, i am using fc8 rawhide, and with libwnck: libwnck-2.19.3-2.fc8 but emerald fail to start, it need libwnck-1.so.18, so i use a trick to pass this error: ln -s libwnck-1.so.21.0.0 libwnck-1.so.18 i think emerald should be compiled with new libwnck From caillon at redhat.com Wed Jun 6 02:11:57 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Jun 2007 22:11:57 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <466615E8.4070101@gmail.com> References: <466615E8.4070101@gmail.com> Message-ID: <466617ED.7030404@redhat.com> Ken YANG wrote: > hi all, > > i am using fc8 rawhide, and with libwnck: > > libwnck-2.19.3-2.fc8 > > but emerald fail to start, it need libwnck-1.so.18, > so i use a trick to pass this error: > > ln -s libwnck-1.so.21.0.0 libwnck-1.so.18 > > i think emerald should be compiled with new libwnck > I wonder why you were able to install the RPM without it complaining about the dependencies there. That might deserve a bug. From mclasen at redhat.com Wed Jun 6 02:10:57 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Jun 2007 22:10:57 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <466617ED.7030404@redhat.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> Message-ID: <1181095857.3620.0.camel@localhost.localdomain> On Tue, 2007-06-05 at 22:11 -0400, Christopher Aillon wrote: > Ken YANG wrote: > > hi all, > > > > i am using fc8 rawhide, and with libwnck: > > > > libwnck-2.19.3-2.fc8 > > > > but emerald fail to start, it need libwnck-1.so.18, > > so i use a trick to pass this error: > > > > ln -s libwnck-1.so.21.0.0 libwnck-1.so.18 > > > > i think emerald should be compiled with new libwnck > > > > I wonder why you were able to install the RPM without it complaining > about the dependencies there. That might deserve a bug. > It is also worth pointing out that the libwnck soname is going to change once more tonight; so people might want to hold off rebuilding for one more day. Sorry about the late notice... From msaksena at marvell.com Wed Jun 6 02:43:15 2007 From: msaksena at marvell.com (Manas Saksena) Date: Tue, 05 Jun 2007 19:43:15 -0700 Subject: fedora for ARM In-Reply-To: <20070604154744.543b041d.zaitcev@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070604154744.543b041d.zaitcev@redhat.com> Message-ID: <46661F43.8060904@marvell.com> Pete Zaitcev wrote: > On Mon, 4 Jun 2007 13:10:55 +0200 (CEST), Linus Walleij wrote: > >> 1. What is the target system(s) you're using? I for one have a very vague >> understanding of what lab boards etc may be used for running ARM >> Fedora. > > This was my question too. I attended a talk by Deepak Saxena a month > ago and it looked like there's no clear leader anymore, like Netwinder > used to be. What are these RPMs for? OpenMoko? Palm? Are these systems > even binary compatible in the user mode? All the packages are built using ARMv5 soft-float with EABI. That provides a good baseline for most ARM boards/devices. To be useful, we will need to build for different CPU variants in the future (e.g., ARMv6, with or without VFP, XScale, etc.) that make use of the optimizations specific to the CPU variant. The other part of this is the kernel. Unlike x86, it is impossible to build a single kernel that will be of much use. So, either we completely punt and not build the kernel image, or we build multiple kernel packages -- one for each target board. The ARM distro will also be unlike x86 distros in that it wont be of much use to have ISOs. Instead, you probably just need the RPM package repository as a good baseline for it to be useful (along with the tools and docs to use the packages to create custom root file systems). Manas From msaksena at marvell.com Wed Jun 6 02:52:25 2007 From: msaksena at marvell.com (Manas Saksena) Date: Tue, 05 Jun 2007 19:52:25 -0700 Subject: fedora for ARM In-Reply-To: <46640036.8020607@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> Message-ID: <46662169.9060208@marvell.com> Andy Green wrote: > Hans de Goede wrote: >> Linus Walleij wrote: >>> 2. As I understand it you employ the Fedora/x86 style of not using a >>> cross-compiler to build these packages, but rather build them with ARM >>> on ARM. I am aware of some RPM derivatives like those used by >>> MontaVista, that employ a cross-compiler instead. What are your >>> thought >>> on these issues? Have you tested both solutions and come to the >>> conclusion that the all-ARM-enclosed build system is the way to go? >>> >> In my somewhat limited experience cross-compiling of software which is >> not designed for that from day one is a big pain, let alone >> cross-compiling an entire distro! There are indeed some hacks around rpm >> to make the packahes think they are being build nativly, but what I've >> seen these are very gross hacks and still break often. >> >> Native compiling definitively is the way to go, an alternative might be >> emulating the native system and building in the emulated system. > > The way to go IMO is to improve the common packages to work well with > crosscompile... ones with recent autoblah on them generally work nice > and easily. Fedora itself could do with say being able to build all the > arch binaries simply on a single build host too. I agree; IMHO, this is the way to go in the long-term. As I see it, the first step is to make sure that rpmbuild and the Fedora spec file do not come in the way. That is, if an upstream package will cross-compile, then it should be possible to cross-build the corresponding Fedora RPM. One might even look at it as a bug (albeit, at this point in time, a low priority one) if a package cannot cross-compile. Over time, it is not unreasonable to believe that this could be addressed through a set of diligent package maintainers and good packaging guidelines. > I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32) here > > http://octotux.org > > See > > http://rpm.octotux.org > > for the packages. I don't claim the spec files meet any criteria of > beauty or utility for Fedora, since I was learning packaging from > scratch while I did them, but they do crosscompile. Did you have to modify rpm/rpmbuild tools? Virtually, every Embedded Linux vendor has modified rpm to make it behave properly for cross-building etc. It would be a good idea if we can get this done right in upstream rpm. I dont know where you can find MontaVista's rpm, but you can certainly take a look at Denx's rpm (as part of their ELDK) and tsrpm by Chris Faylor (TimeSys) for two approaches to this. > Perl and Python are the holdouts I did not bother to spend more than a > day on, since they currently try to use their own target-compiled > binaries as part of their build process. They can (and have been) tamed too :-) Manas From spng.yang at gmail.com Wed Jun 6 05:58:19 2007 From: spng.yang at gmail.com (Ken YANG) Date: Wed, 06 Jun 2007 13:58:19 +0800 Subject: new libwnck make emerald fail to start In-Reply-To: <1181095857.3620.0.camel@localhost.localdomain> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> Message-ID: <46664CFB.7050606@gmail.com> Matthias Clasen wrote: > On Tue, 2007-06-05 at 22:11 -0400, Christopher Aillon wrote: >> Ken YANG wrote: >>> hi all, >>> >>> i am using fc8 rawhide, and with libwnck: >>> >>> libwnck-2.19.3-2.fc8 >>> >>> but emerald fail to start, it need libwnck-1.so.18, >>> so i use a trick to pass this error: >>> >>> ln -s libwnck-1.so.21.0.0 libwnck-1.so.18 >>> >>> i think emerald should be compiled with new libwnck >>> >> I wonder why you were able to install the RPM without it complaining >> about the dependencies there. That might deserve a bug. actually, i update libwnck through "yum update", and there is not dependencies error, anyway, as clasen said, this error will be fixed soon >> > > It is also worth pointing out that the libwnck soname is going to change > once more tonight; so people might want to hold off rebuilding for one > more day. Sorry about the late notice... thank you very much > From andy at smile.org.ua Wed Jun 6 06:21:41 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Wed, 6 Jun 2007 09:21:41 +0300 Subject: ALC861 codec and volume control Message-ID: <20070606062141.GA14773@serv.smile.org.ua> Hi! Just an idea. I'm working with one laptop (RoverBook Voyager V200) based on Uniwill's motherboard. This laptop has ALC861 codec inside. I've downloaded the datasheet for the codec and discovered the codec hasn't hardware volume control (only mute/unmute!). But the Fedora Core distribution does not install any software volume controls (I'm not trying F-7 and above). The solution is to add attached here file as ~/.asoundrc (or to similar system's file). And initialization stuff to file like rc.local: # Mute 'Front' control temporary amixer set "Front" 10% mute # Initialize new control aplay -D default -t wav /usr/share/sounds/alsa/Front_Left.wav aplay -D default -t wav /usr/share/sounds/alsa/Front_Right.wav Do anaconda make this job for us? -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua -------------- next part -------------- # set the default player to a softvolume plug pcm.!default { type plug slave.pcm "softvol" } pcm.dsp0 { type plug slave.pcm "softvol" } # soft volume device with channel named master (this channel cannot already exist) pcm.softvol { type softvol # pipe into dmix in order to mix multiple devices slave { pcm "hw:0,0" } control { name "Front Playback Volume" card 0 } } pcm.dmix-analog { type dmix ipc_key 1024 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } } From andy at warmcat.com Wed Jun 6 06:31:35 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 06 Jun 2007 07:31:35 +0100 Subject: fedora for ARM In-Reply-To: <46662169.9060208@marvell.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> Message-ID: <466654C7.7060406@warmcat.com> Manas Saksena wrote: > Andy Green wrote: >> Hans de Goede wrote: >>> Native compiling definitively is the way to go, an alternative might be >>> emulating the native system and building in the emulated system. >> >> The way to go IMO is to improve the common packages to work well with >> crosscompile... ones with recent autoblah on them generally work nice >> and easily. Fedora itself could do with say being able to build all the >> arch binaries simply on a single build host too. > > I agree; IMHO, this is the way to go in the long-term. As I see it, the > first step is to make sure that rpmbuild and the Fedora spec file do not > come in the way. That is, if an upstream package will cross-compile, > then it should be possible to cross-build the corresponding Fedora RPM. > > One might even look at it as a bug (albeit, at this point in time, a low > priority one) if a package cannot cross-compile. Over time, it is not > unreasonable to believe that this could be addressed through a set of > diligent package maintainers and good packaging guidelines. Absolutely, many upstream projects would no doubt accept small patches or autotools update requests if it was coming as part of a Fedora initiative, since everyone would benefit from it. Any Fedora box being able to be a build farm for all arches would be a great place to end up. >> I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32) >> here > Did you have to modify rpm/rpmbuild tools? Virtually, every Embedded > Linux vendor has modified rpm to make it behave properly for > cross-building etc. It would be a good idea if we can get this done > right in upstream rpm. No, nothing was needed to change in the build host rpmbuild, it works fine with rpmbuild that comes from FC6 and FC7 as it is including using rpmbuild --target to set the arch. The spec files are just normal spec files. The only trick was to define a new dir under %_topdir called devel-filesystem-%{_target_cpu}. When you package a lib for a given %{_target_cpu} (set by --target on rpmbuild), you use a script to rpm -i --root=%_topdir/devel-filesystem-%{_target_cpu} the target-compiled package and any -devel package into the *build host*. Then when you come to cross build an app that wants the target lib, you ensure in the %build that it gets configured and built with CFLAGS="-I%_topdir/devel-filesystem-%{_target_cpu}/usr/include" or whatever and likewise for LDFLAGS. Plus you need something like CROSS=/opt/%{_target_cpu}/bin/%{_target_cpu)-linux- or to set ./configure --host=%{_target_cpu} or otherwise meddle with reality so that the correct CC is used. The earlier packages have dirty hacks to get them to crosscompile in some cases, as I went on I found better ways to come at it (like recooking the configure with later autotools and just patching the things that broke from autotools version changes). On the targets I use it on I can't afford the rpm client app and libs (8MByte NOR flash for everything), so I made a mini rpm client on top of the basic rpm/cpio unpack support that is in busybox already (patch is in the SRPM for Octotux busybox). Instead of a database it snips the RPM header off installed packages and stashes them in /var/lib/rpm, and walks them to determine the requires and provides situation (re-using the existing header parsing code needed anyway for install/query). It's as scalable as it needs to be given that you only use it when the platform is too small to handle the real RPM... and throughout the actual packages themselves are genuine full normal RPMs. >> Perl and Python are the holdouts I did not bother to spend more than a >> day on, since they currently try to use their own target-compiled >> binaries as part of their build process. > > They can (and have been) tamed too :-) Yep I didn't doubt they could be tamed ;-) I was able to redefine my need for them by selecting a different app that initially wanted them though -- for perl it was binning postgrey for the C-based gps IIRC. -Andy From fedora at camperquake.de Wed Jun 6 06:41:15 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 6 Jun 2007 08:41:15 +0200 Subject: Unwanted RPM dependencies -size of glibc-common locales In-Reply-To: <4665E775.1090901@codewiz.org> References: <4663C148.1040909@codewiz.org> <46640CA4.4090001@iinet.net.au> <1180971253.9788.38.camel@erebor.boston.redhat.com> <46647828.5060205@iinet.net.au> <1180991009.9788.99.camel@erebor.boston.redhat.com> <4665CD21.70800@codewiz.org> <1181080867.14383.73.camel@aglarond.local> <4665E775.1090901@codewiz.org> Message-ID: <20070606084115.547be394@banea.int.addix.net> Hi. On Tue, 05 Jun 2007 18:45:09 -0400, Bernardo Innocenti wrote: > MS-DOS in Italian was real fun: on some errors, it would > print: "(A)nnulla, (R)iprova, (T)ralascia". The first two > translate to the familiar (C)ancel and (R)etry. The latter > word means something like "Don't bother", and I never got > to understand what it does :-) "Tell the application that the operation succeeded, even if it did not, and hope for the best." From denis at poolshark.org Wed Jun 6 06:55:27 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 06 Jun 2007 08:55:27 +0200 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <1181077186.32138.24.camel@cmn3.stanford.edu> References: <1181077186.32138.24.camel@cmn3.stanford.edu> Message-ID: <46665A5F.2090002@poolshark.org> Fernando Lopez-Lezcano wrote: > Hi all... I must be missing something obvious or I have not noticed this > behavior before... > > I'm in the process of building a bunch of packages for fedora 7 and > tried installing them on a brand new i386 install through a meta package > (ie: a package that only contains explicit dependencies using Requires: > and installs all required packages as a side effect). There _are_ > packages missing but yum happily goes ahead and installs the meta > package and the dependencies it can find, and ignores the missing > dependencies! Is this expected behavior?? > > A "package-cleanup --problems" does show the missing dependencies. How > can yum install something which does not have its dependencies met? It > seems to me like a very very basic bug in yum... A similar bug was filed against inkscape : http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242748 even though I can't reproduce the problem myself. It looks like something funky is going on... Any ideas ? From pertusus at free.fr Wed Jun 6 07:32:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 09:32:39 +0200 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <4665E902.8010106@codewiz.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> Message-ID: <20070606073239.GA2847@free.fr> On Tue, Jun 05, 2007 at 06:51:46PM -0400, Bernardo Innocenti wrote: > Patrice Dumas wrote: > >On Mon, Jun 04, 2007 at 10:52:41PM -0400, Bernardo Innocenti wrote: > > > >>- /sbin/ldconfig (yes, even this one!) > > > >I am not sure, but wouldn't that be a bit dangerous? What would be the > >gains? > > Space. And speed. Are you sure? For little apps, linking dynamically leads to a loss in performance in both size and speed. I don't know about ldconfig, though. > What would be the loss? A broken environment where only > ldconfig works, with no shell and no init, is still > unusable for recovery. Boot DVDs and USB pens are more > user friendly and flexible in these cases. Depends on the hardware, when things were installed from the net it may be different, but indeed if all the critical commands are not available, it is not a big deal. In fact busybox seems is linked statically, so in fact, if busybox is installed it could be possible to have a working recovery environment with everything but ldconfig. However, I am not sure that booting with busybox init/ shell is that easy. -- Pat From rc040203 at freenet.de Wed Jun 6 07:44:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 09:44:15 +0200 Subject: fedora for ARM In-Reply-To: <466654C7.7060406@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> Message-ID: <1181115856.29024.29.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 07:31 +0100, Andy Green wrote: > Manas Saksena wrote: > > Andy Green wrote: > >> Hans de Goede wrote: > > >> I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32) > >> here > > > Did you have to modify rpm/rpmbuild tools? Virtually, every Embedded > > Linux vendor has modified rpm to make it behave properly for > > cross-building etc. It would be a good idea if we can get this done > > right in upstream rpm. > > No, nothing was needed to change in the build host rpmbuild, it works > fine with rpmbuild that comes from FC6 and FC7 as it is including using > rpmbuild --target to set the arch. The spec files are just normal spec > files. This doesn't match at all with my experience. But .. could it be that you are not having redhat-rpm-config installed? At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm for foreign object formats and many other details. Ralf From pasik at iki.fi Wed Jun 6 07:53:58 2007 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 6 Jun 2007 10:53:58 +0300 Subject: rawhide report: 20070605 changes In-Reply-To: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> References: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> Message-ID: <20070606075358.GA20063@edu.joroinen.fi> On Tue, Jun 05, 2007 at 06:23:08AM -0400, Build System wrote: > > cryptsetup-luks-1.0.3-5.fc8 > --------------------------- > * Mon Jun 04 2007 Peter Jones - 1.0.3-5 > - Don't build static any more. > Are you going to update cryptsetup-luks to support gpg/ssl encrypted keyfiles in crypttab? Encrypted luks disk with a openssl-encrypted keyfile cdisk3 /dev/hda2 /etc/keys/keyfile luks,ssl Example from here: http://pwet.fr/man/linux/formats/crypttab I'm not sure from what version that man page is.. I'm interested in gpg encrypted keyfiles, just like loop-aes does. -- Pasi From denis at poolshark.org Wed Jun 6 08:04:59 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 06 Jun 2007 10:04:59 +0200 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070606073239.GA2847@free.fr> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> Message-ID: <46666AAB.7020005@poolshark.org> Patrice Dumas wrote: > On Tue, Jun 05, 2007 at 06:51:46PM -0400, Bernardo Innocenti wrote: >> Patrice Dumas wrote: >>> On Mon, Jun 04, 2007 at 10:52:41PM -0400, Bernardo Innocenti wrote: >>> >>>> - /sbin/ldconfig (yes, even this one!) >>> I am not sure, but wouldn't that be a bit dangerous? What would be the >>> gains? >> Space. And speed. > > Are you sure? For little apps, linking dynamically leads to a loss in > performance in both size and speed. That's a very questionable statement, and may only be true under very unusual conditions (such as: the linked dyn libraries are never shared with other executables). I don't see how the run-time execution could technically be slower, outside of the start-up time. From andy at warmcat.com Wed Jun 6 08:16:12 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 06 Jun 2007 09:16:12 +0100 Subject: fedora for ARM In-Reply-To: <1181115856.29024.29.camel@mccallum.corsepiu.local> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> Message-ID: <46666D4C.5030903@warmcat.com> Ralf Corsepius wrote: > On Wed, 2007-06-06 at 07:31 +0100, Andy Green wrote: >> Manas Saksena wrote: >>> Andy Green wrote: >>>> Hans de Goede wrote: > >>>> I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32) >>>> here >>> Did you have to modify rpm/rpmbuild tools? Virtually, every Embedded >>> Linux vendor has modified rpm to make it behave properly for >>> cross-building etc. It would be a good idea if we can get this done >>> right in upstream rpm. >> No, nothing was needed to change in the build host rpmbuild, it works >> fine with rpmbuild that comes from FC6 and FC7 as it is including using >> rpmbuild --target to set the arch. The spec files are just normal spec >> files. > This doesn't match at all with my experience. > > But .. could it be that you are not having redhat-rpm-config installed? > At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm > for foreign object formats and many other details. No it's installed, but --target works... well it works as far as setting %{_target_cpu} goes which is pretty much all I ask of it. Note you seem to need to give an arch-dist-os triplet like this $ rpmbuild -ba --target=arm-octotux-linux mISDNuser-1.2.0.spec Building target platforms: arm-octotux-linux Building for target arm-octotux-linux Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.76322 ... + make CROSS=/opt/arm/bin/arm-linux- MISDNDIR=../mISDN-1.2.0 'CFLAGS=-I/projects/octotux/packages/rpm/devel-filesystem-arm/usr/include -I/projects/octotux/packages/rpm/BUILD/mISDNuser-1.2.0/include -I/opt/arm/include -O3' CC=gcc LDFLAGS=-L/projects/octotux/packages/rpm/devel-filesystem-arm/usr/lib ... -Andy From andy at warmcat.com Wed Jun 6 08:36:34 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 06 Jun 2007 09:36:34 +0100 Subject: fedora for ARM In-Reply-To: <46666D4C.5030903@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> Message-ID: <46667212.70803@warmcat.com> Andy Green wrote: >> But .. could it be that you are not having redhat-rpm-config installed? >> At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm >> for foreign object formats and many other details. > > No it's installed, but --target works... well it works as far as setting > %{_target_cpu} goes which is pretty much all I ask of it. Note you seem > to need to give an arch-dist-os triplet like this Just to be a bit clearer, I have a single ~/.rpmmacros with everything that cares about the arch using %{_target_cpu} ... %packager Andy Green %vendor Octotux (http://octotux.org) %_signature gpg %_gpg_name Octotux Packaging %_gpg_path ~/.gnupg %_topdir /projects/octotux/packages/rpm %crosspath /opt/%{_target_cpu}/bin %develfilesystem %{_topdir}/devel-filesystem-%{_target_cpu} %__strip %crosspath/%{_target_cpu}-linux-strip %__objdump %crosspath/%{_target_cpu}-linux-objdump %__patch /usr/bin/patch -f %_use_internal_dependency_generator 0 I guess the debuginfo problem you saw was because you did not override %__strip, defnitely debuginfo rpms are generated and work fine on arm with gdb. -Andy From rc040203 at freenet.de Wed Jun 6 08:40:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 10:40:16 +0200 Subject: fedora for ARM In-Reply-To: <46666D4C.5030903@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> Message-ID: <1181119217.3431.4.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 09:16 +0100, Andy Green wrote: > Ralf Corsepius wrote: > > On Wed, 2007-06-06 at 07:31 +0100, Andy Green wrote: > >> Manas Saksena wrote: > >>> Andy Green wrote: > >>>> Hans de Goede wrote: > > > >>>> I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32) > >>>> here > >>> Did you have to modify rpm/rpmbuild tools? Virtually, every Embedded > >>> Linux vendor has modified rpm to make it behave properly for > >>> cross-building etc. It would be a good idea if we can get this done > >>> right in upstream rpm. > >> No, nothing was needed to change in the build host rpmbuild, it works > >> fine with rpmbuild that comes from FC6 and FC7 as it is including using > >> rpmbuild --target to set the arch. The spec files are just normal spec > >> files. > > This doesn't match at all with my experience. > > > > But .. could it be that you are not having redhat-rpm-config installed? > > At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm > > for foreign object formats and many other details. > > No it's installed, but --target works... Sorry, it can't work, I am sure, because many details causing breakage are hard-coded into redhat-rpm-config. Not even building cross-compilers works correctly because redhat-rpm-config breaks things. (Cf. avr-binutils's and avr-gcc's specs in Fedora). > well it works as far as setting > %{_target_cpu} goes which is pretty much all I ask of it. Note you seem > to need to give an arch-dist-os triplet like this > $ rpmbuild -ba --target=arm-octotux-linux mISDNuser-1.2.0.spec > Building target platforms: arm-octotux-linux > Building for target arm-octotux-linux > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.76322 > ... > + make CROSS=/opt/arm/bin/arm-linux- MISDNDIR=../mISDN-1.2.0 > 'CFLAGS=-I/projects/octotux/packages/rpm/devel-filesystem-arm/usr/include > -I/projects/octotux/packages/rpm/BUILD/mISDNuser-1.2.0/include > -I/opt/arm/include -O3' CC=gcc > LDFLAGS=-L/projects/octotux/packages/rpm/devel-filesystem-arm/usr/lib > ... And what is being produced? An *.i386.rpm or an *.arm.rpm? Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jun 6 08:49:44 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 6 Jun 2007 10:49:44 +0200 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <46665A5F.2090002@poolshark.org> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <46665A5F.2090002@poolshark.org> Message-ID: <20070606104944.2947c228@python3.es.egwn.lan> Denis Leroy wrote : > Fernando Lopez-Lezcano wrote: > > Hi all... I must be missing something obvious or I have not noticed this > > behavior before... > > > > I'm in the process of building a bunch of packages for fedora 7 and > > tried installing them on a brand new i386 install through a meta package > > (ie: a package that only contains explicit dependencies using Requires: > > and installs all required packages as a side effect). There _are_ > > packages missing but yum happily goes ahead and installs the meta > > package and the dependencies it can find, and ignores the missing > > dependencies! Is this expected behavior?? > > > > A "package-cleanup --problems" does show the missing dependencies. How > > can yum install something which does not have its dependencies met? It > > seems to me like a very very basic bug in yum... > > A similar bug was filed against inkscape : > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242748 > > even though I can't reproduce the problem myself. It looks like > something funky is going on... Any ideas ? This is quite similar to a report I got about cinelerra from freshrpms not running. The user installed it with yum, but managed to get broken dependencies because of different ffmpeg packages from rpm.livna.org and freshrpms somehow... I wasn't able to reproduce either, but something weird does seem to be going on :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.42 0.42 0.37 From andy at warmcat.com Wed Jun 6 08:54:08 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 06 Jun 2007 09:54:08 +0100 Subject: fedora for ARM In-Reply-To: <1181119217.3431.4.camel@mccallum.corsepiu.local> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> Message-ID: <46667630.3040303@warmcat.com> Ralf Corsepius wrote: > On Wed, 2007-06-06 at 09:16 +0100, Andy Green wrote: >> Ralf Corsepius wrote: >>> On Wed, 2007-06-06 at 07:31 +0100, Andy Green wrote: >>>> Manas Saksena wrote: >>>>> Andy Green wrote: >>>>>> Hans de Goede wrote: >>>>>> I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32) >>>>>> here >>>>> Did you have to modify rpm/rpmbuild tools? Virtually, every Embedded >>>>> Linux vendor has modified rpm to make it behave properly for >>>>> cross-building etc. It would be a good idea if we can get this done >>>>> right in upstream rpm. >>>> No, nothing was needed to change in the build host rpmbuild, it works >>>> fine with rpmbuild that comes from FC6 and FC7 as it is including using >>>> rpmbuild --target to set the arch. The spec files are just normal spec >>>> files. >>> This doesn't match at all with my experience. >>> >>> But .. could it be that you are not having redhat-rpm-config installed? >>> At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm >>> for foreign object formats and many other details. >> No it's installed, but --target works... > > Sorry, it can't work, I am sure, because many details causing breakage > are hard-coded into redhat-rpm-config. Not even building cross-compilers > works correctly because redhat-rpm-config breaks things. > (Cf. avr-binutils's and avr-gcc's specs in Fedora). It works fine, and has done for over a year. The http://rpm.octotux.org repo is full of the fruits of it and in fact my mailserver runs on an arm box with these packages, so this mail itself passes through the results of such a cross build. I think you're being a bit hasty with the "can't work" there. >> well it works as far as setting >> %{_target_cpu} goes which is pretty much all I ask of it. Note you seem >> to need to give an arch-dist-os triplet like this > >> $ rpmbuild -ba --target=arm-octotux-linux mISDNuser-1.2.0.spec >> Building target platforms: arm-octotux-linux >> Building for target arm-octotux-linux >> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.76322 >> ... >> + make CROSS=/opt/arm/bin/arm-linux- MISDNDIR=../mISDN-1.2.0 >> 'CFLAGS=-I/projects/octotux/packages/rpm/devel-filesystem-arm/usr/include >> -I/projects/octotux/packages/rpm/BUILD/mISDNuser-1.2.0/include >> -I/opt/arm/include -O3' CC=gcc >> LDFLAGS=-L/projects/octotux/packages/rpm/devel-filesystem-arm/usr/lib >> ... > > And what is being produced? An *.i386.rpm or an *.arm.rpm? ... Checking for unpackaged file(s): /usr/lib/rpm/check-files /projects/octotux/packages/rpm/BUILD/mISDNuser-arm-root Wrote: /projects/octotux/packages/rpm/SRPMS/mISDNuser-1.2.0-163.src.rpm Wrote: /projects/octotux/packages/rpm/RPMS/arm/mISDNuser-1.2.0-163.arm.rpm Wrote: /projects/octotux/packages/rpm/RPMS/arm/mISDNuser-devel-1.2.0-163.arm.rpm Wrote: /projects/octotux/packages/rpm/RPMS/arm/mISDNuser-lib-1.2.0-163.arm.rpm Wrote: /projects/octotux/packages/rpm/RPMS/arm/mISDNuser-debuginfo-1.2.0-163.arm.rpm -Andy From fedora at camperquake.de Wed Jun 6 09:03:02 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 6 Jun 2007 11:03:02 +0200 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <20070606104944.2947c228@python3.es.egwn.lan> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <46665A5F.2090002@poolshark.org> <20070606104944.2947c228@python3.es.egwn.lan> Message-ID: <20070606110302.60a24922@banea.int.addix.net> Hi. On Wed, 6 Jun 2007 10:49:44 +0200, Matthias Saou wrote: > This is quite similar to a report I got about cinelerra from freshrpms > not running. The user installed it with yum, but managed to get broken > dependencies because of different ffmpeg packages from rpm.livna.org > and freshrpms somehow... Media packages from livna and freshrpms do not mix, im my experience. From steve at nexusuk.org Wed Jun 6 09:11:34 2007 From: steve at nexusuk.org (Steve Hill) Date: Wed, 6 Jun 2007 10:11:34 +0100 (BST) Subject: Unmounting removable media under Gnome Message-ID: When you insert a CD or DVD into your drive, Gnome automounts it. Nautilus allows you to eject the disc but doesn't seem to have an option to unmount it without ejecting at the same time. This causes some interoperability problems when using non-Gnome CD/DVD burning software, CD rippers, etc. which will often give up if your drive is mounted rather than unmounting it first. For example, if you insert an audio CD which also has a data session, the data session is mounted and trying to rip the CD using Grip results in a failure. Similarly, inserting a CD-RW or DVD-RW which has data on it results in it being immediately mounted which means that non-Gnome software, such as k3b, cannot erase the media. Additionally, it appears that the logged in user does not have permission to umount the disc - the only work around seems to be to open a terminal, log in as root and manually umount the device. Are there any good reasons why Nautilus should not have an option to unmount without ejecting? -- - Steve xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence From denis at poolshark.org Wed Jun 6 09:14:13 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 06 Jun 2007 11:14:13 +0200 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <20070606110302.60a24922@banea.int.addix.net> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <46665A5F.2090002@poolshark.org> <20070606104944.2947c228@python3.es.egwn.lan> <20070606110302.60a24922@banea.int.addix.net> Message-ID: <46667AE5.9030008@poolshark.org> Ralf Ertzinger wrote: > Hi. > > On Wed, 6 Jun 2007 10:49:44 +0200, Matthias Saou wrote: > >> This is quite similar to a report I got about cinelerra from freshrpms >> not running. The user installed it with yum, but managed to get broken >> dependencies because of different ffmpeg packages from rpm.livna.org >> and freshrpms somehow... > > Media packages from livna and freshrpms do not mix, im my experience. No but i think that's a different problem. Here we're seeing systems left with broken deps after a successful yum installation. From rc040203 at freenet.de Wed Jun 6 10:24:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 12:24:38 +0200 Subject: fedora for ARM In-Reply-To: <46667212.70803@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <46667212.70803@warmcat.com> Message-ID: <1181125479.3222.12.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 09:36 +0100, Andy Green wrote: > Andy Green wrote: > > >> But .. could it be that you are not having redhat-rpm-config installed? > >> At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm > >> for foreign object formats and many other details. > > > > No it's installed, but --target works... well it works as far as setting > > %{_target_cpu} goes which is pretty much all I ask of it. Note you seem > > to need to give an arch-dist-os triplet like this > > Just to be a bit clearer, I have a single ~/.rpmmacros with everything > that cares about the arch using %{_target_cpu} ... > > %packager Andy Green > %vendor Octotux (http://octotux.org) > %_signature gpg > %_gpg_name Octotux Packaging > %_gpg_path ~/.gnupg > %_topdir /projects/octotux/packages/rpm > %crosspath /opt/%{_target_cpu}/bin > %develfilesystem %{_topdir}/devel-filesystem-%{_target_cpu} > %__strip %crosspath/%{_target_cpu}-linux-strip > %__objdump %crosspath/%{_target_cpu}-linux-objdump > %__patch /usr/bin/patch -f OK, this explains one half: You are switching off many of the implicitly presets. > %_use_internal_dependency_generator 0 And this is the other half: You are disabling a lot of the hard-coded magic. > I guess the debuginfo problem you saw was because you did not override > %__strip, Not quite. It's because a toolchain package contains both host and target binaries and the redhat-* scripts don't distinguish between host and target binaries, but blindly run "one strip" on all binaries they find. This doesn't building rpms to abort, as long as target and host binary formats are sufficiently compatible. Instead it causes *debuginfo*.rpms to contain both host and target sources. If host and target object format differ, rpmbuild bombs out. AFAIS, you are building pure target binary packages. > defnitely debuginfo rpms are generated and work fine on arm > with gdb. Not unlikely, but you should check your buildlogs for error/warning messages and your resulting rpms for correctness. Ralf From buildsys at redhat.com Wed Jun 6 10:41:02 2007 From: buildsys at redhat.com (Build System) Date: Wed, 6 Jun 2007 06:41:02 -0400 Subject: rawhide report: 20070606 changes Message-ID: <200706061041.l56Af214004293@porkchop.devel.redhat.com> New package audio-entropyd Generate entropy from audio output New package berusky Berusky, 2D logic game New package berusky-data A datafile for Berusky New package callweaver The Truly Open Source PBX New package elsa ELSA is an enhanced Linux system accounting New package empathy GNOME Instant Messaging Client New package keyjnote A program that displays presentation slides New package libpciaccess PCI access library New package online-desktop Desktop built around web sites and online services New package perl-Catalyst-Manual Catalyst web framework manual New package perl-Catalyst-Plugin-SubRequest Make subrequests to actions in Catalyst New package ps2eps PS-to-EPS converter New package python-TurboMail Multi-threaded mail queue manager for TurboGears applications New package telepathy-idle IRC connection manager for Telepathy New package yum-presto Presto plugin for yum Updated Packages: apcupsd-3.14.1-1.fc8 -------------------- * Tue May 29 2007 - Orion Poplawski - 3.14.1-1 - Update to 3.14.1 aplus-fsf-4.20.2-19.fc8 ----------------------- * Tue Jun 05 2007 Jochen Schmitt 4.20.2-19 - Correctiog come typos (#242304) at-spi-1.19.3-1.fc8 ------------------- * Mon Jun 04 2007 Matthias Clasen - 1.19.3-1 - Update to 1.19.3 - Add a -python subpackage beryl-core-0.2.1-1.fc8 ---------------------- * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - belated update to 0.2.1 - fix up ppc64 builds (#239183) beryl-manager-0.2.1-1.fc8 ------------------------- * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 beryl-plugins-0.2.1-1.fc8 ------------------------- * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 * Fri Feb 23 2007 Jarod Wilson 0.1.9999.2-2 - Drop unnecessary dep on fedora-logos (#229793) - Ugh, fine. Build the unsupported plugins (#227539) beryl-settings-0.2.1-1.fc8 -------------------------- * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 * Tue Feb 20 2007 Jarod Wilson 0.1.9999.2-1 - beryl 0.1.9999.2 (aka 0.2.0-rc2) bibletime-1.6.4-2.fc8 --------------------- * Fri May 04 2007 David Anderson 1.6.4-2 - 1.6.4 compiz-0.3.6-10.fc8 ------------------- * Mon Jun 04 2007 Matthias Clasen - 0.3.6-10 - Rebuild against new libwnck * Sat Apr 21 2007 Matthias Clasen - 0.3.6-9 - Don't install INSTALL dasher-4.5.1-1.fc8 ------------------ * Mon Jun 04 2007 Matthias Clasen - 4.5.1-1 - Update to 4.5.1 dbmail-2.2.5-2.fc8 ------------------ * Tue Jun 05 2007 Bernard Johnson 2.2.5-2 - fix %setup directory * Tue Jun 05 2007 Bernard Johnson 2.2.5-1 - 2.2.5 - change method of restarting daemons to that suggested in dbmail bug #600 deltarpm-3.4-3.fc8 ------------------ * Tue Jun 05 2007 Jeremy Katz - 3.4-3 - include colored binaries from non-multilib-dirs so that deltas can work on multilib platforms * Wed May 09 2007 Adam Jackson 3.4-2 - Add -a flag to work around multilib ignorance. (#238964) deskbar-applet-2.19.3-1.fc8 --------------------------- * Tue Jun 05 2007 Luke Macken - 2.19.3-1 - Latest upstream release desktop-file-utils-0.13-1.fc8 ----------------------------- * Tue Jun 05 2007 Matthias Clasen - 0.13-1 - Update to 0.13, which features a completely rewritten validator devhelp-0.14-4.fc8 ------------------ * Tue Jun 05 2007 - Bastien Nocera - 0.14-4 - Rebuild again devilspie-0.20.2-2.fc8 ---------------------- * Tue Jun 05 2007 Sebastian Vahl 0.20.2-2 - rebuild against new libwnck dhcdbd-2.8-1.fc8 ---------------- * Tue Jun 05 2007 David Cantrell - 2.8-1 - Use dbus to avoid waking up so often (#218406) digikam-0.9.2-0.3.beta3.fc8 --------------------------- * Wed Jun 06 2007 Marcin Garski 0.9.2-0.3.beta3 - Fix .desktop category * Wed Jun 06 2007 Marcin Garski 0.9.2-0.2.beta3 - Fix broken compilation caused by Exiv2 dependency * Tue Jun 05 2007 Marcin Garski 0.9.2-0.1.beta3 - Update to version 0.9.2-beta3 (merge with digikamimageplugins) - Update description dirac-0.7.0-1..fc8 ------------------ * Fri Jun 15 2007 kwizart < kwizart at gmail.com > - 0.7.0-1 - Update to 0.7.0 elinks-0.11.3-1.fc8 ------------------- * Tue Jun 05 2007 Ondrej Vasik 0.11.3-1 - update to new upstream version - removed patch for #210103 , included in upstream release - updated patch elinks-0.11.1-negotiate.patch to pass build epiphany-extensions-2.19.2-2 ---------------------------- * Tue Jun 05 2007 Peter Gordon - 2.19.2-2 - Add %{_target_cpu} to versioned Firefox dependency to avoid multilib updating issues such as bug 242318, wherein the 32-bit older Firefox build matches the versioned dependency, but the updated 64-bit Firefox build matches the 64-bit shared library dependencies. (Thanks to Frederik Hertzum for the bug report.) espeak-1.25-1.fc8 ----------------- * Tue Jun 05 2007 Francois Aucamp - 1.25-1 - Update to version 1.25 evolution-2.11.3-2.fc8 ---------------------- * Tue Jun 05 2007 Matthew Barnes - 2.11.3-2.fc8 - Fix an invalid g_free() that was causing lock-ups. * Mon Jun 04 2007 Matthew Barnes - 2.11.3-1.fc8 - Update to 2.11.3 - Evolution no longer has versioned file names. - Remove patch for RH bug #202289 (fixed upstream). - Remove patch for RH bug #235878 (fixed upstream). - Remove patch for RH bug #238155 (fixed upstream). - Remove patch for RH bug #240147 (fixed upstream). evolution-connector-2.11.3.1-1.fc8 ---------------------------------- * Mon Jun 04 2007 Matthew Barnes - 2.11.3.1-1.fc8 - Update to 2.11.3.1 - Add patch for GNOME bug #444101 (new compiler warnings). - Remove patch for GNOME bug #439579 (fixed upstream). fortune-mod-1.99.1-9.fc8 ------------------------ * Tue Jun 05 2007 Jeff Sheltren 1.99.1-9 - Rebuild fuse-2.6.5-2.fc8 ---------------- * Wed Jun 06 2007 Peter Lemenkov 2.6.5-2 - Add BR libselinux-devel (bug #235145) - Config files properly marked as config (bug #211122) * Sat May 12 2007 Peter Lemenkov 2.6.5-1 - Version 2.6.5 * Thu Feb 22 2007 Peter Lemenkov 2.6.3-2 - Fixed bug #229642 gallery2-2.2-0.6.svn20070506.fc8 -------------------------------- * Tue Jun 05 2007 John Berninger - 2.2-0.6.svn20070506 - Fix escaping syntax problem in post scriptlet * Tue May 15 2007 John Berninger - 2.2-0.5.svn20070506 - README file update and new build gdal-1.4.1-4.fc8 ---------------- * Tue Jun 05 2007 Balint Cristian 1.4.1-4 - re-build. gdm-1:2.19.2-1.fc8 ------------------ * Tue Jun 05 2007 Matthias Clasen - 1:2.19.2-1 - Update to 2.19.2 gnome-applets-1:2.18.0-9.fc8 ---------------------------- * Mon Jun 04 2007 Matthias Clasen - 1:2.18.0-9 - Rebuild against new libwnck gnome-games-1:2.19.3-1.fc8 -------------------------- * Mon Jun 04 2007 Matthias Clasen - 1:2.19.3-1 - Update to 2.19.3 - Add a BuildRequires for gstreamer gnome-panel-2.19.3-3.fc8 ------------------------ * Tue Jun 05 2007 Matthias Clasen - 2.19.3-3 - Rebuild again gnome-power-manager-2.19.2-2.fc8 -------------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.19.2-2 - Rebuild against new libwnck gnome-python2-desktop-2.18.0-3.fc8 ---------------------------------- * Mon Jun 04 2007 Matthias Clasen - 2.18.0-3 - Rebuild against new libwnck gnome-python2-extras-2.19.1-1.fc8 --------------------------------- * Tue Jun 05 2007 Matthew Barnes - 2.19.1-1.fc8 - Update to 2.19.1 * Fri Jun 01 2007 Matthew Barnes - 2.14.3-3.fc8 - Rebuild against firefox-2.0.0.4. * Wed Apr 11 2007 Matthew Barnes - 2.14.3-2.fc7 - Rebuild against firefox-2.0.0.3. - Require exactly 2.0.0.3 so we're notified of dependency breaks. gnome-system-monitor-2.19.3-2.fc8 --------------------------------- * Tue Jun 05 2007 Matthias Clasen - 2.19.3-2 - Rebuild gok-1.2.2-4.fc8 --------------- * Tue Jun 05 2007 Matthias Clasen - 1.2.2-4 - Rebuild again gscan2pdf-0.9.10-1.fc8 ---------------------- * Tue Jun 05 2007 Bernard Johnson - 0.9.10-1 - v 0.9.10 gstreamer-0.10.13-2.fc8 ----------------------- * Tue Jun 05 2007 - Bastien Nocera - 0.10.13-2 - Remove upstreamed docs patch gstreamer-plugins-base-0.10.13-2.fc8 ------------------------------------ * Tue Jun 05 2007 - Bastien Nocera - 0.10.13-2 - Add missing files * Tue Jun 05 2007 - Bastien Nocera - 0.10.13-1 - Update to 0.10.13 hunspell-lt-1.1-1.20070510cvs.fc8 --------------------------------- hunspell-pl-0.20070605-1.fc8 ---------------------------- * Tue Jun 05 2007 Caolan McNamara - 0.20070605-1 - next version jd-1.9.5-0.3.svn1110.fc8 ------------------------ * Tue Jun 05 2007 Mamoru Tasaka - 1.9.5-0.3.svn1110 - svn 1110 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta070528 * Tue May 22 2007 Mamoru Tasaka - 1.9.5-0.2.beta070516 - Support C/Migemo search kazehakase-0.4.7-3.fc8 ---------------------- * Tue Jun 05 2007 Mamoru Tasaka - 0.4.7-3 - Patch to follow the newest GLib symbol * Tue Jun 05 2007 Mamoru Tasaka - 0.4.7-2 - Parse GLib version dependency kernel-2.6.21-1.3207.fc8 ------------------------ * Tue Jun 05 2007 Dave Jones - 2.6.22-rc4 kipi-plugins-0.1.4-0.1.beta1.fc8 -------------------------------- * Tue Jun 05 2007 Rex Dieter 0.1.4-0.1.beta1 - kipi-plugins-0.1.4-beta1 koji-1.2.2-1.fc8 ---------------- * Tue Jun 05 2007 Mike Bonnet - 1.2.2-1 - only allow admins to perform non-scratch builds from srpm - bug fixes to the cmd-line and web UIs - don't allow ExclusiveArch to expand the archlist (bz#239359) - add a summary line stating whether the task succeeded or failed to the end of the "watch-task" output - add a search box to the header of every page in the web UI - new koji download-build command (patch provided by Dan Berrange) - patch /etc/koji.conf so the cli will work out-of-the-box with Fedora Koji libnotify-0.4.4-5.fc8 --------------------- * Tue Jun 05 2007 Matthias Clasen - 0.4.4-5 - Temporarily remove the notification-daemon requires for bootstrapping libwnck-2.19.3.1-1.fc8 ---------------------- * Tue Jun 05 2007 Matthias Clasen - 2.19.3.1-1 - Update to 2.19.3.1 liferea-1.2.16b-1.fc8 --------------------- * Tue Jun 05 2007 Brian Pepple - 1.2.16b-1 - Update to 1.2.16b. m4-1.4.9-1.fc8 -------------- * Tue Jun 05 2007 Vitezslav Crhonek - 1.4.9-1 - Update to m4-1.4.9 mono-1.2.4-1.fc8 ---------------- * Sat Jun 02 2007 Christopher Aillon 1.2.4-1 - Update to 1.2.4 * Sun Apr 01 2007 Matthias Clasen - 1.2.3-3 - Fix a spec format error (#210633) * Thu Mar 29 2007 Alexander Larsson - 1.2.3-2 - Also build on alpha (#232268) multiget-1.1.4-7.fc8 -------------------- nautilus-2.19.3-1.fc8 --------------------- * Tue Jun 05 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 * Sat May 19 2007 Matthias Clasen - 2.19.2-1 - Update to 2.19.2 * Wed Apr 11 2007 Alexander Larsson - 2.18.1-2 - Fix memleak (#235696) notification-daemon-0.3.7-4.fc8 ------------------------------- * Tue Jun 05 2007 Matthias Clasen - 0.3.7-4 - Rebuild again orca-2.19.3-1.fc8 ----------------- * Tue Jun 05 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 perl-Ace-1.91-2.fc8 ------------------- perl-Archive-Zip-1.20-1 ----------------------- * Tue Jun 05 2007 Robin Norwood - 1.20-1 - Update to latest CPAN version: 1.20 - Fix broken changelog * Wed Jul 12 2006 Jesse Keating - 1.16-1.2.1 - rebuild * Fri Feb 03 2006 Jason Vas Dias - 1.16-1.2 - rebuilt for new perl-5.8.8 perl-AutoClass-1_01-2.fc8 ------------------------- perl-Bio-ASN1-EntrezGene-1.091-3.fc8 ------------------------------------ perl-Convert-Binary-C-0.67-4.fc8 -------------------------------- perl-Data-Stag-0.10-2.fc8 ------------------------- perl-GD-SVG-0.28-1.fc8 ---------------------- perl-Graph-0.81-1.fc8 --------------------- perl-Math-Derivative-0.01-2.fc8 ------------------------------- perl-Math-Spline-0.01-1.fc8 --------------------------- perl-PostScript-0.06-1.fc8 -------------------------- perl-SVG-2.33-2.fc8 ------------------- * Fri Mar 23 2007 Alex Lancaster 2.33-2 - Filter extra non-explicit (SVG::Element) provides * Wed Mar 14 2007 Alex Lancaster 2.33-1 - Update to 2.33 - Fix rpmlint issues * Wed Apr 06 2005 Hunter Matthews 2.32-2 - Review suggestions from Jos?? Pedro Oliveira perl-SVG-Graph-0.01-6.fc8 ------------------------- perl-Text-Shellwords-1.08-1.fc8 ------------------------------- perl-XML-DOM-XPath-0.13-1.fc8 ----------------------------- perl-XML-Writer-0.602-3.fc8 --------------------------- perl-XML-XPathEngine-0.08-1.fc8 ------------------------------- perl-bioperl-run-1.5.2_100-2.fc8 -------------------------------- pirut-1.3.8-1.fc8 ----------------- * Tue Jun 05 2007 Jeremy Katz - 1.3.8-1 - Fix error message formatting (lmacken, #238372) - Catch more errors (#240711, #241043, #242476) - Avoid a case where we could install with broken deps (#242368) pm-utils-0.99.3-7.fc8 --------------------- * Tue Jun 05 2007 Phil Knirsch - 0.99.3-7 - Bump release and rebuild postfix-2:2.4.3-1.fc8 --------------------- * Tue Jun 05 2007 Thomas Woerner 2:2.4.3-1.fc8 - allow to build without LDAP but SASL2 support (rhbz#216792) * Tue Jun 05 2007 Thomas Woerner 2:2.4.3-1 - new stable version 2.4.3 - enabled mysql support (rhbz#185515) - dropped build requirements for gawk, ed and sed revisor-2.0.3.7-1.fc8 --------------------- * Tue Jun 05 2007 Jeroen van Meeuwen 2.0.3.7-1 - Major bugfixes and speed improvements - tagging for reference purposes - Added /etc/revisor/comps-fc6.xml as a %config file shadow-utils-2:4.0.18.1-15.fc8 ------------------------------ * Wed Jun 06 2007 Peter Vrabec 2:4.0.18.1-15 - fix infinitive loop if there are duplicate entries in /etc/group (#240915) * Wed Jun 06 2007 Peter Vrabec 2:4.0.18.1-14 - do not run find_new_uid() twice and use getpwuid() to check UID uniqueness (#236871) smartmontools-1:5.37-3.fc8 -------------------------- * Tue Jun 05 2007 Tomas Smetana - 1:5.37-3 - fix #241385 - smartmontools missing dependency on mailx - fix #241388 - unneeded smartd-conf.py[co] installed in /usr/sbin sturmbahnfahrer-1.4-1.fc8 ------------------------- * Tue Jun 05 2007 Hans de Goede 1.4-1 - New upstream release 1.4 - Drop all patches (all upstream now) synaptic-0.57.2-8.fc8 --------------------- * Tue Jun 05 2007 Axel Thimm - 0.57.2-8 - Rebuild again, apt had to be manually pulled into the buildroot. telepathy-filesystem-0.0.1-2.fc8 -------------------------------- tetex-3.0-41.fc8 ---------------- * Tue Jun 05 2007 Jindrich Novy 3.0-41 - don't mess up file contexts while running texhash (#235032) trackballs-1.1.4-1.fc8 ---------------------- * Tue Jun 05 2007 Hans de Goede 1.1.4-1 - New upstream release 1.1.4 vim-2:7.1.2-1.fc8 ----------------- * Mon Jun 04 2007 Karsten Hopp 7.1.2-1 - vim 7.1 - drop 240 patches * Tue May 22 2007 Karsten Hopp 7.0.235-1 - Don't wake up system with blinking gvim cursor: http://www.linuxpowertop.org/known.php * Mon Apr 30 2007 Karsten Hopp 7.0.235-1 - update to patchlevel 235, fixes modeline issues w3c-markup-validator-0.8.0-0.1.b2.fc8 ------------------------------------- * Tue Jun 05 2007 Ville Skytt?? - 0.8.0-0.1.b2 - 0.8.0b2. xinetd-2:2.3.14-12.fc8 ---------------------- * Wed May 16 2007 Jan Safranek - 2:2.3.14-12 - bind IPv6 socket by default and switch to IPv4 on error (bz#195265) - service xinetd status returns actual status (bz#232887) - use ssize_t instead of int (bz#211776) From jnovy at redhat.com Wed Jun 6 10:38:34 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 06 Jun 2007 12:38:34 +0200 Subject: mc missing from F7 DVD? Message-ID: <1181126314.3214.28.camel@dhcp-lab-186.brq.redhat.com> Hi, I have feedback from the Midnight Commander users who are pretty angry because of missing mc from the F7 DVD. Is there a reason to not to include a former Core package to the F7 DVD? How to prevent that it happens again for F8? Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jfrieben at gmx.de Wed Jun 6 10:52:21 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Wed, 06 Jun 2007 12:52:21 +0200 Subject: mc missing from F7 DVD? In-Reply-To: <1181126314.3214.28.camel@dhcp-lab-186.brq.redhat.com> References: <1181126314.3214.28.camel@dhcp-lab-186.brq.redhat.com> Message-ID: <20070606105221.321950@gmx.net> > Hi, > > I have feedback from the Midnight Commander users who are pretty angry > because of missing mc from the F7 DVD. Is there a reason to not to > include a former Core package to the F7 DVD? How to prevent that it > happens again for F8? > > Thanks, > Jindrich There are --many-- packages missing from the F7 DVD which were part of "Core", e.g. lam, gnuplot, epiphany (the default GNOME web browser!), and so on. What is strange about this is that these packages have not even been replaced by more popular packages from Fedora Extras. The size of the DVD image shrank down to about 2.5 GB when the previous one was about 1 GB more. As a consequence, 2 GB of DVD space are wasted. Given that there are ever more and faster mirrors out there and bittorrent can be used in many cases, it's hard to see the rationale behind this choice. -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From andy at warmcat.com Wed Jun 6 11:04:25 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 06 Jun 2007 12:04:25 +0100 Subject: fedora for ARM In-Reply-To: <1181125479.3222.12.camel@mccallum.corsepiu.local> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <46667212.70803@warmcat.com> <1181125479.3222.12.camel@mccallum.corsepiu.local> Message-ID: <466694B9.6000805@warmcat.com> Ralf Corsepius wrote: > On Wed, 2007-06-06 at 09:36 +0100, Andy Green wrote: >> Andy Green wrote: >> >>>> But .. could it be that you are not having redhat-rpm-config installed? >>>> At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm >>>> for foreign object formats and many other details. >>> No it's installed, but --target works... well it works as far as setting >>> %{_target_cpu} goes which is pretty much all I ask of it. Note you seem >>> to need to give an arch-dist-os triplet like this >> Just to be a bit clearer, I have a single ~/.rpmmacros with everything >> that cares about the arch using %{_target_cpu} ... >> >> %packager Andy Green >> %vendor Octotux (http://octotux.org) >> %_signature gpg >> %_gpg_name Octotux Packaging >> %_gpg_path ~/.gnupg >> %_topdir /projects/octotux/packages/rpm >> %crosspath /opt/%{_target_cpu}/bin >> %develfilesystem %{_topdir}/devel-filesystem-%{_target_cpu} >> %__strip %crosspath/%{_target_cpu}-linux-strip >> %__objdump %crosspath/%{_target_cpu}-linux-objdump >> %__patch /usr/bin/patch -f > OK, this explains one half: You are switching off many of the implicitly > presets. Well overriding them according to the arch, yes. >> %_use_internal_dependency_generator 0 > And this is the other half: You are disabling a lot of the hard-coded magic. No, this is only turned off because the library rpm used to parse ELF internally segfaulted when dealing with avr32 ELF... it worked fine without this, using the internal one, for arm for example. >> I guess the debuginfo problem you saw was because you did not override >> %__strip, > Not quite. It's because a toolchain package contains both host and > target binaries and the redhat-* scripts don't distinguish between host > and target binaries, but blindly run "one strip" on all binaries they > find. This doesn't building rpms to abort, as long as target and host > binary formats are sufficiently compatible. Instead it causes > *debuginfo*.rpms to contain both host and target sources. But strip runs only on built executables/libraries that are going into the binary packages. There are packages that produce host-compiled binaries during the build, but they aren't often (I never saw it) packaged. I can remember seeing little host-compiled utilities built in some packages as part of the build process, but they are run as part of the build and not packaged, so they should not be stripped. > If host and target object format differ, rpmbuild bombs out. I have never experienced that, so I guess it must be okay for all the packages I addressed, at least. And that includes some big stuff like db4, postfix, asterisk, gdb, linux itself... > AFAIS, you are building pure target binary packages. Right. >> defnitely debuginfo rpms are generated and work fine on arm >> with gdb. > Not unlikely, but you should check your buildlogs for error/warning > messages and your resulting rpms for correctness. My scripts will stop dead if rpmbuild chokes so I am pretty sure none of my packages so far fell into this unusual category of building and packaging apps compiled for both host and target. Anyway the end result is that with a macro setup like this it is quite possible to tell rpmbuild --target= and if you had the right cross compilers installed you can end up with blah..rpm binaries for any arch from a single specfile and source. That is cool! If Fedora wanted to address it I have no doubt that they can fix/meddle with the "official" macros and get it to work cleaner, but the whole deal can and does work soup to nuts with just ~/.rpmmacros set up. -Andy From dakingun at gmail.com Wed Jun 6 11:16:25 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Wed, 6 Jun 2007 07:16:25 -0400 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <46667AE5.9030008@poolshark.org> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <46665A5F.2090002@poolshark.org> <20070606104944.2947c228@python3.es.egwn.lan> <20070606110302.60a24922@banea.int.addix.net> <46667AE5.9030008@poolshark.org> Message-ID: On 6/6/07, Denis Leroy wrote: > Ralf Ertzinger wrote: > > Hi. > > > > On Wed, 6 Jun 2007 10:49:44 +0200, Matthias Saou wrote: > > > >> This is quite similar to a report I got about cinelerra from freshrpms > >> not running. The user installed it with yum, but managed to get broken > >> dependencies because of different ffmpeg packages from rpm.livna.org > >> and freshrpms somehow... > > > > Media packages from livna and freshrpms do not mix, im my experience. > > No but i think that's a different problem. Here we're seeing systems > left with broken deps after a successful yum installation. > Right, that also explains why I got this bug report, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242233 Deji. From pasik at iki.fi Wed Jun 6 11:30:24 2007 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 6 Jun 2007 14:30:24 +0300 Subject: Anaconda/installer aligning partitions during install and SAN performance Message-ID: <20070606113024.GB20063@edu.joroinen.fi> Hi! When anaconda initializes a disk and creates a new partition (the default partition layout), the first partition is set to start from the sector 63. In normal cases and with normal harddisks this is fine. But if your disk is a SAN LUN (iSCSI, FC), this could cause all the IO to be "misaligned", causing a performance drop. Many SAN arrays want the partitions to be aligned on a 8 kB boundary, or some even on 64 kB boundary. Would it cause problems if anaconda automatically aligns partitions to start from a sector that is a multiple of 8 (or even 64 kB) ? Or maybe add an option to specify how to align the partitions? VMware document about aligning partitions for ESX/VMFS for optimal performance: http://www.vmware.com/pdf/esx3_partition_align.pdf Comments welcome! -- Pasi From pasik at iki.fi Wed Jun 6 11:37:29 2007 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 6 Jun 2007 14:37:29 +0300 Subject: Anaconda/installer aligning partitions during install and SAN performance In-Reply-To: <20070606113024.GB20063@edu.joroinen.fi> References: <20070606113024.GB20063@edu.joroinen.fi> Message-ID: <20070606113729.GC20063@edu.joroinen.fi> On Wed, Jun 06, 2007 at 02:30:24PM +0300, Pasi K?rkk?inen wrote: > Hi! > > When anaconda initializes a disk and creates a new partition (the default partition layout), > the first partition is set to start from the sector 63. > > In normal cases and with normal harddisks this is fine. > > But if your disk is a SAN LUN (iSCSI, FC), this could cause all the IO to be > "misaligned", causing a performance drop. Many SAN arrays want the partitions > to be aligned on a 8 kB boundary, or some even on 64 kB boundary. > > Would it cause problems if anaconda automatically aligns partitions to start > from a sector that is a multiple of 8 (or even 64 kB) ? Or maybe add an option > to specify how to align the partitions? > > VMware document about aligning partitions for ESX/VMFS for optimal > performance: > > http://www.vmware.com/pdf/esx3_partition_align.pdf > And more about the performance gains when aligning partitions (from the pdf above): Throughput Increase Min = 2% Max = 62% Avg = 12% Latency Decrease Min = 7% Max = 33% Avg = 10% Results of course depend of the SAN array used, and also on other factors. Btw. this partition alignment should also be done in virtual machine (domU) virtual disks. -- Pasi From rc040203 at freenet.de Wed Jun 6 12:01:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 14:01:25 +0200 Subject: fedora for ARM In-Reply-To: <466694B9.6000805@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <46667212.70803@warmcat.com> <1181125479.3222.12.camel@mccallum.corsepiu.local> <466694B9.6000805@warmcat.com> Message-ID: <1181131285.3231.21.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 12:04 +0100, Andy Green wrote: > Ralf Corsepius wrote: > > On Wed, 2007-06-06 at 09:36 +0100, Andy Green wrote: > >> Andy Green wrote: > > If host and target object format differ, rpmbuild bombs out. > > I have never experienced that, so I guess it must be okay for all the > packages I addressed, at least. And that includes some big stuff like > db4, postfix, asterisk, gdb, linux itself... As soon as you have several different object formats at the same time inside of than rpm, rpmbuild fails, no matter how you override. > >> defnitely debuginfo rpms are generated and work fine on arm > >> with gdb. > > Not unlikely, but you should check your buildlogs for error/warning > > messages and your resulting rpms for correctness. > > My scripts will stop dead if rpmbuild chokes so I am pretty sure none of > my packages so far fell into this unusual category of building and > packaging apps compiled for both host and target. Well, all packages you mention above are "host only" (==target in rpms' nomenclature) packages. You manage to get this working by overriding all tools being used to "build->host cross-tools". Things get really ugly, when building native cross-tools (such as the avr* tools) and when cross-rpmbuilding cross-tools (e.g. rpmbuild --target= avr-gcc). In these cases you'll have different object formats inside of one rpm at the same time. Ralf From ddmbox2 at yahoo.co.uk Wed Jun 6 12:05:17 2007 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 6 Jun 2007 13:05:17 +0100 Subject: Announcing the Fedora Award winners for 2007 Message-ID: <200706061305.21964.ddmbox2@yahoo.co.uk> Not to take anything away from the winners but where was the community involvement here, Can you show me what list this was proposed on previously? and who judged this award please. ...dex ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From vnpenguin at vnoss.org Wed Jun 6 12:19:06 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 6 Jun 2007 14:19:06 +0200 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <466567E8.3040506@redhat.com> <200706051039.32612.jkeating@redhat.com> Message-ID: On 6/6/07, Tony Nelson wrote: > > "Just make"? How? I need instructions, before I could do it and write the > detailed step-by-step instructions that other users would need. Since the > people who need CDs to install F7 probably won't have F7 installed, the > instructions must work with only the DVD image. Also the instructions > should tell them how to get the rest of the packages on the DVD if the > Internet is not available at the machine they're installing / upgrading. I used pungi, of course. Just write yourself a config file for pungi, based on the file in rpm package of pungi (no linux now so I can not tell you where is exactly). And create your manifest file (kickstart syntax) which decides packages will be added into your build. Finally, run: # pungi -c your_pungi_config_file HTH, -- http://vnoss.org From d.lesca at solinos.it Wed Jun 6 12:19:41 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 06 Jun 2007 14:19:41 +0200 Subject: mc missing from F7 DVD? In-Reply-To: <20070606105221.321950@gmx.net> References: <1181126314.3214.28.camel@dhcp-lab-186.brq.redhat.com> <20070606105221.321950@gmx.net> Message-ID: <1181132381.3974.72.camel@lesca.home.solinos.it> Il giorno mer, 06/06/2007 alle 12.52 +0200, Joachim Frieben ha scritto: > it's hard to see the rationale behind this choice. Can someone help us looking for rationale of this choice? > [root at lesca f7]# ls addon/* -l |grep -v mt-st| awk '{printf "%7d %s\n", $5,$9;i=i+$5} END {print i" total"}' > 92078 addon/compat-libstdc++-296-2.96-138.i386.rpm > 889297 addon/dhcp-3.0.5-35.fc7.i386.rpm > 36103 addon/telnet-server-0.17-38.fc7.i386.rpm > 126831 addon/xinetd-2.3.14-11.i386.rpm > 1144309 total I use telnet, xinetd, dhcp, compact-libstd*, ecc.!!! -- Dario Lesca From andy at warmcat.com Wed Jun 6 12:22:17 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 06 Jun 2007 13:22:17 +0100 Subject: fedora for ARM In-Reply-To: <1181131285.3231.21.camel@mccallum.corsepiu.local> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <46667212.70803@warmcat.com> <1181125479.3222.12.camel@mccallum.corsepiu.local> <466694B9.6000805@warmcat.com> <1181131285.3231.21.camel@mccallum.corsepiu.local> Message-ID: <4666A6F9.2000206@warmcat.com> Ralf Corsepius wrote: > On Wed, 2007-06-06 at 12:04 +0100, Andy Green wrote: >> Ralf Corsepius wrote: >>> On Wed, 2007-06-06 at 09:36 +0100, Andy Green wrote: >>>> Andy Green wrote: > >>> If host and target object format differ, rpmbuild bombs out. >> I have never experienced that, so I guess it must be okay for all the >> packages I addressed, at least. And that includes some big stuff like >> db4, postfix, asterisk, gdb, linux itself... > As soon as you have several different object formats at the same time > inside of than rpm, rpmbuild fails, no matter how you override. This is a highly unusual situation though... but I accept what you're saying about that for the toolchains. >>>> defnitely debuginfo rpms are generated and work fine on arm >>>> with gdb. >>> Not unlikely, but you should check your buildlogs for error/warning >>> messages and your resulting rpms for correctness. >> My scripts will stop dead if rpmbuild chokes so I am pretty sure none of >> my packages so far fell into this unusual category of building and >> packaging apps compiled for both host and target. > Well, all packages you mention above are "host only" (==target in rpms' > nomenclature) packages. You manage to get this working by overriding all > tools being used to "build->host cross-tools". > > Things get really ugly, when building native cross-tools (such as the > avr* tools) and when cross-rpmbuilding cross-tools (e.g. > rpmbuild --target= avr-gcc). > > In these cases you'll have different object formats inside of one rpm at > the same time. Can't there be a simple answer to this? Set %__strip to a script that first assesses the ELF arch using objdump and then calls through to the appropriate strip? I see that i386 Fedora objdump says that the arm executables are of "unknown" arch, but my arm-linux-objdump recognizes them as "arm". It would be a bit clunky but the basic idea of redirecting to the correct strip based on the ELF arch will sort it out if I understood it. -Andy From mlichvar at redhat.com Wed Jun 6 12:23:12 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 6 Jun 2007 14:23:12 +0200 Subject: Splitting the ncurses RPM In-Reply-To: <4665F306.40609@codewiz.org> References: <466385F1.8030005@codewiz.org> <20070604120659.GA1483@localhost> <4665F306.40609@codewiz.org> Message-ID: <20070606122312.GA25767@localhost> On Tue, Jun 05, 2007 at 07:34:30PM -0400, Bernardo Innocenti wrote: > >I'm not sure about removing terminfo from default Fedora install, > >Users can connect via ssh and use many different terminals. > > Then let's make the default choice broad enough to include > any hardware or software terminals shipped with the last > 10 years. I'm sure we could _still_ get rid of 95% of that > junk. > > A safe bet could be taking what Debian is also shipping: > > Eterm > Eterm-color -> Eterm > ansi > cons25 > cygwin > umb > hurd > linux > mach > mach-bold > mach-color > pcansi > rxvt > rxvt-basic > rxvt-m -> rxvt-basic > rxvt-unicode > screen > screen-bce > screen-s > screen-w > sun > vt100 > vt102 > vt220 > vt52 > wsvt25 > wsvt25m > xterm > xterm-color > xterm-debian > xterm-mono > xterm-r5 > xterm-r6 > xterm-vt220 > xterm-xfree86 This list is far too short, xterm-256color, gnome, teraterm, jfbterm, mrxvt and others should be included. I guess it will be pretty hard to select from descriptions so the extra terminfo package won't have to be installed by default. Installing all descriptions by default (and removing the package only when it's sure it's not needed) might be a better choice. Although there will be a problem with upgrading from old ncurses as nothing will depend on the new package. Any ideas? -- Miroslav Lichvar From mschwendt.tmp0701.nospam at arcor.de Wed Jun 6 12:28:03 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 6 Jun 2007 14:28:03 +0200 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <200706061305.21964.ddmbox2@yahoo.co.uk> References: <200706061305.21964.ddmbox2@yahoo.co.uk> Message-ID: <20070606142803.3421d71e.mschwendt.tmp0701.nospam@arcor.de> On Wed, 6 Jun 2007 13:05:17 +0100, dexter wrote: > > Not to take anything away from the winners but where was the community > involvement here, Can you show me what list this was proposed on previously? > and who judged this award please. Quoting: "The Fedora Award is presented by Red Hat ..." ^^^^^^^^^^ From buildsys at fedoraproject.org Wed Jun 6 12:38:21 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 06 Jun 2007 12:38:21 -0000 Subject: Summary - Broken dependencies in Fedora development - 2007-06-06 Message-ID: <20070606123821.24089.12601@extras64.linux.duke.edu> New report for: fedora AT deadbabylon.de package: devilspie - 0.20.2-2.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.21 package: devilspie - 0.20.2-2.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.21 package: devilspie - 0.20.2-2.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.21()(64bit) package: devilspie - 0.20.2-2.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.21()(64bit) ====================================================================== New report for: rstrode AT redhat.com package: gnome-applets - 1:2.18.0-9.fc8.i386 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.21 package: gnome-applets - 1:2.18.0-9.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.21 package: gnome-applets - 1:2.18.0-9.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.21 package: gnome-applets - 1:2.18.0-9.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.21()(64bit) package: gnome-applets - 1:2.18.0-9.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.21()(64bit) ====================================================================== New report for: jonathansteffan AT gmail.com package: revisor - 2.0.3.7-1.fc8.noarch from rawhide-development-ppc64 unresolved deps: livecd-tools package: revisor - 2.0.3.7-1.fc8.noarch from rawhide-development-ppc unresolved deps: livecd-tools ====================================================================== New report for: krh AT redhat.com package: compiz - 0.3.6-10.fc8.i386 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.21 package: compiz - 0.3.6-10.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.21 package: compiz - 0.3.6-10.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.21 package: compiz - 0.3.6-10.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.21()(64bit) ====================================================================== New report for: mbarnes AT redhat.com package: gnome-python2-libwnck - 2.18.0-3.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.21 package: gnome-python2-libwnck - 2.18.0-3.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.21 package: gnome-python2-libwnck - 2.18.0-3.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.21()(64bit) package: gnome-python2-libwnck - 2.18.0-3.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.21()(64bit) ====================================================================== New report for: caillon AT redhat.com package: epiphany-extensions - 2.19.2-2.i386 from rawhide-development-i386 unresolved deps: firefox = 0:2.0.0.4.i386 package: epiphany-extensions - 2.19.2-2.ppc from rawhide-development-ppc unresolved deps: firefox = 0:2.0.0.4.ppc package: epiphany-extensions - 2.19.2-2.ppc64 from rawhide-development-ppc64 unresolved deps: firefox = 0:2.0.0.4.ppc64 package: epiphany-extensions - 2.19.2-2.x86_64 from rawhide-development-x86_64 unresolved deps: firefox = 0:2.0.0.4.x86_64 ====================================================================== New report for: jwilson AT redhat.com package: beryl - 0.2.1-1.fc8.i386 from rawhide-development-i386 unresolved deps: bdock >= 0:0.2.1 package: beryl - 0.2.1-1.fc8.ppc from rawhide-development-ppc unresolved deps: bdock >= 0:0.2.1 package: beryl - 0.2.1-1.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: bdock >= 0:0.2.1 package: beryl - 0.2.1-1.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: bdock >= 0:0.2.1 package: beryl-gnome - 0.2.1-1.fc8.i386 from rawhide-development-i386 unresolved deps: emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 heliodor >= 0:0.2.1 package: beryl-gnome - 0.2.1-1.fc8.ppc from rawhide-development-ppc unresolved deps: emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 heliodor >= 0:0.2.1 package: beryl-gnome - 0.2.1-1.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 heliodor >= 0:0.2.1 package: beryl-gnome - 0.2.1-1.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 heliodor >= 0:0.2.1 package: beryl-kde - 0.2.1-1.fc8.i386 from rawhide-development-i386 unresolved deps: aquamarine >= 0:0.2.1 emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 package: beryl-kde - 0.2.1-1.fc8.ppc from rawhide-development-ppc unresolved deps: aquamarine >= 0:0.2.1 emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 package: beryl-kde - 0.2.1-1.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: aquamarine >= 0:0.2.1 emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 package: beryl-kde - 0.2.1-1.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: aquamarine >= 0:0.2.1 emerald-themes >= 0:0.2.1 emerald >= 0:0.2.1 ====================================================================== New report for: davidz AT redhat.com package: gnome-power-manager - 2.19.2-2.fc8.i386 from rawhide-development-i386 unresolved deps: libwnck-1.so.21 package: gnome-power-manager - 2.19.2-2.fc8.ppc from rawhide-development-ppc unresolved deps: libwnck-1.so.21 package: gnome-power-manager - 2.19.2-2.fc8.ppc64 from rawhide-development-ppc64 unresolved deps: libwnck-1.so.21()(64bit) package: gnome-power-manager - 2.19.2-2.fc8.x86_64 from rawhide-development-x86_64 unresolved deps: libwnck-1.so.21()(64bit) ====================================================================== Summary of broken packages (by owner): caillon AT redhat.com epiphany-extensions - 2.19.2-2.i386 epiphany-extensions - 2.19.2-2.ppc epiphany-extensions - 2.19.2-2.ppc64 epiphany-extensions - 2.19.2-2.x86_64 cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (3 days) davidz AT redhat.com gnome-power-manager - 2.19.2-2.fc8.i386 gnome-power-manager - 2.19.2-2.fc8.ppc gnome-power-manager - 2.19.2-2.fc8.ppc64 gnome-power-manager - 2.19.2-2.fc8.x86_64 dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (3 days) fedora AT deadbabylon.de devilspie - 0.20.2-2.fc8.i386 devilspie - 0.20.2-2.fc8.ppc devilspie - 0.20.2-2.fc8.ppc64 devilspie - 0.20.2-2.fc8.x86_64 gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (3 days) glest-data - 2.0.0-2.fc7.noarch (3 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 (3 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 (3 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (3 days) kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 (3 days) kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (3 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (3 days) jonathansteffan AT gmail.com revisor - 2.0.3.7-1.fc8.noarch revisor - 2.0.3.7-1.fc8.noarch jwilson AT redhat.com bdock - 0.2.0-1.fc7.i386 bdock - 0.2.0-1.fc7.ppc bdock - 0.2.0-1.fc7.x86_64 beryl - 0.2.1-1.fc8.i386 beryl - 0.2.1-1.fc8.ppc beryl - 0.2.1-1.fc8.ppc64 beryl - 0.2.1-1.fc8.x86_64 beryl-gnome - 0.2.1-1.fc8.i386 beryl-gnome - 0.2.1-1.fc8.ppc beryl-gnome - 0.2.1-1.fc8.ppc64 beryl-gnome - 0.2.1-1.fc8.x86_64 beryl-kde - 0.2.1-1.fc8.i386 beryl-kde - 0.2.1-1.fc8.ppc beryl-kde - 0.2.1-1.fc8.ppc64 beryl-kde - 0.2.1-1.fc8.x86_64 emerald - 0.2.0-1.fc7.i386 emerald - 0.2.0-1.fc7.i386 emerald - 0.2.0-1.fc7.ppc emerald - 0.2.0-1.fc7.x86_64 emerald-themes - 0.2.0-1.fc7.noarch (3 days) heliodor - 0.2.0-1.fc7.i386 heliodor - 0.2.0-1.fc7.ppc heliodor - 0.2.0-1.fc7.x86_64 karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (3 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (3 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (3 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (3 days) krh AT redhat.com compiz - 0.3.6-10.fc8.i386 compiz - 0.3.6-10.fc8.i386 compiz - 0.3.6-10.fc8.ppc compiz - 0.3.6-10.fc8.x86_64 kwizart AT gmail.com lcdproc - 0.5.2-1.fc8.i386 (3 days) lcdproc - 0.5.2-1.fc8.ppc (3 days) lcdproc - 0.5.2-1.fc8.ppc64 (3 days) lcdproc - 0.5.2-1.fc8.x86_64 (3 days) mbarnes AT redhat.com gnome-python2-libwnck - 2.18.0-3.fc8.i386 gnome-python2-libwnck - 2.18.0-3.fc8.ppc gnome-python2-libwnck - 2.18.0-3.fc8.ppc64 gnome-python2-libwnck - 2.18.0-3.fc8.x86_64 mdehaan AT redhat.com koan - 0.3.1-2.fc7.noarch (3 days) orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 (3 days) rstrode AT redhat.com gnome-applets - 1:2.18.0-9.fc8.i386 gnome-applets - 1:2.18.0-9.fc8.i386 gnome-applets - 1:2.18.0-9.fc8.ppc gnome-applets - 1:2.18.0-9.fc8.ppc64 gnome-applets - 1:2.18.0-9.fc8.x86_64 rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (3 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (3 days) tcallawa AT redhat.com xsupplicant - 1.2.8-1.fc7.1.i386 (3 days) xsupplicant - 1.2.8-1.fc7.1.ppc (3 days) xsupplicant - 1.2.8-1.fc7.1.x86_64 (3 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (3 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc ====================================================================== Broken packages in rawhide-development-i386: bdock-0.2.0-1.fc7.i386 requires libwnck-1.so.18 beryl-0.2.1-1.fc8.i386 requires bdock >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.i386 requires heliodor >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.i386 requires aquamarine >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 compiz-0.3.6-10.fc8.i386 requires libwnck-1.so.21 devilspie-0.20.2-2.fc8.i386 requires libwnck-1.so.21 emerald-0.2.0-1.fc7.i386 requires libwnck-1.so.18 epiphany-extensions-2.19.2-2.i386 requires firefox = 0:2.0.0.4.i386 gnome-applets-1:2.18.0-9.fc8.i386 requires libwnck-1.so.21 gnome-power-manager-2.19.2-2.fc8.i386 requires libwnck-1.so.21 gnome-python2-libwnck-2.18.0-3.fc8.i386 requires libwnck-1.so.21 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 heliodor-0.2.0-1.fc7.i386 requires libwnck-1.so.18 kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE-0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug-0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc-0.5.2-1.fc8.i386 requires perl(Geo::METAR) xsupplicant-1.2.8-1.fc7.1.i386 requires libiw.so.28 ====================================================================== Broken packages in rawhide-development-ppc64: ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) beryl-0.2.1-1.fc8.ppc64 requires bdock >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.ppc64 requires heliodor >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.ppc64 requires aquamarine >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 devilspie-0.20.2-2.fc8.ppc64 requires libwnck-1.so.21()(64bit) emerald-themes-0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 epiphany-extensions-2.19.2-2.ppc64 requires firefox = 0:2.0.0.4.ppc64 geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-applets-1:2.18.0-9.fc8.ppc64 requires libwnck-1.so.21()(64bit) gnome-power-manager-2.19.2-2.fc8.ppc64 requires libwnck-1.so.21()(64bit) gnome-python2-libwnck-2.18.0-3.fc8.ppc64 requires libwnck-1.so.21()(64bit) kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump-0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan-0.3.1-2.fc7.noarch requires syslinux lcdproc-0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display revisor-2.0.3.7-1.fc8.noarch requires livecd-tools rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ====================================================================== Broken packages in rawhide-development-ppc: bdock-0.2.0-1.fc7.ppc requires libwnck-1.so.18 beryl-0.2.1-1.fc8.ppc requires bdock >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.ppc requires heliodor >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.ppc requires aquamarine >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 compiz-0.3.6-10.fc8.ppc requires libwnck-1.so.21 devilspie-0.20.2-2.fc8.ppc requires libwnck-1.so.21 emerald-0.2.0-1.fc7.ppc requires libwnck-1.so.18 epiphany-extensions-2.19.2-2.ppc requires firefox = 0:2.0.0.4.ppc glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-applets-1:2.18.0-9.fc8.ppc requires libwnck-1.so.21 gnome-power-manager-2.19.2-2.fc8.ppc requires libwnck-1.so.21 gnome-python2-libwnck-2.18.0-3.fc8.ppc requires libwnck-1.so.21 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 heliodor-0.2.0-1.fc7.ppc requires libwnck-1.so.18 kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp-0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc-0.5.2-1.fc8.ppc requires perl(Geo::METAR) revisor-2.0.3.7-1.fc8.noarch requires livecd-tools xsupplicant-1.2.8-1.fc7.1.ppc requires libiw.so.28 ====================================================================== Broken packages in rawhide-development-x86_64: bdock-0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) beryl-0.2.1-1.fc8.x86_64 requires bdock >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 beryl-gnome-0.2.1-1.fc8.x86_64 requires heliodor >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.x86_64 requires aquamarine >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-kde-0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 compiz-0.3.6-10.fc8.i386 requires libwnck-1.so.21 compiz-0.3.6-10.fc8.x86_64 requires libwnck-1.so.21()(64bit) devilspie-0.20.2-2.fc8.x86_64 requires libwnck-1.so.21()(64bit) emerald-0.2.0-1.fc7.i386 requires libwnck-1.so.18 emerald-0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) epiphany-extensions-2.19.2-2.x86_64 requires firefox = 0:2.0.0.4.x86_64 gnome-applets-1:2.18.0-9.fc8.i386 requires libwnck-1.so.21 gnome-applets-1:2.18.0-9.fc8.x86_64 requires libwnck-1.so.21()(64bit) gnome-power-manager-2.19.2-2.fc8.x86_64 requires libwnck-1.so.21()(64bit) gnome-python2-libwnck-2.18.0-3.fc8.x86_64 requires libwnck-1.so.21()(64bit) gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 heliodor-0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) kmod-em8300-0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug-0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump-0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc-0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) xsupplicant-1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) From ddmbox2 at yahoo.co.uk Wed Jun 6 12:39:05 2007 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 6 Jun 2007 13:39:05 +0100 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <46667AE5.9030008@poolshark.org> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <20070606110302.60a24922@banea.int.addix.net> <46667AE5.9030008@poolshark.org> Message-ID: <200706061339.07615.ddmbox2@yahoo.co.uk> On Wed June 6 2007 10:14:13 Denis Leroy wrote: > Ralf Ertzinger wrote: > > Hi. > > > > On Wed, 6 Jun 2007 10:49:44 +0200, Matthias Saou wrote: > >> This is quite similar to a report I got about cinelerra from freshrpms > >> not running. The user installed it with yum, but managed to get broken > >> dependencies because of different ffmpeg packages from rpm.livna.org > >> and freshrpms somehow... > > > > Media packages from livna and freshrpms do not mix, im my experience. > > No but i think that's a different problem. Here we're seeing systems > left with broken deps after a successful yum installation. more evidence in this thread: https://www.redhat.com/archives/fedora-list/2007-June/msg00745.html ...dex ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From ddmbox2 at yahoo.co.uk Wed Jun 6 12:49:33 2007 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 6 Jun 2007 13:49:33 +0100 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <20070606142803.3421d71e.mschwendt.tmp0701.nospam@arcor.de> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <20070606142803.3421d71e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706061349.36456.ddmbox2@yahoo.co.uk> On Wed June 6 2007 13:28:03 Michael Schwendt wrote: > On Wed, 6 Jun 2007 13:05:17 +0100, dexter wrote: > > Not to take anything away from the winners but where was the community > > involvement here, Can you show me what list this was proposed on > > previously? and who judged this award please. > > Quoting: "The Fedora Award is presented by Red Hat ..." > ^^^^^^^^^^ Oh it's clear now an internal award for mostly internal folks nice! ...dex ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html From jkeating at redhat.com Wed Jun 6 13:05:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 09:05:50 -0400 Subject: Kernel recommendation without the F7 network issue? In-Reply-To: <2a28d2ab0706051617p51e2a6e6gfda8e00437c0e0e8@mail.gmail.com> References: <2a28d2ab0706051617p51e2a6e6gfda8e00437c0e0e8@mail.gmail.com> Message-ID: <200706060905.53562.jkeating@redhat.com> On Tuesday 05 June 2007 19:17:06 Dr. Diesel wrote: > Any suggestions for a Kernel to drop back to till the F7 Network issue > is resolved? ?Perhaps the F7T4 Kernel? Have you tried booting with 'nohz=off' ? Disabling the tickless kernel may help things. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 6 13:08:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 09:08:57 -0400 Subject: mc missing from F7 DVD? In-Reply-To: <20070606105221.321950@gmx.net> References: <1181126314.3214.28.camel@dhcp-lab-186.brq.redhat.com> <20070606105221.321950@gmx.net> Message-ID: <200706060908.57764.jkeating@redhat.com> On Wednesday 06 June 2007 06:52:21 Joachim Frieben wrote: > > Hi, > > > > I have feedback from the Midnight Commander users who are pretty angry > > because of missing mc from the F7 DVD. Is there a reason to not to > > include a former Core package to the F7 DVD? How to prevent that it > > happens again for F8? > > > > Thanks, > > Jindrich > > There are --many-- packages missing from the F7 DVD which were part of > "Core", e.g. lam, gnuplot, epiphany (the default GNOME web browser!), and > so on. What is strange about this is that these packages have not even been > replaced by more popular packages from Fedora Extras. The size of the DVD > image shrank down to about 2.5 GB when the previous one was about 1 GB > more. As a consequence, 2 GB of DVD space are wasted. Given that there are > ever more and faster mirrors out there and bittorrent can be used in many > cases, it's hard to see the rationale behind this choice. On the other hand, it's 2.5gig less to download to get an installer image. You can add the Everything repo at install time to gain access to every package in Fedora. What is on the DVD has been an ongoing process from Test1 all the way though Test4 and even the RC. I've taken the feedback and adjusted the manifest file for the DVD as appropriate. If you didn't notice it before, well I couldn't help you then. What's important to note is what is on the DVD is _not_ what is /in/ Fedora. All the packages are there, it's a quick yum or Add/Remove Software session away. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 6 13:09:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 09:09:54 -0400 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <200706061349.36456.ddmbox2@yahoo.co.uk> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <20070606142803.3421d71e.mschwendt.tmp0701.nospam@arcor.de> <200706061349.36456.ddmbox2@yahoo.co.uk> Message-ID: <200706060909.54933.jkeating@redhat.com> On Wednesday 06 June 2007 08:49:33 dexter wrote: > Oh it's clear now an internal award for mostly internal folks nice! Um, none of the winners were Red Hat employees at the time of the award. They were all volunteers who were doing very very important work for Fedora in their spare time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 6 13:12:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 09:12:45 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1181070292.3939.3.camel@neutron.verbum.private> Message-ID: <200706060912.45498.jkeating@redhat.com> On Tuesday 05 June 2007 16:56:45 Kevin Kofler wrote: > Or we could just use APT-RPM and stop worrying about Python. Right, because glibc and c libraries never change right? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 6 13:17:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 09:17:16 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <4665AFE1.3090509@redhat.com> Message-ID: <200706060917.16954.jkeating@redhat.com> On Tuesday 05 June 2007 20:16:42 Tony Nelson wrote: > I'm also not sure what you mean by "instructions on the pungi site", as I > didn't see any instructions, only a vague plan on how pungi might end up > being written. At the bottom of https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs which is linked to on the front page there is a link to https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs/RunningPungi At the bottom of that there is https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs/RunningPungiInMock -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed Jun 6 13:20:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 15:20:43 +0200 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <46666AAB.7020005@poolshark.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> Message-ID: <20070606132043.GA2833@free.fr> On Wed, Jun 06, 2007 at 10:04:59AM +0200, Denis Leroy wrote: > > > >Are you sure? For little apps, linking dynamically leads to a loss in > >performance in both size and speed. > > That's a very questionable statement, and may only be true under very > unusual conditions (such as: the linked dyn libraries are never shared > with other executables). I don't see how the run-time execution could > technically be slower, outside of the start-up time. Even if dyn libraries are shared, the code that is needed to perform the link may add more to the executable. You can try with a simple 'hello world' that use printf. -- Pat From denis at poolshark.org Wed Jun 6 13:29:32 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 06 Jun 2007 15:29:32 +0200 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070606132043.GA2833@free.fr> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> Message-ID: <4666B6BC.5010406@poolshark.org> Patrice Dumas wrote: > On Wed, Jun 06, 2007 at 10:04:59AM +0200, Denis Leroy wrote: >>> Are you sure? For little apps, linking dynamically leads to a loss in >>> performance in both size and speed. >> That's a very questionable statement, and may only be true under very >> unusual conditions (such as: the linked dyn libraries are never shared >> with other executables). I don't see how the run-time execution could >> technically be slower, outside of the start-up time. > > Even if dyn libraries are shared, the code that is needed to perform the > link may add more to the executable. You can try with a simple 'hello > world' that use printf. But that penalty is dwarfed by the extra cache misses caused by the larger cache footprints of a statically linked executable. I'm sure it's possible to come up with a counter example, but it's likely to be an unusual corner case (as least as far as glibc is concerned), or something that's simply not a real world example. From j.w.r.degoede at hhs.nl Wed Jun 6 13:06:31 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 06 Jun 2007 15:06:31 +0200 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <200706061305.21964.ddmbox2@yahoo.co.uk> References: <200706061305.21964.ddmbox2@yahoo.co.uk> Message-ID: <4666B157.6030800@hhs.nl> dexter wrote: > Not to take anything away from the winners but where was the community > involvement here, Can you show me what list this was proposed on previously? > and who judged this award please. > I must say I'm a bit disappointed by this action too, lately there has been a lot of uproar that those "managing" Fedora seem to have lost touch with the "workfloor". This award to me confirms that there is an in-crowd, an old boys network, and the rest of us. And to get into this in-crowd one mainly must do a lot of irc-meetings and mailing, actually working oneself into sweat isn't enough. I'm sad to say that these awards mainly seems to be about who can (social) network the most, and not necessarily about contributing. With this I in no way mean to put down the great work done by most of the award receivers. However I do see a drift forming here between some kinda in-crowd and the rest, which is an alarming development. For example why isn't Tibbs on the list, without ihs gargantuan efforts, our whole (great) review process would have collapsed under its own weight. Regards, Hans From cmadams at hiwaay.net Wed Jun 6 13:41:26 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 6 Jun 2007 08:41:26 -0500 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070606132043.GA2833@free.fr> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> Message-ID: <20070606134126.GB1196485@hiwaay.net> Once upon a time, Patrice Dumas said: > Even if dyn libraries are shared, the code that is needed to perform the > link may add more to the executable. You can try with a simple 'hello > world' that use printf. You should probably test that before you post. I would say this is the smallest possible regular C program: $ cat x.c int main () { return 0; } $ gcc -o x-dyn x.c $ gcc -static -o x-stat x.c $ strip x-dyn x-stat $ ls -l x-dyn x-stat -rwxr-xr-x 1 cmadams users 2816 Jun 6 08:38 x-dyn -rwxr-xr-x 1 cmadams users 459492 Jun 6 08:38 x-stat $ I don't forsee a static executable being smaller than a dynamic executable in the real world. It is possible that somebody could hand-build (e.g. no gcc, ld, etc.) such an executable, but that doesn't really count (since that isn't done in the real world). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ddmbox2 at yahoo.co.uk Wed Jun 6 14:05:35 2007 From: ddmbox2 at yahoo.co.uk (dexter) Date: Wed, 6 Jun 2007 15:05:35 +0100 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <200706060909.54933.jkeating@redhat.com> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <200706061349.36456.ddmbox2@yahoo.co.uk> <200706060909.54933.jkeating@redhat.com> Message-ID: <200706061505.37125.ddmbox2@yahoo.co.uk> On Wed June 6 2007 14:09:54 Jesse Keating wrote: > On Wednesday 06 June 2007 08:49:33 dexter wrote: > > Oh it's clear now an internal award for mostly internal folks nice! > > Um, none of the winners were Red Hat employees at the time of the award. > They were all volunteers who were doing very very important work for Fedora > in their spare time. Ok lets not go down the road of who is most deserving here (but someone at redhat has) My surprise was in the title "Fedora Award Winners" I couldn't recall any announcements for nominations or even the award itself. I wrongly assumed this was a Fedora Communitiy lead excercise. my bad as they say. ...dex ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html From fedora.lists at burns.me.uk Wed Jun 6 14:30:06 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Wed, 6 Jun 2007 15:30:06 +0100 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <46665A5F.2090002@poolshark.org> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <46665A5F.2090002@poolshark.org> Message-ID: On 06/06/07, Denis Leroy wrote: > A similar bug was filed against inkscape : > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242748 I've just updated that bug, in short it was a clean F7 install from DVD wiping my old FC6 partition, I did pick and choose packages at install time quite a bit, here's the yum.log of activity post-install up to the inkscape problems Jun 03 17:32:09 Updated: libpurple.i386 2.0.1-1.fc7 Jun 03 17:32:11 Updated: freetype.i386 2.3.4-3.fc7 Jun 03 17:32:28 Updated: firefox.i386 2.0.0.4-1.fc7 Jun 03 17:32:29 Updated: libexif.i386 0.6.15-1.fc7 Jun 03 17:32:32 Updated: libwnck.i386 2.18.2-1.fc7 Jun 03 17:32:52 Updated: yelp.i386 2.18.1-4.fc7 Jun 03 17:33:14 Updated: pidgin.i386 2.0.1-1.fc7 these were first batch of updates after installation Jun 03 17:37:48 Installed: yumex.noarch 1.9.6-1.0.fc7 Jun 03 17:40:33 Installed: wxGTK.i386 2.8.3-2.fc7 Jun 03 17:41:27 Installed: pgadmin3.i386 1.6.3-1.fc7 Jun 03 18:27:52 Installed: php-pear.noarch 1:1.5.0-3 Jun 03 18:27:59 Installed: php-pear-DB.noarch 1.7.6-7.fc6 Jun 03 18:28:05 Installed: php-pear-MDB2.noarch 2.4.1-1.fc7 Jun 03 21:01:42 Installed: rrdtool.i386 1.2.23-3.fc7 Jun 03 21:01:43 Installed: php-snmp.i386 5.2.2-3 Jun 03 21:01:50 Installed: mysql.i386 5.0.37-2.fc7 Jun 03 21:02:31 Installed: cacti.noarch 0.8.6j-1.fc7 Jun 03 21:04:27 Installed: thunderbird.i386 2.0.0.0-1.fc7 Jun 03 21:11:32 Installed: gnonlin.i386 0.10.8-1.fc7 Jun 03 21:11:33 Installed: ladspa.i386 1.12-8.fc7 Jun 03 21:11:39 Installed: gstreamer-python.i386 0.10.7-2.fc7 Jun 03 21:11:48 Installed: python-setuptools.noarch 0.6c5-1.fc7 Jun 03 21:12:17 Installed: jokosher.noarch 0.9-1.fc7 Jun 03 21:23:46 Installed: tcl.i386 1:8.4.13-16.fc7 Jun 03 21:23:56 Installed: tk.i386 1:8.4.13-5.fc7 Jun 03 21:24:01 Installed: gkrellm.i386 2.2.10-2.fc7 Jun 03 21:24:02 Installed: i8kutils.i386 1.25-11.fc6 this was me picking and choosing a bit more apps Jun 05 17:10:38 Installed: inkscape.i386 0.45.1-1.fc7 then I wanted inskape, notice it installed none of the deps Jun 05 17:19:12 Updated: postgresql-libs.i386 8.2.4-1.fc7 Jun 05 17:19:15 Updated: wpa_supplicant.i386 1:0.5.7-3.fc7 Jun 05 17:19:20 Updated: NetworkManager.i386 1:0.6.5-3.fc7 Jun 05 17:19:59 Updated: postgresql.i386 8.2.4-1.fc7 Jun 05 17:20:00 Updated: gpm.i386 1.20.1-84.fc7 Jun 05 17:20:01 Updated: NetworkManager-glib.i386 1:0.6.5-3.fc7 Jun 05 17:20:50 Updated: firefox.i386 2.0.0.4-2.fc7 Jun 05 17:20:58 Updated: NetworkManager-gnome.i386 1:0.6.5-3.fc7 Jun 05 17:21:02 Updated: system-config-nfs.noarch 1.3.25-1.fc7 Jun 05 17:21:06 Updated: yumex.noarch 1.9.7-1.0.fc7 Jun 05 17:21:06 Updated: postgresql-python.i386 8.2.4-1.fc7 Jun 05 17:21:11 Updated: system-config-users.noarch 1.2.58-1.fc7 Jun 05 17:21:42 Updated: postgresql-server.i386 8.2.4-1.fc7 Another batch of upgrades hit the repo so I took them, it was only at this point I realised inkscape wouldn't run. Jun 05 17:24:18 Installed: glibmm24.i386 2.12.8-1.fc7 Jun 05 17:25:18 Installed: gtkmm24.i386 2.10.9-1.fc7 Jun 05 17:26:59 Installed: cairomm.i386 1.2.4-1.fc7 Jun 05 17:27:40 Installed: libsigc++.i386 1.2.7-4.fc6 Jun 05 17:28:13 Installed: libsigc++20.i386 2.0.17-2 Jun 05 17:31:44 Installed: gc.i386 6.8-3.fc7 this was me manually installing the deps for inkscape when I realised it wasn't working Jun 05 17:47:43 Installed: cdlabelgen.noarch 3.6.0-1.fc6 Jun 05 17:47:52 Installed: glabels.i386 2.0.4-5.fc6 Jun 05 18:06:29 Installed: gutenprint-plugin.i386 5.0.0.99.1-3.fc7 just me trying to print to DVDs on my Epson R300, which was why I wanted inkscape Jun 06 14:46:45 Erased: glibmm24 Jun 06 14:46:56 Erased: libsigc++ Jun 06 14:46:56 Erased: gc Jun 06 14:46:57 Erased: gtkmm24 Jun 06 14:46:57 Erased: cairomm Jun 06 14:47:00 Erased: inkscape however, removing inkscapes deps, took inkscape with it Jun 06 14:58:07 Installed: perl-XML-RegExp.noarch 0.03-2.fc6 Jun 06 14:58:08 Installed: cairomm.i386 1.2.4-1.fc7 Jun 06 14:58:09 Installed: glibmm24.i386 2.12.8-1.fc7 Jun 06 14:58:09 Installed: gtkmm24.i386 2.10.9-1.fc7 Jun 06 14:58:10 Installed: perl-XML-Parser.i386 2.34-6.1.2.2.1 Jun 06 14:58:12 Installed: perl-XML-DOM.noarch 1.44-2.fc6 Jun 06 14:58:13 Installed: libEMF.i386 1.0.3-3.fc7 Jun 06 14:58:14 Installed: perl-DateManip.noarch 5.44-3.fc7 Jun 06 14:58:14 Installed: gc.i386 6.8-3.fc7 Jun 06 14:58:17 Installed: plotutils.i386 2.5-3.fc6 Jun 06 14:58:18 Installed: perl-Parse-Yapp.noarch 1.05-36.fc6 Jun 06 14:58:19 Installed: perl-XML-XQL.noarch 0.68-4.fc7 Jun 06 14:58:20 Installed: ImageMagick-c++.i386 6.3.2.9-3.fc7 Jun 06 14:58:20 Installed: pstoedit.i386 3.44-6.fc7 Jun 06 14:58:22 Installed: ImageMagick-perl.i386 6.3.2.9-3.fc7 Jun 06 14:58:33 Installed: inkscape.i386 0.45.1-1.fc7 and reinstalling inkscape pulled back those deps, and more this time around. From bpepple at fedoraproject.org Wed Jun 6 14:33:51 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 06 Jun 2007 10:33:51 -0400 Subject: Plan for tomorrows (20070607) FESCO meeting Message-ID: <1181140431.2818.6.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- rel-eng proposal for Update tool defaults pushing to updates-testing - https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html - f13 /topic FESCO-Meeting -- MISC -- Policy Drafts w/ wiki changes -- f13 /topic FESCO-Meeting -- MISC -- Security Updates needing Security Team approval proposal -- jbressers, jwb /topic FESCo-Meeting -- MISC -- Bugzilla components merger status -- bpepple, poelcat /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-meeting -- Statically link libuu (uulib-static) into klibido -- tibbs -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Jun 6 14:37:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 10:37:17 -0400 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <1181140431.2818.6.camel@kennedy> References: <1181140431.2818.6.camel@kennedy> Message-ID: <200706061037.17447.jkeating@redhat.com> On Wednesday 06 June 2007 10:33:51 Brian Pepple wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. I would like to talk to FESCo about allowing the OLPC project to make use of our infrastructure to work on their migration to a Fedora 7 base. In the past they've used Red Hat's infrastructure to base themselves on Fedora 6, but since the merge they can't do that anymore. They'd need to be able to add/sponsor packagers, olpc specific branches of some packages, some packages that are olpc only, tags within Koji for olpc, and the ability to produce repos of the olpc packages out of koji. John (J5) Palmieri should be able to join the meeting to represent OLPC in this topic. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Jun 6 14:48:00 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 06 Jun 2007 10:48:00 -0400 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <200706061037.17447.jkeating@redhat.com> References: <1181140431.2818.6.camel@kennedy> <200706061037.17447.jkeating@redhat.com> Message-ID: <1181141280.2818.7.camel@kennedy> On Wed, 2007-06-06 at 10:37 -0400, Jesse Keating wrote: > On Wednesday 06 June 2007 10:33:51 Brian Pepple wrote: > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > I would like to talk to FESCo about allowing the OLPC project to make use of > our infrastructure to work on their migration to a Fedora 7 base. In the > past they've used Red Hat's infrastructure to base themselves on Fedora 6, > but since the merge they can't do that anymore. They'd need to be able to > add/sponsor packagers, olpc specific branches of some packages, some packages > that are olpc only, tags within Koji for olpc, and the ability to produce > repos of the olpc packages out of koji. John (J5) Palmieri should be able to > join the meeting to represent OLPC in this topic. I'll add it to the schedule. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed Jun 6 14:59:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Jun 2007 09:59:25 -0500 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <200706061037.17447.jkeating@redhat.com> References: <1181140431.2818.6.camel@kennedy> <200706061037.17447.jkeating@redhat.com> Message-ID: <1181141965.464.27.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 10:37 -0400, Jesse Keating wrote: > On Wednesday 06 June 2007 10:33:51 Brian Pepple wrote: > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > I would like to talk to FESCo about allowing the OLPC project to make use of > our infrastructure to work on their migration to a Fedora 7 base. In the > past they've used Red Hat's infrastructure to base themselves on Fedora 6, > but since the merge they can't do that anymore. They'd need to be able to > add/sponsor packagers, olpc specific branches of some packages, some packages > that are olpc only, tags within Koji for olpc, and the ability to produce > repos of the olpc packages out of koji. John (J5) Palmieri should be able to > join the meeting to represent OLPC in this topic. Could we treat OLPC as a secondary arch? josh From mlichvar at redhat.com Wed Jun 6 15:13:17 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 6 Jun 2007 17:13:17 +0200 Subject: Splitting the ncurses RPM In-Reply-To: <200706061534.34114.arnd@arndb.de> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> Message-ID: <20070606151317.GA27490@localhost> On Wed, Jun 06, 2007 at 03:34:33PM +0200, Arnd Bergmann wrote: > On Wednesday 06 June 2007, Miroslav Lichvar wrote: > > On Tue, Jun 05, 2007 at 07:34:30PM -0400, Bernardo Innocenti wrote: > > > > This list is far too short, xterm-256color, gnome, teraterm, jfbterm, > > mrxvt and others should be included. I guess it will be pretty hard to > > select from descriptions so the extra terminfo package won't have to > > be installed by default. > > Actually, we already have a small subset defined in /lib/terminfo, > as opposed to the full set that gets installed to /usr/share/terminfo. > Maybe it's enough to review the list of files in the former directory > and then use only those by default, with /usr/share/terminfo in an > optional package. In /lib/terminfo should be only a minimal set that might be required when doing system administration with /usr unmounted. Wondering how xterm got there. > What now is in the ncurses package would then become > > libncurses: {,/usr}/lib{,64}/*.so.* /lib/terminfo/* > ncurses-bin: /usr/bin/*, requires: libncurses.%{arch} > ncurses-data: /usr/share/terminfo/, requires: libncurses > ncurses: requires: ncurses-bin, ncurses-data. Ok. Maybe I'd use a bit different naming instead: ncurses-bin: bin/* ncurses-base: lib*.so.* /etc/terminfo /lib/terminfo, some of /usr/share/terminfo ncurses-terminfo: rest of /usr/share/terminfo ncurses: requires: -bin -base -terminfo How does this sound? -- Miroslav Lichvar From mschwendt.tmp0701.nospam at arcor.de Wed Jun 6 15:22:34 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 6 Jun 2007 17:22:34 +0200 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <4666B157.6030800@hhs.nl> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> Message-ID: <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> On Wed, 06 Jun 2007 15:06:31 +0200, Hans de Goede wrote: > I must say I'm a bit disappointed by this action too, lately there has been a > lot of uproar that those "managing" Fedora seem to have lost touch with the > "workfloor". This award to me confirms that there is an in-crowd, an old boys > network, and the rest of us. And to get into this in-crowd one mainly must do a > lot of irc-meetings and mailing, actually working oneself into sweat isn't enough. > > I'm sad to say that these awards mainly seems to be about who can (social) > network the most, and not necessarily about contributing. > > With this I in no way mean to put down the great work done by most of the award > receivers. However I do see a drift forming here between some kinda in-crowd > and the rest, which is an alarming development. Well said. What surprised and disappointed me the most is that this award covers a time-span of several years, not just 2007. And that after years, on one hand, "it is difficult to sometimes give recognition" (quoting gdk) and on the other hand it is that easy to come up with an extreme like this award. From jeff at ocjtech.us Wed Jun 6 15:29:19 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 06 Jun 2007 10:29:19 -0500 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <1181141965.464.27.camel@zod.rchland.ibm.com> References: <1181140431.2818.6.camel@kennedy> <200706061037.17447.jkeating@redhat.com> <1181141965.464.27.camel@zod.rchland.ibm.com> Message-ID: <1181143759.4009.38.camel@lt21223.campus.dmacc.edu> On Wed, 2007-06-06 at 09:59 -0500, Josh Boyer wrote: > On Wed, 2007-06-06 at 10:37 -0400, Jesse Keating wrote: > > > > I would like to talk to FESCo about allowing the OLPC project to make use of > > our infrastructure to work on their migration to a Fedora 7 base. In the > > past they've used Red Hat's infrastructure to base themselves on Fedora 6, > > but since the merge they can't do that anymore. They'd need to be able to > > add/sponsor packagers, olpc specific branches of some packages, some packages > > that are olpc only, tags within Koji for olpc, and the ability to produce > > repos of the olpc packages out of koji. John (J5) Palmieri should be able to > > join the meeting to represent OLPC in this topic. > > Could we treat OLPC as a secondary arch? In addition to that, I think that you'd want to have OLPC branches in the package repository similar to what we do for EPEL. Anyways, the idea in general gets a +1 from me! Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed Jun 6 15:31:04 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Jun 2007 10:31:04 -0500 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1181143864.464.29.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 17:22 +0200, Michael Schwendt wrote: > On Wed, 06 Jun 2007 15:06:31 +0200, Hans de Goede wrote: > > > I must say I'm a bit disappointed by this action too, lately there has been a > > lot of uproar that those "managing" Fedora seem to have lost touch with the > > "workfloor". This award to me confirms that there is an in-crowd, an old boys > > network, and the rest of us. And to get into this in-crowd one mainly must do a > > lot of irc-meetings and mailing, actually working oneself into sweat isn't enough. > > > > I'm sad to say that these awards mainly seems to be about who can (social) > > network the most, and not necessarily about contributing. > > > > With this I in no way mean to put down the great work done by most of the award > > receivers. However I do see a drift forming here between some kinda in-crowd > > and the rest, which is an alarming development. > > Well said. > > What surprised and disappointed me the most is that this award covers a > time-span of several years, not just 2007. And that after years, on one > hand, "it is difficult to sometimes give recognition" (quoting gdk) and on > the other hand it is that easy to come up with an extreme like this award. I would like to point out that you are complaining about nothing more than these people's names on a web page. That's all the award is. josh From skvidal at linux.duke.edu Wed Jun 6 15:40:46 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 06 Jun 2007 11:40:46 -0400 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <1181143864.464.29.camel@zod.rchland.ibm.com> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> <1181143864.464.29.camel@zod.rchland.ibm.com> Message-ID: <1181144446.7085.9.camel@rivendell> On Wed, 2007-06-06 at 10:31 -0500, Josh Boyer wrote: > On Wed, 2007-06-06 at 17:22 +0200, Michael Schwendt wrote: > > On Wed, 06 Jun 2007 15:06:31 +0200, Hans de Goede wrote: > > > > > I must say I'm a bit disappointed by this action too, lately there has been a > > > lot of uproar that those "managing" Fedora seem to have lost touch with the > > > "workfloor". This award to me confirms that there is an in-crowd, an old boys > > > network, and the rest of us. And to get into this in-crowd one mainly must do a > > > lot of irc-meetings and mailing, actually working oneself into sweat isn't enough. > > > > > > I'm sad to say that these awards mainly seems to be about who can (social) > > > network the most, and not necessarily about contributing. > > > > > > With this I in no way mean to put down the great work done by most of the award > > > receivers. However I do see a drift forming here between some kinda in-crowd > > > and the rest, which is an alarming development. > > > > Well said. > > > > What surprised and disappointed me the most is that this award covers a > > time-span of several years, not just 2007. And that after years, on one > > hand, "it is difficult to sometimes give recognition" (quoting gdk) and on > > the other hand it is that easy to come up with an extreme like this award. > > I would like to point out that you are complaining about nothing more > than these people's names on a web page. That's all the award is. > wait, you didn't get your ferrari dipped in gold and the team of unicorn? Damn. I need to tell greg to get yours shipped out. -sv From buildsys at fedoraproject.org Wed Jun 6 15:43:39 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 6 Jun 2007 11:43:39 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-06 Message-ID: <20070606154339.DFA71152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 22 NEW audio-entropyd-1.0.0-2.fc6 : Generate entropy from audio output bibletime-1.6.4-2.fc6 NEW bottlerocket-0.04c-1.fc6 : Utilities to use the FireCracker X10 kit dbmail-2.2.5-2.fc6 NEW empathy-0.6-3.fc6 : GNOME Instant Messaging Client NEW ftplib-3.1-2.fc6 : Library of FTP routines fuse-2.6.5-2.fc6 gallery2-2.2-0.6.svn20070506.fc6 gscan2pdf-0.9.10-1.fc6 NEW keyjnote-0.10.0-2.fc6 : A program that displays presentation slides mcpp-2.6.4-1.fc6 NEW perl-Catalyst-Manual-5.700701-2.fc6 : Catalyst web framework manual NEW perl-Catalyst-Plugin-Static-Simple-0.15-3.fc6 : Make serving static pages painless NEW perl-Catalyst-Plugin-SubRequest-0.11-3.fc6 : Make subrequests to actions in Catalyst perl-File-RsyncP-0.68-1.fc6 NEW perl-GD-Barcode-1.15-2.fc6 : Create barcode image with GD NEW ps2eps-1.64-2.fc6 : PS-to-EPS converter python-sqlobject-0.7.7-1.fc6 NEW telepathy-idle-0.0.5-1.fc6 : IRC connection manager for Telepathy NEW varnish-1.0.4-2.fc6 : Varnish is a high-performance HTTP accelerator NEW xar-1.5-1.fc6 : The eXtensible ARchiver NEW xbiso-0.6.1-1.fc6 : ISO extraction utility for xdvdfs images Packages built and released for Fedora Extras 5: 13 NEW audio-entropyd-1.0.0-2.fc5 : Generate entropy from audio output dbmail-2.2.5-2.fc5 NEW ftplib-3.1-2.fc5 : Library of FTP routines fuse-2.6.5-2.fc5 gallery2-2.2-0.6.svn20070506.fc5 gscan2pdf-0.9.10-1.fc5 NEW perl-Catalyst-Manual-5.700701-2.fc5 : Catalyst web framework manual NEW perl-Catalyst-Plugin-Static-Simple-0.15-3.fc5 : Make serving static pages painless NEW perl-Catalyst-Plugin-SubRequest-0.11-3.fc5 : Make subrequests to actions in Catalyst NEW perl-GD-Barcode-1.15-2.fc5 : Create barcode image with GD NEW ps2eps-1.64-2.fc5 : PS-to-EPS converter NEW xar-1.5-1.fc5 : The eXtensible ARchiver NEW xbiso-0.6.1-1.fc5 : ISO extraction utility for xdvdfs images Changes in Fedora Extras 6: audio-entropyd-1.0.0-2.fc6 -------------------------- * Tue Jun 05 2007 Tom "spot" Callaway 1.0.0-2 - add condrestart to postun * Tue May 15 2007 Tom "spot" Callaway 1.0.0-1 - initial package for Fedora Extras bibletime-1.6.4-2.fc6 --------------------- * Fri May 04 2007 David Anderson 1.6.4-2 - 1.6.4 bottlerocket-0.04c-1.fc6 ------------------------ * Sat May 26 2007 Sindre Pedersen Bj?rdal - 0.04c-1 - Initial build dbmail-2.2.5-2.fc6 ------------------ * Tue Jun 05 2007 Bernard Johnson 2.2.5-2 - fix %setup directory * Tue Jun 05 2007 Bernard Johnson 2.2.5-1 - 2.2.5 - change method of restarting daemons to that suggested in dbmail bug #600 * Wed May 23 2007 Bernard Johnson 2.2.5-0.1.rc3 - update to svn 2.2.5rc3 - remove unneccessary patches - make sqlite default driver for better out of the box experience * Fri Mar 23 2007 Bernard Johnson 2.2.4-4 - actually APPLY the short write patch * Thu Mar 22 2007 Bernard Johnson 2.2.4-3 - patch to eliminate short write messages - use /sbin/service instead of running init scripts directly - requires for initscripts because daemon function in initfile requires it - modern tarballs do not require xmlto and asciidoc to build the docs - change conditionals to give everything sqlite support unless it's built in the fedora buildsystem and %{fedora} < 4 empathy-0.6-3.fc6 ----------------- * Mon Jun 04 2007 David Nielsen - 0.6-3 - Add telepathy-filesystem to Requires - Move .desktop from autostart to applications - Nasty hackery to make empathy launch from the menu * Mon Jun 04 2007 David Nielsen - 0.6-2 - Add gettext to BuildRequires * Fri Jun 01 2007 David Nielsen - 0.6-1 - Bump to 0.6 * Fri Jun 01 2007 David Nielsen - 0.5-2 - Let Empathy own the directory and not just the files in it * Wed May 30 2007 David Nielsen - 0.5-1 - Initial package ftplib-3.1-2.fc6 ---------------- * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-2 - fix licensing (libs LGPL, qftp GPL) * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-1 - initial build for Fedora fuse-2.6.5-2.fc6 ---------------- * Wed Jun 06 2007 Peter Lemenkov 2.6.5-2 - Add BR libselinux-devel (bug #235145) - Config files properly marked as config (bug #211122) * Sat May 12 2007 Peter Lemenkov 2.6.5-1 - Version 2.6.5 gallery2-2.2-0.6.svn20070506.fc6 -------------------------------- * Tue Jun 05 2007 John Berninger - 2.2-0.6.svn20070506 - Fix escaping syntax problem in post scriptlet * Tue May 15 2007 John Berninger - 2.2-0.5.svn20070506 - README file update and new build gscan2pdf-0.9.10-1.fc6 ---------------------- * Tue Jun 05 2007 Bernard Johnson - 0.9.10-1 - v 0.9.10 keyjnote-0.10.0-2.fc6 --------------------- * Tue Jun 05 2007 Allisson Azevedo 0.10.0-2 - Add build section - Remove buildrequires * Tue Jun 05 2007 Allisson Azevedo 0.10.0-1 - Initial RPM release mcpp-2.6.4-1.fc6 ---------------- * Sat May 19 2007 Kiyoshi Matsui 2.6.4-1 - Upstream new release. perl-Catalyst-Manual-5.700701-2.fc6 ----------------------------------- * Tue Jun 05 2007 Chris Weyl 5.700701-2 - bump perl-Catalyst-Plugin-Static-Simple-0.15-3.fc6 --------------------------------------------- * Tue Jun 05 2007 Chris Weyl 0.15-3 - bump * Tue Jun 05 2007 Chris Weyl 0.15-2 - add perl(HTTP::Request::AsCGI) as br - include all of t/, not just t/lib/TestApp/ perl-Catalyst-Plugin-SubRequest-0.11-3.fc6 ------------------------------------------ * Tue Jun 05 2007 Chris Weyl 0.11-3 - bump * Tue May 22 2007 Chris Weyl 0.11-2 - include missing BR - add t/ to doc perl-File-RsyncP-0.68-1.fc6 --------------------------- * Mon Jun 04 2007 Mike McGrath - 0.68-1 - Upstream released new version perl-GD-Barcode-1.15-2.fc6 -------------------------- * Mon Jun 04 2007 Chris Weyl 1.15-2 - bump * Mon May 28 2007 Chris Weyl 1.15-1 - Specfile autogenerated by cpanspec 1.71. ps2eps-1.64-2.fc6 ----------------- * Sat Jun 02 2007 Terje R?sten - 1.64-2 - add secure tmpfile patch - don't skip Install.txt - preserve dates on files (where possible) - fix defattr * Sat Jun 02 2007 Terje R?sten - 1.64-1 - 1.64 - Fix shebang python-sqlobject-0.7.7-1.fc6 ---------------------------- * Tue Jun 05 2007 Luke Macken 0.7.7-1 - 0.7.7 telepathy-idle-0.0.5-1.fc6 -------------------------- * Mon Apr 16 2007 Brian Pepple - 0.0.5-1 - Initial spec file. varnish-1.0.4-2.fc6 ------------------- * Sun May 20 2007 Ingvar Hagelund - 1.0.4-2 - Repack from unchanged 1.0.4 tarball - Final review request and CVS request for Fedora Extras * Fri May 18 2007 Dag-Erling Sm?rgrav - 1.0.4-1 - Bump Version and Release for 1.0.4 * Wed May 16 2007 Ingvar Hagelund - 1.0.svn-20070517 - Wrapping up for 1.0.4 - Changes in sysconfig and init scripts. Syncing with files in trunk/debian * Fri May 11 2007 Ingvar Hagelund - 1.0.svn-20070511 - Threw latest changes into svn trunk - Removed the conversion of manpages into utf8. They are all utf8 in trunk * Wed May 09 2007 Ingvar Hagelund - 1.0.3-7 - Simplified the references to the subpackage names - Added init and logrotate scripts for varnishlog xar-1.5-1.fc6 ------------- * Wed May 30 2007 Matthias Saou 1.5-1 - Update to 1.5. - Include patch to remove rpath. - Include patch to fix file modes, and get the lib properly stripped. xbiso-0.6.1-1.fc6 ----------------- * Mon Jun 04 2007 Tom "spot" Callaway - 0.6.1-1 - initial build for Fedora Changes in Fedora Extras 5: audio-entropyd-1.0.0-2.fc5 -------------------------- * Tue Jun 05 2007 Tom "spot" Callaway 1.0.0-2 - add condrestart to postun * Tue May 15 2007 Tom "spot" Callaway 1.0.0-1 - initial package for Fedora Extras dbmail-2.2.5-2.fc5 ------------------ * Tue Jun 05 2007 Bernard Johnson 2.2.5-2 - fix %setup directory * Tue Jun 05 2007 Bernard Johnson 2.2.5-1 - 2.2.5 - change method of restarting daemons to that suggested in dbmail bug #600 * Wed May 23 2007 Bernard Johnson 2.2.5-0.1.rc3 - update to svn 2.2.5rc3 - remove unneccessary patches - make sqlite default driver for better out of the box experience ftplib-3.1-2.fc5 ---------------- * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-2 - fix licensing (libs LGPL, qftp GPL) * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-1 - initial build for Fedora fuse-2.6.5-2.fc5 ---------------- * Wed Jun 06 2007 Peter Lemenkov 2.6.5-2 - Add BR libselinux-devel (bug #235145) - Config files properly marked as config (bug #211122) gallery2-2.2-0.6.svn20070506.fc5 -------------------------------- * Tue Jun 05 2007 John Berninger - 2.2-0.6.svn20070506 - Fix escaping syntax problem in post scriptlet gscan2pdf-0.9.10-1.fc5 ---------------------- * Tue Jun 05 2007 Bernard Johnson - 0.9.10-1 - v 0.9.10 perl-Catalyst-Manual-5.700701-2.fc5 ----------------------------------- * Tue Jun 05 2007 Chris Weyl 5.700701-2 - bump perl-Catalyst-Plugin-Static-Simple-0.15-3.fc5 --------------------------------------------- * Tue Jun 05 2007 Chris Weyl 0.15-3 - bump * Tue Jun 05 2007 Chris Weyl 0.15-2 - add perl(HTTP::Request::AsCGI) as br - include all of t/, not just t/lib/TestApp/ perl-Catalyst-Plugin-SubRequest-0.11-3.fc5 ------------------------------------------ * Tue Jun 05 2007 Chris Weyl 0.11-3 - bump * Tue May 22 2007 Chris Weyl 0.11-2 - include missing BR - add t/ to doc perl-GD-Barcode-1.15-2.fc5 -------------------------- * Mon Jun 04 2007 Chris Weyl 1.15-2 - bump * Mon May 28 2007 Chris Weyl 1.15-1 - Specfile autogenerated by cpanspec 1.71. ps2eps-1.64-2.fc5 ----------------- * Sat Jun 02 2007 Terje R?sten - 1.64-2 - add secure tmpfile patch - don't skip Install.txt - preserve dates on files (where possible) - fix defattr * Sat Jun 02 2007 Terje R?sten - 1.64-1 - 1.64 - Fix shebang xar-1.5-1.fc5 ------------- * Wed May 30 2007 Matthias Saou 1.5-1 - Update to 1.5. - Include patch to remove rpath. - Include patch to fix file modes, and get the lib properly stripped. xbiso-0.6.1-1.fc5 ----------------- * Mon Jun 04 2007 Tom "spot" Callaway - 0.6.1-1 - initial build for Fedora For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From linux_4ever at yahoo.com Wed Jun 6 15:45:20 2007 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 6 Jun 2007 08:45:20 -0700 (PDT) Subject: rawhide report: 20070605 changes In-Reply-To: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> Message-ID: <183856.84744.qm@web51501.mail.re2.yahoo.com> > >kernel-2.6.21-1.3206.fc8 >------------------------ >* Mon Jun 04 2007 Dave Jones >- Allow kdump to read /proc/kcore. (#241362) > >* Mon Jun 04 2007 Dave Jones >- 2.6.22-rc3-git7 > >* Mon Jun 04 2007 Dave Jones >- Remove some warning switches. FYI, today's kernel breaks hwclock. [root ~]# /sbin/hwclock --systohc --utc --debug hwclock from util-linux-2.13-pre7 hwclock: Open of /dev/rtc failed, errno=19: No such device. No usable clock interface found. Cannot access the Hardware Clock via any known method. Booting the 3194 kernel, it works again. -Steve ___________________________________________________________________________________ You snooze, you lose. Get messages ASAP with AutoCheck in the all-new Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_html.html From mschwendt.tmp0701.nospam at arcor.de Wed Jun 6 16:10:05 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 6 Jun 2007 18:10:05 +0200 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <1181143864.464.29.camel@zod.rchland.ibm.com> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> <1181143864.464.29.camel@zod.rchland.ibm.com> Message-ID: <20070606181005.6d216dc5.mschwendt.tmp0701.nospam@arcor.de> On Wed, 06 Jun 2007 10:31:04 -0500, Josh Boyer wrote: > I would like to point out that you are complaining about nothing more > than these people's names on a web page. That's all the award is. http://en.wikipedia.org/wiki/Award disagrees... From sundaram at fedoraproject.org Wed Jun 6 16:24:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 21:54:44 +0530 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <20070606181005.6d216dc5.mschwendt.tmp0701.nospam@arcor.de> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> <1181143864.464.29.camel@zod.rchland.ibm.com> <20070606181005.6d216dc5.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <4666DFCC.5040408@fedoraproject.org> Michael Schwendt wrote: > On Wed, 06 Jun 2007 10:31:04 -0500, Josh Boyer wrote: > >> I would like to point out that you are complaining about nothing more >> than these people's names on a web page. That's all the award is. > > http://en.wikipedia.org/wiki/Award disagrees... Who cares about what wikipedia says in this context? Rahul From lsof at nodata.co.uk Wed Jun 6 16:35:10 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 06 Jun 2007 18:35:10 +0200 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <1181143864.464.29.camel@zod.rchland.ibm.com> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> <1181143864.464.29.camel@zod.rchland.ibm.com> Message-ID: <1181147710.4526.3.camel@sb-home> Am Mittwoch, den 06.06.2007, 10:31 -0500 schrieb Josh Boyer: > On Wed, 2007-06-06 at 17:22 +0200, Michael Schwendt wrote: > > I would like to point out that you are complaining about nothing more > than these people's names on a web page. That's all the award is. > > josh > Way to kill someone's achievements. Well done. From limb at jcomserv.net Wed Jun 6 16:32:19 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 6 Jun 2007 11:32:19 -0500 (CDT) Subject: First impressions of a system update with yum In-Reply-To: <1181033622.2504.5.camel@work> References: <20070531192013.11324b9b@python3.es.egwn.lan> <4e1f5c1a0705311220u2ed2669ya41db95a8b9243ac@mail.gmail.com> <20070601105241.35b741bc@python3.es.egwn.lan> <1180688318.2556.11.camel@localhost.localdomain> <20070605102553.20ceb611@python3.es.egwn.lan> <1181033622.2504.5.camel@work> Message-ID: <50789.65.192.24.190.1181147539.squirrel@mail.jcomserv.net> I've now completed 2 yum upgrades of x86 32-bit only systems, with no gotchas. This can't be right. . .;) > On Tue, 2007-06-05 at 10:25 +0200, Matthias Saou wrote: >> Richard Hughes wrote : >> >> > On Fri, 2007-06-01 at 10:52 +0200, Matthias Saou wrote: >> > > I just need to get S3 working again, as I wanted to start fresh and >> > > removed all the kernel boot options I had in case they weren't >> useful >> > > anymore... >> > >> > If you are talking about s3 (suspend), see >> > http://people.freedesktop.org/~hughsient/quirk/ >> >> That page was incredibly helpful. I actually understood what all those >> different "quirks" did! :-) > > Good :-) > > I'll continue to add content as required. Soon multimedia keyboard will > be quirks in hal-info and the same site will be used to make keyboards > just work in the future. > >> For my Dell "Latitude X1", which is not yet in the F7 HAL files, I had >> to enable the --quirk-vbe-post quirk, as otherwise the screen never >> turned on. > > Cool. > >> With F7, I switched to the "intel" modesetting driver (also removed >> 855resolution), added the "power_management.quirk.vbe_post" key to true >> in a string="Latitude X1" section of the Dell HAL file, and it all just >> works now! Awesome! :-) > > Cool. > >> I had a last question, though : The Dell models seem to be identified >> with system.hardware.product contains="Foo". This seems like a pretty >> bad idea, since it would be contains="X1" in this case, and will/would >> match a future Dell "Latitude X10" laptop... It would seem wiser to use >> string="Latitude X1", even though it would be partly redundant with the >> earlier prefix="Latitude". Or maybe there is a suffix="Bar"? > > There is such a thing: > > > key CDATA #REQUIRED > string CDATA #IMPLIED > int CDATA #IMPLIED > bool (false|true) #IMPLIED > exists (false|true) #IMPLIED > empty (false|true) #IMPLIED > is_ascii (false|true) #IMPLIED > is_absolute_path (false|true) #IMPLIED > contains CDATA #IMPLIED > contains_ncase CDATA #IMPLIED > contains_not CDATA #IMPLIED > prefix CDATA #IMPLIED > prefix_ncase CDATA #IMPLIED > suffix CDATA #IMPLIED > suffix_ncase CDATA #IMPLIED > compare_lt CDATA #IMPLIED > compare_le CDATA #IMPLIED > compare_gt CDATA #IMPLIED > compare_ge CDATA #IMPLIED > compare_ne CDATA #IMPLIED > sibling_contains CDATA #IMPLIED >> > > You can either use suffix or just use string for the whole text. > > I would be very appreciative if you could generate a patch and sent it > to the mailing list. I'm glad things are now working. > > Richard. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jwboyer at jdub.homelinux.org Wed Jun 6 16:39:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Jun 2007 11:39:19 -0500 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <1181147710.4526.3.camel@sb-home> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> <1181143864.464.29.camel@zod.rchland.ibm.com> <1181147710.4526.3.camel@sb-home> Message-ID: <1181147959.464.32.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 18:35 +0200, nodata wrote: > Am Mittwoch, den 06.06.2007, 10:31 -0500 schrieb Josh Boyer: > > On Wed, 2007-06-06 at 17:22 +0200, Michael Schwendt wrote: > > > > I would like to point out that you are complaining about nothing more > > than these people's names on a web page. That's all the award is. > > > > josh > > > > Way to kill someone's achievements. Well done. Yep. That's exactly what I intended to do. You've found my secret plan to demoralize everyone. josh From david at fubar.dk Wed Jun 6 16:47:56 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 06 Jun 2007 12:47:56 -0400 Subject: Unmounting removable media under Gnome In-Reply-To: References: Message-ID: <1181148476.7761.13.camel@zelda.fubar.dk> On Wed, 2007-06-06 at 10:11 +0100, Steve Hill wrote: > Additionally, it appears that the logged in user does not have permission > to umount the disc - the only work around seems to be to open a terminal, > log in as root and manually umount the device. False. As of Fedora 7, umount from the command line works just fine [davidz at zelda ~]$ mount |grep /dev/scd0 /dev/scd0 on /media/LOST_S1_DISC2_US type udf (ro,nosuid,nodev,uhelper=hal,uid=500) [davidz at zelda ~]$ umount /dev/scd0 [davidz at zelda ~]$ mount |grep /dev/scd0 [davidz at zelda ~]$ sudo /lib/udev/vol_id /dev/scd0 ID_FS_USAGE=filesystem ID_FS_TYPE=udf ID_FS_VERSION= ID_FS_UUID= ID_FS_LABEL=LOST_S1_DISC2_US ID_FS_LABEL_SAFE=LOST_S1_DISC2_US > Are there any good reasons why Nautilus should not have an option to > unmount without ejecting? Are the any good reasons why CD-burning software can't invoke umount(8) or do something else themselves? Nautilus-CD-Burner been able to do this for years... David From cweyl at alumni.drew.edu Wed Jun 6 16:53:58 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 6 Jun 2007 09:53:58 -0700 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <200706060912.45498.jkeating@redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1181070292.3939.3.camel@neutron.verbum.private> <200706060912.45498.jkeating@redhat.com> Message-ID: <7dd7ab490706060953s39313390w9e4963add2bf9c01@mail.gmail.com> On 6/6/07, Jesse Keating wrote: > On Tuesday 05 June 2007 16:56:45 Kevin Kofler wrote: > > Or we could just use APT-RPM and stop worrying about Python. > > Right, because glibc and c libraries never change right? Well, to be fair (and playing devils advocate here), for something like this it seems like the main problem is potential yum/python changes, and the large infrastructure that would be needed to support that. apt could be included and built statically for just this limited purpose. Wouldn't that help? -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Wed Jun 6 16:54:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 12:54:22 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <7dd7ab490706060953s39313390w9e4963add2bf9c01@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <200706060912.45498.jkeating@redhat.com> <7dd7ab490706060953s39313390w9e4963add2bf9c01@mail.gmail.com> Message-ID: <200706061254.22379.jkeating@redhat.com> On Wednesday 06 June 2007 12:53:58 Chris Weyl wrote: > Well, to be fair (and playing devils advocate here), for something > like this it seems like the main problem is potential yum/python > changes, and the large infrastructure that would be needed to support > that. ?apt could be included and built statically for just this > limited purpose. > > Wouldn't that help? I think we're way off in the weeds trying to solve the wrong problem here. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rcritten at redhat.com Wed Jun 6 17:02:50 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Jun 2007 13:02:50 -0400 Subject: Announcing the Fedora Award winners for 2007 In-Reply-To: <4666DFCC.5040408@fedoraproject.org> References: <200706061305.21964.ddmbox2@yahoo.co.uk> <4666B157.6030800@hhs.nl> <20070606172234.7a8a6402.mschwendt.tmp0701.nospam@arcor.de> <1181143864.464.29.camel@zod.rchland.ibm.com> <20070606181005.6d216dc5.mschwendt.tmp0701.nospam@arcor.de> <4666DFCC.5040408@fedoraproject.org> Message-ID: <4666E8BA.5010605@redhat.com> Rahul Sundaram wrote: > Michael Schwendt wrote: >> On Wed, 06 Jun 2007 10:31:04 -0500, Josh Boyer wrote: >> >>> I would like to point out that you are complaining about nothing more >>> than these people's names on a web page. That's all the award is. >> >> http://en.wikipedia.org/wiki/Award disagrees... > > Who cares about what wikipedia says in this context? > > Rahul > Wikipedia says: "An award can also simply be a public acknowledgment of excellence, without a tangible token or a prize." That about sums it up. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From paul at xelerance.com Wed Jun 6 17:30:04 2007 From: paul at xelerance.com (Paul Wouters) Date: Wed, 6 Jun 2007 13:30:04 -0400 (EDT) Subject: CDs from DVD with Pungi almost works In-Reply-To: <200706060917.16954.jkeating@redhat.com> References: <4665AFE1.3090509@redhat.com> <200706060917.16954.jkeating@redhat.com> Message-ID: On Wed, 6 Jun 2007, Jesse Keating wrote: > At the bottom of > https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs which is > linked to on the front page there is a link to > https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs/RunningPungi > > At the bottom of that there is > https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs/RunningPungiInMock Just a small note. As I was trying to compose my own set of packages, and (obviously) doing something wrong, I noticed that pungi somehow, somewhere, decided to use my system's yum, instead of through the config file specified with -c. I know, because my own system includes Livna, while my /etc/pungi/ has no mention of livna whatsover (and I don't want/need it on my own spin) So for testing I created /etc/pungi/f7-fedora-minimal.i386, using the minimal.manifest and overnight that did successfully build the entire tree including ISO images. I haven't had time to debug my own package set configuration yet, I am picking that up later today. Revisor looks like an interesting tool, though it adds another laywer of confusion by using/needing its own pungi files, and comes with a disclaimer that you can only build for the arch that you are currently running (unfortunately, I am running x86_64 and need to build an i386 iso). I am not sure why this requirement is in revisor. Paul From jwilson at redhat.com Wed Jun 6 17:51:48 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 06 Jun 2007 13:51:48 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <46664CFB.7050606@gmail.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> Message-ID: <4666F434.4010508@redhat.com> Ken YANG wrote: > Matthias Clasen wrote: >> On Tue, 2007-06-05 at 22:11 -0400, Christopher Aillon wrote: >>> Ken YANG wrote: >>>> hi all, >>>> >>>> i am using fc8 rawhide, and with libwnck: >>>> >>>> libwnck-2.19.3-2.fc8 >>>> >>>> but emerald fail to start, it need libwnck-1.so.18, >>>> so i use a trick to pass this error: >>>> >>>> ln -s libwnck-1.so.21.0.0 libwnck-1.so.18 >>>> >>>> i think emerald should be compiled with new libwnck >>>> >>> I wonder why you were able to install the RPM without it complaining >>> about the dependencies there. That might deserve a bug. > > actually, i update libwnck through "yum update", and there is not > dependencies error, anyway, as clasen said, this error will be fixed > soon For the record, updated beryl bits just hit updates-testing for F7, and are all checked into cvs for F8, but were failing to build yesterday due to libwnck issues. With luck, this latest libwnck update will fix that and they'll actually build... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Wed Jun 6 17:58:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 13:58:47 -0400 Subject: CDs from DVD with Pungi almost works In-Reply-To: References: <200706060917.16954.jkeating@redhat.com> Message-ID: <200706061358.48021.jkeating@redhat.com> On Wednesday 06 June 2007 13:30:04 Paul Wouters wrote: > Just a small note. As I was trying to compose my own set of packages, > and (obviously) doing something wrong, I noticed that pungi somehow, > somewhere, decided to use my system's yum, instead of through the config > file specified with -c. I know, because my own system includes Livna, > while my /etc/pungi/ has no mention of livna whatsover (and I don't > want/need it on my own spin) That may be a bug in yum, or in the way that I'm using yum. I need to work with Seth on that... > So for testing I created /etc/pungi/f7-fedora-minimal.i386, using the > minimal.manifest and overnight that did successfully build the entire > tree including ISO images. I haven't had time to debug my own package > set configuration yet, I am picking that up later today. > > Revisor looks like an interesting tool, though it adds another laywer > of confusion by using/needing its own pungi files, and comes with a > disclaimer that you can only build for the arch that you are currently > running (unfortunately, I am running x86_64 and need to build an i386 > iso). I am not sure why this requirement is in revisor. Pungi has that requirement too. However with mock and setarch you can get around that. The requirement is actually on the anaconda tools that reviser asks pungi to run, as those need to be ran on the arch you are composing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernie at codewiz.org Wed Jun 6 18:09:11 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Wed, 06 Jun 2007 14:09:11 -0400 Subject: Splitting the ncurses RPM In-Reply-To: <20070606122312.GA25767@localhost> References: <466385F1.8030005@codewiz.org> <20070604120659.GA1483@localhost> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> Message-ID: <4666F847.7090201@codewiz.org> Miroslav Lichvar wrote: > This list is far too short, xterm-256color, gnome, teraterm, jfbterm, > mrxvt and others should be included. I guess it will be pretty hard to > select from descriptions so the extra terminfo package won't have to > be installed by default. You're right, but what is "gnome"? gnome-terminal uses "xterm", afaik. > Any ideas? Couldn't you make the list short and include new terminals by request? So if nobody requests to ask for "jfbterm", it doesn't get in. Something tells me they won't bother you very often :-) -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From buildsys at fedoraproject.org Wed Jun 6 18:20:44 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 06 Jun 2007 18:20:44 -0000 Subject: Summary - Broken dependencies in Fedora 7 - 2007-06-06 Message-ID: <20070606182044.7480.68735@extras64.linux.duke.edu> New report for: Axel.Thimm AT ATrpms.net package: synaptic - 0.57.2-5.2.fc7.i386 from fedora-7-i386 unresolved deps: libapt-pkg-libc6.5-6.so.2 package: synaptic - 0.57.2-5.2.fc7.ppc from fedora-7-ppc unresolved deps: libapt-pkg-libc6.5-6.so.2 package: synaptic - 0.57.2-5.2.fc7.ppc64 from fedora-7-ppc64 unresolved deps: libapt-pkg-libc6.5-6.so.2()(64bit) package: synaptic - 0.57.2-5.2.fc7.x86_64 from fedora-7-x86_64 unresolved deps: libapt-pkg-libc6.5-6.so.2()(64bit) ====================================================================== New report for: jwilson AT redhat.com package: beryl-gnome - 0.2.1-1.fc7.ppc64 from fedora-updates-testing-7-ppc64 unresolved deps: beryl-manager >= 0:0.2.1 package: beryl-kde - 0.2.1-1.fc7.ppc64 from fedora-updates-testing-7-ppc64 unresolved deps: beryl-manager >= 0:0.2.1 ====================================================================== New report for: jonathansteffan AT gmail.com package: revisor - 2.0.3.7-1.fc7.noarch from fedora-updates-testing-7-ppc64 unresolved deps: livecd-tools package: revisor - 2.0.3.7-1.fc7.noarch from fedora-updates-testing-7-ppc unresolved deps: livecd-tools ====================================================================== Summary of broken packages (by owner): Axel.Thimm AT ATrpms.net synaptic - 0.57.2-5.2.fc7.i386 synaptic - 0.57.2-5.2.fc7.ppc synaptic - 0.57.2-5.2.fc7.ppc64 synaptic - 0.57.2-5.2.fc7.x86_64 cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (4 days) dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (4 days) fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 (4 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (4 days) glest-data - 2.0.0-2.fc7.noarch (4 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 (4 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 (4 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (4 days) kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 (4 days) kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (4 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (4 days) jonathansteffan AT gmail.com revisor - 2.0.3.7-1.fc7.noarch revisor - 2.0.3.7-1.fc7.noarch jwilson AT redhat.com beryl-gnome - 0.2.1-1.fc7.ppc64 beryl-kde - 0.2.1-1.fc7.ppc64 karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (4 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (4 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (4 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (4 days) mdehaan AT redhat.com koan - 0.4.0-1.fc7.noarch (4 days) orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 (4 days) rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 (4 days) rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (4 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (4 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (4 days) tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 (4 days) Democracy - 0.9.5.1-8.fc7.ppc (4 days) Democracy - 0.9.5.1-8.fc7.ppc64 (4 days) Democracy - 0.9.5.1-8.fc7.x86_64 (4 days) ====================================================================== Broken packages in fedora-7-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE synaptic-0.57.2-5.2.fc7.i386 requires libapt-pkg-libc6.5-6.so.2 ====================================================================== Broken packages in fedora-7-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) synaptic-0.57.2-5.2.fc7.ppc64 requires libapt-pkg-libc6.5-6.so.2()(64bit) wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in fedora-7-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 synaptic-0.57.2-5.2.fc7.ppc requires libapt-pkg-libc6.5-6.so.2 ====================================================================== Broken packages in fedora-7-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump synaptic-0.57.2-5.2.fc7.x86_64 requires libapt-pkg-libc6.5-6.so.2()(64bit) ====================================================================== Broken packages in fedora-updates-testing-7-ppc64: beryl-gnome-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 beryl-kde-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 koan-0.4.0-1.fc7.noarch requires syslinux revisor-2.0.3.7-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-testing-7-ppc: revisor-2.0.3.7-1.fc7.noarch requires livecd-tools From notting at redhat.com Wed Jun 6 18:24:57 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Jun 2007 14:24:57 -0400 Subject: Splitting the ncurses RPM In-Reply-To: <20070606151317.GA27490@localhost> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> Message-ID: <20070606182457.GG5700@nostromo.devel.redhat.com> Miroslav Lichvar (mlichvar at redhat.com) said: > Ok. Maybe I'd use a bit different naming instead: > > ncurses-bin: bin/* > ncurses-base: lib*.so.* /etc/terminfo /lib/terminfo, some of /usr/share/terminfo > ncurses-terminfo: rest of /usr/share/terminfo > ncurses: requires: -bin -base -terminfo > > How does this sound? For sanity's sake on upgrades, leaving the libraries in the same package name (multilib) would be best. Bill From mclasen at redhat.com Wed Jun 6 18:25:16 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 06 Jun 2007 14:25:16 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <4666F434.4010508@redhat.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> Message-ID: <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> On Wed, 2007-06-06 at 13:51 -0400, Jarod Wilson wrote: > > For the record, updated beryl bits just hit updates-testing for F7, and > are all checked into cvs for F8, but were failing to build yesterday due > to libwnck issues. With luck, this latest libwnck update will fix that > and they'll actually build... > It is not unlikely that beryl needs that same patch that I added to compiz to make it build against the new libwnck. From mmcgrath at redhat.com Wed Jun 6 18:46:43 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 06 Jun 2007 13:46:43 -0500 Subject: Outage Notification - 2007-06-07 04:00 [UTC] Message-ID: <46670113.1020102@redhat.com> There will be an outage starting at 2007-06-07 04:00 [UTC], which will last approximately 30 minutes. To convert UTC to your local time, use: http://www.timeanddate.com/worldclock/converter.html Affected Services: Buildsystem Unaffected Services: Websites CVS / Source Control Database DNS Mail Torrent Reason for Outage: Upgrading Koji Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From jkeating at redhat.com Wed Jun 6 19:01:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 15:01:44 -0400 Subject: Future SCM Technology In-Reply-To: <1181150167.4009.55.camel@lt21223.campus.dmacc.edu> References: <1181150167.4009.55.camel@lt21223.campus.dmacc.edu> Message-ID: <200706061501.44535.jkeating@redhat.com> On Wednesday 06 June 2007 13:16:07 Jeffrey C. Ollie wrote: > It's F7+5 and F8T1-57 (yes, less than two months until F8T1 under the > current schedule[1]). ?If we are going to replace CVS[2] with another > SCM for hosting the Fedora Package Repository we need to get started > now! ?And to get things started, we need to discuss what kinds of > workflow we want our new SCM to support. As stated on Fedora Infrastructure List I firmly believe that this is not something we can do by F8 release. This is something we need to discuss and strawman and put up proof of concepts and get more people thinking on it during the F8 cycle and try to implement during the F9 cycle if possible. > > Here's a list of things to think about (thanks to Jeremy Katz): > * How do we make it easier for a maintainer to rebase their package to a > newer upstream? Perhaps you should define a bit here what is meant by 'rebase'. Is it adjusting local patches to the new source, or is it just getting the new tarball into the mix? For the former, I think that having exploaded source tree modules may be helpful in this regard. Something that doesn't come down by default, but can be requested with a make command. Once you have the exploaded tree then you can do fun things with patch management systems such as quilt to port your patches and some such. For the latter, I'm not sure what we can do to make it easier, if we have to. Seems pretty easy to me to chuck a new tarball at the source control. Is there anybody out there that thinks that this is too hard? > * How do we make it easier for a maintainer to develop, test, and create > a patch to fix a problem that's being experienced in Fedora? This kind of goes back to the exploaded tree again, and a patch management system. Other than that we really want to be able to send test builds with these patches somewhere and get users to them. How much that is related to the SCM, probably not much, just more fun with make files and koji targets. > * How do we make it easy to send these patches to the upstream of the > project being worked on? Git has some pretty compelling tools for sending changesets around, to/from bugzilla, email, etc... It's also easy to make git repos http available so that somebody can easily cherry pick a patch set or change set off an exploaded source tree. > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? I really like this one here. A distributed SCM make this pretty easy I bet, downstreams can just clone our repos, add their changes, and continue to "pull" in upstream changes to merge with their downstream changes. Eventually we upstream can cherry pick their changes into our upstream. > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? distributed SCMs are easy to clone and have local to build stuff. Of course that would mean that the module they clone is self sufficient in that it can be used to produce a source rpm that in turn can be chucked at koji or a local mock target. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Wed Jun 6 19:10:37 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 6 Jun 2007 15:10:37 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-06 Message-ID: <20070606191037.C48F9152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 3 cook-2.28-1.fc6 koji-1.2.2-1.fc6 NEW sipp-2.0-1.fc6 : SIP test tool / traffic generator Changes in Fedora Extras 6: cook-2.28-1.fc6 --------------- * Wed Jun 06 2007 Gerard Milmeister - 2.28-1 - new version 2.28 koji-1.2.2-1.fc6 ---------------- * Tue Jun 05 2007 Mike Bonnet - 1.2.2-1 - only allow admins to perform non-scratch builds from srpm - bug fixes to the cmd-line and web UIs - don't allow ExclusiveArch to expand the archlist (bz#239359) - add a summary line stating whether the task succeeded or failed to the end of the "watch-task" output - add a search box to the header of every page in the web UI - new koji download-build command (patch provided by Dan Berrange) - patch /etc/koji.conf so the cli will work out-of-the-box with Fedora Koji * Tue May 15 2007 Jesse Keating - 1.2.0-3 - More fixes to fedora-packager-setup.sh from mbonnet * Tue May 15 2007 Jesse Keating - 1.2.0-2 - overwrite and hardlink ssl cert for fedora packagers (dgilmore) * Tue May 15 2007 Mike Bonnet - 1.2.0-1 - change version numbering to a 3-token scheme - install the koji favicon * Mon May 14 2007 Mike Bonnet - 1.1-5 - cleanup koji-utils Requires - fix encoding and formatting in email notifications - expand archlist based on ExclusiveArch/BuildArchs - allow import of rpms without srpms - commit before linking in prepRepo to release db locks - remove exec bit from kojid logs and uploaded files (patch by Enrico Scholz) sipp-2.0-1.fc6 -------------- * Sat May 12 2007 Peter Lemenkov 2.0-1 - Version 2.0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From blc at redhat.com Wed Jun 6 19:46:56 2007 From: blc at redhat.com (Brendan Conoboy) Date: Wed, 06 Jun 2007 13:46:56 -0600 Subject: fedora for ARM In-Reply-To: <1181047155.27239.100.camel@mccallum.corsepiu.local> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> Message-ID: <46670F30.8080102@redhat.com> Ralf Corsepius wrote: >> There are indeed some hacks around rpm to make the packahes >> think they are being build nativly, but what I've seen these are very gross >> hacks and still break often. > Well, RH's rpm and redhat-rpm-config are grossly broken when it comes to > cross-building rpms. Many things work once you kick redhat-rpm-config > out :( Hi Ralf, Do you think that redhat-rpm-config is fundamentally broken, or does it simply need to be made more cross friendly? Like others on the list, I am a strong advocate of cross building on platforms that are either slower or scarcer than make for good build hosts. From your posts it seems like problems with redhat-rpm-config have been longstanding for you, so I wonder if you have some suggestions on what needs to be done (even if you don't have the time to do it yourself). >> Native compiling definitively is the way to go, > This is only applicable for sufficiently performing targets. > Esp. for low end targets this is close to impossible. Exactly. >> an alternative might be >> emulating the native system and building in the emulated system. > With a few exceptions, in practice, this is rarely applicable, esp. when > it comes to "less mainstream" targets. There is something to be said for target emulation or run-parts-of-the-build-on-hardware solutions, but I think the best answer is one where any available host can compile Fedora for any target. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Wed Jun 6 19:55:47 2007 From: blc at redhat.com (Brendan Conoboy) Date: Wed, 06 Jun 2007 13:55:47 -0600 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1180719866.25232.36.camel@pmac.infradead.org> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <7dd7ab490705291600x633a3452w85d9275ea662fbf9@mail.gmail.com> <1180516024.26803.87.camel@pmac.infradead.org> <20070530092348.GN4033@devserv.devel.redhat.com> <465F6AB7.8080604@redhat.com> <1180660510.26803.592.camel@pmac.infradead.org> <4660490D.9020902@redhat.com> <1180719866.25232.36.camel@pmac.infradead.org> Message-ID: <46671143.1060508@redhat.com> David Woodhouse wrote: > On Fri, 2007-06-01 at 10:27 -0600, Brendan Conoboy wrote: >> What do you mean by reliable? Once a package is setup to work in a >> cross environment, it builds quite reliably. > > ...until the next time it gets broken by an uncaring upstream :) In my experience, Fedora is the uncaring upstream which breaks things :-) If cross compilation becomes a standard procedure on Fedora, such breakage is less common. This is because a large number of the gotchas to cross compilation have to do with how the spec file works (especially %pre/%post), rather than the sources. This is particularly true for packages that use auto*. The question is how to introduce cross compilation without putting greater burden on the package maintainers. > I just mean that I gave up on it, because I was seeing too many failures > -- some of which didn't show up until you exercise some esoteric code > path in the resulting binary. I wouldn't personally be happy to release > cross-compiled stuff and call it 'Fedora'. Awww, don't give up. A lot of us love Fedora and love neat little devices. We want to run Fedora on those devices. We also run screaming at the idea of building *on* those devices. Cross compilation is the answer. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From jeff at ocjtech.us Wed Jun 6 19:58:49 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 06 Jun 2007 14:58:49 -0500 Subject: Future SCM Technology Message-ID: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> It's F7+5 and F8T1-57 (yes, less than two months until F8T1 under the current schedule[1]). If we are going to replace CVS[2] with another SCM for hosting the Fedora Package Repository we need to get started now! And to get things started, we need to discuss what kinds of workflow we want our new SCM to support. Here's a list of things to think about (thanks to Jeremy Katz): * How do we make it easier for a maintainer to rebase their package to a newer upstream? * How do we make it easier for a maintainer to develop, test, and create a patch to fix a problem that's being experienced in Fedora? * How do we make it easy to send these patches to the upstream of the project being worked on? * How do we enable downstreams to take our bits, track them and make changes as they need/want? * How do we better enable a user who has a problem with something we ship to be able to fix it themselves and get the fix back to us? Jeff [1] http://fedoraproject.org/wiki/Releases/8/Schedule [2] http://fedoraproject.org/wiki/PackageMaintainers/CvsAccess -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwilson at redhat.com Wed Jun 6 20:08:51 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 06 Jun 2007 16:08:51 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> Message-ID: <46671453.6010908@redhat.com> Matthias Clasen wrote: > On Wed, 2007-06-06 at 13:51 -0400, Jarod Wilson wrote: > >> For the record, updated beryl bits just hit updates-testing for F7, and >> are all checked into cvs for F8, but were failing to build yesterday due >> to libwnck issues. With luck, this latest libwnck update will fix that >> and they'll actually build... >> > > It is not unlikely that beryl needs that same patch that I added to > compiz to make it build against the new libwnck. Ah, quite likely. I don't have the failed build log handy, but when I get around to looking at it again, I'll give the compiz patch a look too. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From orion at cora.nwra.com Wed Jun 6 20:29:42 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Jun 2007 14:29:42 -0600 Subject: Tool for generating pungi comps.xml from anaconda kickstart files Message-ID: <46671936.6060603@cora.nwra.com> I'd a tool that will take an anaconda kickstart file as input (along with the standard released comps-f7.xml) and generate a new comps.xml file with only the groups and packages specified in the kickstart file present in the output comps.xml. I've started working on this but my python sucks (and it makes sense for this to be in python since all the other distro tools are). Is anyone interested in helping with this? I think the main thing I need is some example code that uses libxml2 (or something) to read in the comps.xml, make changes, and then write out a new one. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jeff at ocjtech.us Wed Jun 6 20:37:33 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 06 Jun 2007 15:37:33 -0500 Subject: Future SCM Technology In-Reply-To: <200706061501.44535.jkeating@redhat.com> References: <1181150167.4009.55.camel@lt21223.campus.dmacc.edu> <200706061501.44535.jkeating@redhat.com> Message-ID: <1181162254.4009.125.camel@lt21223.campus.dmacc.edu> On Wed, 2007-06-06 at 15:01 -0400, Jesse Keating wrote: > On Wednesday 06 June 2007 13:16:07 Jeffrey C. Ollie wrote: > > It's F7+5 and F8T1-57 (yes, less than two months until F8T1 under the > > current schedule[1]). If we are going to replace CVS[2] with another > > SCM for hosting the Fedora Package Repository we need to get started > > now! And to get things started, we need to discuss what kinds of > > workflow we want our new SCM to support. > > As stated on Fedora Infrastructure List I firmly believe that this is not > something we can do by F8 release. This is something we need to discuss and > strawman and put up proof of concepts and get more people thinking on it > during the F8 cycle and try to implement during the F9 cycle if possible. This post was mainly meant to get the discussion started. After having read some of the discussions on the Infrastructure list I think that you are right - major changes to the packager workflow should be held off until post F8. However, some of the discussions on the Infratrusture list talked about some radical shifts (that I'm in favor of) from the RPM philosophy of "pristine tarballs plus patches" that I think moving wholesale to a different workflow by F9 may be difficult. However, I think that a two-pronged approach is possible: 1) Convert the CVS repository to a new SCM in such a way that the packager workflow is impacted as little as possible. Much of the detail of using CVS to maintain packages is hidden from the package maintainer anyway (all you really need to know right now is "cvs co", "cvs up", and "cvs ci"). Some changes to Koji would be necessary behind the scenes but they would be transparent to the packager, and would be necessary for a new workflow as well. This conversion would largely be automatic... Several people have converted portions of the CVS repository into other SCMs (I know Git, Mercurial, and Subversion conversions have been done) and I've converted the whole repository (yes, all 4500+ packages) to Git. Perhaps this step could be skipped, but the more I learn about CVS the more I want to move away from it yesterday. 2) In parallel, another repository would be set up to handle "new style" packaging (whatever "new style" ends up meaning). Post F8, when a package is ready in the new-style repository an entry would be made in the package database and Koji would stop accepting build requests from the old-style repository for that package and would begin using the new-style repository. F9 would be built from both old-style and new-style packages. By F10 all packages would be converted to the new-style packages. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Jun 6 20:35:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 16:35:19 -0400 Subject: Tool for generating pungi comps.xml from anaconda kickstart files In-Reply-To: <46671936.6060603@cora.nwra.com> References: <46671936.6060603@cora.nwra.com> Message-ID: <200706061635.22824.jkeating@redhat.com> On Wednesday 06 June 2007 16:29:42 Orion Poplawski wrote: > I'd a tool that will take an anaconda kickstart file as input (along > with the standard released comps-f7.xml) and generate a new comps.xml > file with only the groups and packages specified in the kickstart file > present in the output comps.xml. > > I've started working on this but my python sucks (and it makes sense for > this to be in python since all the other distro tools are). ?Is anyone > interested in helping with this? ?I think the main thing I need is some > example code that uses libxml2 (or something) to read in the comps.xml, > make changes, and then write out a new one. So what use is this? Are you just trying to change the group names and such? Change which are mandatory/default/optional? The comps file you use can list WAY more packages than what you include in a spin. yum et al are smart enough to not offer you things that are in comps that aren't in the repodata. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Jun 6 20:38:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 22:38:24 +0200 Subject: Future SCM Technology In-Reply-To: <1181150167.4009.55.camel@lt21223.campus.dmacc.edu> References: <1181150167.4009.55.camel@lt21223.campus.dmacc.edu> Message-ID: <20070606203824.GE30757@neu.nirvana> On Wed, Jun 06, 2007 at 12:16:07PM -0500, Jeffrey C. Ollie wrote: > It's F7+5 and F8T1-57 (yes, less than two months until F8T1 under the > current schedule[1]). If we are going to replace CVS[2] with another > SCM for hosting the Fedora Package Repository we need to get started > now! And to get things started, we need to discuss what kinds of > workflow we want our new SCM to support. > > Here's a list of things to think about (thanks to Jeremy Katz): > * How do we make it easier for a maintainer to rebase their package to a > newer upstream? Is it considered difficult, and can the SCM do anything about it at all? > * How do we make it easier for a maintainer to develop, test, and create > a patch to fix a problem that's being experienced in Fedora? I think that very much depends on the scm used in the upstream project. > * How do we make it easy to send these patches to the upstream of the > project being worked on? See above. > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? You need to pick a distributed or two-way scm for that, e.g. git or mercurial. > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? See above. Distributed/symmetric vcs allow for pushing/pulling from both sides (provided permissions are properly set). Personally I favour mercurial and git, and I think they are both that much alike that I would leave it to the koji developers to pick one, as they will be the ones that will go through the pain of implementation, and they should pick what will really be implementable in this short time frame. (ideally the vcs support in koji would become modular with an api so anyone can add his favourite vcs to 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 jkeating at redhat.com Wed Jun 6 20:37:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 16:37:47 -0400 Subject: Future SCM Technology In-Reply-To: <1181162254.4009.125.camel@lt21223.campus.dmacc.edu> References: <1181150167.4009.55.camel@lt21223.campus.dmacc.edu> <200706061501.44535.jkeating@redhat.com> <1181162254.4009.125.camel@lt21223.campus.dmacc.edu> Message-ID: <200706061637.47250.jkeating@redhat.com> On Wednesday 06 June 2007 16:37:33 Jeffrey C. Ollie wrote: > This post was mainly meant to get the discussion started. ? Can we keep all the discussion on fedora-devel-list now though? I hate cross posting and I hate posting the same thing twice (: > After having > read some of the discussions on the Infrastructure list I think that you > are right - major changes to the packager workflow should be held off > until post F8. ?However, some of the discussions on the Infratrusture > list talked about some radical shifts (that I'm in favor of) from the > RPM philosophy of "pristine tarballs plus patches" that I think moving > wholesale to a different workflow by F9 may be difficult. > > However, I think that a two-pronged approach is possible: > > 1) Convert the CVS repository to a new SCM in such a way that the > packager workflow is impacted as little as possible. ?Much of the detail > of using CVS to maintain packages is hidden from the package maintainer > anyway (all you really need to know right now is "cvs co", "cvs up", and > "cvs ci"). ?Some changes to Koji would be necessary behind the scenes > but they would be transparent to the packager, and would be necessary > for a new workflow as well. > > This conversion would largely be automatic... Several people have > converted portions of the CVS repository into other SCMs (I know Git, > Mercurial, and Subversion conversions have been done) and I've converted > the whole repository (yes, all 4500+ packages) to Git. > > Perhaps this step could be skipped, but the more I learn about CVS the > more I want to move away from it yesterday. ? > > 2) In parallel, another repository would be set up to handle "new style" > packaging (whatever "new style" ends up meaning). ?Post F8, when a > package is ready in the new-style repository an entry would be made in > the package database and Koji would stop accepting build requests from > the old-style repository for that package and would begin using the > new-style repository. ?F9 would be built from both old-style and > new-style packages. ?By F10 all packages would be converted to the > new-style packages. So for the record let me dump Jeremy's reply to this here for others to see, since I fully agree with it: > The problem with a staged approach like this two-fold > 1) Moving off of CVS is going to end up requiring a fair bit of > relearning/retraining for people. Even if we keep the workflow the > same. So by having it as a two-step thing, people have to retrain > themselves _twice_ rather than just once. > 2) If you let some people move and not others, then it becomes very > difficult to know what you have to do to make changes to a specific > package. If you're the only person that works on something, that's not > such a big deal... but we want to be encouraging collaboration and > working together. Having two different ways of doing that at the same > time is going to mean that everyone has to get over the hump _anyway_. > So why not just take our lumps in get there in a go. > > Jeremy -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Wed Jun 6 20:44:26 2007 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 06 Jun 2007 16:44:26 -0400 Subject: Tool for generating pungi comps.xml from anaconda kickstart files In-Reply-To: <46671936.6060603@cora.nwra.com> References: <46671936.6060603@cora.nwra.com> Message-ID: <1181162666.9969.232.camel@cassandra.boston.redhat.com> On Wed, 2007-06-06 at 14:29 -0600, Orion Poplawski wrote: > I'd a tool that will take an anaconda kickstart file as input (along > with the standard released comps-f7.xml) and generate a new comps.xml > file with only the groups and packages specified in the kickstart file > present in the output comps.xml. > > I've started working on this but my python sucks (and it makes sense for > this to be in python since all the other distro tools are). Is anyone > interested in helping with this? I think the main thing I need is some > example code that uses libxml2 (or something) to read in the comps.xml, > make changes, and then write out a new one. > I've found the xml.dom API to be easier to use than libxml2. Try something like this: import xml.dom.minidom import xml.dom.ext # load the file xmlDoc = xml.dom.minidom.parse(filename) # do stuff to xmlDoc here # write the file back xml.dom.ext.PrettyPrint(xmlDoc, open(filename, "w")) Hope this helps Dave From vnpenguin at vnoss.org Wed Jun 6 21:03:20 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 6 Jun 2007 23:03:20 +0200 Subject: XFCE desktop needs ... tetex ? Message-ID: Hi, # yum groupinstall XFCE Loading "downloadonly" plugin Loading "installonlyn" plugin Setting up Group Process Excluding Packages in global exclude list Finished Resolving Dependencies --> Running transaction check ---> Package xfwm4.i386 0:4.4.1-1.fc7 set to be updated ---> Package xfce-mcs-plugins.i386 0:4.4.1-1.fc7 set to be updated ---> Package xfce4-session-engines.i386 0:4.4.1-1.fc7 set to be updated ---> Package xfdesktop.i386 0:4.4.1-1.fc7 set to be updated ---> Package libxfce4mcs.i386 0:4.4.1-2.fc7 set to be updated ---> Package Thunar.i386 0:0.8.0-1.fc7 set to be updated ---> Package xfce4-session.i386 0:4.4.1-1.fc7 set to be updated ---> Package xfce-mcs-manager.i386 0:4.4.1-1.fc7 set to be updated ---> Package libxfce4util.i386 0:4.4.1-2.fc7 set to be updated ---> Package xfce4-mailwatch-plugin.i386 0:1.0.1-6.fc7 set to be updated ---> Package xfce4-mixer.i386 0:4.4.1-1.fc7 set to be updated ---> Package libxfcegui4.i386 0:4.4.1-2.fc7 set to be updated ---> Package xfprint.i386 0:4.4.1-1.fc7 set to be updated ---> Package xfce4-icon-theme.noarch 0:4.4.1-1.fc7 set to be updated ---> Package mousepad.i386 0:0.2.12-1.fc7 set to be updated ---> Package xfce4-panel.i386 0:4.4.1-1.fc7 set to be updated ---> Package xfce-utils.i386 0:4.4.1-1.fc7 set to be updated ---> Package xfce4-appfinder.i386 0:4.4.1-1.fc7 set to be updated --> Processing Dependency: libexo-hal-0.3.so.0 for package: Thunar --> Processing Dependency: a2ps for package: xfprint --> Processing Dependency: libexo-0.3.so.0 for package: Thunar --> Processing Dependency: libexo-0.3.so.0 for package: xfdesktop --> Processing Dependency: Terminal for package: xfce4-panel --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package exo.i386 0:0.3.2-2.fc7 set to be updated ---> Package Terminal.i386 0:0.2.6-2.fc7 set to be updated ---> Package a2ps.i386 0:4.13b-65.fc7 set to be updated --> Processing Dependency: groff-perl for package: a2ps --> Processing Dependency: tetex-latex for package: a2ps --> Processing Dependency: texinfo-tex for package: a2ps --> Processing Dependency: tetex-fonts for package: a2ps --> Processing Dependency: psutils for package: a2ps --> Processing Dependency: tetex-dvips for package: a2ps --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package texinfo-tex.i386 0:4.8-15 set to be updated ---> Package tetex-dvips.i386 0:3.0-39.fc7 set to be updated ---> Package groff-perl.i386 0:1.18.1.4-2 set to be updated ---> Package tetex-fonts.i386 0:3.0-39.fc7 set to be updated ---> Package tetex-latex.i386 0:3.0-39.fc7 set to be updated ---> Package psutils.i386 0:1.17-26.1 set to be updated --> Processing Dependency: texinfo = 4.8-15 for package: texinfo-tex --> Processing Dependency: tetex = 3.0 for package: tetex-latex --> Processing Dependency: tetex for package: texinfo-tex --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package texinfo.i386 0:4.8-15 set to be updated ---> Package tetex.i386 0:3.0-39.fc7 set to be updated --> Processing Dependency: dialog for package: tetex --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package dialog.i386 0:1.1-1.20070227svn.fc7 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: Thunar i386 0.8.0-1.fc7 fedora 5.3 M libxfce4mcs i386 4.4.1-2.fc7 fedora 46 k libxfce4util i386 4.4.1-2.fc7 fedora 73 k libxfcegui4 i386 4.4.1-2.fc7 fedora 276 k mousepad i386 0.2.12-1.fc7 fedora 88 k xfce-mcs-manager i386 4.4.1-1.fc7 fedora 383 k xfce-mcs-plugins i386 4.4.1-1.fc7 fedora 588 k xfce-utils i386 4.4.1-1.fc7 fedora 342 k xfce4-appfinder i386 4.4.1-1.fc7 fedora 264 k xfce4-icon-theme noarch 4.4.1-1.fc7 fedora 2.1 M xfce4-mailwatch-plugin i386 1.0.1-6.fc7 fedora 363 k xfce4-mixer i386 4.4.1-1.fc7 fedora 211 k xfce4-panel i386 4.4.1-1.fc7 fedora 530 k xfce4-session i386 4.4.1-1.fc7 fedora 508 k xfce4-session-engines i386 4.4.1-1.fc7 fedora 325 k xfdesktop i386 4.4.1-1.fc7 fedora 2.7 M xfprint i386 4.4.1-1.fc7 fedora 588 k xfwm4 i386 4.4.1-1.fc7 fedora 1.3 M Installing for dependencies: Terminal i386 0.2.6-2.fc7 fedora 1.2 M a2ps i386 4.13b-65.fc7 fedora 1.1 M dialog i386 1.1-1.20070227svn.fc7 fedora 203 k exo i386 0.3.2-2.fc7 fedora 676 k groff-perl i386 1.18.1.4-2 fedora 23 k psutils i386 1.17-26.1 fedora 85 k tetex i386 3.0-39.fc7 fedora 13 M tetex-dvips i386 3.0-39.fc7 fedora 587 k tetex-fonts i386 3.0-39.fc7 fedora 29 M tetex-latex i386 3.0-39.fc7 fedora 5.4 M texinfo i386 4.8-15 fedora 754 k texinfo-tex i386 4.8-15 fedora 32 k Transaction Summary ============================================================================= Install 30 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 69 M Is this ok [y/N]: My answer is N here, of course. Can't understand why I need install tetex for XFCE desktop :( I do the also groupinstall for Gnome desktop and I don't see tetex. Maybe need some tunings for comps.xml & group definition ? -- http://vnoss.org From jkeating at redhat.com Wed Jun 6 21:05:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 17:05:34 -0400 Subject: XFCE desktop needs ... tetex ? In-Reply-To: References: Message-ID: <200706061705.35119.jkeating@redhat.com> On Wednesday 06 June 2007 17:03:20 Vnpenguin wrote: > ---> Package xfprint.i386 0:4.4.1-1.fc7 set to be updated > --> Processing Dependency: a2ps for package: xfprint > --> Processing Dependency: tetex-latex for package: a2ps > --> Processing Dependency: texinfo-tex for package: a2ps > --> Processing Dependency: tetex-fonts for package: a2ps > --> Processing Dependency: tetex-dvips for package: a2ps > --> Restarting Dependency Resolution with new changes. > --> Running transaction check > ---> Package texinfo-tex.i386 0:4.8-15 set to be updated > ---> Package tetex-dvips.i386 0:3.0-39.fc7 set to be updated > ---> Package groff-perl.i386 0:1.18.1.4-2 set to be updated > ---> Package tetex-fonts.i386 0:3.0-39.fc7 set to be updated > ---> Package tetex-latex.i386 0:3.0-39.fc7 set to be updated > ---> Package psutils.i386 0:1.17-26.1 set to be updated > --> Processing Dependency: texinfo = 4.8-15 for package: texinfo-tex > --> Processing Dependency: tetex = 3.0 for package: tetex-latex > --> Processing Dependency: tetex for package: texinfo-tex > --> Restarting Dependency Resolution with new changes. > --> Running transaction check > ---> Package texinfo.i386 0:4.8-15 set to be updated > ---> Package tetex.i386 0:3.0-39.fc7 set to be updated > --> Processing Dependency: dialog for package: tetex > --> Restarting Dependency Resolution with new changes. > --> Running transaction check > ---> Package dialog.i386 0:1.1-1.20070227svn.fc7 set to be updated > > Dependencies Resolved > > =========================================================================== >== Package ? ? ? ? ? ? ? ? Arch ? ? ? Version ? ? ? ? ?Repository ? ? ? > ?Size > =========================================================================== >== Installing: > ?Thunar ? ? ? ? ? ? ? ? ?i386 ? ? ? 0.8.0-1.fc7 ? ? ?fedora ? ? ? ? ? ?5.3 > M libxfce4mcs ? ? ? ? ? ? i386 ? ? ? 4.4.1-2.fc7 ? ? ?fedora ? ? ? ? ? ? 46 > k libxfce4util ? ? ? ? ? ?i386 ? ? ? 4.4.1-2.fc7 ? ? ?fedora ? ? ? ? ? ? 73 > k libxfcegui4 ? ? ? ? ? ? i386 ? ? ? 4.4.1-2.fc7 ? ? ?fedora ? ? ? ? ? ?276 > k mousepad ? ? ? ? ? ? ? ?i386 ? ? ? 0.2.12-1.fc7 ? ? fedora ? ? ? ? ? ? 88 > k xfce-mcs-manager ? ? ? ?i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?383 > k xfce-mcs-plugins ? ? ? ?i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?588 > k xfce-utils ? ? ? ? ? ? ?i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?342 > k xfce4-appfinder ? ? ? ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?264 > k xfce4-icon-theme ? ? ? ?noarch ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?2.1 > M xfce4-mailwatch-plugin ?i386 ? ? ? 1.0.1-6.fc7 ? ? ?fedora ? ? ? ? ? ?363 > k xfce4-mixer ? ? ? ? ? ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?211 > k xfce4-panel ? ? ? ? ? ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?530 > k xfce4-session ? ? ? ? ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?508 > k xfce4-session-engines ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?325 > k xfdesktop ? ? ? ? ? ? ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?2.7 > M xfprint ? ? ? ? ? ? ? ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?588 > k xfwm4 ? ? ? ? ? ? ? ? ? i386 ? ? ? 4.4.1-1.fc7 ? ? ?fedora ? ? ? ? ? ?1.3 > M Installing for dependencies: > ?Terminal ? ? ? ? ? ? ? ?i386 ? ? ? 0.2.6-2.fc7 ? ? ?fedora ? ? ? ? ? ?1.2 > M a2ps ? ? ? ? ? ? ? ? ? ?i386 ? ? ? 4.13b-65.fc7 ? ? fedora ? ? ? ? ? ?1.1 > M dialog ? ? ? ? ? ? ? ? ?i386 ? ? ? 1.1-1.20070227svn.fc7 ?fedora > ? ? ? 203 k > ?exo ? ? ? ? ? ? ? ? ? ? i386 ? ? ? 0.3.2-2.fc7 ? ? ?fedora ? ? ? ? ? ?676 > k groff-perl ? ? ? ? ? ? ?i386 ? ? ? 1.18.1.4-2 ? ? ? fedora ? ? ? ? ? ? 23 > k psutils ? ? ? ? ? ? ? ? i386 ? ? ? 1.17-26.1 ? ? ? ?fedora ? ? ? ? ? ? 85 > k tetex ? ? ? ? ? ? ? ? ? i386 ? ? ? 3.0-39.fc7 ? ? ? fedora ? ? ? ? ? ? 13 > M tetex-dvips ? ? ? ? ? ? i386 ? ? ? 3.0-39.fc7 ? ? ? fedora ? ? ? ? ? ?587 > k tetex-fonts ? ? ? ? ? ? i386 ? ? ? 3.0-39.fc7 ? ? ? fedora ? ? ? ? ? ? 29 > M tetex-latex ? ? ? ? ? ? i386 ? ? ? 3.0-39.fc7 ? ? ? fedora ? ? ? ? ? ?5.4 > M texinfo ? ? ? ? ? ? ? ? i386 ? ? ? 4.8-15 ? ? ? ? ? fedora ? ? ? ? ? ?754 > k texinfo-tex ? ? ? ? ? ? i386 ? ? ? 4.8-15 ? ? ? ? ? fedora ? ? ? ? ? ? 32 > k > > Transaction Summary > =========================================================================== >== Install ? ? 30 Package(s) > Update ? ? ? 0 Package(s) > Remove ? ? ? 0 Package(s) > > Total download size: 69 M > Is this ok [y/N]: > > My answer is N here, of course. Can't understand why I need install > tetex for XFCE desktop :( > > I do the also groupinstall for Gnome desktop and I don't see tetex. > > Maybe need some tunings for comps.xml & group definition ? It's all above in the output. I snipped it for you to see it more easily. xfprint which is in the xfce group needs a2ps, which needs tetex. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ianburrell at gmail.com Wed Jun 6 21:13:01 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Wed, 6 Jun 2007 14:13:01 -0700 Subject: XFCE desktop needs ... tetex ? In-Reply-To: References: Message-ID: On 6/6/07, Vnpenguin wrote: > ---> Package xfprint.i386 0:4.4.1-1.fc7 set to be updated > --> Processing Dependency: a2ps for package: xfprint > ---> Package a2ps.i386 0:4.13b-65.fc7 set to be updated > --> Processing Dependency: groff-perl for package: a2ps > --> Processing Dependency: tetex-latex for package: a2ps > --> Processing Dependency: texinfo-tex for package: a2ps > --> Processing Dependency: tetex-fonts for package: a2ps > --> Processing Dependency: psutils for package: a2ps > --> Processing Dependency: tetex-dvips for package: a2ps > > My answer is N here, of course. Can't understand why I need install > tetex for XFCE desktop :( > > I do the also groupinstall for Gnome desktop and I don't see tetex. > > Maybe need some tunings for comps.xml & group definition ? > I trimmed down the output from yum to show the dependency chain. xfprint requires a2ps which requires tetex. - Ian From vnpenguin at vnoss.org Wed Jun 6 21:15:07 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 6 Jun 2007 23:15:07 +0200 Subject: XFCE desktop needs ... tetex ? In-Reply-To: References: Message-ID: Thanks Jesse Keating & Ian Burrell. I removed xfprint from XFCE group of my comps.xml :-) -- http://vnoss.org From eswierk at arastra.com Wed Jun 6 21:28:25 2007 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 6 Jun 2007 14:28:25 -0700 Subject: fedora for ARM In-Reply-To: <46670F30.8080102@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> Message-ID: On 6/6/07, Brendan Conoboy wrote: > There is something to be said for target emulation or > run-parts-of-the-build-on-hardware solutions, but I think the best > answer is one where any available host can compile Fedora for any target. Isn't that exactly what we'd get with target emulation? Any available host that can run an emulator could then build all of fedora Fedora for ARM or PowerPC or whatever. Supporting cross-compiling would be great, but having spent a several weeks fighting with Python and its libraries last year and losing, I suspect scouring the other nine zillion Fedora packages for cross-correctness is no small exercise, not to mention battling new bugs as they crop up. Of course supporting an emulator is not trivial either, but Qemu already works for ARM and is only somewhat broken for PowerPC. That said, there is certainly room for both approaches, and getting even a small number of packages to cross-compile might be enough for many embedded applications. --Ed From jeff at ocjtech.us Wed Jun 6 21:34:34 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 06 Jun 2007 16:34:34 -0500 Subject: Future SCM Technology (was: Re: RFR: GIT Package VCS) In-Reply-To: <1181163234.22157.92.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> Message-ID: <1181165674.4009.148.camel@lt21223.campus.dmacc.edu> Moving this to fedora-devel and changing the subject for wider discussion. On Wed, 2007-06-06 at 16:53 -0400, Christopher Blizzard wrote: > On Wed, 2007-06-06 at 16:16 -0400, Jeremy Katz wrote: > > > > The problem with a staged approach like this two-fold > > 1) Moving off of CVS is going to end up requiring a fair bit of > > relearning/retraining for people. Even if we keep the workflow the > > same. So by having it as a two-step thing, people have to retrain > > themselves _twice_ rather than just once. > > 2) If you let some people move and not others, then it becomes very > > difficult to know what you have to do to make changes to a specific > > package. If you're the only person that works on something, that's > > not > > such a big deal... but we want to be encouraging collaboration and > > working together. Having two different ways of doing that at the same > > time is going to mean that everyone has to get over the hump _anyway_. > > So why not just take our lumps in get there in a go. > > So regarding 1. I would suggest that we leave "classic" packages in CVS. > Learning another system is a big deal and we get almost no bang for that > buck so I don't see us moving off of CVS for our current repo setup any > time soon. I would agree except that CVS is such a crappy SCM. While I've been converting the existing CVS repos to Git for some testing I've seen evidence that some of the CVS repositories contain some corruption. It could be that what I'm really seeing are bugs in my conversion tools or that someone manipulated the CVS repositories manually in a non-kosher fashion. However, CVS the fact remains that CVS is a very bad SCM and I don't want to deal with it more than I have to. The only thing that CVS has going for it is that people seem to have infinite amounts of willingness to put up with it's foibles. That being said, I won't put up too much of a fight if in the near future I can move the packages that I maintain to something other than CVS. > I think that moving selectively is the option of the developer and/or > maintainer and should reflect how the upstream project works. And it's > only really required for stuff that's moving quickly or has a large > community. Remember one of our primary goals: get as close to upstream > as possible. If we're supporting them by using the same DVCS then they > are more likely to assist us, not to mention how easy it gets to figure > out what's different between repo a and repo b. > > For example for the kernel, we might want to pull from a git repo. For > people who use hg, we just use that. For projects that just release > tarballs, we stick with what we have. > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > until you realize what you need to do here. To start with you only have > to teach the rpm build side how pull a specific tag from a specific > repo. On the query side we need a browser for each kind, which is a bit > of work, but something I think we need to do anyway. (i.e. "What would > git do?") > > Plus, to be honest, it completely avoids the whole "which damn system do > we use." And I like focusing on the end user features instead of > getting stuck in VCS dicussion hell. We're not going to get everyone > else to agree or even use the same system. So let's build something > that supports both. I think that's a great idea... Even the best tools won't convert repositories perfectly. And using the same SCM as the upstream makes it a lot easier to communicate changes with the upstream developers. I do think that we need to limit the choice of SCM to ones that support a distributed style of operation and to which Koji has been taught to build from (I think that Git and Mercurial stand out as obvious first targets). Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From steve at nexusuk.org Wed Jun 6 21:41:03 2007 From: steve at nexusuk.org (Steve Hill) Date: Wed, 6 Jun 2007 22:41:03 +0100 (BST) Subject: Unmounting removable media under Gnome In-Reply-To: <1181148476.7761.13.camel@zelda.fubar.dk> References: <1181148476.7761.13.camel@zelda.fubar.dk> Message-ID: On Wed, 6 Jun 2007, David Zeuthen wrote: > False. As of Fedora 7, umount from the command line works just fine Ok, fair comment - I only burn and rip CDs under FC6 so hadn't tried under F7. My mistake. >> Are there any good reasons why Nautilus should not have an option to >> unmount without ejecting? > > Are the any good reasons why CD-burning software can't invoke umount(8) > or do something else themselves? Nautilus-CD-Burner been able to do this > for years... Well no, there probably aren't any good reasons why they _can't_, but the point is they _don't_. Your comment is rather like "there's no point in supporting FAT32 since there's no good reason why Microsoft couldn't write ext3 support into Windows" - nice in theory but in the real world you can't just assume that what you consider to be the "right way" to do things is going to be compatible with what other people are actually doing (or indeed what other people consider to be "the right way"). If there's an explicit unmount option then compatibility is maintained and everyone's happy. -- - Steve xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence From jkeating at redhat.com Wed Jun 6 21:43:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 17:43:57 -0400 Subject: Future SCM Technology (was: Re: RFR: GIT Package VCS) In-Reply-To: <1181165674.4009.148.camel@lt21223.campus.dmacc.edu> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181163234.22157.92.camel@localhost.localdomain> <1181165674.4009.148.camel@lt21223.campus.dmacc.edu> Message-ID: <200706061743.58160.jkeating@redhat.com> On Wednesday 06 June 2007 17:34:34 Jeffrey C. Ollie wrote: > > Plus, to be honest, it completely avoids the whole "which damn system do > > we use." ?And I like focusing on the end user features instead of > > getting stuck in VCS dicussion hell. ?We're not going to get everyone > > else to agree or even use the same system. ?So let's build something > > that supports both. > > I think that's a great idea... ? Even the best tools won't convert > repositories perfectly. ?And using the same SCM as the upstream makes it > a lot easier to communicate changes with the upstream developers. ?I do > think that we need to limit the choice of SCM to ones that support a > distributed style of operation and to which Koji has been taught to > build from (I think that Git and Mercurial stand out as obvious first > targets). I don't like the thought of having multiple SCMs for our package SCM. Trying to describe which one new packagers should use is going to be a losing operation. No matter what we use, it should be fairly transparent to new users. They shouldn't have to read a 50 page manual to figure out how to get their new package imported, and built, and later make updates to it and build again. At the same time, what we choose should have the capability of doing the nifty-cool things our power users would like to do. I _really_ don't want to have to present new packagers a choice of Froo and Brob. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Jun 6 21:47:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 17:47:35 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181163234.22157.92.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181158369.4009.93.camel@lt21223.campus.dmacc.edu> <1181160985.8071.95.camel@erebor.boston.redhat.com> <1181163234.22157.92.camel@localhost.localdomain> Message-ID: <1181166455.8071.114.camel@erebor.boston.redhat.com> (Reposting this reply here too... must stop the discussion on the other list :-) On Wed, 2007-06-06 at 16:53 -0400, Christopher Blizzard wrote: > On Wed, 2007-06-06 at 16:16 -0400, Jeremy Katz wrote: > > The problem with a staged approach like this two-fold > > 1) Moving off of CVS is going to end up requiring a fair bit of > > relearning/retraining for people. Even if we keep the workflow the > > same. So by having it as a two-step thing, people have to retrain > > themselves _twice_ rather than just once. > > 2) If you let some people move and not others, then it becomes very > > difficult to know what you have to do to make changes to a specific > > package. If you're the only person that works on something, that's > > not > > such a big deal... but we want to be encouraging collaboration and > > working together. Having two different ways of doing that at the same > > time is going to mean that everyone has to get over the hump _anyway_. > > So why not just take our lumps in get there in a go. > > So regarding 1. I would suggest that we leave "classic" packages in CVS. > Learning another system is a big deal and we get almost no bang for that > buck so I don't see us moving off of CVS for our current repo setup any > time soon. > > I think that moving selectively is the option of the developer and/or > maintainer and should reflect how the upstream project works. And it's > only really required for stuff that's moving quickly or has a large > community. Remember one of our primary goals: get as close to upstream > as possible. If we're supporting them by using the same DVCS then they > are more likely to assist us, not to mention how easy it gets to figure > out what's different between repo a and repo b. > > For example for the kernel, we might want to pull from a git repo. For > people who use hg, we just use that. For projects that just release > tarballs, we stick with what we have. At the same time, I think we still need to be able to very clearly separate out our changes from what upstream has. Just a git repo of the kernel very quickly gets out of control and you end up with bazillions of things that you never push back upstream because it's easier to just keep sitting on them. So I don't think that just a VCS repo of the source is what we want... we're going to end up wanting some integration with something quilt-like to get patches out; so like stgit or mq or ... > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > until you realize what you need to do here. To start with you only have > to teach the rpm build side how pull a specific tag from a specific > repo. On the query side we need a browser for each kind, which is a bit > of work, but something I think we need to do anyway. (i.e. "What would > git do?") So if I am the owner of the rpm package which has an upstream of hg and want to fix, test and commit a change to say (for the sake of argument) neon which is in git, I now have to know two different systems? You're crazy ;-) To add to the craziness of this path, think about actually maintaining these packages across different distro releases... every VCS has its own unique and specially crack-ridden way of handling branching. Or when you star to think about the "I'm a downstream of Fedora and need to change X, Y, and Z" and you are then having them set up potentially 3 different VCS systems to do so. Or the "it's time for a mass-rebuild; let's go and commit a version bump to all the packages so we can rebuild. Uhhm. Uh-oh. > Plus, to be honest, it completely avoids the whole "which damn system do > we use." And I like focusing on the end user features instead of > getting stuck in VCS dicussion hell. We're not going to get everyone > else to agree or even use the same system. So let's build something > that supports both. So instead of picking _one_ answer, we now have to make sure that we implement all of the end user features for N systems? Seriously, this is losing. Jeremy From orion at cora.nwra.com Wed Jun 6 21:50:48 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Jun 2007 15:50:48 -0600 Subject: Tool for generating pungi comps.xml from anaconda kickstart files In-Reply-To: <200706061635.22824.jkeating@redhat.com> References: <46671936.6060603@cora.nwra.com> <200706061635.22824.jkeating@redhat.com> Message-ID: <46672C38.9090409@cora.nwra.com> Jesse Keating wrote: > So what use is this? Are you just trying to change the group names and such? > Change which are mandatory/default/optional? The comps file you use can list > WAY more packages than what you include in a spin. yum et al are smart > enough to not offer you things that are in comps that aren't in the repodata. > My bad - I hadn't noticed that pungi seems to have evolved to have a separate manifest. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jkeating at redhat.com Wed Jun 6 21:52:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 17:52:18 -0400 Subject: Tool for generating pungi comps.xml from anaconda kickstart files In-Reply-To: <46672C38.9090409@cora.nwra.com> References: <46671936.6060603@cora.nwra.com> <200706061635.22824.jkeating@redhat.com> <46672C38.9090409@cora.nwra.com> Message-ID: <200706061752.18395.jkeating@redhat.com> On Wednesday 06 June 2007 17:50:48 Orion Poplawski wrote: > My bad - I hadn't noticed that pungi seems to have evolved to have a > separate manifest. Not only that, but the manifest file uses kickstart syntax. WIN! I may be looking at fun ways of reading more out of kickstart files for pungi stuff, well see (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dr.diesel at gmail.com Wed Jun 6 22:02:07 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 6 Jun 2007 18:02:07 -0400 Subject: Kernel recommendation without the F7 network issue? In-Reply-To: <200706060905.53562.jkeating@redhat.com> References: <2a28d2ab0706051617p51e2a6e6gfda8e00437c0e0e8@mail.gmail.com> <200706060905.53562.jkeating@redhat.com> Message-ID: <2a28d2ab0706061502o7d0d9dcdnabd4359ee7e7b683@mail.gmail.com> Thanks Jesse, in no scientific manor what-so-ever, nohz=off appears worse! On average at 1000BT I can transfer ~500meg (nfs large files) before it hard locks. On 6/6/07, Jesse Keating wrote: > On Tuesday 05 June 2007 19:17:06 Dr. Diesel wrote: > > Any suggestions for a Kernel to drop back to till the F7 Network issue > > is resolved? Perhaps the F7T4 Kernel? > > Have you tried booting with 'nohz=off' ? Disabling the tickless kernel may > help things. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From kevin.kofler at chello.at Wed Jun 6 22:09:06 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 6 Jun 2007 22:09:06 +0000 (UTC) Subject: Announcing Quarticurve: Unofficial Bluecurve Qt 4 port References: Message-ID: Quarticurve is now hosted at kde-look.org: http://www.kde-look.org/content/show.php/Quarticurve?content=59884 (No changes since my previous e-mail about it here.) I will _not_ announce new updates on this list, instead you'll find them there. You may subscribe (for free of course) to get announcements of new versions per e-mail automatically (register for free at kde-look.org, then just click the "subscription" link). Kevin Kofler From blc at redhat.com Wed Jun 6 22:16:12 2007 From: blc at redhat.com (Brendan Conoboy) Date: Wed, 06 Jun 2007 16:16:12 -0600 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> Message-ID: <4667322C.7020904@redhat.com> Ed Swierk wrote: > Isn't that exactly what we'd get with target emulation? Any available > host that can run an emulator could then build all of fedora Fedora > for ARM or PowerPC or whatever. I don't mean to exclude target emulation as an option, it's just not where my particular interest is. Here's why: 1. It is always slower than native or cross compilation. 2. It only exists for a small number of platforms. One of the advantages of cross compiling is that it's not just for arm, it's for anything. You can create a mesh of cross compilers such that any arch can build a target for any other arch. Is the s390 slow or down? No problem, build on one of the plentiful x86 hosts. Cross compilation has the potential to realize maximum use of build hosts and consequently turn around faster builds. > Supporting cross-compiling would be great, but having spent a several > weeks fighting with Python and its libraries last year and losing, I > suspect scouring the other nine zillion Fedora packages for Packages like Python and Perl do take some work, but a number of individuals have already done that work. Multiple times. Multiple approaches. Fedora becoming cross friendly could have the effect of unifying those efforts, getting cross changes upstream, ending all the waste. > That said, there is certainly room for both approaches, and getting > even a small number of packages to cross-compile might be enough for > many embedded applications. Definitely. For cross compilation, I picture a per-package flag in Koji that marks it as cross-friendly or not. There are certainly numerous technical and social details to work out to making such a system work and work equitably. We're just getting started. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From dimi at lattica.com Wed Jun 6 22:22:46 2007 From: dimi at lattica.com (Dimi Paun) Date: Wed, 06 Jun 2007 18:22:46 -0400 Subject: Fedora 7 Anaconda feedback Message-ID: <1181168566.9635.34.camel@dimi.lattica.com> Hi folks, Congrats on the Fedora 7 release, it's quite nice. Here are a few notes about the install/anacoda experience from my perspective. Few things to keep in mind: * I am a experienced hacker that's lazy and wants to behave like a newbie from time to time (and during installation it's one of those times) * I have only one Linux distro on my box, Fedora 6 in this case, which I keep as close to standard as possible And now for my observations: * the general experience is nice and pleasant, congrats! * on the Install/Upgrade screen, why is "Install" selected by default when the program already detected that I have only _one_ image installed. This forces the user to override an option that can be pretty automatic for most people. * on the boot-loader screen, first 2 choices where disabled (for reasons that I did not understand). And since I was running Grub before (which came standard with Fedora), why ask me what do so here, and not just upgrade as required?!? * the advanced config for bootloader checkbox was on by default, and that took me to a new screen (I think it's new in this version), that would make even a grown man cry. Do I want the bootloader in MBR or funny looking LVM-related location? Beats me! The entire screen was cryptic at best, and this from a long-time Linux hacker! Why subject people to this screen by default? * after upgrade, the new system failed to boot -- the horror! It was simple to fix, the default grub entry was still pointed to the old kernel image that got nuked, so I had to manually pick the other, newer image, and then edit /etc/grub.conf by hand. Never experienced this before. * postgres got upgraded (yay!) only to find out that it will not start anymore due to format incompatibility, and I had to do a dump/restore. But how to do so if the database refuses to load?!? At the very least the installer should have detected the condition and warn me to do the dump before the install, at best it would do the dump/restore automagically. I know I am being picky, but anaconda is now such a nice application that the bar is quite high. Good work! -- Dimi Paun Lattica, Inc. From orion at cora.nwra.com Wed Jun 6 22:26:16 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Jun 2007 16:26:16 -0600 Subject: Fedora 7 Anaconda feedback In-Reply-To: <1181168566.9635.34.camel@dimi.lattica.com> References: <1181168566.9635.34.camel@dimi.lattica.com> Message-ID: <46673488.2070701@cora.nwra.com> Dimi Paun wrote: > * after upgrade, the new system failed to boot -- the horror! > It was simple to fix, the default grub entry was still > pointed to the old kernel image that got nuked, so I had > to manually pick the other, newer image, and then edit > /etc/grub.conf by hand. Never experienced this before. I've seen this too on the one upgrade I've done so far. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jonathan.underwood at gmail.com Wed Jun 6 22:27:10 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 6 Jun 2007 23:27:10 +0100 Subject: XFCE desktop needs ... tetex ? In-Reply-To: References: Message-ID: <645d17210706061527k5237fe0ci7c7aeccdd8e9f5a@mail.gmail.com> On 06/06/07, Ian Burrell wrote: > On 6/6/07, Vnpenguin wrote: > > ---> Package xfprint.i386 0:4.4.1-1.fc7 set to be updated > > --> Processing Dependency: a2ps for package: xfprint > > ---> Package a2ps.i386 0:4.13b-65.fc7 set to be updated > > --> Processing Dependency: groff-perl for package: a2ps > > --> Processing Dependency: tetex-latex for package: a2ps > > --> Processing Dependency: texinfo-tex for package: a2ps > > --> Processing Dependency: tetex-fonts for package: a2ps > > --> Processing Dependency: psutils for package: a2ps > > --> Processing Dependency: tetex-dvips for package: a2ps > > > > My answer is N here, of course. Can't understand why I need install > > tetex for XFCE desktop :( > > > > I do the also groupinstall for Gnome desktop and I don't see tetex. > > > > Maybe need some tunings for comps.xml & group definition ? > > > > I trimmed down the output from yum to show the dependency chain. > xfprint requires a2ps which requires tetex. Hm. I wonder if xfprint could be patched to use enscript instead of a2ps - enscript doesn't have such dependencies. From davej at redhat.com Wed Jun 6 22:31:45 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 6 Jun 2007 18:31:45 -0400 Subject: kernel 1PPS support was in FC6 and now not in F7 In-Reply-To: <46649864.6090101@aus-city.com> References: <46649864.6090101@aus-city.com> Message-ID: <20070606223145.GC28560@redhat.com> On Tue, Jun 05, 2007 at 08:55:32AM +1000, David Cottle wrote: > However it refuses to work 1PPS. I put in a bug to fedora bugzilla > and I am told all the kernels were never compiled with 1PPS. bz # ? > If this is the case how was it working happily in FC6 with a stock > kernel. If I removed the DCD line ntpq -p then completely dropped the > SHM(1) GPS1 and went to SHM(0) GPS as * > > So I want to ask that the 1PPS be put back into the F7 kernel as it > was there in FC6, so why take it away? I have no idea what '1PPS' is, but it doesn't show up as a config option, so any pointers to what is actually missing would be appreciated. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jun 6 22:34:26 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 6 Jun 2007 18:34:26 -0400 Subject: rawhide report: 20070605 changes In-Reply-To: <183856.84744.qm@web51501.mail.re2.yahoo.com> References: <200706051023.l55AN8Bm003381@porkchop.devel.redhat.com> <183856.84744.qm@web51501.mail.re2.yahoo.com> Message-ID: <20070606223426.GD28560@redhat.com> On Wed, Jun 06, 2007 at 08:45:20AM -0700, Steve G wrote: > > > >kernel-2.6.21-1.3206.fc8 > >------------------------ > >* Mon Jun 04 2007 Dave Jones > >- Allow kdump to read /proc/kcore. (#241362) > > > >* Mon Jun 04 2007 Dave Jones > >- 2.6.22-rc3-git7 > > > >* Mon Jun 04 2007 Dave Jones > >- Remove some warning switches. > > FYI, today's kernel breaks hwclock. > > [root ~]# /sbin/hwclock --systohc --utc --debug > hwclock from util-linux-2.13-pre7 > hwclock: Open of /dev/rtc failed, errno=19: No such device. > No usable clock interface found. > Cannot access the Hardware Clock via any known method. Ok, should be fixed in the next build. Dave -- http://www.codemonkey.org.uk From dr.diesel at gmail.com Wed Jun 6 22:37:35 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 6 Jun 2007 18:37:35 -0400 Subject: Kernel recommendation without the F7 network issue? In-Reply-To: <2a28d2ab0706061502o7d0d9dcdnabd4359ee7e7b683@mail.gmail.com> References: <2a28d2ab0706051617p51e2a6e6gfda8e00437c0e0e8@mail.gmail.com> <200706060905.53562.jkeating@redhat.com> <2a28d2ab0706061502o7d0d9dcdnabd4359ee7e7b683@mail.gmail.com> Message-ID: <2a28d2ab0706061537i7c5e12eg4368fef66fd30f3c@mail.gmail.com> I dropped back to 3143, transfered 47 gig, no problems so far!! On 6/6/07, Dr. Diesel wrote: > Thanks Jesse, in no scientific manor what-so-ever, nohz=off appears worse! > > On average at 1000BT I can transfer ~500meg (nfs large files) before > it hard locks. > > On 6/6/07, Jesse Keating wrote: > > On Tuesday 05 June 2007 19:17:06 Dr. Diesel wrote: > > > Any suggestions for a Kernel to drop back to till the F7 Network issue > > > is resolved? Perhaps the F7T4 Kernel? > > > > Have you tried booting with 'nohz=off' ? Disabling the tickless kernel may > > help things. > > > > -- > > Jesse Keating > > Release Engineer: Fedora > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > From lmacken at redhat.com Wed Jun 6 23:04:09 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 6 Jun 2007 19:04:09 -0400 Subject: Testing update announcements In-Reply-To: References: <1180708088.3946.1.camel@zebes.localdomain> Message-ID: <20070606230409.GD10574@tomservo.rochester.rr.com> On Mon, Jun 04, 2007 at 08:59:19PM +0000, Kevin Kofler wrote: > Will Woods redhat.com> writes: > > This was a mistake - AFAIK bodhi should be sending announcements for new > > packages in updates-testing from now on. lmacken also said he could > > resend the announcements for the already-pushed ones, when he gets > > around to it. > > Those still don't appear to get through. Out of the last push, only the > announcement for Luke Macken's own python-sqlobject testing update made it > through, not any of the others. The announcements for some stable updates are > also missing. I kicked off all missing update announcements last night. luke From jspaleta at gmail.com Thu Jun 7 00:25:35 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 6 Jun 2007 16:25:35 -0800 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <200706061254.22379.jkeating@redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <200706060912.45498.jkeating@redhat.com> <7dd7ab490706060953s39313390w9e4963add2bf9c01@mail.gmail.com> <200706061254.22379.jkeating@redhat.com> Message-ID: <604aa7910706061725j4c653c28of88442ce6d28b3a3@mail.gmail.com> On 6/6/07, Jesse Keating wrote: > I think we're way off in the weeds trying to solve the wrong problem here. I would agree. Since i started this round of discussion. Let me clarify. All I want is a preferred technical means that we can comfortable offer to users as an upgrade path (and test as part of release-eng) without needing a dvd/cdrom burner/reader locally, especially now that we have dropped cdrom iso sets. A solution that can work with a remote system would be nice, but not my primary concern. For my part, I take it as sacred truth that 'live' upgrades, no matter how you do it, will have more caveats than a specialized boot image based approach and will never be considered the preferred method to be encourage to the 99% of the userbase which is less technically inclined than those of us who attempt to hold constructive discussion in this list. I am not looking for a solution which attempts to make 'live' upgrades look easier. Putting a child proof safety cap on a bottle of shards of broken glass isn't going to get us anywhere. What I want is a preferred solution which can be offered to users without a dvd/cdrom burner/reader which gives them an upgrade path similar to users who have access to burner/reader hardware. Now perhaps a simple way to create a bootable installer usb stick would suffice. Or a simple way to make a grub entry for an installer image would do it. Both of these methods already have cookie-cutter howtos floating around on the web. Toolizing the recipe instructions and offering a tool to users instead of a howto to read seems reasonably done in time for F8. Blowing up the world to re-engineer how we think installs/upgrades should work in general probably isn't. -jef"so if I ask to have my wisdom teeth returned to me after the surgery, can I trade them to the Tooth Fairy for some swag?"spaleta From david at fubar.dk Thu Jun 7 00:35:16 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 06 Jun 2007 20:35:16 -0400 Subject: Unmounting removable media under Gnome In-Reply-To: References: <1181148476.7761.13.camel@zelda.fubar.dk> Message-ID: <1181176516.7761.52.camel@zelda.fubar.dk> On Wed, 2007-06-06 at 22:41 +0100, Steve Hill wrote: > On Wed, 6 Jun 2007, David Zeuthen wrote: > > > False. As of Fedora 7, umount from the command line works just fine > > Ok, fair comment - I only burn and rip CDs under FC6 so hadn't tried under > F7. My mistake. Well, we should probably have added it earlier but now it's finally there. Oh well. > If there's an explicit unmount option then compatibility is maintained > and everyone's happy. Has nothing to do with compatibility. Applications simply need to properly deal with hardware and not punt it to the user to tweak the hardware so it's in a state acceptable for the program. David From nando at ccrma.Stanford.EDU Thu Jun 7 00:39:15 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 06 Jun 2007 17:39:15 -0700 Subject: fc7 i386, yum and explicit dependencies In-Reply-To: <1181090981.32138.35.camel@cmn3.stanford.edu> References: <1181077186.32138.24.camel@cmn3.stanford.edu> <1181090981.32138.35.camel@cmn3.stanford.edu> Message-ID: <1181176755.3261.27.camel@cmn3.stanford.edu> On Tue, 2007-06-05 at 17:49 -0700, Fernando Lopez-Lezcano wrote: > On Tue, 2007-06-05 at 17:50 -0500, Rex Dieter wrote: > > Fernando Lopez-Lezcano wrote: > > > There _are_ > > > packages missing but yum happily goes ahead and installs the meta > > > package and the dependencies it can find, and ignores the missing > > > dependencies! Is this expected behavior?? > > > > No. Concrete example(s)? > > It is a rather long install which I just reproduced. Erased all > pertinent packages, then: > > > yum clean all > (just in case) > > > yum install planetccrma-apps > > After the install goes through (181 packages, see the log in the first > attachment to this email) I get this: > > ---- > > package-cleanup --problems > Setting up yum > Reading local RPM database > Processing all local requires > Missing dependencies: > Package planetccrma-apps requires avifile > Package planetccrma-apps requires ayam > Package planetccrma-apps requires bristol > Package planetccrma-apps requires cinelerra [MUNCH] > ---- > > At this point yum installed a meta package and did not install all the > dependencies mentioned in the package. The first time I tried I got > really surprised because I _knew_ there were a lot of things missing. > > If I then do: > > rpm -e planetccrma-apps > > and then try again I get what should have happened in the first place: > > > yum install planetccrma-apps > Loading "installonlyn" plugin > Setting up Install Process > Parsing package install arguments > Resolving Dependencies > --> Running transaction check [MUNCH] > Error: Missing Dependency: libfishsound is needed by package > planetccrma-apps [MUNCH] An update which may add a bit more detail. Today I added more packages to the repository that contains what is required by the planetccrma-apps meta package. I erased the planetccrma-apps package: > rpm -e planetccrma-apps Then I reinstalled it (it is the same package as before with the same requirements - the only change is that I added more packages to the repository so that more, but not _all_, requirements are met). > yum install planetccrma-apps It happily went ahead and added the new packages but again ignored the missing ones. Looks like a pattern of behavior[*]. After installing successfully the meta package again, the machine is left with unmet dependencies. Again, if I now erase planetccrma-apps and try reinstalling it, it fails as it should have the first time. Puzzling but completely repeatable. Is there anything I could do to help debug this? Looks like a pretty severe bug. -- Fernando [*] at this point my guess is: package with explicit named package dependencies (non-versioned). No other dependencies. if we try to install and some deps are available then it goes ahead and installs them ignoring any missing deps. if we try to install and all missing deps are missing then it complains with an error as it should. From spng.yang at gmail.com Thu Jun 7 01:05:33 2007 From: spng.yang at gmail.com (Ken YANG) Date: Thu, 07 Jun 2007 09:05:33 +0800 Subject: new libwnck make emerald fail to start In-Reply-To: <46671453.6010908@redhat.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> Message-ID: <466759DD.1030302@gmail.com> Jarod Wilson wrote: > Matthias Clasen wrote: >> On Wed, 2007-06-06 at 13:51 -0400, Jarod Wilson wrote: >> >>> For the record, updated beryl bits just hit updates-testing for F7, and >>> are all checked into cvs for F8, but were failing to build yesterday due >>> to libwnck issues. With luck, this latest libwnck update will fix that >>> and they'll actually build... >>> >> It is not unlikely that beryl needs that same patch that I added to >> compiz to make it build against the new libwnck. > > Ah, quite likely. I don't have the failed build log handy, but when I > get around to looking at it again, I'll give the compiz patch a look too. when i "yum update" today, i got following errors: Error: Missing Dependency: emerald-themes >= 0.2.1 is needed by package beryl-gnome Error: Missing Dependency: libwnck-1.so.21 is needed by package gnome-python2-libwnck Error: Missing Dependency: libwnck-1.so.21 is needed by package gnome-applets Error: Missing Dependency: heliodor >= 0.2.1 is needed by package beryl-gnome Error: Missing Dependency: emerald >= 0.2.1 is needed by package beryl-gnome Error: Missing Dependency: libwnck-1.so.21 is needed by package gnome-power-manager Error: Missing Dependency: libwnck-1.so.21 is needed by package compiz and additionally, i have another questions: after i update, i find some errors, and i want to restore to last version, especially in rawhide. for example, the newest foo-1.0.1 is not stable, i want to restore to the last version foo-1.0.0, where i can get this version of foo? > > From bbbush.yuan at gmail.com Thu Jun 7 01:44:35 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Thu, 7 Jun 2007 09:44:35 +0800 Subject: new libwnck make emerald fail to start In-Reply-To: <466759DD.1030302@gmail.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> Message-ID: <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> 2007/6/7, Ken YANG : > > > and additionally, i have another questions: > > after i update, i find some errors, and i want to restore to last > version, especially in rawhide. > for example, the newest foo-1.0.1 is not stable, i want to restore to > the last version foo-1.0.0, where i can get this version of foo? > dig it deeply in the buildsys or on DVD -- bbbush ^_^ From sberry at northlc.com Thu Jun 7 03:06:53 2007 From: sberry at northlc.com (Scott Berry) Date: Wed, 6 Jun 2007 22:06:53 -0500 Subject: an introduction and a question Message-ID: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> Hello, My name is Scott Berry. I am located in the United States in Minnesota up toward the Canadian border. I am totally blind and found a program covered under the BSD license that I would like to get packaged for Fedora. The name of the program is Webmin. I have spoken to the author and he has okayed for me to do this. I have a question though. Actually a few of them. I am brand new to packaging so these may sound kind of silly. 1. I tried creating an rpm of Webmin from the newest sources at www.webmin.com. 2. I have the program on my server and I did the following command with errors: "Rpmbuild -ts webmin-1.350.tar.gz" and I got the following errors: error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: Group field must be present in package: (main package) error: License field must be present in package: (main package) 3. What is the spec file and do I need to build this myself or how is it built and where should it be put? Again I apologize if these sound like simple questions but I would like to give back what I have been freely given by Fedora. Scott From bernie at codewiz.org Thu Jun 7 04:05:10 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 07 Jun 2007 00:05:10 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070606134126.GB1196485@hiwaay.net> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> Message-ID: <466783F6.8080600@codewiz.org> Chris Adams wrote: > $ ls -l x-dyn x-stat > -rwxr-xr-x 1 cmadams users 2816 Jun 6 08:38 x-dyn > -rwxr-xr-x 1 cmadams users 459492 Jun 6 08:38 x-stat It's probably time to switch OSes when a NOP program can't be made smaller than this and most developers don't even think we have a problem... Linux has become fat and slow over the years. > I don't forsee a static executable being smaller than a dynamic > executable in the real world. It is possible that somebody could > hand-build (e.g. no gcc, ld, etc.) such an executable, but that doesn't > really count (since that isn't done in the real world). Somebody actually *could* make small static binaries: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html (for the lazy, the binary is just 45 bytes and even *does* something useful ;-) -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From andy at smile.org.ua Thu Jun 7 04:15:56 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Thu, 7 Jun 2007 07:15:56 +0300 Subject: an introduction and a question In-Reply-To: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> References: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> Message-ID: <20070607041556.GB14773@serv.smile.org.ua> Hi Scott Berry! On Wed, Jun 06, 2007 at 10:06:53PM -0500, Scott Berry wrote next: > 3. What is the spec file and do I need to build this myself or how is it > built and where should it be put? > Again I apologize if these sound like simple questions but I would like to > give back what I have been freely given by Fedora. Try next: - download webmin-1.350.src.rpm - setup rpm-build package and its dependencies - run rpm -ivh webmin-1.350.src.rpm Under /usr/src/fedora (or redhat?) you'll found the subdirectory SPECS where the spec file is placed. You may fix it. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From rodd at clarkson.id.au Thu Jun 7 04:31:34 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 07 Jun 2007 14:31:34 +1000 Subject: Fedora 7 Anaconda feedback In-Reply-To: <1181168566.9635.34.camel@dimi.lattica.com> References: <1181168566.9635.34.camel@dimi.lattica.com> Message-ID: <1181190694.5215.2.camel@localhost.localdomain> On Wed, 2007-06-06 at 18:22 -0400, Dimi Paun wrote: > And now for my observations: > * the general experience is nice and pleasant, congrats! Agreed > * on the Install/Upgrade screen, why is "Install" selected > by default when the program already detected that I have > only _one_ image installed. This forces the user to override > an option that can be pretty automatic for most people. Along similar lines. Why is it that I can choose to upgrade an existing linux install (I've usually got two - the latest stable Fedora and rawhide) but I can't also choose to install where an existing fedora install is? I prefer to install (and leave /home intact) rather than upgrading because it's about as easy and it doesn't leave behind relics like upgrading can. R. -- "It's a fine line between denial and faith. It's much better on my side" From notting at redhat.com Thu Jun 7 04:40:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 00:40:01 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <466783F6.8080600@codewiz.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> <466783F6.8080600@codewiz.org> Message-ID: <20070607044001.GA14463@nostromo.devel.redhat.com> Bernardo Innocenti (bernie at codewiz.org) said: > >I don't forsee a static executable being smaller than a dynamic > >executable in the real world. It is possible that somebody could > >hand-build (e.g. no gcc, ld, etc.) such an executable, but that doesn't > >really count (since that isn't done in the real world). > > Somebody actually *could* make small static binaries: > > http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html > > (for the lazy, the binary is just 45 bytes and even *does* > something useful ;-) Yes, and violates the ELF standard, and is in hand-written assembly, and occupies the exact same amount of disk space and memory to load as the dynamic version that he started out with. (Seriously, if your code is already under a page size, what's the point?) Bill From spng.yang at gmail.com Thu Jun 7 04:57:04 2007 From: spng.yang at gmail.com (Ken YANG) Date: Thu, 07 Jun 2007 12:57:04 +0800 Subject: new libwnck make emerald fail to start In-Reply-To: <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> Message-ID: <46679020.7060909@gmail.com> Yuan Yijun wrote: > 2007/6/7, Ken YANG : >> >> >> and additionally, i have another questions: >> >> after i update, i find some errors, and i want to restore to last >> version, especially in rawhide. >> for example, the newest foo-1.0.1 is not stable, i want to restore to >> the last version foo-1.0.0, where i can get this version of foo? >> > > dig it deeply in the buildsys or on DVD i have found what i want in koji, thank you > > From ankit644 at yahoo.com Thu Jun 7 05:33:39 2007 From: ankit644 at yahoo.com (Ankit Patel) Date: Wed, 6 Jun 2007 22:33:39 -0700 (PDT) Subject: an introduction and a question Message-ID: <980545.12488.qm@web55306.mail.re4.yahoo.com> Hi Scott, Please go through the link: http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s02.html Btw, your tarball is missing spec file i think. ----- Original Message ---- From: Scott Berry To: fedora-devel-list at redhat.com Sent: Thursday, June 7, 2007 8:36:53 AM Subject: an introduction and a question Hello, My name is Scott Berry. I am located in the United States in Minnesota up toward the Canadian border. I am totally blind and found a program covered under the BSD license that I would like to get packaged for Fedora. The name of the program is Webmin. I have spoken to the author and he has okayed for me to do this. I have a question though. Actually a few of them. I am brand new to packaging so these may sound kind of silly. 1. I tried creating an rpm of Webmin from the newest sources at www.webmin.com. 2. I have the program on my server and I did the following command with errors: "Rpmbuild -ts webmin-1.350.tar.gz" and I got the following errors: error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: Group field must be present in package: (main package) error: License field must be present in package: (main package) 3. What is the spec file and do I need to build this myself or how is it built and where should it be put? Again I apologize if these sound like simple questions but I would like to give back what I have been freely given by Fedora. Scott -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Thu Jun 7 05:38:52 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 7 Jun 2007 00:38:52 -0500 Subject: an introduction and a question In-Reply-To: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> References: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> Message-ID: <16de708d0706062238j640aade9if7747c4c72123885@mail.gmail.com> On 6/6/07, Scott Berry wrote: > Hello, > > My name is Scott Berry. I am located in the United States in Minnesota up > toward the Canadian border. I am totally blind and [ snip ] Assuming that "I am totally blind" keeps it's standard meaning, and isn't a turn of phrase, I am curious as to how accessible you're finding Fedora. -- Fedora Core 6 and proud From drago01 at gmail.com Thu Jun 7 06:06:10 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 07 Jun 2007 08:06:10 +0200 Subject: no update info in repo data? Message-ID: <4667A052.5050508@gmail.com> Updates in F7 seem not to contain any additional info like chnagelog, security update or not etc. Atleast pup does not display this information... in FC6 it did. Known issue? From drago01 at gmail.com Thu Jun 7 06:08:49 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 07 Jun 2007 08:08:49 +0200 Subject: Fedora 7 Anaconda feedback In-Reply-To: <46673488.2070701@cora.nwra.com> References: <1181168566.9635.34.camel@dimi.lattica.com> <46673488.2070701@cora.nwra.com> Message-ID: <4667A0F1.9090802@gmail.com> Orion Poplawski wrote: > Dimi Paun wrote: >> * after upgrade, the new system failed to boot -- the horror! >> It was simple to fix, the default grub entry was still >> pointed to the old kernel image that got nuked, so I had >> to manually pick the other, newer image, and then edit >> /etc/grub.conf by hand. Never experienced this before. > > I've seen this too on the one upgrade I've done so far. > > I have done two and have not seen this. bugreport? From notting at redhat.com Thu Jun 7 06:18:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 02:18:25 -0400 Subject: no update info in repo data? In-Reply-To: <4667A052.5050508@gmail.com> References: <4667A052.5050508@gmail.com> Message-ID: <20070607061825.GA15374@nostromo.devel.redhat.com> dragoran (drago01 at gmail.com) said: > Updates in F7 seem not to contain any additional info like chnagelog, > security update or not etc. > Atleast pup does not display this information... in FC6 it did. > Known issue? Yes, it's not fully ported to bodhi yet. Bill From jfrieben at gmx.de Thu Jun 7 06:31:55 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Thu, 07 Jun 2007 08:31:55 +0200 Subject: mc missing from F7 DVD? In-Reply-To: <200706060908.57764.jkeating@redhat.com> References: <1181126314.3214.28.camel@dhcp-lab-186.brq.redhat.com> <20070606105221.321950@gmx.net> <200706060908.57764.jkeating@redhat.com> Message-ID: <20070607063155.202110@gmx.net> > On the other hand, it's 2.5gig less to download to get an installer image. > > You can add the Everything repo at install time to gain access to every > package in Fedora. But if you need network connectivity to obtain a system tailored to your needs in the first place, then you can simply download "boot.iso" which is only a few MB large and perform a network install (which is what I usually do at work but not at home where I only have a modem connection). There are still enough people out there who do not have a fast network connection at home and who have to rely exclusively on physical install media. Moreover, because of a priori unclear dependencies, it's cumbersome to burn required add-on packages on a CD to find out later that one is missing a prerequisite. > What is on the DVD has been an ongoing process from Test1 all the > way though Test4 and even the RC. I've taken the feedback and > adjusted the manifest file for the DVD as appropriate. If you didn't > notice it before, well I couldn't help you then. What's important > to note is what is on the DVD is _not_ what is /in/ Fedora. > All the packages are there, it's a quick yum or Add/Remove Software > session away. > > -- > Jesse Keating > Release Engineer: Fedora Well, I made my point, among others in the thread on the "Classic" spin for "F7T2" which I am actually missing for "F7": https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00993.html Respinning the install media for home use is also not possible for everybody, as this requires hardware resources (disk space) which are not always available, e.g. in the case of notebooks. -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From pertusus at free.fr Thu Jun 7 06:32:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 7 Jun 2007 08:32:39 +0200 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070606134126.GB1196485@hiwaay.net> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> Message-ID: <20070607063239.GA2848@free.fr> On Wed, Jun 06, 2007 at 08:41:26AM -0500, Chris Adams wrote: > You should probably test that before you post. I would say this is the > smallest possible regular C program: > > $ cat x.c > int main () > { > return 0; > } > $ gcc -o x-dyn x.c > $ gcc -static -o x-stat x.c > $ strip x-dyn x-stat > $ ls -l x-dyn x-stat > -rwxr-xr-x 1 cmadams users 2816 Jun 6 08:38 x-dyn > -rwxr-xr-x 1 cmadams users 459492 Jun 6 08:38 x-stat > $ > > I don't forsee a static executable being smaller than a dynamic > executable in the real world. It is possible that somebody could > hand-build (e.g. no gcc, ld, etc.) such an executable, but that doesn't > really count (since that isn't done in the real world). given that the dynamic executable is 2816 bytes, the static one could be smaller, however it is way bigger. In fact it seems to me (but I don't rerally know a lot about those things, I was only saying something I saw elsewhere) that it is way too bigger for that difference to be explained by static linking, there is something else happening there. In any case I stand corrected. -- Pat From lars at homer.se Thu Jun 7 06:41:29 2007 From: lars at homer.se (Lars E. Pettersson) Date: Thu, 07 Jun 2007 08:41:29 +0200 Subject: kernel 1PPS support was in FC6 and now not in F7 In-Reply-To: <20070606223145.GC28560@redhat.com> References: <46649864.6090101@aus-city.com> <20070606223145.GC28560@redhat.com> Message-ID: <4667A899.2030406@homer.se> On 06/07/2007 12:31 AM, Dave Jones wrote: > > So I want to ask that the 1PPS be put back into the F7 kernel as it > > was there in FC6, so why take it away? > > I have no idea what '1PPS' is, but it doesn't show up as a config > option, so any pointers to what is actually missing would be > appreciated. 1PPS is simply one pulse per second. Some information: http://www.eecis.udel.edu/~mills/ntp/html/pps.html http://www.kernel.org/pub/linux/daemons/ntp/PPS/ http://wiki.enneenne.com/index.php/LinuxPPS_support As far as I know it has never been in any of the RedHat/Fedora kernels. Lars -- Lars E. Pettersson http://www.sm6rpz.se/ From pertusus at free.fr Thu Jun 7 06:45:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 7 Jun 2007 08:45:16 +0200 Subject: XFCE desktop needs ... tetex ? In-Reply-To: <645d17210706061527k5237fe0ci7c7aeccdd8e9f5a@mail.gmail.com> References: <645d17210706061527k5237fe0ci7c7aeccdd8e9f5a@mail.gmail.com> Message-ID: <20070607064516.GB2848@free.fr> On Wed, Jun 06, 2007 at 11:27:10PM +0100, Jonathan Underwood wrote: > > Hm. I wonder if xfprint could be patched to use enscript instead of > a2ps - enscript doesn't have such dependencies. enscript doesn't use delegation, it is only for text files. In that case, paps may be a better solution. a2ps allows to use many more document types. -- Pat From pertusus at free.fr Thu Jun 7 06:51:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 7 Jun 2007 08:51:37 +0200 Subject: an introduction and a question In-Reply-To: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> References: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> Message-ID: <20070607065137.GC2848@free.fr> On Wed, Jun 06, 2007 at 10:06:53PM -0500, Scott Berry wrote: > Hello, > > under the BSD license that I would like to get packaged for Fedora. If you want to become a fedora packager, you should certainly read http://fedoraproject.org/wiki/PackageMaintainers/Join http://fedoraproject.org/wiki/PackageMaintainers > The name of the program is Webmin. I have spoken to the author and he has > okayed for me to do this. I have a question though. Actually a few of > them. I am brand new to packaging so these may sound kind of silly. > > 1. I tried creating an rpm of Webmin from the newest sources at > www.webmin.com. Maybe you could have a look at this submission: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184080 A quick reading shows that the spec submitted wasn't really up to the packaging standards in fedora. -- Pat From bernie at codewiz.org Thu Jun 7 07:16:23 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 07 Jun 2007 03:16:23 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070607044001.GA14463@nostromo.devel.redhat.com> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> <466783F6.8080600@codewiz.org> <20070607044001.GA14463@nostromo.devel.redhat.com> Message-ID: <4667B0C7.1080201@codewiz.org> Bill Nottingham wrote: >> http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html >> >> (for the lazy, the binary is just 45 bytes and even *does* >> something useful ;-) > > Yes, and violates the ELF standard, and is in hand-written assembly, > and occupies the exact same amount of disk space and memory to load > as the dynamic version that he started out with. (Seriously, if your > code is already under a page size, what's the point?) That "paper" was clearly trying to do clever hack rather than anything useful in the real world. But the point is still valid: Linux has become somewhat bloated over time. Few people care to admit it, but just a few years ago we used to make fun of those other OSes for being slow and clumsy, and now it's us requiring more disk space, memory and cycles than most of the others. There are many areas we could be pointing fingers at: selinux, fs journaling, utf8, pango, cairo, locale, tls, pie, glibc malloc fences, kernel debug switches, paravirt_ops, etc. Please, don't be picky: maybe one of these items is just in the list by mistake, but you get the point. As a matter of fact, these are also features... Most are even *useful* features. But the fact is that the general attitude in today's Linux development community is that new things go in regardless of their impact on performance. Usually on the basis that computers are fast anyway. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From drago01 at gmail.com Thu Jun 7 07:27:08 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 07 Jun 2007 09:27:08 +0200 Subject: no update info in repo data? In-Reply-To: <20070607061825.GA15374@nostromo.devel.redhat.com> References: <4667A052.5050508@gmail.com> <20070607061825.GA15374@nostromo.devel.redhat.com> Message-ID: <4667B34C.6020400@gmail.com> Bill Nottingham wrote: > dragoran (drago01 at gmail.com) said: > >> Updates in F7 seem not to contain any additional info like chnagelog, >> security update or not etc. >> Atleast pup does not display this information... in FC6 it did. >> Known issue? >> > > Yes, it's not fully ported to bodhi yet. > > ok, thx for the quick reply. From j.w.r.degoede at hhs.nl Thu Jun 7 08:02:41 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Thu, 07 Jun 2007 10:02:41 +0200 Subject: Fedora 8 ideas Message-ID: Hi all, Here are some (unsorted) ideas for cool(?) new things todo for F8, warning braindump, waring. 1 Package nvu ============= The title pretty much sums it up, package nvu a popular opensource web-editor. Anyone know why this hasn't been done yet? 2 Firmware buddy ================ Here is what I would like to see (and would be willing to write code for): 1) A firmware load request is send to userspace 2) When the userspace firmware helper cannot find this firmware, it logs this to a missing-firmware file. 3) When the user logs in, a firmware-helper-applet runs 4) If there is missing firmware and a working internet connection, the applet becomes active, otherwise it exits 5) The applet looksup the firmware name in a table which matches it to a device-identifier. 6) The applet looksup manufacturers + productnames (as seen on the box/outside) of device-identifier devices. 7) The applet shows a gui to the user explaining that firmware is needed for his XXXXX (ex. wireless card) to work, and asks him to select the manufacturer and product of his XXXXX. 8) The applet downloads the windows-driver from the manufacturers websites and runs a special (per driver) shell script to extract the firmware 9) The user is told to reboot (or do something else to get the device re-initialised). 3 plugin buddy ============== Like codec buddy, but then for firefox plugins. Why? because firefox plugin find service doesn't undserstand to install nspluginwrapper (needs to get into Fedora) and then flash on x86_64. Nor knows it to change the selinux type of realplayer to get it to work with our default enabled selinux policy. 4 internet access keys made easy ================================ The title pretty much sums it up, add some gui-helper for people to make it easy to configure there internet access keys on ps2 keyboards (usb should get handled 100% automatically). Use dmi info on laptops to identify and automatically enable there internet access keys. Things todo here: -there is a weird kernel behaviour with similated scancodes, (which is enbaled by default) which confuses X with regards to these keys. If simulated scancodes are disabled, then selecting the proper keyboard in preferences->hardware- >keyboard, gets X to recognise the keys and send special XF86 ext syms for them. -metacity can define keyboard shurtcuts for actions like mail, www, home, search, etc. But does not bind these to the special XF86 keysysms for these by default (easy fix) -for the laptop case automatically configure the correct keyblayout using dmi-info -check that usb works automatically, and if not fix it. 5 proprietary software install helper ===================================== Yes you read it correctly, I'm suggesting the inclusion of a "proprietary software install helper" which gives users a gui which will help them to install popular and free as in beer software. Many of my collegues who I try to convert to Linux have been complaining about the pain to get for example vmware to run, this is when I first came up with this idea, to pretty much discard it the next day. Then today I read this article: http://www.howtoforge.com/the_perfect_desktop_fedora7 (which contains many badness) and I noticed again a lott of workarounds/hacks to get proprietary software to run. Lets face it quite a few of our users (and quite a few of us too I guess) want to atleast try out some proprietary software, and installing that on a quick developing cutting edge distro like Fedora is a pain. Problems with selinux are only one part of this. If we want users to stop disabling selinux, an helper program which fixes selinux types for these will hopefully lead to less users disabling selinux. So do we want this? on one hand we do not endorse / promote proprietary software. OTOH some (many?) of our users use or atleast want to try one or 2 proprietary programs. I think in the name of userfriendlyness, that it is a good idea to make this easier for them. Suggestion: if this is done make the program start witha dialog that we do not endorse this, bla bla bla. When a propietary app gets selected, first popup a dialog advocating free alternatives (qemu for vmware, evince for acroread, etc.) with an install + launch button for the free alternative. Regards, Hans From nicolas.mailhot at laposte.net Thu Jun 7 08:16:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 7 Jun 2007 10:16:12 +0200 (CEST) Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <4667B0C7.1080201@codewiz.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> <466783F6.8080600@codewiz.org> <20070607044001.GA14463@nostromo.devel.redhat.com> <4667B0C7.1080201@codewiz.org> Message-ID: <38900.192.54.193.51.1181204172.squirrel@rousalka.dyndns.org> Le Jeu 7 juin 2007 09:16, Bernardo Innocenti a ?crit : > but the point is still valid: Linux has become somewhat bloated > over time. And it will become unbloated by converging on a new common set of core dynamic libraries, and optimizing them (like pango & qt people are doing for harfbuzz, like popler did before, etc) Static linking is not the solution. Experience shows it only leads to many forks of the same code that bloat memory usage and increase maintenance. -- Nicolas Mailhot From Fedora at FamilleCollet.com Thu Jun 7 08:28:32 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Thu, 07 Jun 2007 10:28:32 +0200 Subject: Fedora 8 ideas In-Reply-To: References: Message-ID: <4667C1B0.9000506@FamilleCollet.com> Goede, J.W.R. de a ?crit : > > 1 Package nvu > ============= > > The title pretty much sums it up, package nvu a popular > opensource web-editor. Anyone know why this hasn't been > done yet? Hi, I think NVU is a "dead" software It should be replaced by "Composer", a Xulrunner App. As we should have Xulrunner in F8, probably a good idea to wait a little. Some info here : http://glazman.org/weblog/dotclear/index.php?Nvu Regards From kevin.kofler at chello.at Thu Jun 7 08:33:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 7 Jun 2007 08:33:03 +0000 (UTC) Subject: Unwanted RPM dependencies References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > > On Monday 04 June 2007 14:17:11 Stefan Held wrote: > > Would the solution with isolated grub graphics harm anyone? > > We have something of a mandate to keep all the trademarked content in one > package, fedora-logos. What about a fedora-logos-grub subpackage? It's easy to identify where it comes from, and derivative distros will need to patch fedora-logos at SRPM level anyway, so there's practically no chance they'd miss the subpackage (which would be built from the same SRPM). Kevin Kofler From steve at nexusuk.org Thu Jun 7 08:34:54 2007 From: steve at nexusuk.org (Steve Hill) Date: Thu, 7 Jun 2007 09:34:54 +0100 (BST) Subject: Unmounting removable media under Gnome In-Reply-To: <1181176516.7761.52.camel@zelda.fubar.dk> References: <1181148476.7761.13.camel@zelda.fubar.dk> <1181176516.7761.52.camel@zelda.fubar.dk> Message-ID: On Wed, 6 Jun 2007, David Zeuthen wrote: >> If there's an explicit unmount option then compatibility is maintained >> and everyone's happy. > > Has nothing to do with compatibility. Applications simply need to > properly deal with hardware and not punt it to the user to tweak the > hardware so it's in a state acceptable for the program. It certainly is to do with compatibility - up until recently (the last couple of years) it was certainly unusual to have the media mounted when you weren't actually using it so it was expected that the media wouldn't be mounted if you were trying to erase it, for example. Over the past couple of years we have had a quite radical shift in the way a lot of stuff works under Linux and one of these changes is that media is often mounted as soon as it is loaded into the machine, so the expectation that it will be unmounted when not in use is nolonger reasonable. However, it takes a while for software to catch up with this shift - there needs to be some (reasonably long) cross-over period where both methodologies are accepted. We can't just suddenly say one day "we've decided to change the way stuff works - all your old software will break and you'll have to modify it to deal with our new grand design" For me, part of the point of Linux is that I get a choice over what software I use, and it all more or less works together - if I choose a particular desktop environment that shouldn't prevent me from effectively using software that isn't explicitly integrated into that environment. Yes, it'd be nice if all the software dealt with the system being in whatever unexpected state another piece of software put it in. But the fact is that many pieces of software don't cope well with this kind of thing and ignoring the problem and saying "well they should" isn't helpful. -- - Steve xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence From andy at warmcat.com Thu Jun 7 09:49:03 2007 From: andy at warmcat.com (Andy Green) Date: Thu, 07 Jun 2007 10:49:03 +0100 Subject: fedora for generic crosscompile In-Reply-To: <4667322C.7020904@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <4667322C.7020904@redhat.com> Message-ID: <4667D48F.4020201@warmcat.com> Brendan Conoboy wrote: > Ed Swierk wrote: >> Isn't that exactly what we'd get with target emulation? Any available >> host that can run an emulator could then build all of fedora Fedora >> for ARM or PowerPC or whatever. > > I don't mean to exclude target emulation as an option, it's just not > where my particular interest is. Here's why: > > 1. It is always slower than native or cross compilation. > > 2. It only exists for a small number of platforms. 2a or 3. It's not self seeding. If you have a cross toolchain (gcc, binutils), you can generate all the target packages needed for a normal runlevel 3 or 5 environment on the target with just the cross toolchain and a set of SRPMs. But for the emulation case, you somehow needed a runlevel 3 working set of binary packages for the target arch (so you can boot it and compile) before you can start making target packages. Progress with new arches will therefore be faster and more distributed with the cross method assuming there is a flexible way to make arbitrary cross toolchains (like rpmbuild --rebuild --target=s390 --runtime-generates=arm gcc-4.0.2-1234.src.rpm ) ... unfortunately rpmbuild target doesn't have the same meaning as in configure. > One of the advantages of cross compiling is that it's not just for arm, > it's for anything. You can create a mesh of cross compilers such that > any arch can build a target for any other arch. Is the s390 slow or > down? No problem, build on one of the plentiful x86 hosts. Cross > compilation has the potential to realize maximum use of build hosts and > consequently turn around faster builds. Right and not only that to empower everyone to kick out s390 versions of their packages if they want. They just install s390 cross toolchain and -devel packages somewhere and rpmbuild --rebuild --target=s390 blah.src.rpm. At the least they can make sure it compiles clean, and hopefully can find an s390 vict... tester. >> Supporting cross-compiling would be great, but having spent a several >> weeks fighting with Python and its libraries last year and losing, I >> suspect scouring the other nine zillion Fedora packages for > > Packages like Python and Perl do take some work, but a number of > individuals have already done that work. Multiple times. Multiple > approaches. Fedora becoming cross friendly could have the effect of > unifying those efforts, getting cross changes upstream, ending all the > waste. Yes, and that would improve the situation for a large and increasing number of embedded folk who may not even use Fedora, that is valuable work. >> That said, there is certainly room for both approaches, and getting >> even a small number of packages to cross-compile might be enough for >> many embedded applications. > > Definitely. For cross compilation, I picture a per-package flag in Koji > that marks it as cross-friendly or not. There are certainly numerous > technical and social details to work out to making such a system work > and work equitably. We're just getting started. Well some areas to think about - extending rpmbuild a very little to take a switch to define a new macro %{_runtime_target_cpu} or somesuch, so cross toolchain packages can be told what the built compilers should emit - The disparity in platform resources and power will be greater than ever before. Choices made in ./configure switches that are the standard Fedora way can easily blow packages and dependencies out of scope for otherwise capable targets. You can tie choices in configuration to the arch, but isn't it more interesting to imagine it is its own "bloat dimension", so weak x86 targets can be built for? How about being able to specify multiple %build and Requires based on a new macro %_bloat. %_bloat = 10 is the normal supported Fedora traditional build with Kerberos everywhere and so on. But the spec file can also define alternatives along the lines of %if %_bloat < 10 %endif or %switch/%case (either requires a little extension to rpm AFAIK). Only the default bloat level needs to be supported and shipped by Fedora to the extent it already is, folks can --rebuild to target lesser platforms fedgentoo style. %_bloat=1 can even give you a busybox / uClibc based result if you want to max it out. But to get started all the packages can just build the standard way without any conditionals. - How to install foreign arch libs and -devel packages. There is already a precedent in having i386 libs on x86_64 boxes but this is a bit different because the arch is REALLY foreign. It will have to know to do some kind of --root= action if it sees you installing s390 libs into an i386 box, because you clearly don't want them going into the real /lib. - How yum can keep the foreign arch packages up to date too. The bloat scheme above would need to issue at least non %_bloat = 10 rpms with a bloat tag on them so the right -devel stuff gets pulled in -Andy From dwmw2 at infradead.org Thu Jun 7 09:51:22 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 07 Jun 2007 10:51:22 +0100 Subject: fedora for ARM In-Reply-To: <4667322C.7020904@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <4667322C.7020904@redhat.com> Message-ID: <1181209882.2785.24.camel@pmac.infradead.org> On Wed, 2007-06-06 at 16:16 -0600, Brendan Conoboy wrote: > > Supporting cross-compiling would be great, but having spent a several > > weeks fighting with Python and its libraries last year and losing, I > > suspect scouring the other nine zillion Fedora packages for > > Packages like Python and Perl do take some work, but a number of > individuals have already done that work. Multiple times. Multiple > approaches. Fedora becoming cross friendly could have the effect of > unifying those efforts, getting cross changes upstream, ending all the > waste. I like the idea, really. But we're seeing serious resistance to the suggestion that package maintainers should even have to look at _native_ build failures on architectures which used to build, even though such failures are _often_ indicative of a generic problem and not an arch-specific problem. Do you really think we're going to get them to care about cross builds too? I _did_ care about cross-compilation, and I gave up on it. I really don't think we have much chance of getting package maintainers (and upstreams) to handle it. Unfortunately. -- dwmw2 From dwmw2 at infradead.org Thu Jun 7 09:52:59 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 07 Jun 2007 10:52:59 +0100 Subject: fedora for generic crosscompile In-Reply-To: <4667D48F.4020201@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <4667322C.7020904@redhat.com> <4667D48F.4020201@warmcat.com> Message-ID: <1181209979.2785.26.camel@pmac.infradead.org> On Thu, 2007-06-07 at 10:49 +0100, Andy Green wrote: > - How to install foreign arch libs and -devel packages. There is > already a precedent in having i386 libs on x86_64 boxes but this is a > bit different because the arch is REALLY foreign. It will have to > know to do some kind of --root= action if it sees you installing s390 > libs into an i386 box, because you clearly don't want them going into > the real /lib. This would be nice. Even if we aren't actually building packages for release that way, it's useful for populating qemu and cross-toolchain sysroots. -- dwmw2 From dominik at greysector.net Thu Jun 7 10:12:14 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 7 Jun 2007 12:12:14 +0200 Subject: Future SCM Technology In-Reply-To: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> Message-ID: <20070607101214.GB18982@ryvius.pekin.waw.pl> On Wednesday, 06 June 2007 at 21:58, Jeffrey C. Ollie wrote: > It's F7+5 and F8T1-57 (yes, less than two months until F8T1 under the > current schedule[1]). If we are going to replace CVS[2] with another > SCM for hosting the Fedora Package Repository we need to get started > now! And to get things started, we need to discuss what kinds of > workflow we want our new SCM to support. > > Here's a list of things to think about (thanks to Jeremy Katz): > * How do we make it easier for a maintainer to rebase their package to a > newer upstream? > * How do we make it easier for a maintainer to develop, test, and create > a patch to fix a problem that's being experienced in Fedora? > * How do we make it easy to send these patches to the upstream of the > project being worked on? > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? I, for one, would welcome something similar to svn cp and svn mv, which allows you to copy and rename files (I'm thinking patches) while preserving change history. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From buytenh at wantstofly.org Thu Jun 7 10:34:41 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 12:34:41 +0200 Subject: fedora for ARM In-Reply-To: <20070602183828.GI7445@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> Message-ID: <20070607103441.GB2079@xi.wantstofly.org> On Sat, Jun 02, 2007 at 02:38:28PM -0400, Dave Jones wrote: > Hi Lennert, Hi Dave, Thanks for your time. > > I'm posting here because I would really really like to get the > > relevant diffs merged back into Fedora. > > I took a quick look at the kernel dir, and the specfile changes are > pretty unoffensive, and mergable imo. Note that the current kernel changes only make %{arm} a nobuildarch. I.e. we don't actually build a kernel image rpm at this point. This is for several reasons, some of which noted elsewhere in the thread: - ARM kernels are pretty much specific to the ARM CPU model they are built for. E.g., while you _can_ make a kernel image that supports multiple different boards that are all based on the same Samsung s3c24xx ARM CPU, you can't build one kernel image that supports both Samsung s3c24xx and Intel PXA27x based boards, due to various differences in those CPUs: - Top-level IRQ demux is done differently on different ARM CPUs (as different ARM CPUs have different on-chip IRQ controllers), and IRQ demux is currently done by a CPU port provided macro (in include/asm-arm/arch-*/entry-macro.S.) It probably _is_ possible to make this switchable at boot time, but would require some work. - Some ARM CPUs are cache coherent w.r.t. DMA, and some are not. - Some ARM CPUs are strongly ordered, while some have weak ordering of RAM accesses versus I/O accesses, and the barrier instructions supported by the (semi-)weakly ordered ARM CPUs are undefined insns on earlier strongly ordered CPUs. - Different ARM CPUs conform to different versions of the ARM instruction set spec, which means that different ops are available for atomic accesses (an xchg-type 'swp' instruction in older CPUs versus load locked/store conditional insns in newer CPUs), some CPUs provide opcodes for 'find first bit' while others do not, etc. So if you want to provide ARM kernel images, you probably have no choice but to provide one per CPU type, which is probably doable (Debian does it this way as well, for the CPU types that people request support for), but it does mean that it's not as easy as just providing one kernel image which would then work everywhere. - The kernels people tend to use on ARM hardware tend to diverge more from upstream than kernels that people tend to use on x86 hardware. While I and many others do build kernels from upstream and make sure the boards we use are fully supported upstream, a lot of others do not. In fact, the upstream kernel probably doesn't even support half of the ARM CPU types out there (despite our best efforts) :-( At this point, the FC6 ARM port is more intended for developers than end users, and that class of people presumably already have working kernel images for their hardware anyway. I'm not sure how much sense it makes in the end. (There appear to be some ARM folks on the list, maybe they can share their opinions on this?) > The config file however I think might be better served if it was > done differently. ACK, that makes sense. I just copied whatever the other FC6 archs did to get the package to build. > Instead of having a single flat config file, the Fedora kernel rpm > generates configs out of templates (see configs/ dir in cvs) > It should be fairly simple to change this though.. > just remove all the symbols from your current config that are already > in config-generic (except for ones you want to override). > Then add a stanza to Makefile.config to call merge.pl on > config-generic and config-arm. To be honest, I didn't spend a lot of effort on creating the current .config file, I actually just used the .config file that I use on one of my ARM boards. > The advantages of doing it this way are that we don't have to update > n config files when upstream adds a new option, just adding it to > config-generic gets it automatically added to all archs where it > makes sense. ACK. > Having a quick scan through some of the options you have set.. > > # CONFIG_UTRACE is not set > > note that this will also disable ptrace too afaik. Hmm. Hmm? [root at iop ~]# uname -a Linux iop.wantstofly.org 2.6.21 #13 Sun May 13 23:39:28 CEST 2007 armv5tel armv5tel armv5tel GNU/Linux [root at iop ~]# cat /etc/redhat-release Fedora Core release 6 (Zod) [root at iop ~]# strace ls execve("/bin/ls", ["ls"], [/* 23 vars */]) = 0 brk(0) = 0x26000 uname({sys="Linux", node="iop.wantstofly.org", ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x15571000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=42215, ...}) = 0 mmap2(NULL, 42215, PROT_READ, MAP_PRIVATE, 3, 0) = 0x1557b000 [...] > CONFIG_DEFAULT_DEADLINE=y > > Any reason not to go with CFQ like we do on other archs? No particular reason, really. > CONFIG_IDE=y > Has anyone looked at porting the ARM ATA drivers over to libata ? IDE/PATA comes in various different flavors on ARM platforms. In summary, yes, most ATA stuff on ARM platforms either works with libata right now or will work with libata very soon. First of all, there's the regular PCI controllers. These work fine on ARM without any changes necessary. The main dev boards that I use all have their storage on PCI, and use libata. [root at iop ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 305678480 69718320 220432536 25% / none 127980 0 127980 0% /dev/shm [root at iop ~]# lspci | grep SATA 00:01.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) [root at iop ~]# Then there's a lot of ARM dev boards that come with CompactFlash slots. These are typically just hooked up to the peripheral bus of the CPU (typically the same bus that the boot flash is on), and if task file accesses can be made with regular direct MMIO accesses, you can just use the pata_platform driver (which works fine.) (In this case, you typically just use PIO.) Then there's also a bunch of ARM CPUs come with PATA or SATA built in to the chip. Most of the SATA stuff is actually using libata already, and most PATA stuff either also uses pata_platform, or when HW designers do ugly things, or when the chip can do DMA, it needs a CPU-specific driver. Most of these have either already been written for libata, or are still being written. E.g.: http://marc.info/?l=linux-ide&m=117001700116724&w=2 > # CONFIG_VT is not set > Is this always going to be useless on ARM ? Probably not -- there's enough ARM CPUs out there with built-in graphics controllers, and you'd probably like to run VTs on those (it's just that my build machines only have serial console.) > # CONFIG_MMC is not set > might be handy for handhelds ? ACK. > # CONFIG_EXT2_FS_XATTR is not set > # CONFIG_EXT3_FS_XATTR is not set > # CONFIG_SECURITY is not set > > aww, no selinux ? I've never actually tested this on ARM. (I _assume_ it should just work..) > There's a lot of stuff built in =y, rather than modular which > seems a little wasteful. (In fact, there's nothing =m, > yet CONFIG_MODULES=y :-) > > There's a few things that stuck out that seem like they may be > useful (ipsec support for eg) in some use-cases for embedded systems > that were disabled. > > I'll concede that Fedora-ARM is breaking new ground here, in that > its the first arch we're supporting (other than olpc I guess) > where the size of the generated rpms is a concern, but I think > there's probably a balance to be struck between what we have > so far, and a 'generic' kernel that may be of use to many different > projects without them needing to rebuild parts of the kernel > that were left out. I think that for development use, when disk space is not a concern (when you're either on directly attached storage or nfsroot), it makes a lot of sense to use a kernel that supports everything, and to run the full vanilla Fedora ARM distro with all the development tools, etc. When you get to the phase where you're building a custom filesystem for an embedded device, where everything has to fit in 32M or 16M of flash or even less, you'd customise both your kernel and all your userland packages from what is provided in Fedora (and you'd typically cross-compile most of your packages when you do so), but that isn't a use case that is targeted with this round of patches yet. I.e. on top of the Fedora ARM patches we have now, there are various other things that can be done (slimming down packages, making them cross-compileable, etc.) to make Fedora packages more suitable for building such minimal filesystems with, things that will benefit ARM and OLPC alike, but those are orthogonal efforts to this ARM support patch set. IOW, I think not spending any effort yet on trying to slim down packages is fine in this stage. cheers, Lennert From buildsys at redhat.com Thu Jun 7 10:40:58 2007 From: buildsys at redhat.com (Build System) Date: Thu, 7 Jun 2007 06:40:58 -0400 Subject: rawhide report: 20070607 changes Message-ID: <200706071040.l57Aew9K016096@porkchop.devel.redhat.com> New package kflickr Standalone Flickr Uploader for KDE New package nikto Web server scanner New package python-IPy Python module for handling IPv4 and IPv6 Addresses and Networks New package specto An desktop application that will watch configurable events New package wdfs WebDAV File System Updated Packages: bigboard-0.4.3-1 ---------------- * Wed Jun 06 2007 Colin Walters - 0.4.3-1 - update - Use sitearch for everything compiz-0.4.0-1.fc8 ------------------ * Tue Jun 05 2007 Matthias Clasen - 0.4.0-1 - Update to 0.4.0 control-center-1:2.19.3-6.fc8 ----------------------------- * Wed Jun 06 2007 - Bastien Nocera - 2.19.3-6 - Remove gst-inspect call, as the configure doesn't check for specific plugins * Tue Jun 05 2007 Matthias Clasen - 2.19.3-5 - Another rebuild, fixing some Makefile syntax problems * Tue Jun 05 2007 - Bastien Nocera - 2.19.3-4 - Another rebuild with GStreamer for PPC rebuilt cook-2.28-1.fc8 --------------- * Wed Jun 06 2007 Gerard Milmeister - 2.28-1 - new version 2.28 deskbar-applet-2.19.3-2.fc8 --------------------------- * Wed Jun 06 2007 Luke Macken - 2.19.3-2 - Add deskbar-applet-firefox-searchplugins.patch to fix the issue where deskbar-applet does not find the default Firefox search plugins (Bug #242977 and #220662) devilspie-0.20.2-3.fc8 ---------------------- * Wed Jun 06 2007 Sebastian Vahl 0.20.2-3 - rebuild against new libwnck (again) epiphany-extensions-2.19.2-3 ---------------------------- * Wed Jun 06 2007 Christopher Aillon - 2.19.2-3 - Specfiles should _NOT_ call rpm directly. Fix the previous bug the correct way, by doing explicit requires on the exact versions instead of via rpm -q evolution-2.11.3-4.fc8 ---------------------- * Wed Jun 06 2007 Matthew Barnes - 2.11.3-4.fc8 - Revise patch for GNOME bug #362638 to fix RH bug #240507 (hang on exit). * Wed Jun 06 2007 Matthew Barnes - 2.11.3-3.fc8 - Remove some debug messages that accidentally slipped in. * Tue Jun 05 2007 Matthew Barnes - 2.11.3-2.fc8 - Fix an invalid g_free() that was causing lock-ups. geomview-1.9.1-1.fc8 -------------------- * Wed Jun 06 2007 Rex Dieter 1.9.1-1 - geomview-1.9.1 - omit orrery/maniview, can now be packaged separately. glib2-2.13.4-1.fc8 ------------------ * Wed Jun 06 2007 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 gnome-applets-1:2.18.0-10.fc8 ----------------------------- * Tue Jun 05 2007 Matthias Clasen - 1:2.18.0-10 - Rebuild again gnome-power-manager-2.19.2-3.fc8 -------------------------------- * Tue Jun 05 2007 Matthias Clasen - 2.19.2-3 - Rebuild again gnome-python2-desktop-2.18.0-4.fc8 ---------------------------------- * Tue Jun 05 2007 Matthias Clasen - 2.18.0-4 - Rebuild again gnutls-1.6.3-1.fc8 ------------------ * Wed Jun 06 2007 Tomas Mraz 1.6.3-1 - upgrade to latest upstream (#232445) gtk2-2.11.2-1.fc8 ----------------- * Wed Jun 06 2007 Matthias Clasen - 1.11.2-1 - Update to 2.11.2 * Mon Jun 04 2007 Matthias Clasen - 1.11.1-1 - Update to 2.11.1 - Update patches * Thu May 24 2007 Matthias Clasen - 1.11.0-1 - Update to 2.11.0 - Drop upstreamed patches hunspell-1.1.5.3-4.fc8 ---------------------- * Wed Jun 06 2007 Caolan McNamara - 1.1.5.3-4 - Resolves: rhbz#212984 discovered problem with missing wordchars hunspell-pl-0.20070606-1.fc8 ---------------------------- * Wed Jun 06 2007 Caolan McNamara - 0.20070606-1 - next version k3b-0:1.0.1-2.fc8 ----------------- * Wed Jun 06 2007 Rex Dieter - 0:1.0.1-2 - respin (for libmpcdec) kernel-2.6.21-1.3209.fc8 ------------------------ * Wed Jun 06 2007 Dave Jones - Build with -Wpointer-arith for a while. See http://bugzilla.kernel.org/show_bug.cgi?id=7561 for info. libmpcdec-1.2.6-2.fc8 --------------------- * Wed Jun 06 2007 Rex Dieter 1.2.6-2 - fix %files (docs/html is no more) * Wed Jun 06 2007 Rex Dieter 1.2.6-1 - libmpcdec-1.2.6 libnotify-0.4.4-6.fc8 --------------------- * Wed Jun 06 2007 Matthias Clasen - 0.4.4-6 - Re-add notification-daemon requirement again libtunepimp-0.5.3-4.fc8 ----------------------- * Wed Jun 06 2007 Rex Dieter 0.5.3-4 - respin (for libmpcdec) lirc-0.8.2-0.1.pre3.fc8 ----------------------- * Wed Jun 06 2007 Ville Skytt?? - 0.8.2-0.1.pre3 - 0.8.2pre3. - Fix up linefeeds and char encodings of more docs. numpy-1.0.3-1.fc8 ----------------- * Wed Jun 06 2007 Jarod Wilson 1.0.3-1 - New upstream release * Mon May 14 2007 Jarod Wilson 1.0.2-2 - Drop BR: atlas-devel, since it just provides binary-compat blas and lapack libs. Atlas can still be optionally used at runtime. (Note: this is all per the atlas maintainer). * Mon May 14 2007 Jarod Wilson 1.0.2-1 - New upstream release pan-1:0.131-1.fc8 ----------------- * Wed Jun 06 2007 Alexander Dalloz - 1:0.131-1 - Update to 0.131 (fixing #241610) pcmciautils-014-8.fc8 --------------------- * Wed Jun 06 2007 Harald Hoyer - 014-8 - fixed 'pccardctl ident' SEGV - Resolves: rhbz#242805 perl-GDGraph3d-0.63-7.fc8 ------------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 0.63-7 - Correction of CPAN URL (#242941). pidgin-2.0.1-5.fc8 ------------------ * Wed Jun 06 2007 Stu Tomlinson - 2.0.1-5 - Enable Bonjour support (#242949) - Fix building against latest evolution-data-server * Tue Jun 05 2007 Stu Tomlinson - 2.0.1-4 - Fix purple-remote for AIM & ICQ accounts (#240589) - Add missing Requires to -devel packages - Add missing BuildRequires for libxml2-devel * Thu May 31 2007 Stu Tomlinson - 2.0.1-2 - Call g_thread_init early (#241883) - Fix purple-remote syntax error (#241905) pilot-link-2:0.12.2-3.fc8 ------------------------- * Wed Jun 06 2007 Ivana Varekova - 2:0.12.2-3 - Resolves: #240327 remove IT_PROG_INTLTOOL definition * Mon Apr 30 2007 Ivana Varekova - 2:0.12.2-2 - Resolves: 238239 fix a syntax error in pilot-link.m4 * Thu Apr 26 2007 Ivana Varekova - 2:0.12.2-1 - update to 0.12.2 polyester-1.0.1-1.fc8 --------------------- * Wed Jun 06 2007 Sebastian Vahl - 1.0.1-1 - new upstream version: 1.0.1 - added README python-basemap-0.9.5-2.fc8 -------------------------- * Wed Jun 06 2007 Orion Poplawski 0.9.5-2 - Rebuild python-matplotlib-0.90.1-1.fc8 ------------------------------ * Mon Jun 04 2007 Orion Poplawski 0.90.1-1 - Update to 0.90.1 scim-bridge-0.4.12-3.fc8 ------------------------ * Wed Jun 06 2007 Huang Peng - 0.4.12-3 - Do not fall back for some key events to fix a bug (#209626) * Mon Jun 04 2007 Jens Petersen - 0.4.12-2 - update scim requires and buildrequires to 1.4.6 * Mon May 21 2007 Jens Petersen - 0.4.12-1 - update to 0.4.12 scribes-0.3.2.8-1.fc8 --------------------- * Wed Jun 06 2007 Peter Gordon - 0.3.2.8-1 - Update to new upstream release (0.3.2.8). * Sun Jun 03 2007 Peter Gordon - 0.3.2.6-1 - Update to new upstream release (0.3.2.6). * Fri May 18 2007 Peter Gordon - 0.3.2.5-1 - Update to new upstream release (0.3.2.5). sysklogd-1.4.2-7.fc8 -------------------- * Wed Jun 06 2007 Peter Vrabec 1.4.2-7 - terminate dispatcher on exit * Wed Jun 06 2007 Peter Vrabec 1.4.2-6 - fix realtime interface - terminate parent of syslogd daemon on SIGCHLD tcp_wrappers-7.6-47.fc8 ----------------------- * Wed Jun 06 2007 Tomas Janousek - 7.6-47 - fix the hostname resolving patch for x86_64 texi2html-1.78-1.fc8 -------------------- * Wed Jun 06 2007 Jindrich Novy 1.78-1 - update to 1.78 vdr-femon-1.1.3-1.fc7 --------------------- * Wed May 16 2007 Ville Skytt?? - 1.1.3-1 - 1.1.3. xar-1.5-1.fc8 ------------- xemacs-21.5.28-2.fc8 -------------------- * Wed Jun 06 2007 Ville Skytt?? - 21.5.28-2 - Set more dirs explicitly until upstream configure honors them better. - Borrow DESTDIR install patch from openSUSE. - Add pkgconfig file to -devel. xfce4-panel-4.4.1-2.fc8 ----------------------- * Wed Jun 06 2007 Kevin Fenzi - 4.4.1-2 - Fix multilib issues. Bug #228168 xine-lib-1.1.6-3.fc8 -------------------- * Wed Jun 06 2007 Rex Dieter - 1.1.6-3 - respin (for libmpcdec) xorg-x11-drv-i810-2.0.0-4.fc8 ----------------------------- * Wed Jun 06 2007 Adam Jackson 2.0.0-4 - Update to git master. Many Xv and DVO fixes. Adds support for 945GME, 965GME, G33, Q33, and Q35 chips. xorg-x11-drv-nv-2.0.96-3.fc8 ---------------------------- * Wed Jun 06 2007 Adam Jackson 2.0.96-3 - Backport of G80 LVDS (laptop) support from git master. xorg-x11-server-1.3.0.0-8.fc8 ----------------------------- * Wed Jun 06 2007 Adam Jackson 1.3.0.0-8 - xserver-1.3.0-ramdac-export.patch: Make sure the old ramdac symbols are exported, since they're in-server now. (#242800) From buytenh at wantstofly.org Thu Jun 7 11:03:54 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 13:03:54 +0200 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> Message-ID: <20070607110354.GC2079@xi.wantstofly.org> On Mon, Jun 04, 2007 at 01:10:55PM +0200, Linus Walleij wrote: > Hi Lennert, your contributions to ARM Linux have not gone unnoticed. > Nice to see you here! Thanks. :-) > >I'm posting here because I would really really like to get the relevant > >diffs merged back into Fedora. > > The diffs look nice so IMHO should simply be applied, just that you'll > probably have to open BZ entries for each and every one of them and push > each individual maintainer to just do it... ACK, I'll do that (after making sure the patches rebased to F8 actually result in working packages.) > A bit off-topic questions: > > 1. What is the target system(s) you're using? I for one have a very > vague understanding of what lab boards etc may be used for running > ARM Fedora. I have a lot of different boards (I probably have ~30 ARM boards by now, not counting my PCI RAID controllers :-), the main ones being: - iop.wantstofly.org: Intel IQ81342EX dev board. ATX form factor, dual-core 800MHz IOP342 CPU w/1M total L2 cache, DDR2, 1 PCI-E slot, 1 64b/133MHz PCI-X slot, dual on-board e1000. Silicon Image SATA controller on PCI card, SATA disk. - orion.wantstofly.org: ATX form factor, Marvell Orion2 dev board, 500MHz/600MHz Orion2 CPU, DDR2, on-chip GigE, 1 PCI-E slot, 3 64b/133MHz PCI-X slots. SATA controller on PCI card, SATA disk. - n2100.wantstofly.org: Thecus n2100 NAS appliance, 600 MHz IOP80219 CPU, on-board dual GigE and SATA controllers, 2 SATA bays, 1 SATA disk. (Both IOP boards are supported in the upstream kernel w/o any patching needed, and for the Orion, patches have been submitted.) But the (userland) packages that we carry should run fine on any ARMv5-compliant CPU. > 2. As I understand it you employ the Fedora/x86 style of not using a > cross-compiler to build these packages, but rather build them with > ARM on ARM. Yes. > I am aware of some RPM derivatives like those used by MontaVista, > that employ a cross-compiler instead. What are your thought on > these issues? That's something we definitely want/plan to do, and hopefully in such a form that it makes sense to merge back into Fedora. Not yet in this stage, though -- IMHO it makes a lot more sense to get the base ARM support in Fedora right first than trying to cram in ARM support together with various intrusive changes to slim down packages and to make cross-compiling work. (Sure, a lot of ARM use cases can benefit from such changes, but they are still orthogonal efforts.) > Have you tested both solutions and come to the conclusion that > the all-ARM-enclosed build system is the way to go? For building the regular 'upstream' Fedora ARM package repositories, building natively makes the most sense now (as Fedora generally doesn't support cross-compiling yet) and it most likely will continue to make the most sense in the future, as there's some things that you simply can't do when cross-compiling (and there will always be packages that do not lend themselves to cross-compiling), and we'd like the main package repo to stay as close to Fedora as possible. When you start doing board-specific customisations, being able to cross-compile some designated subset of Fedora packages makes a ton of sense to me, and as I said, that's definitely something where we'd like to go, but not yet in this stage, and it's possible that this will never be non-intrusive enough and make enough sense for general use to be merged back into Fedora -- but we'll see. From andy at warmcat.com Thu Jun 7 11:12:43 2007 From: andy at warmcat.com (Andy Green) Date: Thu, 07 Jun 2007 12:12:43 +0100 Subject: fedora for ARM In-Reply-To: <20070607110354.GC2079@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <20070607110354.GC2079@xi.wantstofly.org> Message-ID: <4667E82B.3010503@warmcat.com> Lennert Buytenhek wrote: Hi Lennert - > When you start doing board-specific customisations, being able to > cross-compile some designated subset of Fedora packages makes a ton > of sense to me, and as I said, that's definitely something where > we'd like to go, but not yet in this stage, and it's possible that > this will never be non-intrusive enough and make enough sense for > general use to be merged back into Fedora -- but we'll see. Don't forget Fedora itself can gain advantages from just being able to cross-compile between the arches it already supports, including now ARM, spreading the benefit around more than just for the ARM/embedded case. This koji thing seems to be a cenralized build farm workaround for not being able to cross compile already for example... -Andy From buytenh at wantstofly.org Thu Jun 7 11:23:29 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 13:23:29 +0200 Subject: fedora for ARM In-Reply-To: <20070604154744.543b041d.zaitcev@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070604154744.543b041d.zaitcev@redhat.com> Message-ID: <20070607112329.GG2079@xi.wantstofly.org> On Mon, Jun 04, 2007 at 03:47:44PM -0700, Pete Zaitcev wrote: > > 1. What is the target system(s) you're using? I for one have a > > very vague understanding of what lab boards etc may be used > > for running ARM Fedora. > > This was my question too. I attended a talk by Deepak Saxena a month > ago and it looked like there's no clear leader anymore, like Netwinder > used to be. What are these RPMs for? OpenMoko? Palm? The *.armv5tel.rpm RPMs in the repo were built with -march=armv5te, and so they will run on any CPU compliant to at least the ARMv5TE level. This includes every XScale CPU ever made (i.e. PXA25x/PXA27x/PXA3xx/ IXP4xx/IXP2xxx/IOP3xx), the TI omap, and most currently shipping ARM CPUs. The armv5te packages won't run on ARMv4 systems such as the Netwinder, but there's no real reason why you wouldn't be able to build an armv4t package set. I don't think there would be a lot of demand for that, though. > Are these systems even binary compatible in the user mode? Yep, the various ARM architecture generations are upwards compatible in user mode. From jkeating at redhat.com Thu Jun 7 11:23:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 07:23:04 -0400 Subject: Future SCM Technology In-Reply-To: <20070607101214.GB18982@ryvius.pekin.waw.pl> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <20070607101214.GB18982@ryvius.pekin.waw.pl> Message-ID: <200706070723.04824.jkeating@redhat.com> On Thursday 07 June 2007 06:12:14 Dominik 'Rathann' Mierzejewski wrote: > I, for one, would welcome something similar to svn cp and svn mv, > which allows you to copy and rename files (I'm thinking patches) > while preserving change history. Could we better frame this as "I wish our SCM would allow for renaming and/or copying source controlled files to new names, while preserving the recorded history of the file within the SCM." ? (I just don't want to see a lot of requests be tied to a particular SCM or another, just pure features. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From simon.andrews at bbsrc.ac.uk Thu Jun 7 11:21:36 2007 From: simon.andrews at bbsrc.ac.uk (Simon Andrews) Date: Thu, 07 Jun 2007 12:21:36 +0100 Subject: Fedora 7 Anaconda feedback In-Reply-To: <4667A0F1.9090802@gmail.com> References: <1181168566.9635.34.camel@dimi.lattica.com> <46673488.2070701@cora.nwra.com> <4667A0F1.9090802@gmail.com> Message-ID: dragoran wrote: > Orion Poplawski wrote: >> Dimi Paun wrote: >>> * after upgrade, the new system failed to boot -- the horror! >>> It was simple to fix, the default grub entry was still >>> pointed to the old kernel image that got nuked, so I had >>> to manually pick the other, newer image, and then edit >>> /etc/grub.conf by hand. Never experienced this before. >> >> I've seen this too on the one upgrade I've done so far. >> >> > I have done two and have not seen this. > bugreport? Already there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242047 From buytenh at wantstofly.org Thu Jun 7 11:40:28 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 13:40:28 +0200 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> Message-ID: <20070607114028.GH2079@xi.wantstofly.org> On Wed, Jun 06, 2007 at 02:28:25PM -0700, Ed Swierk wrote: > > There is something to be said for target emulation or > > run-parts-of-the-build-on-hardware solutions, but I think the > > best answer is one where any available host can compile Fedora > > for any target. > > Isn't that exactly what we'd get with target emulation? Any available > host that can run an emulator could then build all of fedora Fedora > for ARM or PowerPC or whatever. I think that something like qemu-system-arm is probably one of the very few ways of speeding up package builds while still being able to guarantee that the result is 100% identical. (Although my fastest ARM boxes are probably faster than doing it via qemu.) For the Debian armeb port, what we did for a while is to run all package builds natively, but to have the actual compiling be done on a fast x86 box, by making the ARM board use distcc, and having the x86 box run distccd with an ARM cross-compiler. I don't think this generates 100% identical binary code, but it should still be functionally equivalent. > Supporting cross-compiling would be great, but having spent a several > weeks fighting with Python and its libraries last year and losing, I > suspect scouring the other nine zillion Fedora packages for > cross-correctness is no small exercise, not to mention battling new > bugs as they crop up. I would fully agree with the sentiment that cross-compiling the entire distro as _the_ standard way of maintaining the arch package repository is not a realistic scenario and will likely never be. Preferably, I would like to just keep doing this entirely natively. It appears a lot less effort to maintain a set of patches to make some limited subset of packages (say, 300 packages) cross-compilable, though. In some cases, we'll have to do this anyway. > That said, there is certainly room for both approaches, and getting > even a small number of packages to cross-compile might be enough for > many embedded applications. ACK. From buytenh at wantstofly.org Thu Jun 7 11:50:09 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 13:50:09 +0200 Subject: fedora for ARM In-Reply-To: <4667E82B.3010503@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070607110354.GC2079@xi.wantstofly.org> <4667E82B.3010503@warmcat.com> Message-ID: <20070607115009.GI2079@xi.wantstofly.org> On Thu, Jun 07, 2007 at 12:12:43PM +0100, Andy Green wrote: > Hi Lennert - Andy, > > When you start doing board-specific customisations, being able to > > cross-compile some designated subset of Fedora packages makes a ton > > of sense to me, and as I said, that's definitely something where > > we'd like to go, but not yet in this stage, and it's possible that > > this will never be non-intrusive enough and make enough sense for > > general use to be merged back into Fedora -- but we'll see. > > Don't forget Fedora itself can gain advantages from just being able > to cross-compile between the arches it already supports, including > now ARM, spreading the benefit around more than just for the ARM/ > embedded case. This koji thing seems to be a cenralized build farm > workaround for not being able to cross compile already for example... I am not forgetting that, all I said was that I just don't think we should pile every change to Fedora that could ever be useful on embedded targets together into one patch repository and then present that as a fait accomplis 'Fedora ARM patch set'. When the ARM dust settles and people start spending effort on trying to make Fedora more cross-friendly, I'll certainly be contributing to that effort, but as I said, there's still a possibility that it turns out that this is not realistically doable without making life hard for everyone else, in which case part(s) of that effort might have to be maintained externally. "We'll see." From triad at df.lth.se Thu Jun 7 12:02:37 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 7 Jun 2007 14:02:37 +0200 (CEST) Subject: fedora for ARM In-Reply-To: <46667630.3040303@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> <46667630.3040303@warmcat.com> Message-ID: On Wed, 6 Jun 2007, Andy Green wrote: >> And what is being produced? An *.i386.rpm or an *.arm.rpm? > > ... > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /projects/octotux/packages/rpm/BUILD/mISDNuser-arm-root > Wrote: /projects/octotux/packages/rpm/SRPMS/mISDNuser-1.2.0-163.src.rpm > Wrote: /projects/octotux/packages/rpm/RPMS/arm/mISDNuser-1.2.0-163.arm.rpm .arm.rpm? If we have i386, i686 etc, shouldn't it rather be .armv5.rpm, .armv6.rpm etc, or actually your current -march flag like in my current -march=armv5te? .arm.rpm would be OK once the ARM EABI is employed in latter GCC versions I guess, or? Linus From andy at warmcat.com Thu Jun 7 12:13:29 2007 From: andy at warmcat.com (Andy Green) Date: Thu, 07 Jun 2007 13:13:29 +0100 Subject: fedora for ARM In-Reply-To: <20070607115009.GI2079@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <20070607110354.GC2079@xi.wantstofly.org> <4667E82B.3010503@warmcat.com> <20070607115009.GI2079@xi.wantstofly.org> Message-ID: <4667F669.3000304@warmcat.com> Lennert Buytenhek wrote: > I am not forgetting that, all I said was that I just don't think we > should pile every change to Fedora that could ever be useful on > embedded targets together into one patch repository and then present > that as a fait accomplis 'Fedora ARM patch set'. Well, clearly that wouldn't be a Fedora ARM patch set any more, so fair enough. I agree your patches are a separate issue, it's another arch support added for native compile same as say s390 and that is fine. This all came up on the same thread but talking about building cross isn't saying anything about your patches at all or trying to tie them to the issue of cross compiling. Fedora targeting OLPC and now ARM though, the spread of system capability being aimed at is clearly increasing over time, not decreasing. That does make more reasons to look not only at cross but at more than One True Configuration for some core packages that are in themselves quite configurable at compile time. -Andy From andy at warmcat.com Thu Jun 7 12:16:19 2007 From: andy at warmcat.com (Andy Green) Date: Thu, 07 Jun 2007 13:16:19 +0100 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> <46667630.3040303@warmcat.com> Message-ID: <4667F713.8040607@warmcat.com> Linus Walleij wrote: > If we have i386, i686 etc, shouldn't it rather be .armv5.rpm, .armv6.rpm > etc, or actually your current -march flag like in my current > -march=armv5te? > > .arm.rpm would be OK once the ARM EABI is employed in latter GCC > versions I guess, or? No you're right. It ultimately comes from my cross toolchain having names like arm-linux-gcc, I am sure any Fedora implementation would make a smarter choice as you suggest. -Andy From dominik at greysector.net Thu Jun 7 12:40:07 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 7 Jun 2007 14:40:07 +0200 Subject: Future SCM Technology In-Reply-To: <200706070723.04824.jkeating@redhat.com> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <20070607101214.GB18982@ryvius.pekin.waw.pl> <200706070723.04824.jkeating@redhat.com> Message-ID: <20070607124007.GE18982@ryvius.pekin.waw.pl> On Thursday, 07 June 2007 at 13:23, Jesse Keating wrote: > On Thursday 07 June 2007 06:12:14 Dominik 'Rathann' Mierzejewski wrote: > > I, for one, would welcome something similar to svn cp and svn mv, > > which allows you to copy and rename files (I'm thinking patches) > > while preserving change history. > > Could we better frame this as "I wish our SCM would allow for renaming and/or > copying source controlled files to new names, while preserving the recorded > history of the file within the SCM." ? (I just don't want to see a lot of > requests be tied to a particular SCM or another, just pure features. Sounds fine, thanks. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mlichvar at redhat.com Thu Jun 7 13:08:55 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 7 Jun 2007 15:08:55 +0200 Subject: Splitting the ncurses RPM In-Reply-To: <1181153225.28779.72.camel@localhost> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <1181153225.28779.72.camel@localhost> Message-ID: <20070607130855.GA13063@localhost> On Wed, Jun 06, 2007 at 02:07:05PM -0400, Jim Gettys wrote: > On Wed, 2007-06-06 at 17:13 +0200, Miroslav Lichvar wrote: > > In /lib/terminfo should be only a minimal set that might be required > > when doing system administration with /usr unmounted. Wondering how > > xterm got there. > > yes, sometimes you bring up a system to single user, mount /usr, and > run xinit to get yourself some windowing while you mess with the > machine. Having xterm there makes perfect sense. If /usr is mounted, xterm entry can be in /usr/share/terminfo. Or can Xserver work without /usr/share? -- Miroslav Lichvar From denis at poolshark.org Thu Jun 7 13:09:09 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 07 Jun 2007 15:09:09 +0200 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <20070607063239.GA2848@free.fr> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> <20070607063239.GA2848@free.fr> Message-ID: <46680375.8090306@poolshark.org> Patrice Dumas wrote: > On Wed, Jun 06, 2007 at 08:41:26AM -0500, Chris Adams wrote: >> You should probably test that before you post. I would say this is the >> smallest possible regular C program: >> >> $ cat x.c >> int main () >> { >> return 0; >> } >> $ gcc -o x-dyn x.c >> $ gcc -static -o x-stat x.c >> $ strip x-dyn x-stat >> $ ls -l x-dyn x-stat >> -rwxr-xr-x 1 cmadams users 2816 Jun 6 08:38 x-dyn >> -rwxr-xr-x 1 cmadams users 459492 Jun 6 08:38 x-stat >> $ >> >> I don't forsee a static executable being smaller than a dynamic >> executable in the real world. It is possible that somebody could >> hand-build (e.g. no gcc, ld, etc.) such an executable, but that doesn't >> really count (since that isn't done in the real world). > > given that the dynamic executable is 2816 bytes, the static one could be > smaller, however it is way bigger. In fact it seems to me (but I don't > rerally know a lot about those things, I was only saying something I saw > elsewhere) that it is way too bigger for that difference to be explained by > static linking, there is something else happening there. I believe the granularity of the linker is a single object file. So even if you use just a small routine within a big object file, the whole thing is linked with (if you think about how ld works internally and what it has to do, it makes sense). From mlichvar at redhat.com Thu Jun 7 13:10:16 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 7 Jun 2007 15:10:16 +0200 Subject: Splitting the ncurses RPM In-Reply-To: <4666F847.7090201@codewiz.org> References: <466385F1.8030005@codewiz.org> <20070604120659.GA1483@localhost> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <4666F847.7090201@codewiz.org> Message-ID: <20070607131016.GA12923@localhost> On Wed, Jun 06, 2007 at 02:09:11PM -0400, Bernardo Innocenti wrote: > Miroslav Lichvar wrote: > > >This list is far too short, xterm-256color, gnome, teraterm, jfbterm, > >mrxvt and others should be included. I guess it will be pretty hard to > >select from descriptions so the extra terminfo package won't have to > >be installed by default. > > You're right, but what is "gnome"? gnome-terminal uses "xterm", afaik. In Fedora yes, but other distributions may have different setting. > >Any ideas? > > Couldn't you make the list short and include new terminals by request? > So if nobody requests to ask for "jfbterm", it doesn't get in. > > Something tells me they won't bother you very often :-) Could be, if all descriptions are installed by default. I just don't want to have a situation where users have error messages about unknown terminals and have to install a package they never heard of (or ask admin of a remote machine). -- Miroslav Lichvar From mlichvar at redhat.com Thu Jun 7 13:10:52 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 7 Jun 2007 15:10:52 +0200 Subject: Splitting the ncurses RPM In-Reply-To: <20070606182457.GG5700@nostromo.devel.redhat.com> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <20070606182457.GG5700@nostromo.devel.redhat.com> Message-ID: <20070607131052.GA13291@localhost> On Wed, Jun 06, 2007 at 02:24:57PM -0400, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > Ok. Maybe I'd use a bit different naming instead: > > > > ncurses-bin: bin/* > > ncurses-base: lib*.so.* /etc/terminfo /lib/terminfo, some of /usr/share/terminfo > > ncurses-terminfo: rest of /usr/share/terminfo > > ncurses: requires: -bin -base -terminfo > > > > How does this sound? > > For sanity's sake on upgrades, leaving the libraries in the same > package name (multilib) would be best. I'm confused, do you want to keep the libraries in ncurses package? -- Miroslav Lichvar From buytenh at wantstofly.org Thu Jun 7 13:27:26 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 15:27:26 +0200 Subject: fedora for ARM In-Reply-To: References: <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> <46667630.3040303@warmcat.com> Message-ID: <20070607132726.GR2079@xi.wantstofly.org> On Thu, Jun 07, 2007 at 02:02:37PM +0200, Linus Walleij wrote: > >>And what is being produced? An *.i386.rpm or an *.arm.rpm? > > > >... > >Checking for unpackaged file(s): /usr/lib/rpm/check-files > >/projects/octotux/packages/rpm/BUILD/mISDNuser-arm-root > >Wrote: /projects/octotux/packages/rpm/SRPMS/mISDNuser-1.2.0-163.src.rpm > >Wrote: /projects/octotux/packages/rpm/RPMS/arm/mISDNuser-1.2.0-163.arm.rpm > > .arm.rpm? > > If we have i386, i686 etc, shouldn't it rather be .armv5.rpm, .armv6.rpm > etc, or actually your current -march flag like in my current > -march=armv5te? Our repo uses -march=armv5te, and the packages are *.armv5tel.rpm ('l' for little endian.) Using the mach name is the default, and seemed like the most straightforward option (it's also what most people have been doing for a while with rpm.) While this works fine for different ARM arch levels, the only case where this breaks down is for VFP and iWMMXt and such, since they are optional and not a property of the arch level, so another solution needs to be found for those. From sberry at northlc.com Thu Jun 7 14:02:13 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 09:02:13 -0500 Subject: an introduction and a question In-Reply-To: <980545.12488.qm@web55306.mail.re4.yahoo.com> References: <980545.12488.qm@web55306.mail.re4.yahoo.com> Message-ID: <012e01c7a90c$773433c0$6701a8c0@yellobow> _____ From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Ankit Patel Sent: Thursday, June 07, 2007 12:34 AM To: Development discussions related to Fedora Core Subject: Re: an introduction and a question Hi Scott, Please go through the link: http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s02.html Btw, your tarball is missing spec file i think. ----- Original Message ---- From: Scott Berry To: fedora-devel-list at redhat.com Sent: Thursday, June 7, 2007 8:36:53 AM Subject: an introduction and a question Hello, My name is Scott Berry. I am located in the United States in Minnesota up toward the Canadian border. I am totally blind and found a program covered under the BSD license that I would like to get packaged for Fedora. The name of the program is Webmin. I have spoken to the author and he has okayed for me to do this. I have a question though. Actually a few of them. I am brand new to packaging so these may sound kind of silly. 1. I tried creating an rpm of Webmin from the newest sources at www.webmin.com. 2. I have the program on my server and I did the following command with errors: "Rpmbuild -ts webmin-1.350.tar.gz" and I got the following errors: error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: Group field must be present in package: (main package) error: License field must be present in package: (main package) 3. What is the spec file and do I need to build this myself or how is it built and where should it be put? Again I apologize if these sound like simple questions but I would like to give back what I have been freely given by Fedora. Scott -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list _____ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sberry at northlc.com Thu Jun 7 13:58:13 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 08:58:13 -0500 Subject: an introduction and a question In-Reply-To: <16de708d0706062238j640aade9if7747c4c72123885@mail.gmail.com> References: <000001c7a8b0$ebbcfc10$6701a8c0@yellobow> <16de708d0706062238j640aade9if7747c4c72123885@mail.gmail.com> Message-ID: <012a01c7a90b$e7a40910$6701a8c0@yellobow> Well I do a lot of ssh connections here and find that Fedora works well. Now actually using Orca and Speakup I haven't done much with that just because I like the ssh method much better. I ssh through a Windows box using Jaws for Windows which is my screen reader of choice for Windows. Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Arthur Pemberton Sent: Thursday, June 07, 2007 12:39 AM To: Development discussions related to Fedora Core Subject: Re: an introduction and a question On 6/6/07, Scott Berry wrote: > Hello, > > My name is Scott Berry. I am located in the United States in Minnesota up > toward the Canadian border. I am totally blind and [ snip ] Assuming that "I am totally blind" keeps it's standard meaning, and isn't a turn of phrase, I am curious as to how accessible you're finding Fedora. -- Fedora Core 6 and proud -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/836 - Release Date: 6/6/2007 1:10 PM From laxathom at fedoraproject.org Thu Jun 7 14:38:33 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 7 Jun 2007 10:38:33 -0400 Subject: Fedora 8 ideas In-Reply-To: References: Message-ID: <62bc09df0706070738k58f14ce2x37f253695e04c22a@mail.gmail.com> 2007/6/7, Goede, J.W.R. de : > > Hi all, > > Here are some (unsorted) ideas for cool(?) new things todo > for F8, warning braindump, waring. > > 1 Package nvu > ============= > > The title pretty much sums it up, package nvu a popular > opensource web-editor. Anyone know why this hasn't been > done yet? > > 2 Firmware buddy > ================ > > Here is what I would like to see (and would be willing to > write code for): > > 1) A firmware load request is send to userspace > 2) When the userspace firmware helper cannot find this > firmware, it logs this to a missing-firmware file. > 3) When the user logs in, a firmware-helper-applet runs > 4) If there is missing firmware and a working internet > connection, the applet becomes active, otherwise it > exits > 5) The applet looksup the firmware name in a table which > matches it to a device-identifier. > 6) The applet looksup manufacturers + productnames (as seen > > on the box/outside) of device-identifier devices. > 7) The applet shows a gui to the user explaining that > firmware is needed for his XXXXX (ex. wireless card) to > work, and asks him to select the manufacturer and > product > of his XXXXX. > 8) The applet downloads the windows-driver from the > manufacturers websites and runs a special (per driver) > shell script to extract the firmware > 9) The user is told to reboot (or do something else to > get the device re-initialised). I'm actually working on an gtk UI that able to do the samething for all uninstalled hardware. But i don't think it can be added to F8 or higher as its requires to install extras repository (such as livna, Freshrpms, ...) My first approach was to provide an gtk wizard that assist the end-user. If you interessting about my work feel free to contact me. 3 plugin buddy > ============== > > Like codec buddy, but then for firefox plugins. Why? > because firefox plugin find service doesn't undserstand to > install nspluginwrapper (needs to get into Fedora) and then > flash on x86_64. Nor knows it to change the selinux type of > realplayer to get it to work with our default enabled > selinux policy. > > 4 internet access keys made easy > ================================ > > The title pretty much sums it up, add some gui-helper for > people to make it easy to configure there internet access > keys on ps2 keyboards (usb should get handled 100% > automatically). Use dmi info on laptops to identify and > automatically enable there internet access keys. > > Things todo here: > -there is a weird kernel behaviour with similated > scancodes, > (which is enbaled by default) which confuses X with > regards > to these keys. If simulated scancodes are disabled, then > selecting the proper keyboard in preferences->hardware- > >keyboard, gets X to recognise the keys and send special > XF86 ext syms for them. > -metacity can define keyboard shurtcuts for actions like > mail, www, home, search, etc. But does not bind these to > the special XF86 keysysms for these by default (easy fix) > -for the laptop case automatically configure the correct > keyblayout using dmi-info > -check that usb works automatically, and if not fix it. > > 5 proprietary software install helper > ===================================== > > Yes you read it correctly, I'm suggesting the inclusion of > a "proprietary software install helper" which gives users a > gui which will help them to install popular and free as in > beer software. > > Many of my collegues who I try to convert to Linux have > been complaining about the pain to get for example vmware > to run, this is when I first came up with this idea, to > pretty much discard it the next day. > > Then today I read this article: > http://www.howtoforge.com/the_perfect_desktop_fedora7 > (which contains many badness) and I noticed again a lott > of workarounds/hacks to get proprietary software to run. > > Lets face it quite a few of our users (and quite a few of > us too I guess) want to atleast try out some proprietary > software, and installing that on a quick developing > cutting edge distro like Fedora is a pain. > > Problems with selinux are only one part of this. If we want > users to stop disabling selinux, an helper program which > fixes selinux types for these will hopefully lead to less > users disabling selinux. > > So do we want this? on one hand we do not endorse / promote > proprietary software. OTOH some (many?) of our users use or > atleast want to try one or 2 proprietary programs. I think > in the name of userfriendlyness, that it is a good idea to > make this easier for them. > > Suggestion: if this is done make the program start witha > dialog that we do not endorse this, bla bla bla. When a > propietary app gets selected, first popup a dialog > advocating free alternatives (qemu for vmware, evince for > acroread, etc.) with an install + launch button for the > free alternative. > > Regards, > > Hans > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Thu Jun 7 14:48:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 10:48:39 -0400 Subject: Splitting the ncurses RPM In-Reply-To: <20070607131052.GA13291@localhost> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <20070606182457.GG5700@nostromo.devel.redhat.com> <20070607131052.GA13291@localhost> Message-ID: <20070607144839.GA25221@nostromo.devel.redhat.com> Miroslav Lichvar (mlichvar at redhat.com) said: > > For sanity's sake on upgrades, leaving the libraries in the same > > package name (multilib) would be best. > > I'm confused, do you want to keep the libraries in ncurses package? (This has nothing to to with OLPC, and everything to do with the distro) If the libraries move to a different package, we end up with ncurses-devel/ ncurses-libs being multilib, instead of ncurses-devel/ncurses as we have currently. This causes problems for upgrades with getting a no-longer-multilib ncurses package off the system for the secondary arch. So, if possible, keeping the libraries in the 'same' package as it was previously is preferred. Bill From notting at redhat.com Thu Jun 7 14:57:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 10:57:03 -0400 Subject: Unwanted RPM dependencies In-Reply-To: References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> Message-ID: <20070607145703.GB25221@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > > We have something of a mandate to keep all the trademarked content in one > > package, fedora-logos. > > What about a fedora-logos-grub subpackage? It's easy to identify where it comes > from, and derivative distros will need to patch fedora-logos at SRPM level > anyway, so there's practically no chance they'd miss the subpackage (which > would be built from the same SRPM). fedora-logos is mentioned by name in the EULA. I'd prefer to keep it simple (especially if we're deprecating the theming of grub) Bill From notting at redhat.com Thu Jun 7 15:06:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 11:06:20 -0400 Subject: Fedora 8 ideas In-Reply-To: References: Message-ID: <20070607150620.GC25221@nostromo.devel.redhat.com> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: > 2 Firmware buddy > ================ > > Here is what I would like to see (and would be willing to > write code for): > > 1) A firmware load request is send to userspace > 2) When the userspace firmware helper cannot find this > firmware, it logs this to a missing-firmware file. > 3) When the user logs in, a firmware-helper-applet runs > 4) If there is missing firmware and a working internet > connection, the applet becomes active, otherwise it > exits > 5) The applet looksup the firmware name in a table which > matches it to a device-identifier. > 6) The applet looksup manufacturers + productnames (as seen > > on the box/outside) of device-identifier devices. > 7) The applet shows a gui to the user explaining that > firmware is needed for his XXXXX (ex. wireless card) to > work, and asks him to select the manufacturer and > product > of his XXXXX. > 8) The applet downloads the windows-driver from the > manufacturers websites and runs a special (per driver) > shell script to extract the firmware > 9) The user is told to reboot (or do something else to > get the device re-initialised). What cards is this useful for that we don't ship firmware for? Anything other than bcm43xx and ralink? > 3 plugin buddy > ============== > > Like codec buddy, but then for firefox plugins. Why? > because firefox plugin find service doesn't undserstand to > install nspluginwrapper (needs to get into Fedora) and then > flash on x86_64. Nor knows it to change the selinux type of > realplayer to get it to work with our default enabled > selinux policy. So, *if* we install nspluginwrapper by default, does firefox then do the right thing? > 5 proprietary software install helper > ===================================== > > Yes you read it correctly, I'm suggesting the inclusion of > a "proprietary software install helper" which gives users a > gui which will help them to install popular and free as in > beer software. > > Many of my collegues who I try to convert to Linux have > been complaining about the pain to get for example vmware > to run, this is when I first came up with this idea, to > pretty much discard it the next day. > > Then today I read this article: > http://www.howtoforge.com/the_perfect_desktop_fedora7 > (which contains many badness) and I noticed again a lott > of workarounds/hacks to get proprietary software to run. > > Lets face it quite a few of our users (and quite a few of > us too I guess) want to atleast try out some proprietary > software, and installing that on a quick developing > cutting edge distro like Fedora is a pain. > > Problems with selinux are only one part of this. If we want > users to stop disabling selinux, an helper program which > fixes selinux types for these will hopefully lead to less > users disabling selinux. > > So do we want this? on one hand we do not endorse / promote > proprietary software. OTOH some (many?) of our users use or > atleast want to try one or 2 proprietary programs. I think > in the name of userfriendlyness, that it is a good idea to > make this easier for them. > > Suggestion: if this is done make the program start witha > dialog that we do not endorse this, bla bla bla. When a > propietary app gets selected, first popup a dialog > advocating free alternatives (qemu for vmware, evince for > acroread, etc.) with an install + launch button for the > free alternative. I'm not really thrilled about working on this because of a) the insinuation, at least, of moderate endorsement b) the fact that it seems it would be going down a rathole of chasing-the-fixes-for-each-new-package. Bill From sberry at northlc.com Thu Jun 7 15:18:49 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 10:18:49 -0500 Subject: another question about spec files for Webmin Message-ID: <003301c7a917$2aae33b0$6701a8c0@yellobow> Hello there, I have another question about the spec files for Webmin. I need to know which group Webmin would fit in. I looked through "/usr/share/doc/rpm-4.42/groups" and the best fit I can find it this: Applications/Text [Scott] Is this correct since this is a web application? Also what do I do about the icon for this do I forgo the icon for now and put that in later? Scott From j.w.r.degoede at hhs.nl Thu Jun 7 15:15:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 07 Jun 2007 17:15:24 +0200 Subject: Fedora 8 ideas In-Reply-To: <20070607150620.GC25221@nostromo.devel.redhat.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> Message-ID: <4668210C.50808@hhs.nl> Bill Nottingham wrote: > Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: >> 2 Firmware buddy >> ================ >> >> Here is what I would like to see (and would be willing to >> write code for): >> >> 1) A firmware load request is send to userspace >> 2) When the userspace firmware helper cannot find this >> firmware, it logs this to a missing-firmware file. >> 3) When the user logs in, a firmware-helper-applet runs >> 4) If there is missing firmware and a working internet >> connection, the applet becomes active, otherwise it >> exits >> 5) The applet looksup the firmware name in a table which >> matches it to a device-identifier. >> 6) The applet looksup manufacturers + productnames (as seen >> >> on the box/outside) of device-identifier devices. >> 7) The applet shows a gui to the user explaining that >> firmware is needed for his XXXXX (ex. wireless card) to >> work, and asks him to select the manufacturer and >> product >> of his XXXXX. >> 8) The applet downloads the windows-driver from the >> manufacturers websites and runs a special (per driver) >> shell script to extract the firmware >> 9) The user is told to reboot (or do something else to >> get the device re-initialised). > > What cards is this useful for that we don't ship firmware > for? Anything other than bcm43xx and ralink? > I originally came to this idea after going through some pain to get my SIL card (prism 2 softmac, driver prism_pci) to work. So add prism cards to that, notice that I bought that card very recently, so those are still in the stores. Also aren't there many many ralink + bcm cards, you make it sound like those are rare. >> 3 plugin buddy >> ============== >> >> Like codec buddy, but then for firefox plugins. Why? >> because firefox plugin find service doesn't undserstand to >> install nspluginwrapper (needs to get into Fedora) and then >> flash on x86_64. Nor knows it to change the selinux type of >> realplayer to get it to work with our default enabled >> selinux policy. > > > > So, *if* we install nspluginwrapper by default, does firefox > then do the right thing? > Nope, I tried that. >> 5 proprietary software install helper >> ===================================== >> >> Yes you read it correctly, I'm suggesting the inclusion of >> a "proprietary software install helper" which gives users a >> gui which will help them to install popular and free as in >> beer software. >> >> Many of my collegues who I try to convert to Linux have >> been complaining about the pain to get for example vmware >> to run, this is when I first came up with this idea, to >> pretty much discard it the next day. >> >> Then today I read this article: >> http://www.howtoforge.com/the_perfect_desktop_fedora7 >> (which contains many badness) and I noticed again a lott >> of workarounds/hacks to get proprietary software to run. >> >> Lets face it quite a few of our users (and quite a few of >> us too I guess) want to atleast try out some proprietary >> software, and installing that on a quick developing >> cutting edge distro like Fedora is a pain. >> >> Problems with selinux are only one part of this. If we want >> users to stop disabling selinux, an helper program which >> fixes selinux types for these will hopefully lead to less >> users disabling selinux. >> >> So do we want this? on one hand we do not endorse / promote >> proprietary software. OTOH some (many?) of our users use or >> atleast want to try one or 2 proprietary programs. I think >> in the name of userfriendlyness, that it is a good idea to >> make this easier for them. >> >> Suggestion: if this is done make the program start witha >> dialog that we do not endorse this, bla bla bla. When a >> propietary app gets selected, first popup a dialog >> advocating free alternatives (qemu for vmware, evince for >> acroread, etc.) with an install + launch button for the >> free alternative. > > I'm not really thrilled about working on this because > of a) the insinuation, at least, of moderate endorsement > b) the fact that it seems it would be going down a rathole > of chasing-the-fixes-for-each-new-package. > I'm not asking anyone to be thrilled about working on this, what I'm asking is do others agree this might have (some) added value for Fedora, and more in general would such a beast be acceptable? Regards, Hans From Lam at Lam.pl Thu Jun 7 15:26:46 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 07 Jun 2007 17:26:46 +0200 Subject: Fedora 8 ideas In-Reply-To: <20070607150620.GC25221@nostromo.devel.redhat.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> Message-ID: <1181230006.9479.2.camel@pensja.lam.pl> Dnia 07-06-2007, czw o godzinie 11:06 -0400, Bill Nottingham napisa?(a): > What cards is this useful for that we don't ship firmware > for? Anything other than bcm43xx and ralink? For example, there are millions of potential speedtch.ko users here in Europe. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From mlichvar at redhat.com Thu Jun 7 15:27:17 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 7 Jun 2007 17:27:17 +0200 Subject: Splitting the ncurses RPM In-Reply-To: <20070607144839.GA25221@nostromo.devel.redhat.com> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <20070606182457.GG5700@nostromo.devel.redhat.com> <20070607131052.GA13291@localhost> <20070607144839.GA25221@nostromo.devel.redhat.com> Message-ID: <20070607152717.GA30027@localhost> On Thu, Jun 07, 2007 at 10:48:39AM -0400, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > > For sanity's sake on upgrades, leaving the libraries in the same > > > package name (multilib) would be best. > > > > I'm confused, do you want to keep the libraries in ncurses package? > > (This has nothing to to with OLPC, and everything to do with the distro) > > If the libraries move to a different package, we end up with ncurses-devel/ > ncurses-libs being multilib, instead of ncurses-devel/ncurses as we have > currently. This causes problems for upgrades with getting a no-longer-multilib > ncurses package off the system for the secondary arch. So, if possible, > keeping the libraries in the 'same' package as it was previously is preferred. Ok, that makes sense. Unfortunately I don't see other way how to create a subpackage that will be installed in upgrade and have dependencies that would allow removing the subpackage. -- Miroslav Lichvar From katzj at redhat.com Thu Jun 7 15:22:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 07 Jun 2007 11:22:53 -0400 Subject: Fedora 8 ideas In-Reply-To: <4668210C.50808@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668210C.50808@hhs.nl> Message-ID: <1181229773.22860.1.camel@aglarond.local> On Thu, 2007-06-07 at 17:15 +0200, Hans de Goede wrote: > Bill Nottingham wrote: > > Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: > >> 2 Firmware buddy > >> ================ > > > > What cards is this useful for that we don't ship firmware > > for? Anything other than bcm43xx and ralink? > I originally came to this idea after going through some pain to get my SIL card > (prism 2 softmac, driver prism_pci) to work. So add prism cards to that, notice > that I bought that card very recently, so those are still in the stores. > > Also aren't there many many ralink + bcm cards, you make it sound like those > are rare. Oh, they're very common. But I'd rather spend some time trying to work with the vendors so we can ship the firmware and have it just work. Going to the network to get the firmware for your wireless card sucks because you first have to find a network cable :) Jeremy From jwilson at redhat.com Thu Jun 7 15:37:17 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 07 Jun 2007 11:37:17 -0400 Subject: Fedora 8 ideas In-Reply-To: <20070607150620.GC25221@nostromo.devel.redhat.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> Message-ID: <4668262D.4090602@redhat.com> Bill Nottingham wrote: > Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: >> 2 Firmware buddy >> ================ >> >> Here is what I would like to see (and would be willing to >> write code for): >> >> 1) A firmware load request is send to userspace >> 2) When the userspace firmware helper cannot find this >> firmware, it logs this to a missing-firmware file. >> 3) When the user logs in, a firmware-helper-applet runs >> 4) If there is missing firmware and a working internet >> connection, the applet becomes active, otherwise it >> exits >> 5) The applet looksup the firmware name in a table which >> matches it to a device-identifier. >> 6) The applet looksup manufacturers + productnames (as seen >> >> on the box/outside) of device-identifier devices. >> 7) The applet shows a gui to the user explaining that >> firmware is needed for his XXXXX (ex. wireless card) to >> work, and asks him to select the manufacturer and >> product >> of his XXXXX. >> 8) The applet downloads the windows-driver from the >> manufacturers websites and runs a special (per driver) >> shell script to extract the firmware >> 9) The user is told to reboot (or do something else to >> get the device re-initialised). > > What cards is this useful for that we don't ship firmware > for? Anything other than bcm43xx and ralink? A number of dvb and v4l devices also require firmware that we don't ship. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rjones at redhat.com Thu Jun 7 15:58:47 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 07 Jun 2007 16:58:47 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <464F2791.1060309@redhat.com> References: <464F2791.1060309@redhat.com> Message-ID: <46682B37.8070905@redhat.com> Richard W.M. Jones wrote: > I suspect it's unlikely that upstream will do (a), ever. There's a > technical issue. OCaml really doesn't have a concept of an ABI. It > does a kind of whole-program optimisation where even changes to the > internal implementation of a library can affect the resulting binary. > Moreover even if you "fixed" that, any change whatsoever to the > library's signature or the version of compiler it was built with (even > bugfix releases which have the same version number) will make the > library incompatible. > > You might also find this entertaining: > > http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c365d6671704.en.html I always like to be proven wrong ... An experimental dynamic linking of native code patch has just been added to OCaml CVS upstream. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jun 7 15:59:21 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 07 Jun 2007 11:59:21 -0400 Subject: Splitting the ncurses RPM In-Reply-To: <20070607144839.GA25221@nostromo.devel.redhat.com> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <20070606182457.GG5700@nostromo.devel.redhat.com> <20070607131052.GA13291@localhost> <20070607144839.GA25221@nostromo.devel.redhat.com> Message-ID: <1181231962.3749.63.camel@willson> On Thu, 2007-06-07 at 10:48 -0400, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > > For sanity's sake on upgrades, leaving the libraries in the same > > > package name (multilib) would be best. > > > > I'm confused, do you want to keep the libraries in ncurses package? > > (This has nothing to to with OLPC, and everything to do with the distro) > > If the libraries move to a different package, we end up with ncurses-devel/ > ncurses-libs being multilib, instead of ncurses-devel/ncurses as we have > currently. This causes problems for upgrades with getting a no-longer-multilib > ncurses package off the system for the secondary arch. So, if possible, > keeping the libraries in the 'same' package as it was previously is preferred. Bill, to be honest, I think deciding the package shape based on the broken way we are currently detecting multi-libs is a bad way to decide. We should fix the way we detect multi-libs, not produce substandard packaging to keep the current multi-libs detection process happy. IMO, Simo. From wwoods at redhat.com Thu Jun 7 16:00:30 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 07 Jun 2007 12:00:30 -0400 Subject: gtk2/gtk2-engines changed tooltip colors in F7 Message-ID: <1181232031.4586.29.camel@metroid.rdu.redhat.com> So, it appears that gtk2-2.10.12-2.fc7 or gtk2-engines-2.10.2-1.fc7 changes the default background color for tooltips. If you're running F7 updates-testing you've probably noticed that your tooltips are now gray instead of yellow. Check the upstream GNOME bug that caused this change: http://bugzilla.gnome.org/show_bug.cgi?id=412982 We should probably change the default theme to preserve the normal tooltip color until upstream sorts it out. Our default theme inherits from Clearlooks, so that's the theme we need to change. For some reason, while Clearlooks is included in the gnome-themes SRPM, it's removed during packaging - gtk2-engines is the package that actually provides Clearlooks. Confusing! Anyway - attached is a patch for gtk2-engines that preserves the old tooltip colors. Patch can be applied in the spec with -p1, or on your system with: cd /usr/share/themes sudo patch -p2 < ~/gtk-engines-2.10.2-keep-default-tooltip-color.patch Hope that helps. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: gtk-engines-2.10.2-keep-default-tooltip-color.patch Type: text/x-patch Size: 881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sberry at northlc.com Thu Jun 7 16:12:08 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 11:12:08 -0500 Subject: a look at my spec file for Webmin Message-ID: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> Can someone have a look at this spec file and tell me if I have everything correct? It looks correct to me pretty much but I think there are just a couple things missing. I will attach this as a file. Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: webmin-1.350.spec Type: application/octet-stream Size: 27261 bytes Desc: not available URL: From manuel at todo-linux.com Thu Jun 7 16:15:41 2007 From: manuel at todo-linux.com (Manuel Arostegui Ramirez) Date: Thu, 7 Jun 2007 18:15:41 +0200 Subject: a look at my spec file for Webmin In-Reply-To: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> Message-ID: <200706071815.41412.manuel@todo-linux.com> El Jueves, 7 de Junio de 2007 18:12, Scott Berry escribi?: > Can someone have a look at this spec file and tell me if I have everything > correct? It looks correct to me pretty much but I think there are just a > couple things missing. I will attach this as a file. > > Scott The thing is...that works for you? If you're looking for the correct way to write spec files why you don't follow guidelines? -- Manuel Arostegui Ramirez. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. From blc at redhat.com Thu Jun 7 16:20:36 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 07 Jun 2007 10:20:36 -0600 Subject: fedora for ARM In-Reply-To: <20070607132726.GR2079@xi.wantstofly.org> References: <4663FAEB.8070807@hhs.nl> <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> <46667630.3040303@warmcat.com> <20070607132726.GR2079@xi.wantstofly.org> Message-ID: <46683054.3050801@redhat.com> Lennert Buytenhek wrote: > While this works fine for different ARM arch levels, the only case > where this breaks down is for VFP and iWMMXt and such, since they are > optional and not a property of the arch level, so another solution > needs to be found for those. You can handle this, to an extent, with the target triplet- arm-linux-gnu is pretty generic, so it's better to have names like armv5l-linux-gnu (little endian) armv5b-linux-gnu (big endian), armv5l-softvfp-linux-gnu (little endian soft floating point). It can get pretty long. That said, I don't see anywhere in the near future that Fedora is going to support a multitude of arm variants. Big and Little endian with an implicit baseline (v5?) is probably enough distinction for a while to come. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From a.badger at gmail.com Thu Jun 7 16:21:35 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 09:21:35 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <1181152249.22157.44.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> Message-ID: <1181233295.4070.81.camel@localhost.localdomain> On Wed, 2007-06-06 at 13:50 -0400, Christopher Blizzard wrote: > o Do we want to move to a process where code is just in a repo and it's > built automatically instead of source + patches + spec file? I have a lot more to say on this topic but for now I'd like to just mention this Ubuntu page: https://wiki.ubuntu.com/NoMoreSourcePackages Debian and Ubuntu's build methodology is much worse (IMHO) than ours so their need for this is much greater than ours (but it seems that they're dropping the ball a bit... Ubuntu is working on something called the Hypothetical Changeset Tool, but I haven't been able to find any source for it and the developer hasn't replied to me yet.) The link has a complete process for something not quite at the same stage as you're proposing here (there'd still be a spec file and patches and delivery would still be via rpm... but the patches would be held in the VCS as changes against the vanilla upstream source). It's definitely good reading as it outlines a complete implementation of exploded trees that we can compare our schemes against :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Thu Jun 7 16:24:49 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Jun 2007 11:24:49 -0500 Subject: Splitting the ncurses RPM References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <20070606182457.GG5700@nostromo.devel.redhat.com> <20070607131052.GA13291@localhost> <20070607144839.GA25221@nostromo.devel.redhat.com> <1181231962.3749.63.camel@willson> Message-ID: Simo Sorce wrote: > I think deciding the package shape based on the broken way we are > currently detecting multi-libs is a bad way to decide. > > We should fix the way we detect multi-libs, not produce substandard > packaging to keep the current multi-libs detection process happy. True, to a degree, but until the the multilib issue is addressed (which may take some time), you need to make do the best you can. And "making do", for now, is following Bill's advice (and I'd argue Bill's suggestion is in no way substandard, with or without multilib considerations). -- Rex From buytenh at wantstofly.org Thu Jun 7 16:30:27 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 18:30:27 +0200 Subject: fedora for ARM In-Reply-To: <46683054.3050801@redhat.com> References: <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> <46667630.3040303@warmcat.com> <20070607132726.GR2079@xi.wantstofly.org> <46683054.3050801@redhat.com> Message-ID: <20070607163027.GT2079@xi.wantstofly.org> On Thu, Jun 07, 2007 at 10:20:36AM -0600, Brendan Conoboy wrote: > > While this works fine for different ARM arch levels, the only case > > where this breaks down is for VFP and iWMMXt and such, since they are > > optional and not a property of the arch level, so another solution > > needs to be found for those. > > You can handle this, to an extent, with the target triplet- > arm-linux-gnu is pretty generic, so it's better to have names like > armv5l-linux-gnu (little endian) armv5b-linux-gnu (big endian), > armv5l-softvfp-linux-gnu (little endian soft floating point). It can > get pretty long. Hmm. I was talking about what rpm arch name to use for packages compiled with VFP/iWMMXt (and noted that that decision was not entirely trivial because they are not encoded in the ARMvN arch spec level and so the default format does not convey enough info.) Are you suggesting to use the target triple as the rpm arch name? Isn't gcc-4.1.2-12.armv5l-softvfp-linux-gnueabi.rpm kind of long? (Note that our package repo uses eabi, where vfp byte/word order and softfloat are the default, so we don't encode those bits of info explicitly. The packages use 'armv5tel' as the rpm arch name.) > That said, I don't see anywhere in the near future > that Fedora is going to support a multitude of arm variants. Big and > Little endian with an implicit baseline (v5?) is probably enough > distinction for a while to come. Yes. From mclasen at redhat.com Thu Jun 7 16:26:45 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 07 Jun 2007 12:26:45 -0400 Subject: gtk2/gtk2-engines changed tooltip colors in F7 In-Reply-To: <1181232031.4586.29.camel@metroid.rdu.redhat.com> References: <1181232031.4586.29.camel@metroid.rdu.redhat.com> Message-ID: <1181233605.3533.3.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-06-07 at 12:00 -0400, Will Woods wrote: > We should probably change the default theme to preserve the normal > tooltip color until upstream sorts it out. Sure, we could do that. > Our default theme inherits from Clearlooks, so that's the theme we need > to change. For some reason, while Clearlooks is included in the > gnome-themes SRPM, it's removed during packaging - gtk2-engines is the > package that actually provides Clearlooks. Confusing! No, not confusing. Every engine comes with a default theme; for the clearlooks engine, thats the Clearlooks theme. From blc at redhat.com Thu Jun 7 16:33:40 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 07 Jun 2007 10:33:40 -0600 Subject: fedora for ARM In-Reply-To: <1181209882.2785.24.camel@pmac.infradead.org> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <4667322C.7020904@redhat.com> <1181209882.2785.24.camel@pmac.infradead.org> Message-ID: <46683364.60508@redhat.com> David Woodhouse wrote: > Do you really think we're going to get them to care about cross builds > too? I _did_ care about cross-compilation, and I gave up on it. I really > don't think we have much chance of getting package maintainers (and > upstreams) to handle it. Unfortunately. No, I don't think it's realistic that existing package maintainers should have to directly handle cross build failures as well as native build failures. This is largely a volunteer effort and adding more load to volunteers is going to have a negative impact. I do believe that people who care about cross building could share in the responsibility for packages that fail to build in a cross environment. Fedora is a project in the spirit of cooperation and I'm sure a large number of maintainers wouldn't mind the extra help. For many autotools-based packages, the changes are minimal. In a perfect (bug free) world, cross support could simply be added to Koji, the switch could be thrown, and all packages would magically build as crosses. Of course, that's not going to happen. It will start with 1 package, then 2.... whatever the final method is, it will start with the desirous, then continue with the willing. Like suggested in the secondary arches discussion, failed cross builds would not hold up packages that build fine natively (The hypothetical cross-friendly flag could be removed, even). Part of the fun with Fedora is breaking new ground, but we don't want to spoil things for anybody else in the process. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Thu Jun 7 16:39:54 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 07 Jun 2007 10:39:54 -0600 Subject: fedora for ARM In-Reply-To: <20070607114028.GH2079@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <20070607114028.GH2079@xi.wantstofly.org> Message-ID: <466834DA.1060009@redhat.com> Lennert Buytenhek wrote: > I would fully agree with the sentiment that cross-compiling the entire > distro as _the_ standard way of maintaining the arch package repository > is not a realistic scenario and will likely never be. Preferably, I > would like to just keep doing this entirely natively. I hesitate to say never, prefering to invoke the forseeable future. Wherever native builds are a viable option, it makes sense to use them. Wherever cross builds are a viable option, it makes sense to use them. > It appears a lot less effort to maintain a set of patches to make some > limited subset of packages (say, 300 packages) cross-compilable, > though. In some cases, we'll have to do this anyway. Indeed- if you can simply cross build the packages at the top of the dependency tree (kernel, libc, coreutils, init, bash/sh), you are in much better shape. What's more, they are typically very cross friendly. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From david at fubar.dk Thu Jun 7 16:44:54 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 07 Jun 2007 12:44:54 -0400 Subject: Unmounting removable media under Gnome In-Reply-To: References: <1181148476.7761.13.camel@zelda.fubar.dk> <1181176516.7761.52.camel@zelda.fubar.dk> Message-ID: <1181234694.2887.8.camel@zelda.fubar.dk> On Thu, 2007-06-07 at 09:34 +0100, Steve Hill wrote: > It certainly is to do with compatibility - up until recently (the > last > couple of years) it was certainly unusual to have the media mounted when > you weren't actually using it so it was expected that the media wouldn't > be mounted if you were trying to erase it, for example. Let's see. From FC3 through today automounting of storage devices was handled by g-v-m and HAL. Prior to FC3 there was magicdev which only handled optical discs: Magicdev is a daemon that runs within the GNOME environment and detects when a CD is removed or inserted. Magicdev handles running autorun programs on the CD, updating the File Manager, and playing audio CDs. Looking at the earliest version of magicdev I find a build date of Wed 22 Sep 1999 04:21:52. That would probably land it (I didn't check) in RHL 6.1 (codename Cartman) that was released October 4, 1999. So we've been automounting optical discs since late 1999. That's almost 8 years by now. Other distributions of Linux have a similar history. David From nicolas.mailhot at laposte.net Thu Jun 7 16:22:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 7 Jun 2007 18:22:41 +0200 (CEST) Subject: Fedora 8 ideas In-Reply-To: <4668262D.4090602@redhat.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> Message-ID: <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> Le Jeu 7 juin 2007 17:37, Jarod Wilson a ?crit : > Bill Nottingham wrote: >> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: >> What cards is this useful for that we don't ship firmware >> for? Anything other than bcm43xx and ralink? > > A number of dvb and v4l devices also require firmware that we don't > ship. And alsa devices But that's because historically we've never shipped firmware, not because anyone looked hard recently and decided we could not ship them. Please try to get the firmware in-distro before focusing on a download helper. -- Nicolas Mailhot From sberry at northlc.com Thu Jun 7 17:10:35 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 12:10:35 -0500 Subject: a look at my spec file for Webmin In-Reply-To: <200706071815.41412.manuel@todo-linux.com> References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> <200706071815.41412.manuel@todo-linux.com> Message-ID: <007f01c7a926$c8b2f050$6701a8c0@yellobow> This is from a srpm from www.webmin.com. Yes it has worked on Fedora 6. The reason I don't follow guidelines is there is no Examples. I tried understanding them but they are a little too in depth for beginning users. The guidelines I do use are found here: http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s02.html The guidelines need to be geared more towards a beginner if you want more packagers. I understand that not everything can be predicted but a good tutorial would be in the order for beginners. I just took the spec file and added what the document said to add. The document given as a link hasn't been updated in two years. Scott ----- Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Manuel Arostegui Ramirez Sent: Thursday, June 07, 2007 11:16 AM To: Development discussions related to Fedora Core Subject: Re: a look at my spec file for Webmin El Jueves, 7 de Junio de 2007 18:12, Scott Berry escribi?: > Can someone have a look at this spec file and tell me if I have everything > correct? It looks correct to me pretty much but I think there are just a > couple things missing. I will attach this as a file. > > Scott The thing is...that works for you? If you're looking for the correct way to write spec files why you don't follow guidelines? -- Manuel Arostegui Ramirez. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM From ndbecker2 at gmail.com Thu Jun 7 17:16:47 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 07 Jun 2007 13:16:47 -0400 Subject: tetex-doc is not noarch? Message-ID: Seems a bit odd: tetex-doc x86_64 From pemboa at gmail.com Thu Jun 7 17:20:19 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 7 Jun 2007 12:20:19 -0500 Subject: Fedora 8 ideas In-Reply-To: <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> Message-ID: <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> On 6/7/07, Nicolas Mailhot wrote: > > Le Jeu 7 juin 2007 17:37, Jarod Wilson a ?crit : > > Bill Nottingham wrote: > >> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: > > >> What cards is this useful for that we don't ship firmware > >> for? Anything other than bcm43xx and ralink? > > > > A number of dvb and v4l devices also require firmware that we don't > > ship. > > And alsa devices > > But that's because historically we've never shipped firmware, not > because anyone looked hard recently and decided we could not ship > them. > > Please try to get the firmware in-distro before focusing on a download > helper. > > -- > Nicolas Mailhot I have felt the pain of no firmware installed for an alsa device. 2-3 hours wasted. It would have been nice if I at least knew firmware was needed. -- Fedora Core 6 and proud From nicolas.mailhot at laposte.net Thu Jun 7 17:23:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 19:23:34 +0200 Subject: Fedora 8 ideas In-Reply-To: <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> Message-ID: <1181237014.17222.1.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 12:20 -0500, Arthur Pemberton a ?crit : > On 6/7/07, Nicolas Mailhot wrote: > > > > Le Jeu 7 juin 2007 17:37, Jarod Wilson a ?crit : > > > Bill Nottingham wrote: > > >> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: > > > > >> What cards is this useful for that we don't ship firmware > > >> for? Anything other than bcm43xx and ralink? > > > > > > A number of dvb and v4l devices also require firmware that we don't > > > ship. > > > > And alsa devices > > > > But that's because historically we've never shipped firmware, not > > because anyone looked hard recently and decided we could not ship > > them. > > > > Please try to get the firmware in-distro before focusing on a download > > helper. > I have felt the pain of no firmware installed for an alsa device. 2-3 > hours wasted. It would have been nice if I at least knew firmware was > needed. Alsa is mostly a case of "someone needs to poke RH Legal to check the alsa firmware dumps can be packaged (and if not go ask the hadrware vendors for permission)" -- 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 blc at redhat.com Thu Jun 7 17:26:47 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 07 Jun 2007 11:26:47 -0600 Subject: fedora for ARM In-Reply-To: <20070607163027.GT2079@xi.wantstofly.org> References: <46640036.8020607@warmcat.com> <46662169.9060208@marvell.com> <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> <46667630.3040303@warmcat.com> <20070607132726.GR2079@xi.wantstofly.org> <46683054.3050801@redhat.com> <20070607163027.GT2079@xi.wantstofly.org> Message-ID: <46683FD7.5040002@redhat.com> Lennert Buytenhek wrote: > Are you suggesting to use the target triple as the rpm arch name? > > Isn't gcc-4.1.2-12.armv5l-softvfp-linux-gnueabi.rpm kind of long? Yes, it's much too long, but it is a starting point should Fedora deem armv5l-softvfp-linux-gnueabi an important variant :-) > (Note that our package repo uses eabi, where vfp byte/word order > and softfloat are the default, so we don't encode those bits of > info explicitly. The packages use 'armv5tel' as the rpm arch name.) I like armv5l and armv5b arch names, but this seems like a relatively minor point. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From rdieter at math.unl.edu Thu Jun 7 17:27:59 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Jun 2007 12:27:59 -0500 Subject: tetex-doc is not noarch? References: Message-ID: Neal Becker wrote: > Seems a bit odd: > tetex-doc x86_64 It's built along with the rest of tetex, which *is* arch-specific. The only way to get this to be noarch, would be to build it separately, and the extra work/maintainance may or may not be worth the payoff. There's lots of similar cases, kdelibs-apidocs is one that comes to mind. :) -- Rex From sundaram at fedoraproject.org Thu Jun 7 17:28:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Jun 2007 22:58:24 +0530 Subject: a look at my spec file for Webmin In-Reply-To: <007f01c7a926$c8b2f050$6701a8c0@yellobow> References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> <200706071815.41412.manuel@todo-linux.com> <007f01c7a926$c8b2f050$6701a8c0@yellobow> Message-ID: <46684038.3060207@fedoraproject.org> Scott Berry wrote: > This is from a srpm from www.webmin.com. Yes it has worked on Fedora 6. > The reason I don't follow guidelines is there is no > Examples. I tried understanding them but they are a little too in depth for > beginning users. The guidelines I do use are found here: > http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s02.html > The guidelines need to be geared more towards a beginner if you want more > packagers. A more appropriate guide would be http://fedoraproject.org/wiki/Packaging/Guidelines Rahul From j.w.r.degoede at hhs.nl Thu Jun 7 17:44:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 07 Jun 2007 19:44:47 +0200 Subject: Fedora 8 ideas In-Reply-To: <1181229773.22860.1.camel@aglarond.local> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668210C.50808@hhs.nl> <1181229773.22860.1.camel@aglarond.local> Message-ID: <4668440F.20209@hhs.nl> Jeremy Katz wrote: > On Thu, 2007-06-07 at 17:15 +0200, Hans de Goede wrote: >> Bill Nottingham wrote: >>> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: >>>> 2 Firmware buddy >>>> ================ >>> What cards is this useful for that we don't ship firmware >>> for? Anything other than bcm43xx and ralink? > >> I originally came to this idea after going through some pain to get my SIL card >> (prism 2 softmac, driver prism_pci) to work. So add prism cards to that, notice >> that I bought that card very recently, so those are still in the stores. >> >> Also aren't there many many ralink + bcm cards, you make it sound like those >> are rare. > > Oh, they're very common. But I'd rather spend some time trying to work > with the vendors so we can ship the firmware and have it just work. Fully agreed, but some vendors are notoriously hard to work with. Regards, Hans From j.w.r.degoede at hhs.nl Thu Jun 7 17:46:04 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 07 Jun 2007 19:46:04 +0200 Subject: Fedora 8 ideas In-Reply-To: <1181237014.17222.1.camel@rousalka.dyndns.org> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> Message-ID: <4668445C.2070906@hhs.nl> Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 12:20 -0500, Arthur Pemberton a ?crit : >> On 6/7/07, Nicolas Mailhot wrote: >>> Le Jeu 7 juin 2007 17:37, Jarod Wilson a ?crit : >>>> Bill Nottingham wrote: >>>>> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: >>>>> What cards is this useful for that we don't ship firmware >>>>> for? Anything other than bcm43xx and ralink? >>>> A number of dvb and v4l devices also require firmware that we don't >>>> ship. >>> And alsa devices >>> >>> But that's because historically we've never shipped firmware, not >>> because anyone looked hard recently and decided we could not ship >>> them. >>> >>> Please try to get the firmware in-distro before focusing on a download >>> helper. > >> I have felt the pain of no firmware installed for an alsa device. 2-3 >> hours wasted. It would have been nice if I at least knew firmware was >> needed. > > Alsa is mostly a case of "someone needs to poke RH Legal to check the > alsa firmware dumps can be packaged (and if not go ask the hadrware > vendors for permission)" > Okay, that would be great, any tokers on working on this and packaging it? I could do it, but I think this is better handled by somewhere with (some of) the involved hardware. Regards, Hans From pemboa at gmail.com Thu Jun 7 17:30:33 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 7 Jun 2007 12:30:33 -0500 Subject: Fedora 8 ideas In-Reply-To: <1181237014.17222.1.camel@rousalka.dyndns.org> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> Message-ID: <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> On 6/7/07, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 12:20 -0500, Arthur Pemberton a ?crit : > > On 6/7/07, Nicolas Mailhot wrote: > > > > > > Le Jeu 7 juin 2007 17:37, Jarod Wilson a ?crit : > > > > Bill Nottingham wrote: > > > >> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: > > > > > > >> What cards is this useful for that we don't ship firmware > > > >> for? Anything other than bcm43xx and ralink? > > > > > > > > A number of dvb and v4l devices also require firmware that we don't > > > > ship. > > > > > > And alsa devices > > > > > > But that's because historically we've never shipped firmware, not > > > because anyone looked hard recently and decided we could not ship > > > them. > > > > > > Please try to get the firmware in-distro before focusing on a download > > > helper. > > > I have felt the pain of no firmware installed for an alsa device. 2-3 > > hours wasted. It would have been nice if I at least knew firmware was > > needed. > > Alsa is mostly a case of "someone needs to poke RH Legal to check the > alsa firmware dumps can be packaged (and if not go ask the hadrware > vendors for permission)" After 2hrs trying to figure out why the device didn't work, it took me an hour to find the firmware at the bottom of the page. -- Fedora Core 6 and proud From nicolas.mailhot at laposte.net Thu Jun 7 17:34:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 19:34:34 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181233295.4070.81.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> Message-ID: <1181237674.17222.8.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 09:21 -0700, Toshio Kuratomi a ?crit : > On Wed, 2007-06-06 at 13:50 -0400, Christopher Blizzard wrote: > > o Do we want to move to a process where code is just in a repo and it's > > built automatically instead of source + patches + spec file? > > I have a lot more to say on this topic but for now I'd like to just > mention this Ubuntu page: > https://wiki.ubuntu.com/NoMoreSourcePackages The premise of this document is source packages are evil because they can be injected in the buildsys without being traced in the scm. The Fedora way to inject a source package in koji is cvs-import which *will* trace changes in our SCM. So the whole argument does not really apply to Fedora. We can both use source packages (as the ubuntu document rightly notes that's a very natural thing to do) and trace changes. -- 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 j.w.r.degoede at hhs.nl Thu Jun 7 17:50:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 07 Jun 2007 19:50:52 +0200 Subject: Fedora 8 ideas In-Reply-To: <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> Message-ID: <4668457C.6050002@hhs.nl> Arthur Pemberton wrote: > On 6/7/07, Nicolas Mailhot wrote: >> Le jeudi 07 juin 2007 ? 12:20 -0500, Arthur Pemberton a ?crit : >> > On 6/7/07, Nicolas Mailhot wrote: >> > > >> > > Le Jeu 7 juin 2007 17:37, Jarod Wilson a ?crit : >> > > > Bill Nottingham wrote: >> > > >> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: >> > > >> > > >> What cards is this useful for that we don't ship firmware >> > > >> for? Anything other than bcm43xx and ralink? >> > > > >> > > > A number of dvb and v4l devices also require firmware that we don't >> > > > ship. >> > > >> > > And alsa devices >> > > >> > > But that's because historically we've never shipped firmware, not >> > > because anyone looked hard recently and decided we could not ship >> > > them. >> > > >> > > Please try to get the firmware in-distro before focusing on a >> download >> > > helper. >> >> > I have felt the pain of no firmware installed for an alsa device. 2-3 >> > hours wasted. It would have been nice if I at least knew firmware was >> > needed. >> >> Alsa is mostly a case of "someone needs to poke RH Legal to check the >> alsa firmware dumps can be packaged (and if not go ask the hadrware >> vendors for permission)" > > > After 2hrs trying to figure out why the device didn't work, it took me > an hour to find the firmware at the bottom of the page. > Yeah, I think the least we need is an gui applet which looks for missing firmware messages in the logs, alerts the user and explains things to him, including a link to a wiki page, with links to various download locations for various devices. This applet ofcourse needs a do not nag again checkbox :) Regards, Hans From j.w.r.degoede at hhs.nl Thu Jun 7 17:53:04 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 07 Jun 2007 19:53:04 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <1181230006.9479.2.camel@pensja.lam.pl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> Message-ID: <46684600.3050803@hhs.nl> Leszek Matok wrote: > Dnia 07-06-2007, czw o godzinie 11:06 -0400, Bill Nottingham napisa?(a): >> What cards is this useful for that we don't ship firmware >> for? Anything other than bcm43xx and ralink? > For example, there are millions of potential speedtch.ko users here in > Europe. > Okay, I think we need to build a list of all potential needed / wanted firmware, with URL's where to download it and instructions howto unpack it. We then also need to start contacting the manufacturers asking for redistribution permission. Here is a start of the list with things metioned sofar: sil firmware (for prism and prism_pci) bcm firmware ralink firmware speedtouch firmware alsa firmware I think this is best put in the wiki, but where, maybe a firmware SIG? Regards, Hans From pemboa at gmail.com Thu Jun 7 17:30:33 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 7 Jun 2007 12:30:33 -0500 Subject: Fedora 8 ideas In-Reply-To: <1181237014.17222.1.camel@rousalka.dyndns.org> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> Message-ID: <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> On 6/7/07, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 12:20 -0500, Arthur Pemberton a ?crit : > > On 6/7/07, Nicolas Mailhot wrote: > > > > > > Le Jeu 7 juin 2007 17:37, Jarod Wilson a ?crit : > > > > Bill Nottingham wrote: > > > >> Goede, J.W.R. de (j.w.r.degoede at hhs.nl) said: > > > > > > >> What cards is this useful for that we don't ship firmware > > > >> for? Anything other than bcm43xx and ralink? > > > > > > > > A number of dvb and v4l devices also require firmware that we don't > > > > ship. > > > > > > And alsa devices > > > > > > But that's because historically we've never shipped firmware, not > > > because anyone looked hard recently and decided we could not ship > > > them. > > > > > > Please try to get the firmware in-distro before focusing on a download > > > helper. > > > I have felt the pain of no firmware installed for an alsa device. 2-3 > > hours wasted. It would have been nice if I at least knew firmware was > > needed. > > Alsa is mostly a case of "someone needs to poke RH Legal to check the > alsa firmware dumps can be packaged (and if not go ask the hadrware > vendors for permission)" After 2hrs trying to figure out why the device didn't work, it took me an hour to find the firmware at the bottom of the page. -- Fedora Core 6 and proud From sberry at northlc.com Thu Jun 7 17:42:32 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 12:42:32 -0500 Subject: a look at my spec file for Webmin In-Reply-To: <46684038.3060207@fedoraproject.org> References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> <200706071815.41412.manuel@todo-linux.com><007f01c7a926$c8b2f050$6701a8c0@yellobow> <46684038.3060207@fedoraproject.org> Message-ID: <001e01c7a92b$4173e270$6701a8c0@yellobow> Yep I have that one here also. This is the one that needs a little work. The guidelines are okay but for a new user what do you do? Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Rahul Sundaram Sent: Thursday, June 07, 2007 12:28 PM To: Development discussions related to Fedora Core Subject: Re: a look at my spec file for Webmin Scott Berry wrote: > This is from a srpm from www.webmin.com. Yes it has worked on Fedora 6. > The reason I don't follow guidelines is there is no > Examples. I tried understanding them but they are a little too in depth for > beginning users. The guidelines I do use are found here: > http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s02.html > The guidelines need to be geared more towards a beginner if you want more > packagers. A more appropriate guide would be http://fedoraproject.org/wiki/Packaging/Guidelines Rahul -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM From dsmith at redhat.com Thu Jun 7 17:45:08 2007 From: dsmith at redhat.com (David Smith) Date: Thu, 07 Jun 2007 12:45:08 -0500 Subject: a look at my spec file for Webmin In-Reply-To: <007f01c7a926$c8b2f050$6701a8c0@yellobow> References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> <200706071815.41412.manuel@todo-linux.com> <007f01c7a926$c8b2f050$6701a8c0@yellobow> Message-ID: <46684424.9000403@redhat.com> Scott Berry wrote: > This is from a srpm from www.webmin.com. Yes it has worked on Fedora 6. > The reason I don't follow guidelines is there is no > Examples. I tried understanding them but they are a little too in depth for > beginning users. The guidelines I do use are found here: > http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s02.html > The guidelines need to be geared more towards a beginner if you want more > packagers. > I understand that not everything can be predicted but a good tutorial > would be in the order for beginners. I just took the spec file and added > what the document said to add. The document given as a link hasn't been > updated in two years. > Scott Scott, One of the problems you are having is that you picked a package with such a complicated spec file to begin with. There really aren't too many packages that include all the scripts that this one does: %pre, %post, %preun, %postun, and %triggerpostun. From my brief look at the spec file it appears to be doing way too much. You probably need to sit back and think a bit and dramatically simplify the spec file. Contact me off-list if you'd like some help (not that I own any packages but I've hacked on spec files before). -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jun 7 17:47:48 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 08 Jun 2007 02:47:48 +0900 Subject: tetex-doc is not noarch? In-Reply-To: References: Message-ID: <466844C4.8090200@ioa.s.u-tokyo.ac.jp> Rex Dieter wrote, at 06/08/2007 02:27 AM +9:00: > Neal Becker wrote: > >> Seems a bit odd: >> tetex-doc x86_64 > > It's built along with the rest of tetex, which *is* arch-specific. > > The only way to get this to be noarch, would be to build it separately, and > the extra work/maintainance may or may not be worth the payoff. There's > lots of similar cases, kdelibs-apidocs is one that comes to mind. :) If we want to make tetex-doc noarch, perhaps the method done by kernel spec can be applied. Mamoru From sundaram at fedoraproject.org Thu Jun 7 17:52:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Jun 2007 23:22:34 +0530 Subject: a look at my spec file for Webmin In-Reply-To: <001e01c7a92b$4173e270$6701a8c0@yellobow> References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> <200706071815.41412.manuel@todo-linux.com><007f01c7a926$c8b2f050$6701a8c0@yellobow> <46684038.3060207@fedoraproject.org> <001e01c7a92b$4173e270$6701a8c0@yellobow> Message-ID: <466845E2.9010306@fedoraproject.org> Scott Berry wrote: > Yep I have that one here also. This is the one that needs a little work. > The guidelines are okay but for a new user what do you do? > > Scott Read it. If you have specific questions you can always ask. If you got a spec file that follows the guidelines you can submit it for review and the reviewer can suggest changes to improve it before it gets imported into the repository. Rahul From msaksena at marvell.com Thu Jun 7 17:54:47 2007 From: msaksena at marvell.com (Manas Saksena) Date: Thu, 07 Jun 2007 10:54:47 -0700 Subject: fedora for generic crosscompile In-Reply-To: <4667D48F.4020201@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <4667322C.7020904@redhat.com> <4667D48F.4020201@warmcat.com> Message-ID: <46684667.9000706@marvell.com> Andy Green wrote: > Brendan Conoboy wrote: >> Ed Swierk wrote: >>> That said, there is certainly room for both approaches, and getting >>> even a small number of packages to cross-compile might be enough for >>> many embedded applications. >> Definitely. For cross compilation, I picture a per-package flag in Koji >> that marks it as cross-friendly or not. There are certainly numerous >> technical and social details to work out to making such a system work >> and work equitably. We're just getting started. > > Well some areas to think about > > - The disparity in platform resources and power will be greater than > ever before. Choices made in ./configure switches that are the standard > Fedora way can easily blow packages and dependencies out of scope for > otherwise capable targets. You can tie choices in configuration to the > arch, but isn't it more interesting to imagine it is its own "bloat > dimension", so weak x86 targets can be built for? How about being able > to specify multiple %build and Requires based on a new macro %_bloat. > %_bloat = 10 is the normal supported Fedora traditional build with > Kerberos everywhere and so on. But the spec file can also define > alternatives along the lines of %if %_bloat < 10 args> %endif or %switch/%case (either requires a little extension to rpm > AFAIK). Only the default bloat level needs to be supported and shipped > by Fedora to the extent it already is, folks can --rebuild to target > lesser platforms fedgentoo style. %_bloat=1 can even give you a busybox > / uClibc based result if you want to max it out. But to get started all > the packages can just build the standard way without any conditionals. While using a bloat dimension is interesting, I think it is too difficult to capture the full richness of feature/footprint tradeoffs using a single parameter like that. Instead, the way I think this could be addressed is by: -- providing a tool that makes it easy to rebuild packages with different configure flags -- make it easy for folks downstream to fedora to rebuild fedora packages and fedora based custom distros using the above too. -- make it easy for folks downstream to fedora to track upstream fedora changes, while maintaining local In my experience, this kind of customization is best done when the feature/footprint tradeoffs are well-understood; i.e., when a root file system is being created for a specific device, and when both the functions to be supported by the device and the footprint constraints are well-understood. Over time, you could see a bunch of sample device profiles -- each representing a customized root file system that is derived from fedora packages, but in a systematic, easy, and traceable manner. And, these can then become the basis of new device profiles. You might want to take a look at "tsrpm" tool that was built by Chris Faylor (ex TimeSys) that allowed some of this for Fedora RPM packages using a mechanism called package hints. You can find more information at: https://crossdev.timesys.com/ (the site is pretty much dead, but there is useful information there). I have also cc'ed Chris. > - How to install foreign arch libs and -devel packages. There is > already a precedent in having i386 libs on x86_64 boxes but this is a > bit different because the arch is REALLY foreign. It will have to know > to do some kind of --root= action if it sees you installing s390 libs > into an i386 box, because you clearly don't want them going into the > real /lib. This is handled by tsrpm as well (among a number of other nifty features). Manas From notting at redhat.com Thu Jun 7 17:54:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 13:54:55 -0400 Subject: Splitting the ncurses RPM In-Reply-To: <1181231962.3749.63.camel@willson> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <20070606182457.GG5700@nostromo.devel.redhat.com> <20070607131052.GA13291@localhost> <20070607144839.GA25221@nostromo.devel.redhat.com> <1181231962.3749.63.camel@willson> Message-ID: <20070607175455.GA27054@nostromo.devel.redhat.com> Simo Sorce (ssorce at redhat.com) said: > to be honest, > I think deciding the package shape based on the broken way we are > currently detecting multi-libs is a bad way to decide. > > We should fix the way we detect multi-libs, not produce substandard > packaging to keep the current multi-libs detection process happy. It's not a matter of changing the detection (getting the right packages in the tree a multilib), it's a matter of making upgrades work when package X is no longer multilib. That's significantly trickier. Bill From katzj at redhat.com Thu Jun 7 18:00:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 07 Jun 2007 14:00:09 -0400 Subject: Splitting the ncurses RPM In-Reply-To: <20070607175455.GA27054@nostromo.devel.redhat.com> References: <466385F1.8030005@codewiz.org> <4665F306.40609@codewiz.org> <20070606122312.GA25767@localhost> <200706061534.34114.arnd@arndb.de> <20070606151317.GA27490@localhost> <20070606182457.GG5700@nostromo.devel.redhat.com> <20070607131052.GA13291@localhost> <20070607144839.GA25221@nostromo.devel.redhat.com> <1181231962.3749.63.camel@willson> <20070607175455.GA27054@nostromo.devel.redhat.com> Message-ID: <1181239214.26928.35.camel@erebor.boston.redhat.com> On Thu, 2007-06-07 at 13:54 -0400, Bill Nottingham wrote: > Simo Sorce (ssorce at redhat.com) said: > > to be honest, > > I think deciding the package shape based on the broken way we are > > currently detecting multi-libs is a bad way to decide. > > > > We should fix the way we detect multi-libs, not produce substandard > > packaging to keep the current multi-libs detection process happy. > > It's not a matter of changing the detection (getting the right packages > in the tree a multilib), it's a matter of making upgrades work when > package X is no longer multilib. That's significantly trickier. It's not like we don't already have the problem, though. Adding to the list in anaconda is simple enough and Seth has most of a yum plugin written. Then we just have to move the list from being hard-coded in anaconda to a separate metadata file that ends up in the repos Jeremy From nicolas.mailhot at laposte.net Thu Jun 7 17:42:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 19:42:28 +0200 Subject: Fedora 8 ideas In-Reply-To: <4668445C.2070906@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <4668445C.2070906@hhs.nl> Message-ID: <1181238148.17222.12.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 19:46 +0200, Hans de Goede a ?crit : > Okay, that would be great, any tokers on working on this and packaging it? I > could do it, but I think this is better handled by somewhere with (some of) the > involved hardware. The review bug exists there : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217259 The packaging part is easy. But I wouldn't ack it before a lawyer actually tells us the licensing as declared by the Alsa project is legit -- 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 a.badger at gmail.com Thu Jun 7 18:06:10 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 11:06:10 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <1181237674.17222.8.camel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> Message-ID: <1181239570.4070.109.camel@localhost.localdomain> On Thu, 2007-06-07 at 19:34 +0200, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 09:21 -0700, Toshio Kuratomi a ?crit : > > On Wed, 2007-06-06 at 13:50 -0400, Christopher Blizzard wrote: > > > o Do we want to move to a process where code is just in a repo and it's > > > built automatically instead of source + patches + spec file? > > > > I have a lot more to say on this topic but for now I'd like to just > > mention this Ubuntu page: > > https://wiki.ubuntu.com/NoMoreSourcePackages > > The premise of this document is source packages are evil because they > can be injected in the buildsys without being traced in the scm. > > The Fedora way to inject a source package in koji is cvs-import which > *will* trace changes in our SCM. > > So the whole argument does not really apply to Fedora. We can both use > source packages (as the ubuntu document rightly notes that's a very > natural thing to do) and trace changes. > Absolutely -- they have different reasons for wanting this than we do. Our reasons are: 1) Better able to work with upstream 2) Better able to rebase our local changes. 3) Better able to see how our changes have been modified over time. However, the solution they arrive at is similar to what we want. That's why looking at it is good. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Thu Jun 7 17:45:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 19:45:25 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <46684600.3050803@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> Message-ID: <1181238325.17222.15.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 19:53 +0200, Hans de Goede a ?crit : > I think we need to build a list of all potential needed / wanted firmware, with > URL's where to download it and instructions howto unpack it. > > We then also need to start contacting the manufacturers asking for > redistribution permission. > > Here is a start of the list with things metioned sofar: > sil firmware (for prism and prism_pci) > bcm firmware > ralink firmware > speedtouch firmware > alsa firmware + ivtv firmware Axel promised to submit for review someday (he got the licensing acked by the vendor, and has a working package atrpms side, and has asked to be the one who merges it in Fedora) > I think this is best put in the wiki, but where, maybe a firmware SIG? 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 jspaleta at gmail.com Thu Jun 7 18:09:05 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 7 Jun 2007 10:09:05 -0800 Subject: Fedora 8 ideas In-Reply-To: <4668457C.6050002@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> <4668457C.6050002@hhs.nl> Message-ID: <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> On 6/7/07, Hans de Goede wrote: > Yeah, I think the least we need is an gui applet which looks for missing > firmware messages in the logs, alerts the user and explains things to him, > including a link to a wiki page, with links to various download locations for > various devices. This applet ofcourse needs a do not nag again checkbox :) If you are going to do this, how about we also make an effort to catalog these missing-firmware devices for Fedora project's purposes as well? Short term, having a gui wizard as a "must get this working NOW" fix to assuage the emotions of end-users maybe of modest value. But if we want to fix this long term. project contributors who care about the issue need to be able to get a grasp on the number of Fedora users using said hardware so those contributors can go and work with vendors for a long term solution so users don't have to deal with this at all. So perhaps the wizard, if it comes into being, can be done such that it phones home back to the Fedora project so information concerning the devices which need firmware, and the number of users attempting to use each device. Unless of course this sort of information is already buried inside the smolt treasure trove. If so... then users of the gui should be encourage to register their system with smolt to make sure the Fedora project has the information. -jef From limb at jcomserv.net Thu Jun 7 18:08:06 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 7 Jun 2007 13:08:06 -0500 (CDT) Subject: Unsigned package Message-ID: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> Trying to upgrade, yum complains: Package scons-0.97-2.fc7.noarch.rpm is not signed This is from my local mirror, but the one from two other official mirrors and d.f.r.c match it. rpm --checksig on all of these yields: scons-0.97-2.fc7.noarch.rpm: sha1 md5 OK Huh? Jon -- novus ordo absurdum From rdieter at math.unl.edu Thu Jun 7 18:15:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Jun 2007 13:15:44 -0500 Subject: tetex-doc is not noarch? References: <466844C4.8090200@ioa.s.u-tokyo.ac.jp> Message-ID: Mamoru Tasaka wrote: > Rex Dieter wrote, at 06/08/2007 02:27 AM +9:00: >> The only way to get this to be noarch, would be to build it separately, >> and >> the extra work/maintainance may or may not be worth the payoff. There's >> lots of similar cases, kdelibs-apidocs is one that comes to mind. :) > > If we want to make tetex-doc noarch, perhaps the method done > by kernel spec can be applied. Oooh thanks, I'll have to take a look. -- Rex From jkeating at redhat.com Thu Jun 7 18:16:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 14:16:21 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181239570.4070.109.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> Message-ID: <200706071416.28976.jkeating@redhat.com> On Thursday 07 June 2007 14:06:10 Toshio Kuratomi wrote: > Absolutely -- they have different reasons for wanting this than we do. > > Our reasons are: > 1) Better able to work with upstream > 2) Better able to rebase our local changes. > 3) Better able to see how our changes have been modified over time. > > However, the solution they arrive at is similar to what we want. ?That's > why looking at it is good. I think it's important to note that having exploaded trees with patch management doesn't exclude generating a srpm with prestine source +patches to send into the buildsystem and publish in our source repos. What we're talking about is making it easier to manage the patches on top of the prestine source. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jun 7 18:21:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 14:21:00 -0400 Subject: Unsigned package In-Reply-To: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> Message-ID: <200706071421.00899.jkeating@redhat.com> On Thursday 07 June 2007 14:08:06 Jon Ciesla wrote: > Trying to upgrade, yum complains: > Package scons-0.97-2.fc7.noarch.rpm is not signed > > This is from my local mirror, but the one from two other official mirrors > and d.f.r.c match it. > > rpm --checksig on all of these yields: > > scons-0.97-2.fc7.noarch.rpm: sha1 md5 OK > > Huh? > > Jon > > -- > novus ordo absurdum A few unsigned packages leaked out in the tree due to some tools errors and oversight. I have a new tree with signed packages and new repodata for the signed packages that I'll be uploading at some point today (once my day of meetings is over). There is some impact on users. Yum caches metadata (and packages) for a period of time (30 minutes). So changing the package checksum without changing the NVR can have some impact: With a warm cache, and no package in cache, it'll say your package doesn't match checksum. With a warm cache and a already cached (unsigned) package, it'll say the package is unsigned. Once cache expires, it Just Works(tm). This only effects the unsigned packages in the tree, all other operations on signed packages will be fine. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mastahnke at gmail.com Thu Jun 7 18:25:00 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 7 Jun 2007 13:25:00 -0500 Subject: Fedora 8 ideas In-Reply-To: <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> <4668457C.6050002@hhs.nl> <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> Message-ID: <7874d9dd0706071125q4a0f5422r159151d67cff8c0c@mail.gmail.com> I assume the items scheduled for F7 that didn't make it in[1] are all in-scope for F7? stahnma [1] http://fedoraproject.org/wiki/Releases/7/FeatureList From a.badger at gmail.com Thu Jun 7 18:23:55 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 11:23:55 -0700 Subject: Upcoming FESCo Election In-Reply-To: <466494EB.1010300@redhat.com> References: <1180627394.5867.2.camel@lincoln> <466494EB.1010300@redhat.com> Message-ID: <1181240635.4070.122.camel@localhost.localdomain> On Mon, 2007-06-04 at 15:40 -0700, John Poelstra wrote: > Brian Pepple said the following on 05/31/2007 09:03 AM Pacific Time: > > Hi All! > > > > It's that time of year again. Everyone that wants to be in the next > > FESCo needs to nominate him/herself for it by June 12, 2007 0:00 UTC; > > that self-nomination should contain some information's like "Mission > > Statement, Past work summary and Future plans". > > > > Please place your nomination on this page in the wiki: > > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations > > > > The actual election will start on Thursday, June 14, 2007 0:01 UTC and > > will last until Sunday, June 24, 2007 23:59 UTC. The results will be > > posted to the fedora-devel list. The first meeting of the "new" FESCo > > will be on Thursday, July 05, 2007 on #fedora-meeting at 17:00 UTC. A > > new chair will be elected there by the new members. > > > > For more information regarding the election, please refer to this: > > http://fedoraproject.org/wiki/Extras/Policy/FESCoElections > > > > > > Thanks, > > /B > > > > Forgive me if I am wrong, but I cannot find any information on the wiki that explains *exactly* what FESCO does or what it is responsible for. Thus, I'm not sure whether it is something I or other people would want to become involved with. > > Can someone provide a URL or add a new wiki page? > ATM, FESCo kind of fields any problem that is bigger than an individual package/packager and not seen as something that the board should handle. They delegate some of the decision making to other groups -- Releng and the Packaging Committee coming to mind immediately. work. This is a very loose idea of what's going on because who owns what is not very well defined at the moment. Max and the Board are working on something to better separate the responsibilities of the Board and FESCo. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mastahnke at gmail.com Thu Jun 7 18:25:21 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 7 Jun 2007 13:25:21 -0500 Subject: Fedora 8 ideas In-Reply-To: <7874d9dd0706071125q4a0f5422r159151d67cff8c0c@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> <4668457C.6050002@hhs.nl> <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> <7874d9dd0706071125q4a0f5422r159151d67cff8c0c@mail.gmail.com> Message-ID: <7874d9dd0706071125s3fa91cc3w5df9a63ae6adda48@mail.gmail.com> On 6/7/07, Michael Stahnke wrote: > I assume the items scheduled for F7 that didn't make it in[1] are all > in-scope for F7? Pretend I said F8 there. > > stahnma > > [1] http://fedoraproject.org/wiki/Releases/7/FeatureList > From j.w.r.degoede at hhs.nl Thu Jun 7 18:41:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 07 Jun 2007 20:41:57 +0200 Subject: Fedora 8 ideas In-Reply-To: <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> <4668457C.6050002@hhs.nl> <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> Message-ID: <46685175.5020906@hhs.nl> Jeff Spaleta wrote: > On 6/7/07, Hans de Goede wrote: >> Yeah, I think the least we need is an gui applet which looks for missing >> firmware messages in the logs, alerts the user and explains things to >> him, >> including a link to a wiki page, with links to various download >> locations for >> various devices. This applet ofcourse needs a do not nag again >> checkbox :) > > If you are going to do this, how about we also make an effort to > catalog these missing-firmware devices for Fedora project's purposes > as well? > If I write such a beast you are ofcourse free to submit a patch implementing that. Regards, Hans From notting at redhat.com Thu Jun 7 18:25:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 14:25:46 -0400 Subject: tetex-doc is not noarch? In-Reply-To: References: <466844C4.8090200@ioa.s.u-tokyo.ac.jp> Message-ID: <20070607182545.GD27054@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > > If we want to make tetex-doc noarch, perhaps the method done > > by kernel spec can be applied. > > Oooh thanks, I'll have to take a look. Note: this requires hacks in the build system to handle for all packages where you'd want this. Bill From notting at redhat.com Thu Jun 7 18:27:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 14:27:35 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <200706071416.28976.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <200706071416.28976.jkeating@redhat.com> Message-ID: <20070607182735.GE27054@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > However, the solution they arrive at is similar to what we want. ?That's > > why looking at it is good. > > I think it's important to note that having exploaded trees with patch > management doesn't exclude generating a srpm with prestine source +patches to > send into the buildsystem and publish in our source repos. What we're > talking about is making it easier to manage the patches on top of the > prestine source. The question is... how much does working in an exploded tree push you towards less incentive to get a set of patches and changes upstream. Heck, we could just work in exploded source and start claiming we *are* the upstream... Bill From rdieter at math.unl.edu Thu Jun 7 18:31:26 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Jun 2007 13:31:26 -0500 Subject: Fedora 8 ideas References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Alsa is mostly a case of "someone needs to poke RH Legal to check the > alsa firmware dumps can be packaged (and if not go ask the hadrware > vendors for permission)" All Fedora requires is free redistributability. -- Rex From katzj at redhat.com Thu Jun 7 18:32:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 07 Jun 2007 14:32:10 -0400 Subject: Fedora 8 ideas In-Reply-To: <7874d9dd0706071125q4a0f5422r159151d67cff8c0c@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> <4668457C.6050002@hhs.nl> <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> <7874d9dd0706071125q4a0f5422r159151d67cff8c0c@mail.gmail.com> Message-ID: <1181241131.26928.37.camel@erebor.boston.redhat.com> On Thu, 2007-06-07 at 13:25 -0500, Michael Stahnke wrote: > I assume the items scheduled for F7 that didn't make it in[1] are all > in-scope for F7? If someone signs up to drive them to completion Jeremy From notting at redhat.com Thu Jun 7 18:30:12 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 14:30:12 -0400 Subject: Fedora 8 ideas In-Reply-To: <4668210C.50808@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668210C.50808@hhs.nl> Message-ID: <20070607183012.GF27054@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > I originally came to this idea after going through some pain to get my SIL > card (prism 2 softmac, driver prism_pci) to work. So add prism cards to > that, notice that I bought that card very recently, so those are still in > the stores. > > Also aren't there many many ralink + bcm cards, you make it sound like > those are rare. Right, but I'd like to work with the mfrs, if at all possible, to get the firmware redistribution rights. (The ralink one is especially silly, as they offer the firmware free for download on their site... with no license.) > >>3 plugin buddy > >>============== > >> > >>Like codec buddy, but then for firefox plugins. Why? > >>because firefox plugin find service doesn't undserstand to > >>install nspluginwrapper (needs to get into Fedora) and then > >>flash on x86_64. Nor knows it to change the selinux type of > >>realplayer to get it to work with our default enabled > >>selinux policy. > > > > > > > >So, *if* we install nspluginwrapper by default, does firefox > >then do the right thing? > > > > Nope, I tried that. Is this something that can be patched and fixed in firefox? > >I'm not really thrilled about working on this because > >of a) the insinuation, at least, of moderate endorsement > >b) the fact that it seems it would be going down a rathole > >of chasing-the-fixes-for-each-new-package. > > I'm not asking anyone to be thrilled about working on this, what I'm asking > is do others agree this might have (some) added value for Fedora, and more > in general would such a beast be acceptable? I'd say it's somewhat unacceptable. Wouldn't the effort be better spent on making things like evince, kvm, etc. full alternatives, rather than building bridges out of band-aids? (Yes, I realize the skill sets involved are not the same.) Bill From notting at redhat.com Thu Jun 7 18:31:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 14:31:02 -0400 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <46684600.3050803@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> Message-ID: <20070607183102.GG27054@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Here is a start of the list with things metioned sofar: > sil firmware (for prism and prism_pci) > bcm firmware > ralink firmware > speedtouch firmware > alsa firmware > > I think this is best put in the wiki, but where, maybe a firmware SIG? There's the old FeatureWirelessFirmware page; we could start a new page,though. Bill From pemboa at gmail.com Thu Jun 7 18:35:50 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 7 Jun 2007 13:35:50 -0500 Subject: Fedora 8 ideas In-Reply-To: <7874d9dd0706071125q4a0f5422r159151d67cff8c0c@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> <4668457C.6050002@hhs.nl> <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> <7874d9dd0706071125q4a0f5422r159151d67cff8c0c@mail.gmail.com> Message-ID: <16de708d0706071135l696998f9t72d9e69808ee3e8c@mail.gmail.com> On 6/7/07, Michael Stahnke wrote: > I assume the items scheduled for F7 that didn't make it in[1] are all > in-scope for F7? > > stahnma > > [1] http://fedoraproject.org/wiki/Releases/7/FeatureList I'm guessing enough effort was not put in. I know I'm guilty of that. One somewhat related question: is there a list of active fedora software projects? -- Fedora Core 6 and proud From nicolas.mailhot at laposte.net Thu Jun 7 18:37:39 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 20:37:39 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181239570.4070.109.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> Message-ID: <1181241459.18723.13.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 11:06 -0700, Toshio Kuratomi a ?crit : > Absolutely -- they have different reasons for wanting this than we do. Wanting what? If what = kill centralised cvs for modern scm exploded trees, with cvs/svn/whatever gateways, while keeping the current srpm export/import modes, why not If what = get everyone to use _insert_preferred_scm_there and kill other access modes ? not good > Our reasons are: > 1) Better able to work with upstream Upstreams do not agree on scm choices (when they use one) > 2) Better able to rebase our local changes. We don't want to get good at local changes, we want to push changes upstream, and even cvs is good enough for our basic rebasing needs today > 3) Better able to see how our changes have been modified over time. See 2. IMHO the killer argument for SCM changes is the unconnected mode new scms offer, but any package that needs something else than CVS because of your 1 2 3 is in deep trouble. -- 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 jspaleta at gmail.com Thu Jun 7 18:38:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 7 Jun 2007 10:38:00 -0800 Subject: Fedora 8 ideas In-Reply-To: <46685175.5020906@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <16de708d0706071030p1a1c1446m1d3ba9656f5e470c@mail.gmail.com> <4668457C.6050002@hhs.nl> <604aa7910706071109v13de685cif9bb19368f85c23f@mail.gmail.com> <46685175.5020906@hhs.nl> Message-ID: <604aa7910706071138tff1d10oc02cce86023eabce@mail.gmail.com> On 6/7/07, Hans de Goede wrote: > If I write such a beast you are ofcourse free to submit a patch implementing that. As long as I don't have to promise that my patch actually works. -jef"does smolt track the state of firmwarelessness at all currently?... inquiring minds want to know"spaleta From rdieter at math.unl.edu Thu Jun 7 18:34:57 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Jun 2007 13:34:57 -0500 Subject: Fedora 8 ideas References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <4668445C.2070906@hhs.nl> <1181238148.17222.12.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 19:46 +0200, Hans de Goede a ?crit : > >> Okay, that would be great, any tokers on working on this and packaging >> it? I could do it, but I think this is better handled by somewhere with >> (some of) the involved hardware. > > The review bug exists there : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217259 > > The packaging part is easy. But I wouldn't ack it before a lawyer > actually tells us the licensing as declared by the Alsa project is legit >From briefly looking at it, it says GPL, which certainly is freely redistributable. Now, all it needs is a review(er). -- Rex From Axel.Thimm at ATrpms.net Thu Jun 7 18:41:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 7 Jun 2007 20:41:41 +0200 Subject: Future SCM Technology In-Reply-To: <200706070723.04824.jkeating@redhat.com> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <20070607101214.GB18982@ryvius.pekin.waw.pl> <200706070723.04824.jkeating@redhat.com> Message-ID: <20070607184141.GB12450@neu.nirvana> On Thu, Jun 07, 2007 at 07:23:04AM -0400, Jesse Keating wrote: > On Thursday 07 June 2007 06:12:14 Dominik 'Rathann' Mierzejewski wrote: > > I, for one, would welcome something similar to svn cp and svn mv, > > which allows you to copy and rename files (I'm thinking patches) > > while preserving change history. > > Could we better frame this as "I wish our SCM would allow for renaming and/or > copying source controlled files to new names, while preserving the recorded > history of the file within the SCM." ? (I just don't want to see a lot of > requests be tied to a particular SCM or another, just pure features. FWIW one could rephrase it with "Every SCM, but CVS". This is a CVS limitation that any willing successor has fixed, I don't think any of the systems we're thinking about has this flaw. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jun 7 18:39:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 14:39:45 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <20070607182735.GE27054@nostromo.devel.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706071416.28976.jkeating@redhat.com> <20070607182735.GE27054@nostromo.devel.redhat.com> Message-ID: <200706071439.45528.jkeating@redhat.com> On Thursday 07 June 2007 14:27:35 Bill Nottingham wrote: > The question is... how much does working in an exploded tree push you > towards less incentive to get a set of patches and changes upstream. > > Heck, we could just work in exploded source and start claiming we *are* > the upstream... We have to do it in a way that makes the exploaded tree useful for managing your CHANGES to that exploaded tree. We don't let the sourcerpm passed into the buildsystem be of a modified tarball, we continue to force it to be the unmodified upstream tarball plus the patches that you've been managing with the exploaded tree applied to it. This continues to enforce the patches are valid to a known release, allows you to use exploaded tree to manage the patches, gives upstream a place to cherry pick changes from, or old style patch files to deal with. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Jun 7 18:44:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 20:44:15 +0200 Subject: Fedora 8 ideas In-Reply-To: References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> Message-ID: <1181241855.18723.18.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 13:31 -0500, Rex Dieter a ?crit : > Nicolas Mailhot wrote: > > > > Alsa is mostly a case of "someone needs to poke RH Legal to check the > > alsa firmware dumps can be packaged (and if not go ask the hadrware > > vendors for permission)" > > All Fedora requires is free redistributability. In the case of alsa you have a huge firmware archive for hardware from many vendors, with alsa telling you the whole set is GPL, and with many text files in the alsa archive tracing vendor permissions. So the question is: do you trust the text files as is? Do they cover all the firmwares in the archive set? Have any of them incompatible terms? That's questions for a lawyer, not a packager. -- 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 jkeating at redhat.com Thu Jun 7 18:43:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 14:43:47 -0400 Subject: Future SCM Technology In-Reply-To: <20070607184141.GB12450@neu.nirvana> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706070723.04824.jkeating@redhat.com> <20070607184141.GB12450@neu.nirvana> Message-ID: <200706071443.48136.jkeating@redhat.com> On Thursday 07 June 2007 14:41:41 Axel Thimm wrote: > On Thu, Jun 07, 2007 at 07:23:04AM -0400, Jesse Keating wrote: > > On Thursday 07 June 2007 06:12:14 Dominik 'Rathann' Mierzejewski wrote: > > > I, for one, would welcome something similar to svn cp and svn mv, > > > which allows you to copy and rename files (I'm thinking patches) > > > while preserving change history. > > > > Could we better frame this as "I wish our SCM would allow for renaming > > and/or copying source controlled files to new names, while preserving the > > recorded history of the file within the SCM." ? (I just don't want to > > see a lot of requests be tied to a particular SCM or another, just pure > > features. > > FWIW one could rephrase it with "Every SCM, but CVS". This is a CVS > limitation that any willing successor has fixed, I don't think any of > the systems we're thinking about has this flaw. Well, hg cannot do this yet. It has a function to copy a file, but all it really does is hg rm ; hg add . yes, this is dumb. :( -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Jun 7 18:47:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 7 Jun 2007 20:47:21 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <1181238325.17222.15.camel@rousalka.dyndns.org> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> <1181238325.17222.15.camel@rousalka.dyndns.org> Message-ID: <20070607184721.GC12450@neu.nirvana> On Thu, Jun 07, 2007 at 07:45:25PM +0200, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 19:53 +0200, Hans de Goede a ?crit : > > > I think we need to build a list of all potential needed / wanted firmware, with > > URL's where to download it and instructions howto unpack it. > > > > We then also need to start contacting the manufacturers asking for > > redistribution permission. > > > > Here is a start of the list with things metioned sofar: > > sil firmware (for prism and prism_pci) > > bcm firmware > > ralink firmware > > speedtouch firmware > > alsa firmware > > + ivtv firmware Axel promised to submit for review someday Thanks for pinging, yes, I'll submit this, but as long as the kernel doesn't ship ivtv it wasn't a high priority. But I guess F7 will soon go 2.6.22 which will have ivtv, so it should definitely make it into devel now. I think I had you cornered as a reviewer? :) > (he got the licensing acked by the vendor, and has a working package > atrpms side, and has asked to be the one who merges it in Fedora) BTW I hope the licenses are OK, as I wrote them. They were derived by permission from Intel's licensing text and ratified by the vendor's legal department. -- 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 gajownik at gmail.com Thu Jun 7 18:49:47 2007 From: gajownik at gmail.com (Dawid Gajownik) Date: Thu, 07 Jun 2007 20:49:47 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <46684600.3050803@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> Message-ID: <4668534B.5040408@gmail.com> Dnia 06/07/2007 07:40 PM, U?ytkownik Hans de Goede napisa?: > I think we need to build a list of all potential needed / wanted > firmware, with URL's where to download it and instructions howto unpack it. 3Com Bluetooth Wireless PC Card 3CRWB6096. Instructions are here ? http://www.bluez.org/drivers.html BTW I noticed that "Reply-To:" field is set to "Development discussions related to Fedora Core". May someone fix it, please? HTH, Dawid -- ^_* From nicolas.mailhot at laposte.net Thu Jun 7 18:52:59 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 20:52:59 +0200 Subject: Unsigned package In-Reply-To: <200706071421.00899.jkeating@redhat.com> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706071421.00899.jkeating@redhat.com> Message-ID: <1181242379.18723.25.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 14:21 -0400, Jesse Keating a ?crit : > Yum caches metadata (and packages) for a period of time (30 minutes). So > changing the package checksum without changing the NVR can have some impact: That's assuming there's no proxy between the user and yum. If there is one it can be many times longer than 30 min. It'd be nice if createrepo generated proxy-friendly content (foo-datetime.xml.gz instead of foo.xml.gz) -- 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 a.badger at gmail.com Thu Jun 7 18:40:53 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 11:40:53 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <200706071416.28976.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <200706071416.28976.jkeating@redhat.com> Message-ID: <1181241653.4070.138.camel@localhost.localdomain> On Thu, 2007-06-07 at 14:16 -0400, Jesse Keating wrote: > On Thursday 07 June 2007 14:06:10 Toshio Kuratomi wrote: > > Absolutely -- they have different reasons for wanting this than we do. > > > > Our reasons are: > > 1) Better able to work with upstream > > 2) Better able to rebase our local changes. > > 3) Better able to see how our changes have been modified over time. > > > > However, the solution they arrive at is similar to what we want. That's > > why looking at it is good. > > I think it's important to note that having exploaded trees with patch > management doesn't exclude generating a srpm with prestine source +patches to > send into the buildsystem and publish in our source repos. What we're > talking about is making it easier to manage the patches on top of the > prestine source. Of course. And contrary to the name of the URL I posted [1]_, the document has this to say: ''' The "source package" can still be obtained from the archive for auditing purposes, however it is no longer the form in which changes are uploaded, so it does not usurp the revision control system underneath. ''' The methodology outlined there is to save changes into the revision control system in such a way that they can be pulled out as patches against upstream and shipped to the build system. We'd want to have a slightly different directory hierarchy since we save spec files outside of the upstream tree and .debs save the spec equivalent inside the upstream tree. [1]_: https://wiki.ubuntu.com/NoMoreSourcePackages NoMoreSourcePackages refers to Ubuntu's current need to ship the source to the build system as a source package created on the contributor's machine rather than a set of files in the revision control system. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Thu Jun 7 18:51:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 11:51:14 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <20070607182735.GE27054@nostromo.devel.redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <200706071416.28976.jkeating@redhat.com> <20070607182735.GE27054@nostromo.devel.redhat.com> Message-ID: <1181242274.4070.150.camel@localhost.localdomain> On Thu, 2007-06-07 at 14:27 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > > However, the solution they arrive at is similar to what we want. That's > > > why looking at it is good. > > > > I think it's important to note that having exploaded trees with patch > > management doesn't exclude generating a srpm with prestine source +patches to > > send into the buildsystem and publish in our source repos. What we're > > talking about is making it easier to manage the patches on top of the > > prestine source. > > The question is... how much does working in an exploded tree push you towards > less incentive to get a set of patches and changes upstream. > That is a good question. I could be optimistic and rephrase it though: Is there an incentive to get your changes upstream even when working in an exploded tree? I think the answer is yes because even though it makes carrying a local patchset from one upstream release to another less effort it doesn't make the rebase free. You still have to do work when upstream introduces conflicting changes. The exploded tree just makes it easier to see what changes were made and how they relate to your changes. > Heck, we could just work in exploded source and start claiming we *are* > the upstream... > Distributed Revision Control does make that possible. However, 1) Do we want the burden of being upstream to another project? 2) Has that happened to Linus's kernel, xorg, mercurial, bzr, darcs, or any of the other projects storing their source in a DRCS? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Thu Jun 7 18:57:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 20:57:33 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <20070607184721.GC12450@neu.nirvana> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> <1181238325.17222.15.camel@rousalka.dyndns.org> <20070607184721.GC12450@neu.nirvana> Message-ID: <1181242653.18723.27.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 20:47 +0200, Axel Thimm a ?crit : > On Thu, Jun 07, 2007 at 07:45:25PM +0200, Nicolas Mailhot wrote: > > + ivtv firmware Axel promised to submit for review someday > > Thanks for pinging, yes, I'll submit this, but as long as the kernel > doesn't ship ivtv it wasn't a high priority. But I guess F7 will soon > go 2.6.22 which will have ivtv, so it should definitely make it into > devel now. I think I had you cornered as a reviewer? :) Don't wait till I change hardware :) I may lose motivation. -- 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 Axel.Thimm at ATrpms.net Thu Jun 7 19:01:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 7 Jun 2007 21:01:12 +0200 Subject: Future SCM Technology In-Reply-To: <200706071443.48136.jkeating@redhat.com> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706070723.04824.jkeating@redhat.com> <20070607184141.GB12450@neu.nirvana> <200706071443.48136.jkeating@redhat.com> Message-ID: <20070607190112.GD12450@neu.nirvana> On Thu, Jun 07, 2007 at 02:43:47PM -0400, Jesse Keating wrote: > On Thursday 07 June 2007 14:41:41 Axel Thimm wrote: > > On Thu, Jun 07, 2007 at 07:23:04AM -0400, Jesse Keating wrote: > > > On Thursday 07 June 2007 06:12:14 Dominik 'Rathann' Mierzejewski wrote: > > > > I, for one, would welcome something similar to svn cp and svn mv, > > > > which allows you to copy and rename files (I'm thinking patches) > > > > while preserving change history. > > > > > > Could we better frame this as "I wish our SCM would allow for renaming > > > and/or copying source controlled files to new names, while preserving the > > > recorded history of the file within the SCM." ? (I just don't want to > > > see a lot of requests be tied to a particular SCM or another, just pure > > > features. > > > > FWIW one could rephrase it with "Every SCM, but CVS". This is a CVS > > limitation that any willing successor has fixed, I don't think any of > > the systems we're thinking about has this flaw. > > Well, hg cannot do this yet. It has a function to copy a file, but all it > really does is hg rm ; hg add . yes, this is dumb. :( I think it is more like "copy, then remove", which is all you really want as the history can be propagated back through the copy/rename operation (-f option to any relevant hg command will do the trick). What you're quoting is more the CVS variant of renaming, e.g. no scm relation between the two operations at all. -- 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 limb at jcomserv.net Thu Jun 7 19:00:52 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 7 Jun 2007 14:00:52 -0500 (CDT) Subject: Unsigned package In-Reply-To: <200706071421.00899.jkeating@redhat.com> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706071421.00899.jkeating@redhat.com> Message-ID: <23087.65.192.24.190.1181242852.squirrel@mail.jcomserv.net> > On Thursday 07 June 2007 14:08:06 Jon Ciesla wrote: >> Trying to upgrade, yum complains: >> Package scons-0.97-2.fc7.noarch.rpm is not signed >> >> This is from my local mirror, but the one from two other official >> mirrors >> and d.f.r.c match it. >> >> rpm --checksig on all of these yields: >> >> scons-0.97-2.fc7.noarch.rpm: sha1 md5 OK >> >> Huh? >> >> Jon >> >> -- >> novus ordo absurdum > > A few unsigned packages leaked out in the tree due to some tools errors > and > oversight. I have a new tree with signed packages and new repodata for > the > signed packages that I'll be uploading at some point today (once my day of > meetings is over). There is some impact on users. > > Yum caches metadata (and packages) for a period of time (30 minutes). So > changing the package checksum without changing the NVR can have some > impact: > > With a warm cache, and no package in cache, it'll say your package doesn't > match checksum. With a warm cache and a already cached (unsigned) > package, > it'll say the package is unsigned. Once cache expires, it Just Works(tm). > This only effects the unsigned packages in the tree, all other operations > on > signed packages will be fine. So, try again tomorrow. :) Ok. Thanks. :) > -- > Jesse Keating > Release Engineer: Fedora > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From oisin.feeley at gmail.com Thu Jun 7 19:07:59 2007 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Thu, 7 Jun 2007 15:07:59 -0400 Subject: Fedora 8 ideas In-Reply-To: <4667C1B0.9000506@FamilleCollet.com> References: <4667C1B0.9000506@FamilleCollet.com> Message-ID: On 6/7/07, Remi Collet wrote: > Goede, J.W.R. de a ?crit : > > > > 1 Package nvu > > ============= > > > > The title pretty much sums it up, package nvu a popular > > opensource web-editor. Anyone know why this hasn't been > > done yet? > > Hi, > I think NVU is a "dead" software > > It should be replaced by "Composer", a Xulrunner App. > As we should have Xulrunner in F8, probably a good idea to wait a little. > > Some info here : http://glazman.org/weblog/dotclear/index.php?Nvu As things stand the KompoZer fork is actually more usable until Daniel finally releases "Composer" . KompoZer is a bug-fix fork of Nvu-1.0 http://kompozer.net/ Oisin From jkeating at redhat.com Thu Jun 7 19:12:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 15:12:22 -0400 Subject: Future SCM Technology In-Reply-To: <20070607190112.GD12450@neu.nirvana> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706071443.48136.jkeating@redhat.com> <20070607190112.GD12450@neu.nirvana> Message-ID: <200706071512.22430.jkeating@redhat.com> On Thursday 07 June 2007 15:01:12 Axel Thimm wrote: > I think it is more like "copy, then remove", which is all you really > want as the history can be propagated back through the copy/rename > operation (-f option to any relevant hg command will do the trick). Maybe you know something that I don't, but the last time I looked at this, there was no way in HG to rename a file, but keep change history of that file. When changing the name you suddenly have no history of that file. [jkeating at reducto test]$ hg init [jkeating at reducto test]$ echo "hi" > file1 [jkeating at reducto test]$ hg add file1 [jkeating at reducto test]$ vim file1 [jkeating at reducto test]$ hg commit [jkeating at reducto test]$ hg log changeset: 0:be1bfb05d4e3 tag: tip user: Jesse Keating date: Thu Jun 07 15:11:57 2007 -0400 summary: Add changes [jkeating at reducto test]$ vim file1 [jkeating at reducto test]$ hg commit -m 'more changes' [jkeating at reducto test]$ hg rename -f file1 file2 [jkeating at reducto test]$ hg log changeset: 1:330279523a87 tag: tip user: Jesse Keating date: Thu Jun 07 15:12:16 2007 -0400 summary: more changes changeset: 0:be1bfb05d4e3 user: Jesse Keating date: Thu Jun 07 15:11:57 2007 -0400 summary: Add changes [jkeating at reducto test]$ hg commit [jkeating at reducto test]$ hg log changeset: 2:6aebe1d981ee tag: tip user: Jesse Keating date: Thu Jun 07 15:12:39 2007 -0400 summary: File rename changeset: 1:330279523a87 user: Jesse Keating date: Thu Jun 07 15:12:16 2007 -0400 summary: more changes changeset: 0:be1bfb05d4e3 user: Jesse Keating date: Thu Jun 07 15:11:57 2007 -0400 summary: Add changes [jkeating at reducto test]$ log log file2 -bash: log: command not found [jkeating at reducto test]$ hg log file2 changeset: 2:6aebe1d981ee tag: tip user: Jesse Keating date: Thu Jun 07 15:12:39 2007 -0400 summary: File rename No history in that file before the rename. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jun 7 19:14:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 15:14:37 -0400 Subject: Unsigned package In-Reply-To: <1181242379.18723.25.camel@rousalka.dyndns.org> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706071421.00899.jkeating@redhat.com> <1181242379.18723.25.camel@rousalka.dyndns.org> Message-ID: <200706071514.37397.jkeating@redhat.com> On Thursday 07 June 2007 14:52:59 Nicolas Mailhot wrote: > That's assuming there's no proxy between the user and yum. If there is > one it can be many times longer than 30 min. It'd be nice if createrepo > generated proxy-friendly content (foo-datetime.xml.gz instead of > foo.xml.gz) But in this case, we're not making things any worse than they already are (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jos at xos.nl Thu Jun 7 19:18:30 2007 From: jos at xos.nl (Jos Vos) Date: Thu, 7 Jun 2007 21:18:30 +0200 Subject: a look at my spec file for Webmin In-Reply-To: <007f01c7a926$c8b2f050$6701a8c0@yellobow>; from sberry@northlc.com on Thu, Jun 07, 2007 at 12:10:35PM -0500 References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> <200706071815.41412.manuel@todo-linux.com> <007f01c7a926$c8b2f050$6701a8c0@yellobow> Message-ID: <20070607211830.A30740@xos037.xos.nl> On Thu, Jun 07, 2007 at 12:10:35PM -0500, Scott Berry wrote: > This is from a srpm from www.webmin.com. Yes it has worked on Fedora 6. > The reason I don't follow guidelines is there is no > Examples. I tried understanding them but they are a little too in depth for > beginning users. The guidelines I do use are found here: > http://docs.fedoraproject.org/drafts/rpm-guide-en/ch11s02.html > The guidelines need to be geared more towards a beginner if you want more > packagers. Although docs can always be better, you shouldn't necessarily assume that docs (alone) can make you a good packager starting as an unexperienced "beginner", as you call yourself. As someone giving RPM packaging talks and courses, I think packaging is not something you learn from a set of guidelines alone. The most important thing, besides reading theory, is browsing through existing spec files. Fedora has more than 4200 of them (not all are of the same quality, b.t.w.). From those examples, you can easily learn how packages deal with init scripts, for example. My advice: - Start reading . - Browse through some spec files, e.g. by going to the Fedora directory with 4200+ src.rpm's and get all the spec files like this: mkdir /tmp/specs for f in *.src.rpm; do rpm2cpio $f | (cd /tmp/specs; cpio -iuvdm '*.spec') done - Start experimenting and ask questions on a mailing list. As others already pointed out, the example you gave has some really bad parts in it and is certainly not an example of a good spec file. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From rdieter at math.unl.edu Thu Jun 7 19:52:15 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Jun 2007 14:52:15 -0500 Subject: Fedora 8 ideas References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <1181241855.18723.18.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 13:31 -0500, Rex Dieter a ?crit : >> Nicolas Mailhot wrote: >> >> >> > Alsa is mostly a case of "someone needs to poke RH Legal to check the >> > alsa firmware dumps can be packaged (and if not go ask the hadrware >> > vendors for permission)" >> >> All Fedora requires is free redistributability. > > In the case of alsa you have a huge firmware archive for hardware from > many vendors, with alsa telling you the whole set is GPL, and with many > text files in the alsa archive tracing vendor permissions. > > So the question is: do you trust the text files as is? Do they cover all > the firmwares in the archive set? Have any of them incompatible terms? My take is to trust upstream, until there surfaces cause/evidence to believe otherwise. -- Rex From buytenh at wantstofly.org Thu Jun 7 19:59:34 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 7 Jun 2007 21:59:34 +0200 Subject: fedora for ARM In-Reply-To: <46683FD7.5040002@redhat.com> References: <466654C7.7060406@warmcat.com> <1181115856.29024.29.camel@mccallum.corsepiu.local> <46666D4C.5030903@warmcat.com> <1181119217.3431.4.camel@mccallum.corsepiu.local> <46667630.3040303@warmcat.com> <20070607132726.GR2079@xi.wantstofly.org> <46683054.3050801@redhat.com> <20070607163027.GT2079@xi.wantstofly.org> <46683FD7.5040002@redhat.com> Message-ID: <20070607195934.GY2079@xi.wantstofly.org> On Thu, Jun 07, 2007 at 11:26:47AM -0600, Brendan Conoboy wrote: > > Are you suggesting to use the target triple as the rpm arch name? > > > > Isn't gcc-4.1.2-12.armv5l-softvfp-linux-gnueabi.rpm kind of long? > > Yes, it's much too long, but it is a starting point should Fedora > deem armv5l-softvfp-linux-gnueabi an important variant :-) The current package set _is_ basically that, we just call it 'armv5tel' since the rest doesn't add much. Especially the linux-gnu part. :-) > > (Note that our package repo uses eabi, where vfp byte/word order > > and softfloat are the default, so we don't encode those bits of > > info explicitly. The packages use 'armv5tel' as the rpm arch name.) > > I like armv5l and armv5b arch names, but this seems like a > relatively minor point. Well, armv5l implies that the CPU doesn't support the "T" or "E" extensions. This is an important distinction, since even though a package compiled with -march=armv5te will probably not automagically contain thumb insns, it _is_ allowed for gcc to emit ldrd (load double word) and strd (guess..) instructions when the "E" extension is specified to be present. I know of at least one theoretically armv5te compliant ARM CPU where ldrd/strd are buggy, and where the workaround is to make the kernel report 'armv5t' to userspace instead of 'armv5te', and to build userland with -march=armv5t instead of -march=armv5te. I.e. you can't compile a package with -march=armv5te and then call it 'armv5l', because people will then try running it on armv5l and armv5tl machines, which might be less than successful. From a.badger at gmail.com Thu Jun 7 20:00:16 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 13:00:16 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <1181241459.18723.13.camel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> Message-ID: <1181246416.4070.201.camel@localhost.localdomain> On Thu, 2007-06-07 at 20:37 +0200, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 11:06 -0700, Toshio Kuratomi a ?crit : > > > Absolutely -- they have different reasons for wanting this than we do. > > Wanting what? > > If what = kill centralised cvs for modern scm exploded trees, with > cvs/svn/whatever gateways, while keeping the current srpm export/import > modes, why not > Yes. But what is the end of your proposal? > If what = get everyone to use _insert_preferred_scm_there and kill other > access modes ? not good > To be sure I understand, what are the other access modes? > > Our reasons are: > > 1) Better able to work with upstream > > Upstreams do not agree on scm choices (when they use one) > True. but: 1) If we were to share the same DRCS with upstream we would have the ability to share code with them through the DRCS whereas if we share cvs in common with upstream, we are not. 2) Having the ability to pull arbitrary patches out of our VCS vs pulling a discrete patch out of our current CVS system is a postive thing for working with upstream. I can provide upstream with new patches that are a subset of all the changes I made in a patch if they like some of what I did but not all of it. When the changes come back to me in the next release, I can merge that patch against the new upstream and use the VCS to help me see where things have been integrated, where they have not been merged, and where upstream has made other changes that conflict but don't solve the issue that the patch does. I can correct things that upstream thinks would better be done some other way and still have a history of what I changed in the context of the whole project. I can pull snapshots from upstream into my local repository, merge my changes from Fedora, and send the changes back to upstream against their current tree instead of the last released tree. If upstream is slow to respond and needs the changes ported to a new snapshot, I can use the VCS to help me merge my changes to the previous snapshot to the new one. If I need to make changes to a patchset that touches files that subsequent patchset also changes, the VCS helps me operate on the correct files at the correct time in their history and assign the changes to the correct patchset. It then helps me resolve any conflicts with the later patchset. This helps me update patches and resubmit to upstream without mingling the two separate changes. A VCS is not just a place to store changes. It is a tool to help develop and evolve changes. And that has great bearing on its ability to help interact with upstream. > > 2) Better able to rebase our local changes. > > We don't want to get good at local changes, we want to push changes > upstream, and even cvs is good enough for our basic rebasing needs today > We do want to be good at making local changes. We want to be so good at it that when we submit the changes to upstream, upstream has no trouble recognizing that they're good changes and has no issues with accepting them. Part of doing that is making sure that we keep distro-specific changes (ex: changes to the configuration files), backports, and patches sent upstream separate from each other. That way we can easily submit changes to upstream that are relevant to them and enjoy the benefits of version control for our changes that A) are not relevant to upstream or B) only exist in upstream's development branch. Also, cvs is not good enough for our basic needs. I always use quilt to help manage the changes that I'm making to the vanilla upstream source because cvs is not good enough. It doesn't have any facilities for seeing what order a set of patches should be applied in. It doesn't have any facilities for helping me make changes to a patch that's in the middle of a stack of logically separate changes. Even quilt can't help me when I have to update a patch with a better solution. cvs diff -r 1 -r 2 apatchfile.patch is less than ideal. > > 3) Better able to see how our changes have been modified over time. > > See 2. > > IMHO the killer argument for SCM changes is the unconnected mode new > scms offer, but any package that needs something else than CVS because > of your 1 2 3 is in deep trouble. Disconnected mode is a killer argument for changing from cvs-dist to DRCS-dist. It doesn't address the reasons that exploded trees are good. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tjb at unh.edu Thu Jun 7 20:22:28 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 07 Jun 2007 16:22:28 -0400 Subject: fedora devel mirroring? Message-ID: <1181247748.4097.34.camel@raptor.sr.unh.edu> Any clue why mirrors.kernel.org would not be mirroring fedora development? I mirror them and devel is the only thing that is not being updated. Hasn't been since May 25. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From cmadams at hiwaay.net Thu Jun 7 20:25:06 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 7 Jun 2007 15:25:06 -0500 Subject: fedora devel mirroring? In-Reply-To: <1181247748.4097.34.camel@raptor.sr.unh.edu> References: <1181247748.4097.34.camel@raptor.sr.unh.edu> Message-ID: <20070607202506.GK846510@hiwaay.net> Once upon a time, Thomas J. Baker said: > Any clue why mirrors.kernel.org would not be mirroring fedora > development? I mirror them and devel is the only thing that is not being > updated. Hasn't been since May 25. Have you repointed your mirror source to the new development directory? The directory layout for everything changed with the release of F7. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From blc at redhat.com Thu Jun 7 20:41:41 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 07 Jun 2007 14:41:41 -0600 Subject: Fedora and Cross Compiling Message-ID: <46686D85.5000603@redhat.com> For the last few days, I've been writing posts that advocate cross compiling packages for Fedora. Some appear skeptical of this approach, so I want to share a bit more of where I am coming from. Inside Red Hat, my group (GES) creates custom compilers and embedded Linux systems for our customers. We have done this for many years, using various upstream sources, building natively and with cross tools. For the last few years, we have used either RHEL or Fedora as our upstream source base. Along the way, we stopped compiling our packages on the target hardware. It was just too slow, or didn't have enough RAM, or there weren't enough of them, or real hardware didn't even exist yet. Regardless, there were always less expensive commodity PC CPU cycles to be had. We have gone through several generations of build methods, trying new systems, modifying them, trying to get an optimal environment for relatively fast, cyclic builds. Much of this time has been consumed by making packages build with rpm and using a cross compiler to do the work. We've had some success here, though not without considerable effort. We spend quite a bit of time chasing Fedora development. We cross-compile every package that we build(a subset of packages from the aforementioned distributions). There is no simulator or native hardware employed. Judging by messages on the list, other people and businesses are working toward a similar goal, though each with their own infrastructure and method. All the messages about adding arm to Fedora are very exciting! Everybody who has their own private way of getting Fedora built for arm could instead contribute toward the common goal. I would like to see cross compilation become a standard method in Fedora. It scales where native builds don't. There might be faster arm chips these days, but lets not forget all the underpowered embedded CPUs and costly systems like s390. Bootstrapping is simplified. People without access to hardware can work on build problems (Simulators are good for this too). What are the hurdles to adoption? Broadly, they break down into technical and social: Technical: There must be cross compilers before we can cross compile. The build system must be enhanced to support cross compilation. Finally, packages must be modified to support cross compilation. Social: As a volunteer effort, it is unreasonable to expect existing package maintainers to do the work necessary to support cross compilation. There must be people to take on that responsibility and work with upstream and package maintainers to integrate the necessary changes. I don't have fast and easy answers to all of the above, but I would like to have a discussion about them. My group may be able to offer expertise, patches and some man power toward this goal. What do you think? -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From tdiehl at rogueind.com Thu Jun 7 20:43:25 2007 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 7 Jun 2007 16:43:25 -0400 (EDT) Subject: fedora devel mirroring? In-Reply-To: <1181247748.4097.34.camel@raptor.sr.unh.edu> References: <1181247748.4097.34.camel@raptor.sr.unh.edu> Message-ID: On Thu, 7 Jun 2007, Thomas J. Baker wrote: > Any clue why mirrors.kernel.org would not be mirroring fedora > development? I mirror them and devel is the only thing that is not being > updated. Hasn't been since May 25. I can tell you for a fact that they are mirroring devel. I rsync from them here. The problem is most likely that you are looking in the wrong place. The whole tree for f7 has been moved around. There is no more core. Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From j.w.r.degoede at hhs.nl Thu Jun 7 21:01:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 07 Jun 2007 23:01:53 +0200 Subject: Fedora 8 ideas In-Reply-To: References: <20070607150620.GC25221@nostromo.devel.redhat.com> <4668262D.4090602@redhat.com> <36421.192.54.193.51.1181233361.squirrel@rousalka.dyndns.org> <16de708d0706071020s37853809u1ced24d85d7917bd@mail.gmail.com> <1181237014.17222.1.camel@rousalka.dyndns.org> <1181241855.18723.18.camel@rousalka.dyndns.org> Message-ID: <46687241.80402@hhs.nl> Rex Dieter wrote: > Nicolas Mailhot wrote: > >> Le jeudi 07 juin 2007 ? 13:31 -0500, Rex Dieter a ?crit : >>> Nicolas Mailhot wrote: >>> >>> >>>> Alsa is mostly a case of "someone needs to poke RH Legal to check the >>>> alsa firmware dumps can be packaged (and if not go ask the hadrware >>>> vendors for permission)" >>> All Fedora requires is free redistributability. >> In the case of alsa you have a huge firmware archive for hardware from >> many vendors, with alsa telling you the whole set is GPL, and with many >> text files in the alsa archive tracing vendor permissions. >> >> So the question is: do you trust the text files as is? Do they cover all >> the firmwares in the archive set? Have any of them incompatible terms? > > My take is to trust upstream, until there surfaces cause/evidence to believe > otherwise. > +1 We do need to go through all the README's though and check the actual conditions. For each included firmware file, but I see no reason not to trust included permission notices. Regards, Hans From nicolas.mailhot at laposte.net Thu Jun 7 20:25:02 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 22:25:02 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181246416.4070.201.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> Message-ID: <1181247902.18723.44.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 13:00 -0700, Toshio Kuratomi a ?crit : > On Thu, 2007-06-07 at 20:37 +0200, Nicolas Mailhot wrote: > > Le jeudi 07 juin 2007 ? 11:06 -0700, Toshio Kuratomi a ?crit : > > > > > Absolutely -- they have different reasons for wanting this than we do. > > > > Wanting what? > > > > If what = kill centralised cvs for modern scm exploded trees, with > > cvs/svn/whatever gateways, while keeping the current srpm export/import > > modes, why not > > > Yes. But what is the end of your proposal? > > > If what = get everyone to use _insert_preferred_scm_there and kill other > > access modes ? not good > > > To be sure I understand, what are the other access modes? archive + patches, srpm import/export, export gateways to other vcs > 2) Having the ability to pull arbitrary patches out of our VCS vs > pulling a discrete patch out of our current CVS system is a postive > thing for working with upstream. You're describing heavy forking which is not Fedora's target and not needed by the overwhelming majority of fedora packages. You're assuming upstream has the same vcs as you And I'm not sure even in this case we'd want all your coding attempts traced in a public vcs. Seems a lot of stuff you should do in local, and then produce clean patches for the fedora vcs and upstream > > > 2) Better able to rebase our local changes. > > > > We don't want to get good at local changes, we want to push changes > > upstream, and even cvs is good enough for our basic rebasing needs today > > > We do want to be good at making local changes. We want to be so good at > it that when we submit the changes to upstream, upstream has no trouble > recognizing that they're good changes and has no issues with accepting > them. And upstream will ask targeted localised patches not huge vcs feeds it has to sift through > Disconnected mode is a killer argument for changing from cvs-dist to > DRCS-dist. It doesn't address the reasons that exploded trees are good. Well you've convinced me pretty well they're *not* good in a fedora packaging context. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Thu Jun 7 21:04:56 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 23:04:56 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181247902.18723.44.camel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> Message-ID: <1181250296.3472.23.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 22:25 +0200, Nicolas Mailhot a ?crit : > > Disconnected mode is a killer argument for changing from cvs-dist to > > DRCS-dist. It doesn't address the reasons that exploded trees are good. > > Well you've convinced me pretty well they're *not* good in a fedora > packaging context. To expand a little more : the primary form of our "sources" is published upstream archive + fedora patches, because fedora users that audit code will audit these bits separately. Clear separation of Fedora changes is more important than seamless upstream integration. 1. "rebasing" should always start from a published archive, not an upstream vcs tag/label (very often upstream tags something and releases an archive that saw manual tweaks) 2. we don't really care what happened between two upstream releases, that's best traced in the upstream vcs, a giant changeset between them is more pertinent at the fedora level than all the upstream change history 3. we don't really care what happened on the packager system either, just what was pushed as a build (or attempted-to-built package) 4. we really do not want patches that stomp on each other 5. it would be nice to distinguish between patches intended to be pushed upstream and just-for-fedora patches. *if* we decide to trace this info however, it should be traced in the spec file too one way or another (ne patch-for-upstream element, patch naming conventions, annotations, whatever) Given all those points, non-exploded VCS has the clear advantage of forcing the packager to separate upstream and packaging work instead of blurring the boundaries. An exploded export of source+patches for upstream is possible, but killing the source+patches stage at the import level seems dangerous. Not surprisingly, someone like Andrew Morton that needs to rebase regularly from Linus *and* trace transient patches uses quilt instead of an exploded vcs -- 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 naheemzaffar at gmail.com Thu Jun 7 20:54:44 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 7 Jun 2007 21:54:44 +0100 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <604aa7910706061725j4c653c28of88442ce6d28b3a3@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <200706060912.45498.jkeating@redhat.com> <7dd7ab490706060953s39313390w9e4963add2bf9c01@mail.gmail.com> <200706061254.22379.jkeating@redhat.com> <604aa7910706061725j4c653c28of88442ce6d28b3a3@mail.gmail.com> Message-ID: <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> Can we currently upgrade via anaconda installed on the system? Maybe we should have some way to launch anaconda via grub? Get it to do the upgrade however it does that atm? to have a higher "live" time, maybe do the dep resolving beforehand (possibly downloading packages to a different location than the standard yum place_? A potential workflow: 1. Type "yum upgrade" (or something else "fedora upgrade"? or maybe some gui saying "upgrade to next version or something") 1a. Somehow find out if an upgrade is available. Maybe download latest anaconda - probably not installed as part of current install, but a separate boot entry. 2. Yum resolves dependencies and downloads them to a new location. 3. (default) Boot entries for anaconda are added and the user is asked to restart. 4. Anaconda starts 5. Anaconda does it's thing minus the normal screens asking for the info we already have - a simple upgrade with no (default) options to change package selection etc. The issue I think will be step 2 where yum may not be able to read the new comps file. In that case, just move that stage to after relaunching in anaconda (Order being 1,3,4,2,5). From Axel.Thimm at ATrpms.net Thu Jun 7 21:19:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 7 Jun 2007 23:19:29 +0200 Subject: Future SCM Technology In-Reply-To: <200706071512.22430.jkeating@redhat.com> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706071443.48136.jkeating@redhat.com> <20070607190112.GD12450@neu.nirvana> <200706071512.22430.jkeating@redhat.com> Message-ID: <20070607211929.GH12450@neu.nirvana> On Thu, Jun 07, 2007 at 03:12:22PM -0400, Jesse Keating wrote: > On Thursday 07 June 2007 15:01:12 Axel Thimm wrote: > > I think it is more like "copy, then remove", which is all you really > > want as the history can be propagated back through the copy/rename > > operation (-f option to any relevant hg command will do the trick). > > Maybe you know something that I don't, but the last time I looked at this, > there was no way in HG to rename a file, but keep change history of that > file. When changing the name you suddenly have no history of that file. Try man hg | egrep -2 '(rename|-f)' E.g. | rename [OPTION]... SOURCE... DEST | Mark dest as copies of sources; mark sources for deletion. If dest is a directory, copies are put in that directory. If dest is a file, there can only be one source. [...] | log [OPTION]... [FILE] | Print the revision history of the specified files or the entire project. | | File history is shown without following rename or copy history of | files. Use -f/--follow with a file name to follow history across | renames and copies. And similar for hg grep and other history querying commands. -- 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 naheemzaffar at gmail.com Thu Jun 7 20:54:44 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 7 Jun 2007 21:54:44 +0100 Subject: Feature idea: package an installer image as a grub entry before F8. In-Reply-To: <604aa7910706061725j4c653c28of88442ce6d28b3a3@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <200706060912.45498.jkeating@redhat.com> <7dd7ab490706060953s39313390w9e4963add2bf9c01@mail.gmail.com> <200706061254.22379.jkeating@redhat.com> <604aa7910706061725j4c653c28of88442ce6d28b3a3@mail.gmail.com> Message-ID: <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> Can we currently upgrade via anaconda installed on the system? Maybe we should have some way to launch anaconda via grub? Get it to do the upgrade however it does that atm? to have a higher "live" time, maybe do the dep resolving beforehand (possibly downloading packages to a different location than the standard yum place_? A potential workflow: 1. Type "yum upgrade" (or something else "fedora upgrade"? or maybe some gui saying "upgrade to next version or something") 1a. Somehow find out if an upgrade is available. Maybe download latest anaconda - probably not installed as part of current install, but a separate boot entry. 2. Yum resolves dependencies and downloads them to a new location. 3. (default) Boot entries for anaconda are added and the user is asked to restart. 4. Anaconda starts 5. Anaconda does it's thing minus the normal screens asking for the info we already have - a simple upgrade with no (default) options to change package selection etc. The issue I think will be step 2 where yum may not be able to read the new comps file. In that case, just move that stage to after relaunching in anaconda (Order being 1,3,4,2,5). From giallu at gmail.com Thu Jun 7 21:27:03 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 7 Jun 2007 23:27:03 +0200 Subject: a look at my spec file for Webmin In-Reply-To: <20070607211830.A30740@xos037.xos.nl> References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow> <200706071815.41412.manuel@todo-linux.com> <007f01c7a926$c8b2f050$6701a8c0@yellobow> <20070607211830.A30740@xos037.xos.nl> Message-ID: On 6/7/07, Jos Vos wrote: > My advice: > > - Start reading . > > - Browse through some spec files, e.g. by going to the Fedora directory > with 4200+ src.rpm's and get all the spec files like this: > > mkdir /tmp/specs > for f in *.src.rpm; do > rpm2cpio $f | (cd /tmp/specs; cpio -iuvdm '*.spec') > done > > - Start experimenting and ask questions on a mailing list. > Add to that: - subscribe to fedora-package-review list, so you get an idea of the common mistakes a beginner does. This is even more useful if you need a sponsor, since you are supposed to do some reviews (partial, full, just comments, etc) in order to show your understanding of the guidelines. PS. btw, webim was already submitted for review in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184080 you may want to contact the original submitter and start from his spec file. From giallu at gmail.com Thu Jun 7 21:42:42 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 7 Jun 2007 23:42:42 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46686D85.5000603@redhat.com> References: <46686D85.5000603@redhat.com> Message-ID: On 6/7/07, Brendan Conoboy wrote: > > I don't have fast and easy answers to all of the above, but I would like > to have a discussion about them. My group may be able to offer > expertise, patches and some man power toward this goal. What do you think? I think that would be wonderful to have Fedora (or a significant subset of it) available for my Linksys NSLU2, since it's the only way to resurrect it from the drawer I buried it after I had enough of the unslung (debian based) firmware... From a.badger at gmail.com Thu Jun 7 21:44:58 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 14:44:58 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <1181247902.18723.44.camel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> Message-ID: <1181252698.4070.234.camel@localhost.localdomain> On Thu, 2007-06-07 at 22:25 +0200, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 13:00 -0700, Toshio Kuratomi a ?crit : > > On Thu, 2007-06-07 at 20:37 +0200, Nicolas Mailhot wrote: > > > Le jeudi 07 juin 2007 ? 11:06 -0700, Toshio Kuratomi a ?crit : > > > > > > > Absolutely -- they have different reasons for wanting this than we do. > > > > > > Wanting what? > > > > > > If what = kill centralised cvs for modern scm exploded trees, with > > > cvs/svn/whatever gateways, while keeping the current srpm export/import > > > modes, why not > > > > > Yes. But what is the end of your proposal? > > Could you please answer this question? You seemed to have an idea but didn't finish your thought. > > > If what = get everyone to use _insert_preferred_scm_there and kill other > > > access modes ? not good > > > > > To be sure I understand, what are the other access modes? > > archive + patches, srpm import/export, export gateways to other vcs > I agree with you. We must be able to take the information in our DRCS and generate srpms that contain multiple patches just like today. Not being able to do that is to make rpm emulate the build methods of debian packages. *shudder*. > > > 2) Having the ability to pull arbitrary patches out of our VCS vs > > pulling a discrete patch out of our current CVS system is a postive > > thing for working with upstream. > > You're describing heavy forking which is not Fedora's target and not > needed by the overwhelming majority of fedora packages. > Not at all. Config files -- local changes that shouldn't be merged upstream but we might change over time. They would benefit from being revision controlled. Backports -- Our backport would benefit from a DRCS's history and merging features to help update the patch when the upstream fix changes. Local changes that are submitted upstream -- We would want to track the history of changes that make up each patch just as if we were doing the changes directly in upstream's tree. If upstream asks us to modify the patch in any of the ways that I described the DRCS helps us do that. > You're assuming upstream has the same vcs as you > No. Nothing in 2) depends on upstream sharing the same DRCS. What are you visualizing that makes you think that it does? > And I'm not sure even in this case we'd want all your coding attempts > traced in a public vcs. Seems a lot of stuff you should do in local, and > then produce clean patches for the fedora vcs and upstream Having things in an exploded tree DRCS makes it easy to work locally because you can make a local feature branch of the Fedora exploded tree, work on the code for the patch and when done, push it back to the Fedora tree. But just because something is going to be submitted upstream as a patch doesn't mean that a lack of history is desirable. Work done in our tree and then merged to upstream's tree is helped just as much by having history for us to look at as upstream being able to see the changes they made in their tree. Backporting a fix from upstream's development branch to one of our stable packages is an easy example of where having history would be desirable since the changes may need to be reworked anytime upstream makes a new release to their stable branch. > > > > 2) Better able to rebase our local changes. > > > > > > We don't want to get good at local changes, we want to push changes > > > upstream, and even cvs is good enough for our basic rebasing needs today > > > > > We do want to be good at making local changes. We want to be so good at > > it that when we submit the changes to upstream, upstream has no trouble > > recognizing that they're good changes and has no issues with accepting > > them. > > And upstream will ask targeted localised patches not huge vcs feeds it > has to sift through > Right. Which is why you can't just drop everything into an exploded tree but have to construct something like the Ubuntu page describes. This allows you to easily manage logical changesets within the DRCS and send them upstream as discrete patches. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Thu Jun 7 22:12:22 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 15:12:22 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <1181250296.3472.23.camel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> Message-ID: <1181254342.4070.262.camel@localhost.localdomain> On Thu, 2007-06-07 at 23:04 +0200, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 ? 22:25 +0200, Nicolas Mailhot a ?crit : > > > > Disconnected mode is a killer argument for changing from cvs-dist to > > > DRCS-dist. It doesn't address the reasons that exploded trees are good. > > > > Well you've convinced me pretty well they're *not* good in a fedora > > packaging context. > > To expand a little more : the primary form of our "sources" is published > upstream archive + fedora patches, because fedora users that audit code > will audit these bits separately. Clear separation of Fedora changes is > more important than seamless upstream integration. > I agree with this. Where we disagree is whether the implementation of exploded trees will interfere with this or not. > 1. "rebasing" should always start from a published archive, not an > upstream vcs tag/label (very often upstream tags something and releases > an archive that saw manual tweaks) > I agree with this. I don't support using upstream's tags instead of a published archive. We should always import upstream's archive into the DRCS. It's a vendor branch. When upstream is using the same DRCS as we are using we can use their tree in addition to the vendor branch as a way to merge fixes for their current head that are easier for them to add to their tree but the branch that we use to create the packages should always stem from the vendor branch. > 2. we don't really care what happened between two upstream releases, > that's best traced in the upstream vcs, a giant changeset between them > is more pertinent at the fedora level than all the upstream change > history > We do when we're backporting a specific fix from upstream's development tree. > 3. we don't really care what happened on the packager system either, > just what was pushed as a build (or attempted-to-built package) > I disagree with this one quite a bit. 1) For the reviewer/auditor: When a patch changes, don't you want to see what change was made? The current output from cvs is quite garbled (it's a diff of a diff.) It would be much better to see this as changes to the tree with the previous patch applied and the tree with the current patch applies. 2) The packager is developing code. It may only be a patch against upstream but that doesn't mean the good practices associated with using a VCS to checkpoint your changes goes away. > 4. we really do not want patches that stomp on each other > Actually, we do. One example is that I sometimes have to make several fixes to configure.ac andMakefile.am files to build a package. These changes are often separate changes that should go to upstream in discrete patches. Therefore I generate several patches for this which each touch these files. A DRCS makes management of these patchsets easier. > 5. it would be nice to distinguish between patches intended to be pushed > upstream and just-for-fedora patches. *if* we decide to trace this info > however, it should be traced in the spec file too one way or another (ne > patch-for-upstream element, patch naming conventions, annotations, > whatever) > Yes. And exploded trees don't interfere with this. > Given all those points, non-exploded VCS has the clear advantage of > forcing the packager to separate upstream and packaging work instead of > blurring the boundaries. An exploded export of source+patches for > upstream is possible, but killing the source+patches stage at the import > level seems dangerous. > Could you explain the import level statement? I think I've dealt with the rest of your concerns above. > Not surprisingly, someone like Andrew Morton that needs to rebase > regularly from Linus *and* trace transient patches uses quilt instead of > an exploded vcs This is what I'm talking about. The Ubuntu page outlines how to combine a DRCS with quilt-like functionality. That's why I say that it's good reading. Merely using an exploded tree without incorporating features found in quilt is not a good idea. (How to map quilt features into the DRCS could be debated but the fact that it has to be done somehow is a no-brainer to me.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From christoph.wickert at nurfuerspam.de Thu Jun 7 22:12:37 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 08 Jun 2007 00:12:37 +0200 Subject: x86_64 nightmare on F7 Message-ID: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> I have to admit that I'm net in the multilib universe. I just installed F7 x86_64 on my brand new laptop and there are strange things happening. Maybe I'm just stupid, but I think there's something seriously wrong with package management. $ rpm -qa --qf %{NAME}\\n | sort | uniq -d | wc 259 259 2634 So 259 of 1364 Packages are installed in both versions, i386 and x86_64. And it's not just libraries or devel packages. For example, I have firefox installed twice, and both packages have conflicting files. $ rpm -qf --qf %{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\\n /usr/share/pixmaps/firefox.png firefox-2.0.0.4-2.fc7-x86_64 firefox-2.0.0.4-2.fc7-i386 Another example: With "yum groupinstall XFCE" I get a lot of i386 packages too. I can remove the i386 ones, but this will break the x86_64 versions. rpm -V tells me that not much of the package is left, in most cases only the contents of /usr/lib64 is still there. So I tried to reinstall the i386 Version, just to see what happens. But this time yum correctly prevents me from doing this and shows a file conflict. Please take a look at https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156403 and correct me if I'm wrong, but IMO package management on multilib systems is completely broken ATM. Ideas? Christoph From tjb at unh.edu Thu Jun 7 22:18:40 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 07 Jun 2007 18:18:40 -0400 Subject: fedora devel mirroring? In-Reply-To: References: <1181247748.4097.34.camel@raptor.sr.unh.edu> Message-ID: <1181254720.23696.13.camel@neuromancer> On Thu, 2007-06-07 at 16:43 -0400, Tom Diehl wrote: > On Thu, 7 Jun 2007, Thomas J. Baker wrote: > > > Any clue why mirrors.kernel.org would not be mirroring fedora > > development? I mirror them and devel is the only thing that is not being > > updated. Hasn't been since May 25. > > I can tell you for a fact that they are mirroring devel. I rsync from them here. > The problem is most likely that you are looking in the wrong place. The whole > tree for f7 has been moved around. There is no more core. > > Regards, > Actually, core still exists for FC6 and before :-) I believe I'm aware of the structure change and I'm rsyncing all of mirrors.kernel.org::fedora. The fedora/development and fedora/core/development both seem to be the same on my mirror. In fact, I just visited http://mirrors.kernel.org/fedora/development/i386/os/ and it indeed is only up to May 25th. Are you sure you're getting devel from kernel.org? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From khc at pm.waw.pl Thu Jun 7 22:24:03 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Fri, 08 Jun 2007 00:24:03 +0200 Subject: fedora for ARM In-Reply-To: <466834DA.1060009@redhat.com> (Brendan Conoboy's message of "Thu, 07 Jun 2007 10:39:54 -0600") References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <20070607114028.GH2079@xi.wantstofly.org> <466834DA.1060009@redhat.com> Message-ID: Brendan Conoboy writes: > Indeed- if you can simply cross build the packages at the top of the > dependency tree (kernel, libc, coreutils, init, bash/sh), you are in > much better shape. What's more, they are typically very cross > friendly. Are they? First you need a cross-gcc, you can't build it without libc or magic tricks like -Dinhibit_libc. For big-endian ARM, you have to modify gcc because otherwise it won't generate normal (non-kernel) BE code (you need BE gcc lib, but I don't recomment multilib BE/LE gcc either). bash... can you cross-compile bash at all? Not sure about current situation (my box can run ARM programs as well and configure thinks it's native) but ~ 2 years ago it was impossible without much handcraft. -- Krzysztof Halasa From dwmw2 at infradead.org Thu Jun 7 22:37:00 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 07 Jun 2007 23:37:00 +0100 Subject: x86_64 nightmare on F7 In-Reply-To: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> Message-ID: <1181255820.20322.7.camel@shinybook.infradead.org> On Fri, 2007-06-08 at 00:12 +0200, Christoph Wickert wrote: > So 259 of 1364 Packages are installed in both versions, i386 and x86_64. > And it's not just libraries or devel packages. For example, I have > firefox installed twice, and both packages have conflicting files. Yes, this is a known bug which I had hoped would be fixed before F7 but wasn't. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235756 (part of https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib ) -- dwmw2 From dwmw2 at infradead.org Thu Jun 7 22:49:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 07 Jun 2007 23:49:18 +0100 Subject: x86_64 nightmare on F7 In-Reply-To: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> Message-ID: <1181256559.20322.10.camel@shinybook.infradead.org> On Fri, 2007-06-08 at 00:12 +0200, Christoph Wickert wrote: > Another example: With "yum groupinstall XFCE" I get a lot of i386 > packages too. I can remove the i386 ones, but this will break the > x86_64 versions. 'yum --exclude=\*.i386 groupinstall XFCE' btw Yes, yum is broken. But you _can_ make it behave vaguely sensibly for installing new stuff, although it's hard to fix up the breakage it leaves after the default install. -- dwmw2 From bernie at codewiz.org Thu Jun 7 22:54:48 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 07 Jun 2007 18:54:48 -0400 Subject: Fedora 8 ideas In-Reply-To: References: Message-ID: <46688CB8.5090004@codewiz.org> Goede, J.W.R. de wrote: > 3 plugin buddy > ============== > > Like codec buddy, but then for firefox plugins. Why? > because firefox plugin find service doesn't undserstand to > install nspluginwrapper (needs to get into Fedora) and then > flash on x86_64. Nor knows it to change the selinux type of > realplayer to get it to work with our default enabled > selinux policy. This is why I hate programs like Firefox and Thunderbird that come their own custom package system. No matter how cool Firefox plugins are, if all programs did such things, Linux systems would become as maintainable and robust as Windows. We could kill off Firefox's plugin system and package useful plugins as RPMs instead. Not to say anything about the custom localization system. Maybe this is material for a different flame, but who likes Firefox's and Thunderbird's own implementations of keyring, with different passwords and interfaces? And what about the custom filetype associations? -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From dwmw2 at infradead.org Thu Jun 7 22:57:05 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 07 Jun 2007 23:57:05 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <46682B37.8070905@redhat.com> References: <464F2791.1060309@redhat.com> <46682B37.8070905@redhat.com> Message-ID: <1181257026.20322.11.camel@shinybook.infradead.org> On Thu, 2007-06-07 at 16:58 +0100, Richard W.M. Jones wrote: > I always like to be proven wrong ... An experimental dynamic linking > of native code patch has just been added to OCaml CVS upstream. Oooh, shiny. That would make it easier for me to work out why freetennis is segfaulting... -- dwmw2 From ivazqueznet at gmail.com Thu Jun 7 23:04:17 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 07 Jun 2007 19:04:17 -0400 Subject: another question about spec files for Webmin In-Reply-To: <003301c7a917$2aae33b0$6701a8c0@yellobow> References: <003301c7a917$2aae33b0$6701a8c0@yellobow> Message-ID: <1181257457.3686.1.camel@ignacio.lan> On Thu, 2007-06-07 at 10:18 -0500, Scott Berry wrote: > I need to know which group Webmin would fit in. I looked through > "/usr/share/doc/rpm-4.42/groups" and the best fit I can find it this: > Applications/Text > [Scott] Is this correct since this is a web application? Applications/System would probably be best. > Also what do I do about the icon for this do I forgo the icon for now and > put that in later? The icon isn't really used by much these days so feel free to omit it completely. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From christoph.wickert at nurfuerspam.de Thu Jun 7 23:06:25 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 08 Jun 2007 01:06:25 +0200 Subject: x86_64 nightmare on F7 In-Reply-To: <1181256559.20322.10.camel@shinybook.infradead.org> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <1181256559.20322.10.camel@shinybook.infradead.org> Message-ID: <1181257586.3950.41.camel@hal9000.oberschlesier.lan> Am Donnerstag, den 07.06.2007, 23:49 +0100 schrieb David Woodhouse: > On Fri, 2007-06-08 at 00:12 +0200, Christoph Wickert wrote: > > Another example: With "yum groupinstall XFCE" I get a lot of i386 > > packages too. I can remove the i386 ones, but this will break the > > x86_64 versions. > > 'yum --exclude=\*.i386 groupinstall XFCE' btw Thanks for that one. I already added the exclude statement to my yum config permanently. > Yes, yum is broken. There are two questions: Why does yum install i386 at all? Why doesn't yum check for conflicts on a groupinstall? So obviously it must be using using "rpm -i --force", which is pretty dangerous. Another question about your bug 235756: Why is it still assigned to "Anaconda Maintenance Team" instead of the yum owner? Christoph From dwmw2 at infradead.org Thu Jun 7 23:12:45 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 08 Jun 2007 00:12:45 +0100 Subject: x86_64 nightmare on F7 In-Reply-To: <1181257586.3950.41.camel@hal9000.oberschlesier.lan> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <1181256559.20322.10.camel@shinybook.infradead.org> <1181257586.3950.41.camel@hal9000.oberschlesier.lan> Message-ID: <1181257965.20322.18.camel@shinybook.infradead.org> On Fri, 2007-06-08 at 01:06 +0200, Christoph Wickert wrote: > There are two questions: > Why does yum install i386 at all? Potential answers to this include 'crack' and just 'it's a bug'. > Why doesn't yum check for conflicts on a groupinstall? So obviously it > must be using using "rpm -i --force", which is pretty dangerous. Don't know. Might be worth filing another bug, if it's installing a set of packages which RPM wouldn't happily install for itself. > Another question about your bug 235756: Why is it still assigned to > "Anaconda Maintenance Team" instead of the yum owner? Because I forgot to click on the right button when I reassigned it to yum from anaconda. Should be fixed now. -- dwmw2 From jkeating at redhat.com Thu Jun 7 23:18:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 19:18:22 -0400 Subject: Future SCM Technology In-Reply-To: <20070607211929.GH12450@neu.nirvana> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706071512.22430.jkeating@redhat.com> <20070607211929.GH12450@neu.nirvana> Message-ID: <200706071918.25778.jkeating@redhat.com> On Thursday 07 June 2007 17:19:29 Axel Thimm wrote: > Try > > man hg | egrep -2 '(rename|-f)' What version of hg are you playing with? The hg in rawhide for rename -f has: -f, --force forcibly copy over an existing managed file which is really not follow. 0.9.3 is the latest in rawhide, perhaps we need a version bump. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernie at codewiz.org Thu Jun 7 23:26:28 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 07 Jun 2007 19:26:28 -0400 Subject: Reply-To header munging for fedora-devel-list@ Message-ID: <46689424.5030009@codewiz.org> Hello, could we change the list configuration not to munge the Reply-To header, so that when we "Reply All", we actually don't loose the Cc list? The way it's configured now makes it very difficult to notice own's replies in threads. Most high-traffic lists I subscribe are configured this way: linux-kernel, xorg-devel, gcc, gcc-patches, xcb, mesa, dri, uclinux-dev... -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From dwmw2 at infradead.org Thu Jun 7 23:34:07 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 08 Jun 2007 00:34:07 +0100 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <46689424.5030009@codewiz.org> References: <46689424.5030009@codewiz.org> Message-ID: <1181259247.20322.20.camel@shinybook.infradead.org> On Thu, 2007-06-07 at 19:26 -0400, Bernardo Innocenti wrote: > could we change the list configuration not to munge > the Reply-To header, so that when we "Reply All", we > actually don't loose the Cc list? > > The way it's configured now makes it very difficult to > notice own's replies in threads. Yes, reply-to munging is a very bad idea. It would be nice to turn it off. -- dwmw2 From jkeating at redhat.com Thu Jun 7 23:31:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 19:31:36 -0400 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <1181259247.20322.20.camel@shinybook.infradead.org> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> Message-ID: <200706071931.36736.jkeating@redhat.com> On Thursday 07 June 2007 19:34:07 David Woodhouse wrote: > Yes, reply-to munging is a very bad idea. It would be nice to turn it > off. Please do. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Jun 7 23:31:37 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 19:31:37 -0400 Subject: x86_64 nightmare on F7 In-Reply-To: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> Message-ID: <20070607233137.GE31520@nostromo.devel.redhat.com> > $ rpm -qa --qf %{NAME}\\n | sort | uniq -d | wc > 259 259 2634 > > So 259 of 1364 Packages are installed in both versions, i386 and x86_64. > And it's not just libraries or devel packages. For example, I have > firefox installed twice, and both packages have conflicting files. This is normal. > $ rpm -qf --qf %{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\\n > /usr/share/pixmaps/firefox.png > firefox-2.0.0.4-2.fc7-x86_64 > firefox-2.0.0.4-2.fc7-i386 The files are identical, so there is not a conflict - this is expected. > Another example: With "yum groupinstall XFCE" I get a lot of i386 > packages too. Again, expected. > I can remove the i386 ones, but this will break the x86_64 > versions. rpm -V tells me that not much of the package is left, in most > cases only the contents of /usr/lib64 is still there. *That* is a bug. Can you file that, please? Bill From bernie at codewiz.org Thu Jun 7 23:36:00 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 07 Jun 2007 19:36:00 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <38900.192.54.193.51.1181204172.squirrel@rousalka.dyndns.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> <466783F6.8080600@codewiz.org> <20070607044001.GA14463@nostromo.devel.redhat.com> <4667B0C7.1080201@codewiz.org> <38900.192.54.193.51.1181204172.squirrel@rousalka.dyndns.org> Message-ID: <46689660.9030002@codewiz.org> Nicolas Mailhot wrote: > Le Jeu 7 juin 2007 09:16, Bernardo Innocenti a ?crit : >> but the point is still valid: Linux has become somewhat bloated >> over time. > > And it will become unbloated by converging on a new common set of core > dynamic libraries, and optimizing them (like pango & qt people are > doing for harfbuzz, like popler did before, etc) I didn't know about Harfbuzz, good to see somone is hard working on the desktop convergence! > Static linking is not the solution. Experience shows it only leads to > many forks of the same code that bloat memory usage and increase > maintenance. I totally agree. Did I give the impression of thinking otherwise? By the way, Apple banned static linking with libc and other system libraries in OSX a long time ago. The rationale is somewhere in their knowledge base and it's pretty straightforward. So I think we should follow up and do the same on Linux too. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From Axel.Thimm at ATrpms.net Thu Jun 7 23:38:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 01:38:36 +0200 Subject: Future SCM Technology In-Reply-To: <200706071918.25778.jkeating@redhat.com> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706071512.22430.jkeating@redhat.com> <20070607211929.GH12450@neu.nirvana> <200706071918.25778.jkeating@redhat.com> Message-ID: <20070607233836.GN12450@neu.nirvana> On Thu, Jun 07, 2007 at 07:18:22PM -0400, Jesse Keating wrote: > On Thursday 07 June 2007 17:19:29 Axel Thimm wrote: > > Try > > > > man hg | egrep -2 '(rename|-f)' > > What version of hg are you playing with? # rpm -q mercurial mercurial-0.9.3-1.fc6 > The hg in rawhide for rename -f has: > > -f, --force forcibly copy over an existing managed file > > which is really not follow. 0.9.3 is the latest in rawhide, perhaps we need a > version bump. I don't think that will be much different than what FC6 currently ships - just try the man hg | egrep line above. The option -f/--follow is an option to hg log, hg grep etc, not hg rename. E.g. the "following" is not something you need to tell hg at node forking time (copy/rename), that happens automatically. It is only at retrospective querying that the propagations by default stop at copy operation/renames that you can change by using -f/--follow. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernie at codewiz.org Thu Jun 7 23:44:00 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 07 Jun 2007 19:44:00 -0400 Subject: Eliminating static binaries (Was: Unwanted RPM dependencies) In-Reply-To: <46680375.8090306@poolshark.org> References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> <4664CFF9.90606@codewiz.org> <20070605065813.GA5736@free.fr> <4665E902.8010106@codewiz.org> <20070606073239.GA2847@free.fr> <46666AAB.7020005@poolshark.org> <20070606132043.GA2833@free.fr> <20070606134126.GB1196485@hiwaay.net> <20070607063239.GA2848@free.fr> <46680375.8090306@poolshark.org> Message-ID: <46689840.3080907@codewiz.org> Denis Leroy wrote: > I believe the granularity of the linker is a single object file. So even > if you use just a small routine within a big object file, the whole > thing is linked with (if you think about how ld works internally and > what it has to do, it makes sense). True, but irrelevant. Because this behavior of linkers is well known, library implementors always have been splitting functions in separate compilation units. The reason you get 400KB of stuff in is that library calls are so interconnected that linking printf() could easily end up pulling in even the DNS resolver ;-) As a side note, today, glibc and other libraries designe for GCC only could use -ffunction-sections to achieve pretty much the same goal without creating that much debris and cutting build time considerably. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From sberry at northlc.com Thu Jun 7 23:49:37 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 18:49:37 -0500 Subject: a look at my spec file for Webmin In-Reply-To: References: <004b01c7a91e$9ee9e470$6701a8c0@yellobow><200706071815.41412.manuel@todo-linux.com><007f01c7a926$c8b2f050$6701a8c0@yellobow><20070607211830.A30740@xos037.xos.nl> Message-ID: <004b01c7a95e$877e9bb0$6701a8c0@yellobow> How is the contact made for the original sender I see no email or anything? Just a reply to the bug? Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Gianluca Sforna Sent: Thursday, June 07, 2007 4:27 PM To: Development discussions related to Fedora Core Subject: Re: a look at my spec file for Webmin On 6/7/07, Jos Vos wrote: > My advice: > > - Start reading . > > - Browse through some spec files, e.g. by going to the Fedora directory > with 4200+ src.rpm's and get all the spec files like this: > > mkdir /tmp/specs > for f in *.src.rpm; do > rpm2cpio $f | (cd /tmp/specs; cpio -iuvdm '*.spec') > done > > - Start experimenting and ask questions on a mailing list. > Add to that: - subscribe to fedora-package-review list, so you get an idea of the common mistakes a beginner does. This is even more useful if you need a sponsor, since you are supposed to do some reviews (partial, full, just comments, etc) in order to show your understanding of the guidelines. PS. btw, webim was already submitted for review in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184080 you may want to contact the original submitter and start from his spec file. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM From jkeating at redhat.com Thu Jun 7 23:49:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 19:49:32 -0400 Subject: Future SCM Technology In-Reply-To: <20070607233836.GN12450@neu.nirvana> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706071918.25778.jkeating@redhat.com> <20070607233836.GN12450@neu.nirvana> Message-ID: <200706071949.32897.jkeating@redhat.com> On Thursday 07 June 2007 19:38:36 Axel Thimm wrote: > I don't think that will be much different than what FC6 currently > ships - just try the man hg | egrep line above. The option -f/--follow > is an option to hg log, hg grep etc, not hg rename. > > E.g. the "following" is not something you need to tell hg at node > forking time (copy/rename), that happens automatically. It is only at > retrospective querying that the propagations by default stop at copy > operation/renames that you can change by using -f/--follow. Argle. That's awful. It should just follow it by default. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sberry at northlc.com Thu Jun 7 23:54:59 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 18:54:59 -0500 Subject: Feature idea: package an installer image as a grub entry beforeF8. In-Reply-To: <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com><200706060912.45498.jkeating@redhat.com><7dd7ab490706060953s39313390w9e4963add2bf9c01@mail.gmail.com><200706061254.22379.jkeating@redhat.com><604aa7910706061725j4c653c28of88442ce6d28b3a3@mail.gmail.com> <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> Message-ID: <004c01c7a95f$476e59b0$6701a8c0@yellobow> I really like this idea. Another thing in anaconda which would be nice if it can be implemented some way is to have speech files that ask the questions in a human voice and also give the choices when you use the gui install like next back skip. This would help a lot of blind people and I also believe this would be something that Fedora would lead the way on. I could do the voice files but I am not well versed enough to do coding yet unfortunately. I would like to though. Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Naheem Zaffar Sent: Thursday, June 07, 2007 3:55 PM To: Development discussions related to Fedora Core Subject: Re: Feature idea: package an installer image as a grub entry beforeF8. Can we currently upgrade via anaconda installed on the system? Maybe we should have some way to launch anaconda via grub? Get it to do the upgrade however it does that atm? to have a higher "live" time, maybe do the dep resolving beforehand (possibly downloading packages to a different location than the standard yum place_? A potential workflow: 1. Type "yum upgrade" (or something else "fedora upgrade"? or maybe some gui saying "upgrade to next version or something") 1a. Somehow find out if an upgrade is available. Maybe download latest anaconda - probably not installed as part of current install, but a separate boot entry. 2. Yum resolves dependencies and downloads them to a new location. 3. (default) Boot entries for anaconda are added and the user is asked to restart. 4. Anaconda starts 5. Anaconda does it's thing minus the normal screens asking for the info we already have - a simple upgrade with no (default) options to change package selection etc. The issue I think will be step 2 where yum may not be able to read the new comps file. In that case, just move that stage to after relaunching in anaconda (Order being 1,3,4,2,5). -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM From jkeating at redhat.com Thu Jun 7 23:55:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 19:55:57 -0400 Subject: Feature idea: package an installer image as a grub entry beforeF8. In-Reply-To: <004c01c7a95f$476e59b0$6701a8c0@yellobow> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> <004c01c7a95f$476e59b0$6701a8c0@yellobow> Message-ID: <200706071955.57344.jkeating@redhat.com> On Thursday 07 June 2007 19:54:59 Scott Berry wrote: > I really like this idea. ?Another thing in anaconda which would be nice if > it can be implemented some way is to have speech files that ask the > questions in a human voice and also give the choices when you use the gui > install like next back skip. ?This would help a lot of blind people and I > also believe this would be something that Fedora would lead the way on. ?I > could do the voice files but I am not well versed enough to do coding yet > unfortunately. ?I would like to though. Yikes. Including translated voice files for every prompt is going to make the installer get quite large (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jun 8 00:07:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 02:07:08 +0200 Subject: Future SCM Technology In-Reply-To: <200706071949.32897.jkeating@redhat.com> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706071918.25778.jkeating@redhat.com> <20070607233836.GN12450@neu.nirvana> <200706071949.32897.jkeating@redhat.com> Message-ID: <20070608000708.GO12450@neu.nirvana> On Thu, Jun 07, 2007 at 07:49:32PM -0400, Jesse Keating wrote: > On Thursday 07 June 2007 19:38:36 Axel Thimm wrote: > > I don't think that will be much different than what FC6 currently > > ships - just try the man hg | egrep line above. The option -f/--follow > > is an option to hg log, hg grep etc, not hg rename. > > > > E.g. the "following" is not something you need to tell hg at node > > forking time (copy/rename), that happens automatically. It is only at > > retrospective querying that the propagations by default stop at copy > > operation/renames that you can change by using -f/--follow. > > Argle. That's awful. It should just follow it by default. > cat >> ~/.hgrc << EOF [defaults] annotate = -f grep = -f log = -f EOF :) -- 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 sberry at northlc.com Fri Jun 8 00:09:40 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 19:09:40 -0500 Subject: Feature idea: package an installer image as a grub entrybeforeF8. In-Reply-To: <200706071955.57344.jkeating@redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com><3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com><004c01c7a95f$476e59b0$6701a8c0@yellobow> <200706071955.57344.jkeating@redhat.com> Message-ID: <000c01c7a961$53c8aa10$6701a8c0@yellobow> [Scott] Jesse, [Scott] Windows has had talking installs for their screen readers for a while now. If Fedora could do this I think you would have a leg up in the disability community. As long as the speech isn't horrid I would compromise to other suggestions. Scott From kzak at redhat.com Fri Jun 8 00:11:30 2007 From: kzak at redhat.com (Karel Zak) Date: Fri, 8 Jun 2007 02:11:30 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181250296.3472.23.camel@rousalka.dyndns.org> References: <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> Message-ID: <20070608001130.GP16879@petra.dvoda.cz> On Thu, Jun 07, 2007 at 11:04:56PM +0200, Nicolas Mailhot wrote: > Not surprisingly, someone like Andrew Morton that needs to rebase > regularly from Linus *and* trace transient patches uses quilt instead of > an exploded vcs Ask Linus what he thinks about Andrew's quilt :-) I think that's personal choice only. I'm almost sure that someone other (for example Linus) will use GIT instead quilt for same job. Karel -- Karel Zak From jkeating at redhat.com Fri Jun 8 00:11:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 20:11:55 -0400 Subject: Feature idea: package an installer image as a grub entrybeforeF8. In-Reply-To: <000c01c7a961$53c8aa10$6701a8c0@yellobow> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <200706071955.57344.jkeating@redhat.com> <000c01c7a961$53c8aa10$6701a8c0@yellobow> Message-ID: <200706072011.55693.jkeating@redhat.com> On Thursday 07 June 2007 20:09:40 Scott Berry wrote: > Windows has had talking installs for their screen readers for a while now. > If Fedora could do this I think you would have a leg up in the disability > community. ?As long as the speech isn't horrid I would compromise to other > suggestions. Doesn't windows have different CDs for each language though? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Fri Jun 8 00:26:54 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 07 Jun 2007 20:26:54 -0400 Subject: x86_64 nightmare on F7 In-Reply-To: <1181256559.20322.10.camel@shinybook.infradead.org> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <1181256559.20322.10.camel@shinybook.infradead.org> Message-ID: <1181262414.4534.1.camel@rivendell> On Thu, 2007-06-07 at 23:49 +0100, David Woodhouse wrote: > On Fri, 2007-06-08 at 00:12 +0200, Christoph Wickert wrote: > > Another example: With "yum groupinstall XFCE" I get a lot of i386 > > packages too. I can remove the i386 ones, but this will break the > > x86_64 versions. > > 'yum --exclude=\*.i386 groupinstall XFCE' btw > > Yes, yum is broken. But you _can_ make it behave vaguely sensibly for > installing new stuff, although it's hard to fix up the breakage it > leaves after the default install. David, yum is not broken. Broken implies it is unexpected behavior vs what was intended. It is exactly the intended behavior. It may be that the feature of installing compat arch is undesirable in certain situations of fedora use. However it is NOT that it is broken. I'd appreciate it if you'd get that straight. -sv From skvidal at linux.duke.edu Fri Jun 8 00:28:28 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 07 Jun 2007 20:28:28 -0400 Subject: x86_64 nightmare on F7 In-Reply-To: <1181257586.3950.41.camel@hal9000.oberschlesier.lan> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <1181256559.20322.10.camel@shinybook.infradead.org> <1181257586.3950.41.camel@hal9000.oberschlesier.lan> Message-ID: <1181262508.4534.4.camel@rivendell> On Fri, 2007-06-08 at 01:06 +0200, Christoph Wickert wrote: > Am Donnerstag, den 07.06.2007, 23:49 +0100 schrieb David Woodhouse: > > On Fri, 2007-06-08 at 00:12 +0200, Christoph Wickert wrote: > > > Another example: With "yum groupinstall XFCE" I get a lot of i386 > > > packages too. I can remove the i386 ones, but this will break the > > > x86_64 versions. > > > > 'yum --exclude=\*.i386 groupinstall XFCE' btw > > Thanks for that one. I already added the exclude statement to my yum > config permanently. > > > Yes, yum is broken. > > There are two questions: > Why does yum install i386 at all? > Why doesn't yum check for conflicts on a groupinstall? So obviously it > must be using using "rpm -i --force", which is pretty dangerous. rpm can install multiple identical files and the behavior you see is exactly how it supposed to handle multilib file installs. yum has not and will not use anything like rpm --force and in fact does not enable that capability in its interface to the rpm python modules. -sv From sberry at northlc.com Fri Jun 8 00:35:23 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 19:35:23 -0500 Subject: Feature idea: package an installer image as a grubentrybeforeF8. In-Reply-To: <200706072011.55693.jkeating@redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com><200706071955.57344.jkeating@redhat.com><000c01c7a961$53c8aa10$6701a8c0@yellobow> <200706072011.55693.jkeating@redhat.com> Message-ID: <001b01c7a964$ebe25190$6701a8c0@yellobow> You know I am not sure. I imagine they do. You know another idea would be to make a spin off the regular dvd and do it that way too. Maybe have that as a Fedora mirror download though? Would that work? Also projects like Orca use people out in the community for translating their speech maybe something like that could be the same with Fedora. I think the real problem would be finding a good speech engine that would work. Festival is okay but I understand there are other engines like espeak that might work too. You could use synthesized speech. Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Jesse Keating Sent: Thursday, June 07, 2007 7:12 PM To: fedora-devel-list at redhat.com Subject: Re: Feature idea: package an installer image as a grubentrybeforeF8. On Thursday 07 June 2007 20:09:40 Scott Berry wrote: > Windows has had talking installs for their screen readers for a while now. > If Fedora could do this I think you would have a leg up in the disability > community. ?As long as the speech isn't horrid I would compromise to other > suggestions. Doesn't windows have different CDs for each language though? -- Jesse Keating Release Engineer: Fedora From christoph.wickert at nurfuerspam.de Fri Jun 8 00:38:10 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 08 Jun 2007 02:38:10 +0200 Subject: x86_64 nightmare on F7 In-Reply-To: <20070607233137.GE31520@nostromo.devel.redhat.com> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <20070607233137.GE31520@nostromo.devel.redhat.com> Message-ID: <1181263090.6806.5.camel@hal9000.oberschlesier.lan> Am Donnerstag, den 07.06.2007, 19:31 -0400 schrieb Bill Nottingham: > > I can remove the i386 ones, but this will break the x86_64 > > versions. rpm -V tells me that not much of the package is left, in most > > cases only the contents of /usr/lib64 is still there. > > *That* is a bug. Can you file that, please? Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243224 BTW: I have to correct my previous statement. It's not _that_ bad as I thought, it's "just" locales and %doc missing, the rest ist still there. Also a big thanks to Seth for his clarifications. Christoph From dwmw2 at infradead.org Fri Jun 8 00:48:14 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 08 Jun 2007 01:48:14 +0100 Subject: x86_64 nightmare on F7 In-Reply-To: <1181262414.4534.1.camel@rivendell> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <1181256559.20322.10.camel@shinybook.infradead.org> <1181262414.4534.1.camel@rivendell> Message-ID: <1181263694.20322.23.camel@shinybook.infradead.org> On Thu, 2007-06-07 at 20:26 -0400, seth vidal wrote: > yum is not broken. Broken implies it is eexpected behavior vs what > was intended. It is exactly the intended behavior. It may be that the > feature of installing compat arch is undesirable in certain situations > of fedora use. However it is NOT that it is broken. I'd appreciate it > if you'd get that straight. As long as it gets fixed I don't mind much whether we call it 'feature' or 'bug'. -- dwmw2 From david at fubar.dk Fri Jun 8 00:52:06 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 07 Jun 2007 20:52:06 -0400 Subject: Feature idea: package an installer image as a grub entrybeforeF8. In-Reply-To: <000c01c7a961$53c8aa10$6701a8c0@yellobow> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> <004c01c7a95f$476e59b0$6701a8c0@yellobow> <200706071955.57344.jkeating@redhat.com> <000c01c7a961$53c8aa10$6701a8c0@yellobow> Message-ID: <1181263926.4727.3.camel@zelda.fubar.dk> On Thu, 2007-06-07 at 19:09 -0500, Scott Berry wrote: > [Scott] Jesse, > [Scott] > Windows has had talking installs for their screen readers for a while now. > If Fedora could do this I think you would have a leg up in the disability > community. As long as the speech isn't horrid I would compromise to other > suggestions. We wanted to do this for the Fedora 7 Live CD (which is accessible; you can start Orca by pressing Ctrl+S for one second at the login screen) but it involved an upgrade of atspi (because anaconda runs as uid 0) and then the freeze happened. Definitely worth doing for F8. David From jkeating at redhat.com Fri Jun 8 00:49:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 20:49:46 -0400 Subject: Feature idea: package an installer image as a grubentrybeforeF8. In-Reply-To: <001b01c7a964$ebe25190$6701a8c0@yellobow> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <200706072011.55693.jkeating@redhat.com> <001b01c7a964$ebe25190$6701a8c0@yellobow> Message-ID: <200706072049.46339.jkeating@redhat.com> On Thursday 07 June 2007 20:35:23 Scott Berry wrote: > You know I am not sure. ?I imagine they do. ?You know another idea would be > to make a spin off the regular dvd and do it that way too. ?Maybe have that > as a Fedora mirror download though? ?Would that work? ?Also projects like > Orca use people out in the community for translating their speech maybe > something like that could be the same with Fedora. ?I think the real > problem would be finding a good speech engine that would work. ?Festival is > okay but I understand there are other engines like espeak that might work > too. ?You could use synthesized speech. Having done QA at Microsoft, and now here at Fedora as part of spinning distros, it's far easier to QA a single iso set with multiple translations than to QA a multitude of iso sets. Really not something I want to get into, but that's just me, I'm a lazy bastard. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Fri Jun 8 00:53:14 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 07 Jun 2007 20:53:14 -0400 Subject: x86_64 nightmare on F7 In-Reply-To: <1181263694.20322.23.camel@shinybook.infradead.org> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <1181256559.20322.10.camel@shinybook.infradead.org> <1181262414.4534.1.camel@rivendell> <1181263694.20322.23.camel@shinybook.infradead.org> Message-ID: <1181263994.4534.7.camel@rivendell> On Fri, 2007-06-08 at 01:48 +0100, David Woodhouse wrote: > On Thu, 2007-06-07 at 20:26 -0400, seth vidal wrote: > > yum is not broken. Broken implies it is eexpected behavior vs what > > was intended. It is exactly the intended behavior. It may be that the > > feature of installing compat arch is undesirable in certain situations > > of fedora use. However it is NOT that it is broken. I'd appreciate it > > if you'd get that straight. > > As long as it gets fixed I don't mind much whether we call it 'feature' > or 'bug'. Fixed implies broken, so you're begging the question. I think a lot of folks agree about needing to change some default behaviors. How they get changed I don't know, yet. -sv From sberry at northlc.com Fri Jun 8 00:59:36 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 19:59:36 -0500 Subject: Feature idea: package an installer image as a grubentrybeforeF8. In-Reply-To: <1181263926.4727.3.camel@zelda.fubar.dk> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com><3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com><004c01c7a95f$476e59b0$6701a8c0@yellobow><200706071955.57344.jkeating@redhat.com><000c01c7a961$53c8aa10$6701a8c0@yellobow> <1181263926.4727.3.camel@zelda.fubar.dk> Message-ID: <002401c7a968$4f300af0$6701a8c0@yellobow> David, Could this work for the Dvd too that would be awesome. Oh man would that be great. Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of David Zeuthen Sent: Thursday, June 07, 2007 7:52 PM To: Development discussions related to Fedora Core Subject: RE: Feature idea: package an installer image as a grubentrybeforeF8. On Thu, 2007-06-07 at 19:09 -0500, Scott Berry wrote: > [Scott] Jesse, > [Scott] > Windows has had talking installs for their screen readers for a while now. > If Fedora could do this I think you would have a leg up in the disability > community. As long as the speech isn't horrid I would compromise to other > suggestions. We wanted to do this for the Fedora 7 Live CD (which is accessible; you can start Orca by pressing Ctrl+S for one second at the login screen) but it involved an upgrade of atspi (because anaconda runs as uid 0) and then the freeze happened. Definitely worth doing for F8. David -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM From sberry at northlc.com Fri Jun 8 01:00:52 2007 From: sberry at northlc.com (Scott Berry) Date: Thu, 7 Jun 2007 20:00:52 -0500 Subject: Feature idea: package an installer image as a grubentrybeforeF8. In-Reply-To: <200706072049.46339.jkeating@redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com><200706072011.55693.jkeating@redhat.com><001b01c7a964$ebe25190$6701a8c0@yellobow> <200706072049.46339.jkeating@redhat.com> Message-ID: <002501c7a968$7b2a2140$6701a8c0@yellobow> Jesse, Grin! I see your point though. Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Jesse Keating Sent: Thursday, June 07, 2007 7:50 PM To: fedora-devel-list at redhat.com Subject: Re: Feature idea: package an installer image as a grubentrybeforeF8. On Thursday 07 June 2007 20:35:23 Scott Berry wrote: > You know I am not sure. ?I imagine they do. ?You know another idea would be > to make a spin off the regular dvd and do it that way too. ?Maybe have that > as a Fedora mirror download though? ?Would that work? ?Also projects like > Orca use people out in the community for translating their speech maybe > something like that could be the same with Fedora. ?I think the real > problem would be finding a good speech engine that would work. ?Festival is > okay but I understand there are other engines like espeak that might work > too. ?You could use synthesized speech. Having done QA at Microsoft, and now here at Fedora as part of spinning distros, it's far easier to QA a single iso set with multiple translations than to QA a multitude of iso sets. Really not something I want to get into, but that's just me, I'm a lazy bastard. -- Jesse Keating Release Engineer: Fedora From mclasen at redhat.com Fri Jun 8 01:00:47 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 07 Jun 2007 21:00:47 -0400 Subject: Feature idea: package an installer image as a grub entrybeforeF8. In-Reply-To: <000c01c7a961$53c8aa10$6701a8c0@yellobow> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> <004c01c7a95f$476e59b0$6701a8c0@yellobow> <200706071955.57344.jkeating@redhat.com> <000c01c7a961$53c8aa10$6701a8c0@yellobow> Message-ID: <1181264447.4404.4.camel@localhost.localdomain> On Thu, 2007-06-07 at 19:09 -0500, Scott Berry wrote: > [Scott] Jesse, > [Scott] > Windows has had talking installs for their screen readers for a while now. > If Fedora could do this I think you would have a leg up in the disability > community. As long as the speech isn't horrid I would compromise to other > suggestions. Using the live cd installer should almost get you there. It runs in a full desktop environment and could work with the a11y framework we have in the desktop. The only problem is that it runs as root. From shams at orcon.net.nz Fri Jun 8 01:52:41 2007 From: shams at orcon.net.nz (Shams) Date: Fri, 8 Jun 2007 13:52:41 +1200 Subject: Fedora 7: lib64 directories Message-ID: Hi, I have installed Fedora 7 on a 64-bit cpu. I noticed that Fedora has both /usr/lib and /usr/lib64. 1. Is this only on Fedora or standard across many Linux distros? 2. Technically why is this needed, can it be just solved with having all the 64-bit libs in /usr/lib? 3. Also if I have a 64-bit cpu that is not capable of supporting IA32 will then only /usr/lib exist? 4. Also does this mean that a lot of installed packages are still 32-bit? Thanks Shams From jkeating at redhat.com Fri Jun 8 01:58:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 21:58:06 -0400 Subject: Fedora 7: lib64 directories In-Reply-To: References: Message-ID: <200706072158.06683.jkeating@redhat.com> On Thursday 07 June 2007 21:52:41 Shams wrote: > I have installed Fedora 7 on a 64-bit cpu. > I noticed that Fedora has both /usr/lib and /usr/lib64. > > 1. Is this only on Fedora or standard across many Linux distros? Standard. > 2. Technically why is this needed, can it be just ?solved with having all > the 64-bit libs in /usr/lib? The libraries have the same file names, so to be able to support multilib (that is running either 32bit or 64bit content) you need to separate the 32bit content from the 64bit content. > 3. Also if I have a 64-bit cpu that is not capable of supporting IA32 will > then only /usr/lib exist? Erm, I'm not sure of any such CPU that we support in existence. ia64 may be in that boat, but I can't remember if it uses /usr/lib64 as well. > 4. Also does this mean that a lot of installed packages are still 32-bit? Your installed packages are x86_64, although many copies of the 32bit packages may be installed as well for 32bit compatibility, so that if you need to run a piece of software that happens to be 32bit, it'll hopefully Just Work and you don't have to think about things like multilib. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Jun 8 02:07:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 19:07:04 -0700 Subject: Fedora 7: lib64 directories In-Reply-To: References: Message-ID: <1181268424.4070.312.camel@localhost.localdomain> On Fri, 2007-06-08 at 13:52 +1200, Shams wrote: > Hi, > > I have installed Fedora 7 on a 64-bit cpu. > I noticed that Fedora has both /usr/lib and /usr/lib64. > > 1. Is this only on Fedora or standard across many Linux distros? > > 2. Technically why is this needed, can it be just solved with having all > the 64-bit libs in /usr/lib? > > 3. Also if I have a 64-bit cpu that is not capable of supporting IA32 will > then only /usr/lib exist? > > 4. Also does this mean that a lot of installed packages are still 32-bit? > This is an end user question and should be directed to fedora-list instead of fedora-devel-list. fedora-devel-list is for discussions about creating and directing the next version of Fedora. Thanks, Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwilson at redhat.com Fri Jun 8 03:20:36 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 07 Jun 2007 23:20:36 -0400 Subject: Fedora 7: lib64 directories In-Reply-To: <200706072158.06683.jkeating@redhat.com> References: <200706072158.06683.jkeating@redhat.com> Message-ID: <4668CB04.7070506@redhat.com> Jesse Keating wrote: > On Thursday 07 June 2007 21:52:41 Shams wrote: >> 3. Also if I have a 64-bit cpu that is not capable of supporting IA32 will >> then only /usr/lib exist? > > Erm, I'm not sure of any such CPU that we support in existence. ia64 may be > in that boat, but I can't remember if it uses /usr/lib64 as well. ia64 just uses /usr/lib. -- Jarod Wilson jwilson at redhat.com From mike at miketc.com Fri Jun 8 03:38:03 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 07 Jun 2007 22:38:03 -0500 Subject: fedora devel mirroring? In-Reply-To: <1181254720.23696.13.camel@neuromancer> References: <1181247748.4097.34.camel@raptor.sr.unh.edu> <1181254720.23696.13.camel@neuromancer> Message-ID: <1181273883.24214.1.camel@scrappy.miketc.com> On Thu, 2007-06-07 at 18:18 -0400, Thomas J. Baker wrote: > I believe I'm aware of the structure change and I'm rsyncing all of > mirrors.kernel.org::fedora. The fedora/development and > fedora/core/development both seem to be the same on my mirror. In fact, > I just visited http://mirrors.kernel.org/fedora/development/i386/os/ and > it indeed is only up to May 25th. I checked it out as well and he is correct, May 27th is the last update. I would email someone (an admin or webmaster) and maybe there is a problem on their end. I do that all the time on a site I mirror from and they usually respond pretty quick and let me know of any problems. -- Mike Chambers Madisonville, KY "Best little town on Earth!" From jwilson at redhat.com Fri Jun 8 03:42:12 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 07 Jun 2007 23:42:12 -0400 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <46684600.3050803@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> Message-ID: <4668D014.7090804@redhat.com> Hans de Goede wrote: > Leszek Matok wrote: >> Dnia 07-06-2007, czw o godzinie 11:06 -0400, Bill Nottingham napisa?(a): >>> What cards is this useful for that we don't ship firmware >>> for? Anything other than bcm43xx and ralink? >> For example, there are millions of potential speedtch.ko users here in >> Europe. >> > > Okay, > > I think we need to build a list of all potential needed / wanted > firmware, with URL's where to download it and instructions howto unpack it. > > We then also need to start contacting the manufacturers asking for > redistribution permission. > > Here is a start of the list with things metioned sofar: > sil firmware (for prism and prism_pci) > bcm firmware > ralink firmware > speedtouch firmware > alsa firmware http://www.linuxtv.org/downloads/firmware/ Not sure whether or not someone got the okay for all of those to be redistributed or not... -- Jarod Wilson jwilson at redhat.com From mike at miketc.com Fri Jun 8 03:44:25 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 07 Jun 2007 22:44:25 -0500 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <200706071931.36736.jkeating@redhat.com> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <200706071931.36736.jkeating@redhat.com> Message-ID: <1181274265.24214.3.camel@scrappy.miketc.com> On Thu, 2007-06-07 at 19:31 -0400, Jesse Keating wrote: > On Thursday 07 June 2007 19:34:07 David Woodhouse wrote: > > Yes, reply-to munging is a very bad idea. It would be nice to turn it > > off. > https://www.redhat.com/mailman/listinfo/fedora-devel-list I think Warren is listed as the Admin if that helps get it done, or mentioned anyway. -- Mike Chambers Madisonville, KY "Best little town on Earth!" From bernie at codewiz.org Fri Jun 8 04:35:29 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Fri, 08 Jun 2007 00:35:29 -0400 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <1181274265.24214.3.camel@scrappy.miketc.com> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <200706071931.36736.jkeating@redhat.com> <1181274265.24214.3.camel@scrappy.miketc.com> Message-ID: <4668DC91.6060403@codewiz.org> Mike Chambers wrote: > On Thu, 2007-06-07 at 19:31 -0400, Jesse Keating wrote: >> On Thursday 07 June 2007 19:34:07 David Woodhouse wrote: >>> Yes, reply-to munging is a very bad idea. It would be nice to turn it >>> off. > >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > I think Warren is listed as the Admin if that helps get it done, or > mentioned anyway. Added to Cc. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From Lam at Lam.pl Fri Jun 8 05:08:37 2007 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 08 Jun 2007 07:08:37 +0200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <4668DC91.6060403@codewiz.org> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <200706071931.36736.jkeating@redhat.com> <1181274265.24214.3.camel@scrappy.miketc.com> <4668DC91.6060403@codewiz.org> Message-ID: <1181279317.9479.3.camel@pensja.lam.pl> Dnia 08-06-2007, pi? o godzinie 00:35 -0400, Bernardo Innocenti napisa?(a): > Mike Chambers wrote: > > On Thu, 2007-06-07 at 19:31 -0400, Jesse Keating wrote: > >> On Thursday 07 June 2007 19:34:07 David Woodhouse wrote: > >>> Yes, reply-to munging is a very bad idea. It would be nice to turn it > >>> off. > > > >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > I think Warren is listed as the Admin if that helps get it done, or > > mentioned anyway. > > Added to Cc. The same, done better. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From shams at orcon.net.nz Fri Jun 8 06:09:54 2007 From: shams at orcon.net.nz (Shams) Date: Fri, 8 Jun 2007 18:09:54 +1200 Subject: Fedora 7: Gnome menu and Evolution Message-ID: Hi, I installed Evolution and it too me a while to find where it was installed in the Gnome menu. It is Internet -> Mail but why? Shouldn't it should just be called Internet -> Evolution or Internet -> Evolution Email Client Just like Fiefox shows up as Internet -> Firefox Web Browser Just like ThunderBird shows up as Internet -> ThunderBird And just like Outlook Express shows up as All Program -> Outlook Express Why hide its identity? Thanks Shams From fedora at camperquake.de Fri Jun 8 06:36:35 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 8 Jun 2007 08:36:35 +0200 Subject: Feature idea: package an installer image as a grub entry beforeF8. In-Reply-To: <200706071955.57344.jkeating@redhat.com> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <3adc77210706071354v33fd174bid4d494ba36b6aaf4@mail.gmail.com> <004c01c7a95f$476e59b0$6701a8c0@yellobow> <200706071955.57344.jkeating@redhat.com> Message-ID: <20070608083635.07c6eee5@banea.int.addix.net> Hi. On Thu, 7 Jun 2007 19:55:57 -0400, Jesse Keating wrote: > Yikes. Including translated voice files for every prompt is going to > make the installer get quite large (: It may be worth a try. Speech can be compressed quite effectively. It will take up some bytes, though :) From pertusus at free.fr Fri Jun 8 06:35:54 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 8 Jun 2007 08:35:54 +0200 Subject: a look at my spec file for Webmin In-Reply-To: <004b01c7a95e$877e9bb0$6701a8c0@yellobow> References: <004b01c7a95e$877e9bb0$6701a8c0@yellobow> Message-ID: <20070608063554.GB2846@free.fr> On Thu, Jun 07, 2007 at 06:49:37PM -0500, Scott Berry wrote: > How is the contact made for the original sender I see no email or anything? > Just a reply to the bug? You should see a mail adress only if you login to bugzilla. This hopefully helps reducing the spam. -- Pat From markg85 at gmail.com Fri Jun 8 07:18:01 2007 From: markg85 at gmail.com (Mark) Date: Fri, 8 Jun 2007 09:18:01 +0200 Subject: Fedora 8 ideas In-Reply-To: <46688CB8.5090004@codewiz.org> References: <46688CB8.5090004@codewiz.org> Message-ID: <6e24a8e80706080018n5b883419nbce6b5b48d84088e@mail.gmail.com> Idea: - Make the login stuff (from GDM/KDM to the Desktop) all in fullscreen and show the desktop when everything is loaded. might be better user expereice and that way the KDE and Gnome login stuff can finally be equal. 2007/6/8, Bernardo Innocenti : > > Goede, J.W.R. de wrote: > > > 3 plugin buddy > > ============== > > > > Like codec buddy, but then for firefox plugins. Why? > > because firefox plugin find service doesn't undserstand to > > install nspluginwrapper (needs to get into Fedora) and then > > flash on x86_64. Nor knows it to change the selinux type of > > realplayer to get it to work with our default enabled > > selinux policy. > > This is why I hate programs like Firefox and Thunderbird > that come their own custom package system. > > No matter how cool Firefox plugins are, if all programs > did such things, Linux systems would become as maintainable > and robust as Windows. > > We could kill off Firefox's plugin system and package > useful plugins as RPMs instead. Not to say anything > about the custom localization system. > > Maybe this is material for a different flame, but who > likes Firefox's and Thunderbird's own implementations > of keyring, with different passwords and interfaces? > And what about the custom filetype associations? > > -- > // Bernardo Innocenti > \X/ http://www.codewiz.org/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giallu at gmail.com Fri Jun 8 07:41:09 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 8 Jun 2007 09:41:09 +0200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <1181259247.20322.20.camel@shinybook.infradead.org> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> Message-ID: On 6/8/07, David Woodhouse wrote: > On Thu, 2007-06-07 at 19:26 -0400, Bernardo Innocenti wrote: > > could we change the list configuration not to munge > > the Reply-To header, so that when we "Reply All", we > > actually don't loose the Cc list? > > > > The way it's configured now makes it very difficult to > > notice own's replies in threads. > > Yes, reply-to munging is a very bad idea. It would be nice to turn it > off. > This debate looks like the tabs/spaces or the default MTA ones... Let me say I'm just fine with the munging, probably because: 1. I don't care about the CC list 2. gmail does a fine job with threads anyway 3. w/o munging I hit reply and the mail does not go to the list... of course this is just my 0.02 From dev at nigelj.com Fri Jun 8 07:56:22 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 08 Jun 2007 19:56:22 +1200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> Message-ID: <46690BA6.5040504@nigelj.com> Gianluca Sforna wrote: > On 6/8/07, David Woodhouse wrote: >> On Thu, 2007-06-07 at 19:26 -0400, Bernardo Innocenti wrote: >> > could we change the list configuration not to munge >> > the Reply-To header, so that when we "Reply All", we >> > actually don't loose the Cc list? >> > >> > The way it's configured now makes it very difficult to >> > notice own's replies in threads. >> >> Yes, reply-to munging is a very bad idea. It would be nice to turn it >> off. >> > > This debate looks like the tabs/spaces or the default MTA ones... > > Let me say I'm just fine with the munging, probably because: > 1. I don't care about the CC list Some people do > 2. gmail does a fine job with threads anyway I don't think a great number of people on the list use gmail, but decent point > 3. w/o munging I hit reply and the mail does not go to the list... This is the thing that really bugs me. I don't think there is a clean solution to get the best of both worlds though (sadly). N.J. From nicolas.mailhot at laposte.net Fri Jun 8 07:58:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 8 Jun 2007 09:58:48 +0200 (CEST) Subject: Fedora 8 ideas In-Reply-To: <46688CB8.5090004@codewiz.org> References: <46688CB8.5090004@codewiz.org> Message-ID: <9954.192.54.193.51.1181289528.squirrel@rousalka.dyndns.org> Le Ven 8 juin 2007 00:54, Bernardo Innocenti a ?crit : > This is why I hate programs like Firefox and Thunderbird > that come their own custom package system. +1 If we could get xulrunner in and package popular firefox pluggins for F8 that would be way better than multiplying foo-buddy bandaids -- Nicolas Mailhot From fedora at camperquake.de Fri Jun 8 08:04:29 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 8 Jun 2007 10:04:29 +0200 Subject: Fedora 8 ideas In-Reply-To: <46688CB8.5090004@codewiz.org> References: <46688CB8.5090004@codewiz.org> Message-ID: <20070608100429.310909e5@banea.int.addix.net> Hi. On Thu, 07 Jun 2007 18:54:48 -0400, Bernardo Innocenti wrote: > We could kill off Firefox's plugin system and package > useful plugins as RPMs instead. Not to say anything > about the custom localization system. Well, I for one like that I can install plugins without having to wrangle with RPM. From pmatilai at laiskiainen.org Fri Jun 8 08:08:39 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 8 Jun 2007 11:08:39 +0300 (EEST) Subject: OCaml find-requires and find-provides In-Reply-To: <46571CAB.203@redhat.com> References: <46571CAB.203@redhat.com> Message-ID: On Fri, 25 May 2007, Richard W.M. Jones wrote: > Here are some working find-requires and find-provides scripts for OCaml. The > produce dependencies according to what I wrote about here: > > https://www.redhat.com/archives/fedora-packaging/2007-May/msg00105.html > > (Ignore the earlier versions of the same scripts attached to that email). > > To use them is simply a matter of adding the following lines to a spec file: > > %define _use_internal_dependency_generator 0 > %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh > %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh > > Also attached is a patch to the ocaml.spec file to install these. > Hey, if/when you think these are ready for widespread use, please drop a note to rpm-maint at lists.rpm.org for inclusion... - Panu - From fedora at leemhuis.info Fri Jun 8 08:36:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 08 Jun 2007 10:36:15 +0200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <46690BA6.5040504@nigelj.com> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <46690BA6.5040504@nigelj.com> Message-ID: <466914FF.5080506@leemhuis.info> On 08.06.2007 09:56, Nigel Jones wrote: > Gianluca Sforna wrote: > [...] > I don't think there is a clean solution to get the best of both worlds > though (sadly). Agreed. But we should choose one side and stick through it throughout most of our mailing lists to avoid confusion. CU thl From jnovy at redhat.com Fri Jun 8 08:36:42 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 08 Jun 2007 10:36:42 +0200 Subject: tetex-doc is not noarch? In-Reply-To: References: Message-ID: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> On Thu, 2007-06-07 at 13:16 -0400, Neal Becker wrote: > Seems a bit odd: > tetex-doc x86_64 Yup, this is odd. The TeXLive 2007 packages which are now under review: http://bugzilla.redhat.com/229180 http://bugzilla.redhat.com/242416 and splits the TeXLive into two parts just for this reason (the largest part -> texmf tree, docs) is noarch and only the binary part, which is arch specific, is packaged separately thanks to the better design of TeXLive. The packages are now in a ready-to-use(tm) state and needs review, please help with it so that we can get rid of TeTeX soon. Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From giallu at gmail.com Fri Jun 8 08:42:52 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 8 Jun 2007 10:42:52 +0200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <466914FF.5080506@leemhuis.info> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <46690BA6.5040504@nigelj.com> <466914FF.5080506@leemhuis.info> Message-ID: On 6/8/07, Thorsten Leemhuis wrote: > On 08.06.2007 09:56, Nigel Jones wrote: > > Gianluca Sforna wrote: > > [...] > > I don't think there is a clean solution to get the best of both worlds > > though (sadly). > > Agreed. But we should choose one side and stick through it throughout > most of our mailing lists to avoid confusion. +1 I'm costantly sending private replies on fedora-laptop... From oliver at linux-kernel.at Fri Jun 8 08:45:17 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jun 2007 10:45:17 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46686D85.5000603@redhat.com> References: <46686D85.5000603@redhat.com> Message-ID: <4669171D.90906@linux-kernel.at> Hi Brendan! On 06/07/2007 10:41 PM, Brendan Conoboy wrote: [ ... ] > Inside Red Hat, my group (GES) creates custom compilers and embedded > Linux systems for our customers. We have done this for many years, > using various upstream sources, building natively and with cross tools. > For the last few years, we have used either RHEL or Fedora as our > upstream source base. Good self introduction. Now we know, that you know what you're talking 'bout. :-) [ ... ] > I would like to see cross compilation become a standard method in > Fedora. It scales where native builds don't. There might be faster arm > chips these days, but lets not forget all the underpowered embedded CPUs > and costly systems like s390. Bootstrapping is simplified. People > without access to hardware can work on build problems (Simulators are > good for this too). True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*... > What are the hurdles to adoption? Broadly, they break down into > technical and social: > > Technical: There must be cross compilers before we can cross compile. > The build system must be enhanced to support cross compilation. Finally, > packages must be modified to support cross compilation. If you would have not written this, I would. :-) Yes, that's the first part. There where already a few threads about cross compilers for Fedora; I don't know what the outcome is/was. It seems to be some never ending story. :-( I saw some cross compilers in CentOS :-) > Social: As a volunteer effort, it is unreasonable to expect existing > package maintainers to do the work necessary to support cross > compilation. There must be people to take on that responsibility and > work with upstream and package maintainers to integrate the necessary > changes. I think that's the same as with secondary arches. Yes, there must be some team supporting the arch, if it's done via cross compilers or on native hardware; But with one difference: The people who are involved in the 2ndary arch stuff, might not be very experienced with cross compilation; Like me and Alpha for example. > I don't have fast and easy answers to all of the above, Nobody would expect... I don't have as well. Just posting my 2 cent... > but I would like > to have a discussion about them. My group may be able to offer > expertise, patches and some man power toward this goal. What do you think? I think for Alpha we will have enough fast machines that can get the job done. I don't know about the other arches.... If there are volunteers for a arch and you have some man power who can support the ArchTeam, that would be great - I think. If the arch-team doesn't want cross compilation..... Let 'em alone. :-) Best, Oliver From oliver at linux-kernel.at Fri Jun 8 09:10:52 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 08 Jun 2007 11:10:52 +0200 Subject: Fedora and Cross Compiling In-Reply-To: References: <46686D85.5000603@redhat.com> Message-ID: <46691D1C.1060004@linux-kernel.at> On 06/07/2007 11:42 PM, Gianluca Sforna wrote: > On 6/7/07, Brendan Conoboy wrote: > >> >> I don't have fast and easy answers to all of the above, but I would like >> to have a discussion about them. My group may be able to offer >> expertise, patches and some man power toward this goal. What do you >> think? > > I think that would be wonderful to have Fedora (or a significant > subset of it) available for my Linksys NSLU2, since it's the only way > to resurrect it from the drawer I buried it after I had enough of the > unslung (debian based) firmware... Seems there are a lot of of people who want to run Fedora on everything that has some CPU. I wonder when the first watch and coffee machine comes out; Running Fedora of course. :-) Just joking. If there would be a Fedora port to NSLU, I would think about buying such a piece and replacing my old Pentium box. :-) -of From sundaram at fedoraproject.org Fri Jun 8 09:12:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 14:42:39 +0530 Subject: Fedora 7: Gnome menu and Evolution In-Reply-To: References: Message-ID: <46691D87.2010505@fedoraproject.org> Shams wrote: > Hi, > > I installed Evolution and it too me a while to find where it was installed > in the Gnome menu. > > It is Internet -> Mail > > but why? > > Shouldn't it should just be called Internet -> Evolution or Internet -> > Evolution Email Client > > Just like Fiefox shows up as Internet -> Firefox Web Browser > Just like ThunderBird shows up as Internet -> ThunderBird > > And just like Outlook Express shows up as All Program -> Outlook Express > > Why hide its identity? We already had a discussion along similar lines in this list before so you might want to look at the archives in fedora-devel. I noticed that you have been cross posting the recent mails. Don't do that. Rahul From andy at warmcat.com Fri Jun 8 09:21:56 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 08 Jun 2007 10:21:56 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <4669171D.90906@linux-kernel.at> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> Message-ID: <46691FB4.1090508@warmcat.com> Oliver Falk wrote: >> I would like to see cross compilation become a standard method in >> Fedora. It scales where native builds don't. There might be faster arm >> chips these days, but lets not forget all the underpowered embedded CPUs >> and costly systems like s390. Bootstrapping is simplified. People >> without access to hardware can work on build problems (Simulators are >> good for this too). > > True. But is cross compilation really as reliable as native compilation > is? I'm not experienced with cross compilation... But I think some > errors will only occur on *real native hardware*... Cross toolchains are made like this: you use your normal host compiler, for i386 say, to compile the gcc sources configured to emit target, say ARM, code. So you end up with an i386 executable compiler that emits ARM code. Native compilers would be built on an ARM box or emulation creating an ARM executable compiler that emits ARM code. But in both cases, the compiler is coming from the same gcc sources. In either case, if you give it some C to compile, it should emit the same ARM object file, one happens to emit that ARM object code with a compiler that is built from i386 instructions itself and another does it with the same compiler built from ARM instructions itself. In this way "real native hardware" has absolutely *nothing* to do with it. I also went through Brendan's wandering through the desert of alternative build methods, I started with an NBD-mounted filesystem on a n x86 box and native compilers in there that ran on my 180MHz ARM9 board with 32MB of SDRAM (and swap over NBD that worked incidentally). Compiling a kernel on that worked, but gave me plenty of time, 8 hours or so IIRC, to ruminate over how addressing the 'fearsome' cross monster would probably be less painful than going on that way. And it really was just another way to get the same compiler sources to emit the same object faster by running it on a better box... it's just a few minutes now. > If there are volunteers for a arch and you have some man power who can > support the ArchTeam, that would be great - I think. If the arch-team > doesn't want cross compilation..... Let 'em alone. :-) Cross is a lot less mysterious and magical than it sounds. Once it is sorted out according to Fedora's high engineering standards, being able to build for any supported arch on one physical platform with one filesystem at native platform speed will in fact be simpler, faster, more conistent and cheaper than the workarounds. -Andy From opensource at till.name Fri Jun 8 09:23:13 2007 From: opensource at till.name (Till Maas) Date: Fri, 08 Jun 2007 11:23:13 +0200 Subject: Fedora 8 ideas In-Reply-To: <46688CB8.5090004@codewiz.org> References: <46688CB8.5090004@codewiz.org> Message-ID: <200706081123.15298.opensource@till.name> On Fr Juni 8 2007, Bernardo Innocenti wrote: > This is why I hate programs like Firefox and Thunderbird > that come their own custom package system. Is there a more general alternative to this? rpm does not support installation by an unprivileged user afaik. And this is what all custom packages systems that come to my mind allow (Perl/Cpan, ruby/gems, Haskell/Cabal, Firefox/Thunderbird/XPI). Regards, Till From obi at unixkiste.org Fri Jun 8 09:26:48 2007 From: obi at unixkiste.org (Stefan Held) Date: Fri, 08 Jun 2007 11:26:48 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <20070607145703.GB25221@nostromo.devel.redhat.com> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> Message-ID: <1181294808.3782.0.camel@workstation.unixkiste.local> Am Donnerstag, den 07.06.2007, 10:57 -0400 schrieb Bill Nottingham: > fedora-logos is mentioned by name in the EULA. I'd prefer to keep it simple > (especially if we're deprecating the theming of grub) I would prefer to have such a package so that those of us who want the "normal" grub behavior back could do that. > Bill Stefan -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dwmw2 at infradead.org Fri Jun 8 09:35:15 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 08 Jun 2007 10:35:15 +0100 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <46690BA6.5040504@nigelj.com> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <46690BA6.5040504@nigelj.com> Message-ID: <1181295315.20322.27.camel@shinybook.infradead.org> On Fri, 2007-06-08 at 19:56 +1200, Nigel Jones wrote: > > 3. w/o munging I hit reply and the mail does not go to the list... > This is the thing that really bugs me. If it bugs you, then why do you hit 'Reply' and not 'Reply to all'? > I don't think there is a clean solution to get the best of both worlds > though (sadly). There isn't. Nevertheless -- a mail which was accidentally sent to only one person can be sent again to the list if you so desire. A message which you _intended_ to be private and which you accidentally sent to the list because of Reply-To: munging cannot ever be recalled. http://www.unicom.com/pw/reply-to-harmful.html -- dwmw2 From sundaram at fedoraproject.org Fri Jun 8 09:35:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 15:05:04 +0530 Subject: tetex-doc is not noarch? In-Reply-To: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> References: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> Message-ID: <466922C8.1090402@fedoraproject.org> Jindrich Novy wrote: > On Thu, 2007-06-07 at 13:16 -0400, Neal Becker wrote: >> Seems a bit odd: >> tetex-doc x86_64 > > Yup, this is odd. > > The TeXLive 2007 packages which are now under review: > > http://bugzilla.redhat.com/229180 > http://bugzilla.redhat.com/242416 > > and splits the TeXLive into two parts just for this reason (the largest > part -> texmf tree, docs) is noarch and only the binary part, which is > arch specific, is packaged separately thanks to the better design of > TeXLive. > > The packages are now in a ready-to-use(tm) state and needs review, > please help with it so that we can get rid of TeTeX soon. > You should update http://fedoraproject.org/wiki/Releases/FeatureTexLive and added it to Fedora 8 feature list. Rahul From buildsys at redhat.com Fri Jun 8 09:47:32 2007 From: buildsys at redhat.com (Build System) Date: Fri, 8 Jun 2007 05:47:32 -0400 Subject: rawhide report: 20070608 changes Message-ID: <200706080947.l589lWpe003304@porkchop.devel.redhat.com> New package evolution-exchange Evolution plugin to interact with MS Exchange Server New package min12xxw Converts PBM stream to Minolta printer language New package perl-Compress-Raw-Bzip2 Low-Level Interface to bzip2 compression library New package xbiso ISO extraction utility for xdvdfs images Updated Packages: CGAL-3.3-4.fc8 -------------- * Thu Jun 07 2007 Laurent Rineau - 3.3-4.fc8 - Move the makefile back to %{_datadir}/CGAL, and rename it cgal.mk (sync with Debian package). That file is not a config file, but just an example .mk file that can be copied and adapted by users. - Fix the %{_sysconfdir}/profile.d/cgal.* files (the csh one was buggy). - CGAL-devel now requires all its dependancies. NetworkManager-1:0.6.5-5.fc8 ---------------------------- * Thu Jun 07 2007 Dan Williams 1:0.6.5-5 - Fix ethernet link detection (gnome #354565, rh #194124) - Fix perpetual credentials request with private key passwords in the applet - Sleep a bit before activating wireless cards to work around driver bugs * Mon Jun 04 2007 Dan Williams 1:0.6.5-4 - Don't spawn wpa_supplicant with -o * Wed May 23 2007 Christopher Aillon 1:0.6.5-3 - Rebuild alsa-lib-1.0.14-0.4.fc8 ----------------------- * Thu Jun 07 2007 Martin Stransky 1.0.14-0.5 - new upstream alsa-utils-1.0.14-0.7.fc8 ------------------------- * Thu Jun 07 2007 Martin Stransky 1.0.14-0.8 - new upstream antlr-0:2.7.7-1jpp.3 -------------------- * Thu Jun 07 2007 Deepak Bhole 2.7.7-1jpp.3 - Applied patch to fix conditionals (from skasal at redhat dot com) autofs-1:5.0.1-14 ----------------- * Thu Jun 07 2007 Ian Kent - 5.0.1-14 - fix deadlock in alarm manager module. childsplay-0.85.1-2.fc8 ----------------------- * Thu Jun 07 2007 Hans de Goede 0.85.1-2 - Add pyfribidi Requires for Hebrew support * Fri Dec 22 2006 Hans de Goede 0.85.1-1 - New upstream release 0.85.1 * Tue Oct 31 2006 Hans de Goede 0.84.1-1 - New upstream release 0.84.1 - Install the (still used) assetml files under %{_datadir}/%{name} instead of under %{_datadir}/assetml, since we no longer ship libassetml createrepo-0.4.10-1.fc8 ----------------------- * Thu Jun 07 2007 Paul Nasrat - 0.4.10-1 - Update to 0.4.10 * Wed May 16 2007 Paul Nasrat - 0.4.9-1 - Update to 0.4.9 digikam-doc-0.9.2-0.1.beta2.fc8 ------------------------------- * Thu Jun 07 2007 Marcin Garski 0.9.2-0.1.beta2 - Update to 0.9.2-beta2 (merge with digikamimageplugins-doc) eventlog-0.2.5-8.fc8 -------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 0.2.5-8 - Fixed URL typo. * Thu Jun 07 2007 Jose Pedro Oliveira - 0.2.5-7 - New upstream download location (https://lists.balabit.hu/pipermail/syslog-ng/2007-May/010258.html) fontforge-20070511-1.fc8 ------------------------ * Thu Jun 07 2007 Kevin Fenzi - 20070511-1 - Update to upstream 20070511 - Remove some leftover CVS bits - Remove useless .pc file. gdb-6.6-15.fc8 -------------- * Thu Jun 07 2007 Jan Kratochvil - 6.6-15 - Testcase update to cover PPC Power6/DFP instructions disassembly (BZ 230000). - Disable some known timeouting/failing testcases to reduce the build time. - Fix crash on missing filenames debug info (BZ 242155). * Sat Apr 28 2007 Jan Kratochvil - 6.6-14 - Fixup for the PPC Power6/DFP instructions disassembly (BZ 230000). - New testcase for the GCORE buffer overflow (for BZ 238285, formerly 235753). * Wed Apr 25 2007 Jan Kratochvil - 6.6-13 - Fix `gcore' command for 32bit PPC inferiors on 64bit PPC hosts (BZ 232015). gdesklets-0.35.4-7.1.fc8 ------------------------ * Thu Jun 07 2007 Luya Tshimbalanga - 0.35.4-7.1 - Dropped Applet name category - Replaced Accesories name category by Applet - Added patch to remove old Xorg 6.8 notification for transition.py - Removed no-longer needed python-abi * Tue May 15 2007 Luya Tshimbalanga - 0.35.4-5 - Rebuild with Koji gnome-themes-2.19.3-2.fc8 ------------------------- * Thu Jun 07 2007 Matthias Clasen - 2.19.3-2 - Fix directory ownership issues grass-6.2.2-0.2.RC1.fc8 ----------------------- * Thu Jun 07 2007 Balint Cristian 6.2.2-0.2.RC1 - fix version string in desktop file - add RO lang to desktop file - dropped one patch, seems fixed upstream. * Fri Jun 01 2007 Balint Cristian 6.2.2-0.1.RC1 - 6.2.2 rc1 bugfix release - fix docbase lookup path for g.manual gtk2-engines-2.11.1-2.fc8 ------------------------- * Thu Jun 07 2007 Matthias Clasen - 2.11.1-2 - Keep the default tooltip color for Clearlooks - Fix up directory ownership hotwire-0.556-1.fc8 ------------------- * Thu Jun 07 2007 Colin Walters - 0.556-1 - update - kill off pygtk br jadetex-3.13-1 -------------- * Fri Jun 08 2007 Ondrej Vasik 3.13-1 - update to latest upstream version( 3.13) - removed jadetex-3.12-theta.patch(included in 3.13) - added small typo fix from upstream kernel-2.6.21-1.3213.fc8 ------------------------ * Thu Jun 07 2007 John W. Linville - Re-introduce iwlwifi patch w/ update to version 0.0.24 * Thu Jun 07 2007 John W. Linville - Refresh wireless-dev patch to work w/ 2.6.22 base. libnetfilter_conntrack-0.0.75-1.fc8 ----------------------------------- * Wed May 30 2007 Paul P. Komkoff Jr - 0.0.75-1 - new upstream version mash-0.1.17-1.fc8 ----------------- * Thu Jun 07 2007 Bill Nottingham 0.1.17-1 - exclude debuginfo from repodata where appropriate - add spam-o-matic mrtg-2.15.1-2 ------------- * Thu Jun 07 2007 Vitezslav Crhonek - 2.15.1-2 - Specfile update, because upstream decides to install mrtg-traffic-sum Resolves: #243112 nas-1.9-2.fc7 ------------- * Fri May 04 2007 Frank B??ttner - 1.9-2.fc7 - rebuild for the new ppc64 arch * Sun Apr 08 2007 Frank B??ttner - 1.9-1.fc7 - update to 1.9 - remove old patch file * Mon Mar 26 2007 Frank B??ttner - 1.8b-1.fc7 - update to 1.8b openvrml-0.16.5-1.fc8 --------------------- * Thu Jun 07 2007 Braden McDaniel - 0.16.5-1 - Updated to 0.16.5. perl-Crypt-SSLeay-0.55-1.fc8 ---------------------------- * Thu Jun 07 2007 Robin Norwood - 0.55-1 - Update to latest version from CPAN: 0.55 - Remove two old patches, update lib64 patch for Makefile.PL changes. perl-DBD-MySQL-4.004-1.fc8 -------------------------- * Thu Jun 07 2007 Robin Norwood - 4.004-1 - New version from CPAN: 4.004 - Move requires filter into spec file perl-DBI-1.56-1.fc8 ------------------- * Thu Jun 07 2007 Robin Norwood - 1.56-1 - Update to latest CPAN version: 1.56 - Move the filter requires step into %prep - Remove very old patch (for perl 5.8.1) - Fix a couple of rpmlint issues (non-UTF8 manpage and script with incorrect shebang line perl-Log-Log4perl-1.11-1.fc8 ---------------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 1.11-1 - Update to 1.11. perl-Test-WWW-Mechanize-1.14-1.fc8 ---------------------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 1.14-1 - Update to 1.14. perl-WWW-Mechanize-1.30-2.fc8 ----------------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 1.30-2 - New rebuild option: "--with livetests". * Thu Jun 07 2007 Jose Pedro Oliveira - 1.30-1 - Update to 1.30. - The Makefile.PL --mech-dump option is now deprecated. * Thu Jun 07 2007 Jose Pedro Oliveira - 1.24-1 - Update to 1.24. perl-Wx-0.74-1.fc8 ------------------ * Thu Jun 07 2007 Jose Pedro Oliveira - 0.74-1 - Update to 0.74. perltidy-20070508-1.fc7 ----------------------- * Wed May 09 2007 Ville Skytt?? - 20070508-1 - 20070508. * Sat May 05 2007 Ville Skytt?? - 20070504-1 - 20070504. pm-utils-0.99.3-8.fc8 --------------------- * Thu Jun 07 2007 Peter Jones - 0.99.3-8 - Bump release and rebuild for newer buildsystem code psmisc-22.5-1.2.fc8 ------------------- * Thu Jun 07 2007 Tomas Smetana 22.5-1.2 - exclude peekfd manpage on non-x86 archs * Thu Jun 07 2007 Tomas Smetana 22.5-1.1 - rebuild * Wed Jun 06 2007 Tomas Smetana 22.5-1 - update to new upstream version qt4-qsa-1.2.2-4.fc7 ------------------- * Fri May 04 2007 Frank B??ttner - 1.2.2-4.fc7 - exclude ppc64, because of segmentation fault during build If someone have such an machine please debug it. * Fri May 04 2007 Frank B??ttner - 1.2.2-3.fc7 - rebuild for the ppc64 arch redhat-menus-8.9.10-3.fc8 ------------------------- * Thu Jun 07 2007 Matthew Barnes - 8.9.10-3 - Add X-GNOME-Bugzilla-Version to Evolution desktop files (#243101). - Bump evolution-data-server version in desktop files to 1.12. * Sun May 06 2007 Matthias Clasen - 8.9.10-2 - Don't own directories that are already owned by the filesystem package * Thu Mar 29 2007 Ray Strode - 8.9.10-1 - add encoding to all the desktop files that don't have it (bug 105796) revisor-2.0.3.8-1.fc8 --------------------- * Thu Jun 07 2007 Jonathan Steffan 2.0.3.8-1 - Updated to 2.0.3.8 - More major bugfixes sonata-1.1.1-2.fc8 ------------------ * Thu Jun 07 2007 Micha?? Bentkowski - 1.1.1-2 - Fix desktop file * Thu Jun 07 2007 Micha?? Bentkowski - 1.1.1-1 - Update to 1.1.1 sysklogd-1.4.2-8.fc8 -------------------- * Thu Jun 07 2007 Peter Vrabec 1.4.2-8 - provide dispatcher sample program syslog-ng-2.0.4-4.fc8 --------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 2.0.4-4 - Add support for vim 7.1. t1lib-5.1.1-1.fc8 ----------------- * Thu Jun 07 2007 Jos?? Matos - 5.1.1-1 - Update to 5.1.1. - Remove t1lib-5.1.0-destdir.patch (applied upstream). tellico-1.2.11-1.fc8 -------------------- * Thu Jun 07 2007 Jos?? Matos - 1.2.11-1 - New upstream version. weechat-0.2.5-1.fc8 ------------------- * Fri Jun 08 2007 Paul P. Komkoff Jr - 0.2.5-1 - new upstream version wpa_supplicant-1:0.5.7-3.fc8 ---------------------------- xine-lib-1.1.7-1.fc8 -------------------- * Thu Jun 07 2007 Ville Skytt?? - 1.1.7-1 - 1.1.7. * Wed Jun 06 2007 Rex Dieter - 1.1.6-3 - respin (for libmpcdec) * Wed Apr 25 2007 Ville Skytt?? - 1.1.6-2 - Make Real codec search path /usr/lib(64)/codecs again (#237743). xmms-musepack-1.2-4.fc8 ----------------------- * Thu Jun 07 2007 Matthias Saou 1.2-4 - Update to 1.2.1... not! Fails to compile, the fast seeking patch must be bad. - Rebuild against new libmpcdec. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jun 8 09:31:36 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jun 2007 11:31:36 +0200 Subject: x86_64 nightmare on F7 In-Reply-To: <1181263090.6806.5.camel@hal9000.oberschlesier.lan> References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <20070607233137.GE31520@nostromo.devel.redhat.com> <1181263090.6806.5.camel@hal9000.oberschlesier.lan> Message-ID: <20070608113136.54c51426@python3.es.egwn.lan> Christoph Wickert wrote : > Am Donnerstag, den 07.06.2007, 19:31 -0400 schrieb Bill Nottingham: > > > I can remove the i386 ones, but this will break the x86_64 > > > versions. rpm -V tells me that not much of the package is left, in most > > > cases only the contents of /usr/lib64 is still there. > > > > *That* is a bug. Can you file that, please? > > Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243224 > > BTW: I have to correct my previous statement. It's not _that_ bad as I > thought, it's "just" locales and %doc missing, the rest ist still > there. I've ran into some big issues on one of my home systems after "yum remove glibc.i686" where some programs (gnome-terminal for instance) would segfault somewhere in gconv functions/libraries. It was "fixed" by upgrading all the glibc* packages to the Rawhide versions, which reinstalled all the docs and locales fine, and I've never been able to reproduce it. But evil is lurking... ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.41 0.46 0.41 From Axel.Thimm at ATrpms.net Fri Jun 8 10:02:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 12:02:17 +0200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <46689424.5030009@codewiz.org> References: <46689424.5030009@codewiz.org> Message-ID: <20070608100217.GA30585@neu.nirvana> On Thu, Jun 07, 2007 at 07:26:28PM -0400, Bernardo Innocenti wrote: > Hello, > > could we change the list configuration not to munge > the Reply-To header, so that when we "Reply All", we > actually don't loose the Cc list? Why do you lose the Cc list with reply *all*? At least my mutt doesn't, so perhaps its a MUA issue? > The way it's configured now makes it very difficult to > notice own's replies in threads. Why? the From: field doesn't change, you're still the author of your reply. > Most high-traffic lists I subscribe are configured this > way: linux-kernel, xorg-devel, gcc, gcc-patches, xcb, > mesa, dri, uclinux-dev... But some of these lists you mention are not subscriber only. If you allow non-members to post (even if moderated) then you can't use Reply-To. -- 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 jnovy at redhat.com Fri Jun 8 10:30:41 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 08 Jun 2007 12:30:41 +0200 Subject: tetex-doc is not noarch? In-Reply-To: <466922C8.1090402@fedoraproject.org> References: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> <466922C8.1090402@fedoraproject.org> Message-ID: <1181298641.2733.18.camel@dhcp-lab-186.brq.redhat.com> On Fri, 2007-06-08 at 15:05 +0530, Rahul Sundaram wrote: > Jindrich Novy wrote: > > On Thu, 2007-06-07 at 13:16 -0400, Neal Becker wrote: > >> Seems a bit odd: > >> tetex-doc x86_64 > > > > Yup, this is odd. > > > > The TeXLive 2007 packages which are now under review: > > > > http://bugzilla.redhat.com/229180 > > http://bugzilla.redhat.com/242416 > > > > and splits the TeXLive into two parts just for this reason (the largest > > part -> texmf tree, docs) is noarch and only the binary part, which is > > arch specific, is packaged separately thanks to the better design of > > TeXLive. > > > > The packages are now in a ready-to-use(tm) state and needs review, > > please help with it so that we can get rid of TeTeX soon. > > > > You should update http://fedoraproject.org/wiki/Releases/FeatureTexLive > and added it to Fedora 8 feature list. Updated. -- Jindrich Novy http://people.redhat.com/jnovy/ From jwboyer at jdub.homelinux.org Fri Jun 8 10:59:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 08 Jun 2007 05:59:08 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <200706071439.45528.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706071416.28976.jkeating@redhat.com> <20070607182735.GE27054@nostromo.devel.redhat.com> <200706071439.45528.jkeating@redhat.com> Message-ID: <1181300349.17463.2.camel@vader.jdub.homelinux.org> On Thu, 2007-06-07 at 14:39 -0400, Jesse Keating wrote: > On Thursday 07 June 2007 14:27:35 Bill Nottingham wrote: > > The question is... how much does working in an exploded tree push you > > towards less incentive to get a set of patches and changes upstream. > > > > Heck, we could just work in exploded source and start claiming we *are* > > the upstream... > > We have to do it in a way that makes the exploaded tree useful for managing > your CHANGES to that exploaded tree. We don't let the sourcerpm passed into > the buildsystem be of a modified tarball, we continue to force it to be the > unmodified upstream tarball plus the patches that you've been managing with > the exploaded tree applied to it. This continues to enforce the patches are > valid to a known release, allows you to use exploaded tree to manage the > patches, gives upstream a place to cherry pick changes from, or old style > patch files to deal with. That then begs the question as to why we can't have a simple 'make explode' target. Or why people can't do 'make sources' + untar themselves, or run rpmbuild -bp.. For the vast majority of packages, I don't think having an exploded tree in the SCM helps anything. And it simply adds more overhead for those packages. josh From mcepl at redhat.com Fri Jun 8 10:52:28 2007 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 08 Jun 2007 12:52:28 +0200 Subject: Reply-To header munging for fedora-devel-list@ References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <46690BA6.5040504@nigelj.com> Message-ID: On Fri, 08 Jun 2007 19:56:22 +1200, Nigel Jones scripst: > I don't think there is a clean solution to get the best of both worlds > though (sadly). Fix email programs? kmail has it fixed, mutt had it fixed since forever (option ignore_list_reply_to), why not other programs? We are not talking about need to be compatible with horribly broken proprietary programs like Outlook or Notes, this is fedora-devel after all! Matej From mcepl at redhat.com Fri Jun 8 10:54:23 2007 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 08 Jun 2007 12:54:23 +0200 Subject: Reply-To header munging for fedora-devel-list@ References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <46690BA6.5040504@nigelj.com> <1181295315.20322.27.camel@shinybook.infradead.org> Message-ID: On Fri, 08 Jun 2007 10:35:15 +0100, David Woodhouse scripst: > There isn't. Not 100%, but ignore_list_reply_to in mutt (and whatever in KMail is doing the same) goes LONG way towards those 100%. Reply-To has really no sense in 99,999999% email messages. Mat?j From ndbecker2 at gmail.com Fri Jun 8 10:56:04 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 08 Jun 2007 06:56:04 -0400 Subject: tetex-doc is not noarch? References: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> Message-ID: Jindrich Novy wrote: > On Thu, 2007-06-07 at 13:16 -0400, Neal Becker wrote: >> Seems a bit odd: >> tetex-doc x86_64 > > Yup, this is odd. > > The TeXLive 2007 packages which are now under review: > > http://bugzilla.redhat.com/229180 > http://bugzilla.redhat.com/242416 > > and splits the TeXLive into two parts just for this reason (the largest > part -> texmf tree, docs) is noarch and only the binary part, which is > arch specific, is packaged separately thanks to the better design of > TeXLive. > > The packages are now in a ready-to-use(tm) state and needs review, > please help with it so that we can get rid of TeTeX soon. > > Thanks, > Jindrich > OK, I'll try out the texlive packages. Does this obsolete tetex? Coexist? IOW, how should I install this on a current FC7 system that already has tetex? From jkeating at redhat.com Fri Jun 8 11:05:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 07:05:11 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181267967.4070.309.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706072118.04076.jkeating@redhat.com> <1181267967.4070.309.camel@localhost.localdomain> Message-ID: <200706080705.11909.jkeating@redhat.com> Taking this threadling over to fedora-devel as well (: On Thursday 07 June 2007 21:59:27 Toshio Kuratomi wrote: > On Thu, 2007-06-07 at 21:18 -0400, Jesse Keating wrote: > > > > We have two things for the upstream in our package SCM. We have the > > prestine tarball stashed away in a lookaside, and we have an exploaded > > tree of the source. We use the exploaded tree of the source to manage > > our patches to that source and to help with rebases. However the patches > > we manage always apply to the prestine point. At package build time, the > > patches we manage + the spec file + the prestine tarball stashed away are > > combined to make an srpm, and that is shoved through the build system. > > > > So I see two ways to store patches: > vendor-branch > > |-- Foo.patch branch > | > |-- Bar.patch branch > > Foo.patch and Bar.patch both directly apply to the upstream vendor > branch. > > vendor-branch > > |-- Foo.patch branch > | > |-- Bar.patch branch > > Foo.patch is the first patch against vendor-branch. Bar.patch is > committed to the combination of vendor-branch and Foo.patch. > > At first I was hoping to do the first way as it makes it easier to > cherrypick changes for upstream. However, it quickly became complex as > we had to manage a separate merge branch that was equivalent to the > second storage graph. Whenever we rebased we would potentially have to > remove conflicts from the second graph as well as the first. > > So I decided that going directly to the second style was preferable. > That does not have the enhanced cherrypicking benefits to upstream but > it still allows us to work with individual patches within the VCS more > easily than when they were simply patches stored in CVS. > > Do you see a way around this limitation? > I honestly don't have deep enough knowledge of the SCMs to know how to setup how your patches are managed. If there was a patch management system wouldn't it allow you to remove various patches so that you could get Bar.patch in a state that it would apply to vendor-branch without any other patches, or with only the absolutely required patches applied as well? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 8 11:13:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 07:13:26 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181300349.17463.2.camel@vader.jdub.homelinux.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706071439.45528.jkeating@redhat.com> <1181300349.17463.2.camel@vader.jdub.homelinux.org> Message-ID: <200706080713.27067.jkeating@redhat.com> On Friday 08 June 2007 06:59:08 Josh Boyer wrote: > That then begs the question as to why we can't have a simple 'make > explode' target. ?Or why people can't do 'make sources' + untar > themselves, or run rpmbuild -bp.. Well, untar every time and then check into an SCM to bang against may not be efficient. You want the source already there and some history with your patches so that the patch management system can work if you so choose to use it. > For the vast majority of packages, I don't think having an exploded tree > in the SCM helps anything. ?And it simply adds more overhead for those > packages. What I envisioned is when you imported a new source it would take care of updating the optional exploaded directory for you. When a maintainer checks out a module from the package scm they get patches/spec/sources file per usual. They could optionally ask to get the exploaded tree for more indepth work, but it would be an optional thing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 8 11:17:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 07:17:51 -0400 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <46690BA6.5040504@nigelj.com> References: <46689424.5030009@codewiz.org> <46690BA6.5040504@nigelj.com> Message-ID: <200706080717.51368.jkeating@redhat.com> On Friday 08 June 2007 03:56:22 Nigel Jones wrote: > > 3. w/o munging I hit reply and the mail does not go to the list... > > This is the thing that really bugs me. > > I don't think there is a clean solution to get the best of both worlds > though (sadly). Get a better mail client. one that is smart enough to have a 'reply-list' function that sees that there is a 'list-post' header and replies to that address. Frankly I haven't noticed which lists munge reply-to until I want to send an offlist reply. Thankfully my client is smart enough to let me right click any email address in the headers/mail and 'reply-to' that address. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 8 11:18:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 07:18:48 -0400 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: References: <46689424.5030009@codewiz.org> <46690BA6.5040504@nigelj.com> Message-ID: <200706080718.48340.jkeating@redhat.com> On Friday 08 June 2007 06:52:28 Matej Cepl wrote: > Fix email programs? kmail has it fixed, mutt had it fixed since forever > (option ignore_list_reply_to), why not other programs? We are not talking > about need to be compatible with horribly broken proprietary programs > like Outlook or Notes, this is fedora-devel after all! Evolution has a reply-list feature as well. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Fri Jun 8 11:22:37 2007 From: opensource at till.name (Till Maas) Date: Fri, 08 Jun 2007 13:22:37 +0200 Subject: tetex-doc is not noarch? In-Reply-To: References: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> Message-ID: <200706081322.37963.opensource@till.name> On Fr Juni 8 2007, Neal Becker wrote: > OK, I'll try out the texlive packages. Does this obsolete tetex? Coexist? Texlive obsoletes tetex, tetex is no longer maintained by upstream. Regards, Till From jwboyer at jdub.homelinux.org Fri Jun 8 11:25:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 08 Jun 2007 06:25:23 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <200706080713.27067.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706071439.45528.jkeating@redhat.com> <1181300349.17463.2.camel@vader.jdub.homelinux.org> <200706080713.27067.jkeating@redhat.com> Message-ID: <1181301923.17463.10.camel@vader.jdub.homelinux.org> On Fri, 2007-06-08 at 07:13 -0400, Jesse Keating wrote: > On Friday 08 June 2007 06:59:08 Josh Boyer wrote: > > That then begs the question as to why we can't have a simple 'make > > explode' target. Or why people can't do 'make sources' + untar > > themselves, or run rpmbuild -bp.. > > Well, untar every time and then check into an SCM to bang against may not be > efficient. You want the source already there and some history with your > patches so that the patch management system can work if you so choose to use > it. But if you're doing that much development against this code base, isn't it likely that you already have upstream's SCM repo checked out somewhere? Which you could then use for patch management... And which also encourages people to shove their changes back. Maybe what you're saying for things like the Fedora kernel makes sense. Where you have more than one or two packagers constantly dealing with updating patches, etc. > > For the vast majority of packages, I don't think having an exploded tree > > in the SCM helps anything. And it simply adds more overhead for those > > packages. > > What I envisioned is when you imported a new source it would take care of > updating the optional exploaded directory for you. When a maintainer checks > out a module from the package scm they get patches/spec/sources file per > usual. They could optionally ask to get the exploaded tree for more indepth > work, but it would be an optional thing. So thinking in SCM terms, you'd need the 'checkout' to not pull down the exploded sources by default. I'm not sure of an easy way to do that with git at the moment. Maybe hg can already do stuff like that? josh From jnovy at redhat.com Fri Jun 8 11:34:17 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 08 Jun 2007 13:34:17 +0200 Subject: tetex-doc is not noarch? In-Reply-To: References: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> Message-ID: <1181302457.2733.29.camel@dhcp-lab-186.brq.redhat.com> On Fri, 2007-06-08 at 06:56 -0400, Neal Becker wrote: > Jindrich Novy wrote: > > > On Thu, 2007-06-07 at 13:16 -0400, Neal Becker wrote: > >> Seems a bit odd: > >> tetex-doc x86_64 > > > > Yup, this is odd. > > > > The TeXLive 2007 packages which are now under review: > > > > http://bugzilla.redhat.com/229180 > > http://bugzilla.redhat.com/242416 > > > > and splits the TeXLive into two parts just for this reason (the largest > > part -> texmf tree, docs) is noarch and only the binary part, which is > > arch specific, is packaged separately thanks to the better design of > > TeXLive. > > > > The packages are now in a ready-to-use(tm) state and needs review, > > please help with it so that we can get rid of TeTeX soon. > > > > Thanks, > > Jindrich > > > > OK, I'll try out the texlive packages. Does this obsolete tetex? Coexist? > IOW, how should I install this on a current FC7 system that already has > tetex? The new texlive packages should contain all needed provides for the old tetex ones, so that it could be no problem to replace your current tetex installation by the texlive packages just now. Only a few packages actually require tetex, the most of them only BuildRequire it to generate documentation. They definitely cannot coexist, because they ship the same stuff. I also can't guarantee 100% tetex compatibity in the current state. -- Jindrich Novy http://people.redhat.com/jnovy/ From jkeating at redhat.com Fri Jun 8 11:34:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 07:34:03 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181301923.17463.10.camel@vader.jdub.homelinux.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080713.27067.jkeating@redhat.com> <1181301923.17463.10.camel@vader.jdub.homelinux.org> Message-ID: <200706080734.04118.jkeating@redhat.com> On Friday 08 June 2007 07:25:23 Josh Boyer wrote: > So thinking in SCM terms, you'd need the 'checkout' to not pull down the > exploded sources by default. ?I'm not sure of an easy way to do that > with git at the moment. ?Maybe hg can already do stuff like that? You're assuming that it's in the same "repo". There is no reason that the exploaded source couldn't be in another 'repo' in the module subdirectory. In fact, when I did a dist-git/hg proof of concept, each "branch" we have like FC-6/F-7 were independent repos that happened to be in the same directory structure. On used a simple shell tool to get them, 'get-fedora-package ' or something similar. It would clone , look for a BRANCHES file, parse it and clone the existing branches, + common/. One could go further and in the make file have 'make expload' or some such that would clone the exploaded source repo that belongs to the module. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ndbecker2 at gmail.com Fri Jun 8 11:39:50 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 08 Jun 2007 07:39:50 -0400 Subject: tetex-doc is not noarch? References: <1181291802.2733.15.camel@dhcp-lab-186.brq.redhat.com> <200706081322.37963.opensource@till.name> Message-ID: Till Maas wrote: > On Fr Juni 8 2007, Neal Becker wrote: > >> OK, I'll try out the texlive packages. Does this obsolete tetex? >> Coexist? > > Texlive obsoletes tetex, tetex is no longer maintained by upstream. > > Regards, > Till > It doesn't seem to be marked with Obsoletes. From nicolas.mailhot at laposte.net Fri Jun 8 11:42:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 8 Jun 2007 13:42:04 +0200 (CEST) Subject: RFR: GIT Package VCS In-Reply-To: <200706080713.27067.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706071439.45528.jkeating@redhat.com> <1181300349.17463.2.camel@vader.jdub.homelinux.org> <200706080713.27067.jkeating@redhat.com> Message-ID: <19181.192.54.193.51.1181302924.squirrel@rousalka.dyndns.org> Le Ven 8 juin 2007 13:13, Jesse Keating a ?crit : > What I envisioned is when you imported a new source it would take care > of updating the optional exploaded directory for you. ??? -> archive + patches -> exploded tree (exploded tree as a way to export data) can probably be done easily ???? -> exploded tree -> archive + patches OTOH hand is a dangerous can of worms -- Nicolas Mailhot From jwboyer at jdub.homelinux.org Fri Jun 8 11:44:32 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 08 Jun 2007 06:44:32 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <200706080734.04118.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080713.27067.jkeating@redhat.com> <1181301923.17463.10.camel@vader.jdub.homelinux.org> <200706080734.04118.jkeating@redhat.com> Message-ID: <1181303072.17463.12.camel@vader.jdub.homelinux.org> On Fri, 2007-06-08 at 07:34 -0400, Jesse Keating wrote: > On Friday 08 June 2007 07:25:23 Josh Boyer wrote: > > So thinking in SCM terms, you'd need the 'checkout' to not pull down the > > exploded sources by default. I'm not sure of an easy way to do that > > with git at the moment. Maybe hg can already do stuff like that? > > You're assuming that it's in the same "repo". There is no reason that the > exploaded source couldn't be in another 'repo' in the module subdirectory. Which goes back to just having the upstream repo checked out there then... josh From nicolas.mailhot at laposte.net Fri Jun 8 12:05:06 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 8 Jun 2007 14:05:06 +0200 (CEST) Subject: RFR: GIT Package VCS In-Reply-To: <1181254342.4070.262.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <1181254342.4070.262.camel@localhost.localdomain> Message-ID: <2979.192.54.193.51.1181304306.squirrel@rousalka.dyndns.org> Le Ven 8 juin 2007 00:12, Toshio Kuratomi a ?crit : >> 2. we don't really care what happened between two upstream releases, >> that's best traced in the upstream vcs, a giant changeset between >> them >> is more pertinent at the fedora level than all the upstream change >> history >> > We do when we're backporting a specific fix from upstream's > development > tree. > >> 3. we don't really care what happened on the packager system either, >> just what was pushed as a build (or attempted-to-built package) >> > I disagree with this one quite a bit. >> 4. we really do not want patches that stomp on each other >> > Actually, we do. IMHO you just don't realise a srpm content and the Fedora VCS are intended for very different audiences than an upstream VCS. Upstream VCS is for core developpers. You trace what changes were made, by whom, for what reasons and people who consult it are specialists who know the codebase. SRPMs and Fedora packaging VCSes have quite another target. It's : - "did Fedora break my trust in the upstream release" - "can I check quickly with no deep knowledge of upstream codebase nothing is obviously wrong" - "can I quickly revert a suspicious change" It's definitely not - "are Fedora patches are correct or useful fonctionnality-wise" - "why did the Packager did this thing" To this end you need: - small patches - which are not interdependant - and have little churn -- Nicolas Mailhot From jkeating at redhat.com Fri Jun 8 12:13:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 08:13:14 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181303072.17463.12.camel@vader.jdub.homelinux.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080734.04118.jkeating@redhat.com> <1181303072.17463.12.camel@vader.jdub.homelinux.org> Message-ID: <200706080813.14360.jkeating@redhat.com> On Friday 08 June 2007 07:44:32 Josh Boyer wrote: > Which goes back to just having the upstream repo checked out there > then... Only if the upstream repo is using a DSCM that we can write to, sure. But if they're not, or if they don't have the proper release tags we need, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 8 12:14:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 08:14:55 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <19181.192.54.193.51.1181302924.squirrel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080713.27067.jkeating@redhat.com> <19181.192.54.193.51.1181302924.squirrel@rousalka.dyndns.org> Message-ID: <200706080814.55539.jkeating@redhat.com> On Friday 08 June 2007 07:42:04 Nicolas Mailhot wrote: > ??? -> archive + patches -> exploded tree (exploded tree as a way to > export data) can probably be done easily > > ???? -> exploded tree -> archive + patches OTOH hand is a dangerous > can of worms I'm not following. In my scenario the exploaded tree is used only for patch management and for interacting with upstream when possible/acceptable. What goes into the buildsystem would continue to be prestine upstream tarball unmodified + spec + patches from patch management to make an srpm. Patches still get applied in the rpmbuild task. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjb at unh.edu Fri Jun 8 12:52:14 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 08 Jun 2007 08:52:14 -0400 Subject: fedora devel mirroring? In-Reply-To: <1181273883.24214.1.camel@scrappy.miketc.com> References: <1181247748.4097.34.camel@raptor.sr.unh.edu> <1181254720.23696.13.camel@neuromancer> <1181273883.24214.1.camel@scrappy.miketc.com> Message-ID: <1181307134.29370.6.camel@raptor.sr.unh.edu> On Thu, 2007-06-07 at 22:38 -0500, Mike Chambers wrote: > On Thu, 2007-06-07 at 18:18 -0400, Thomas J. Baker wrote: > > > I believe I'm aware of the structure change and I'm rsyncing all of > > mirrors.kernel.org::fedora. The fedora/development and > > fedora/core/development both seem to be the same on my mirror. In fact, > > I just visited http://mirrors.kernel.org/fedora/development/i386/os/ and > > it indeed is only up to May 25th. > > I checked it out as well and he is correct, May 27th is the last update. > I would email someone (an admin or webmaster) and maybe there is a > problem on their end. > > I do that all the time on a site I mirror from and they usually respond > pretty quick and let me know of any problems. > > -- > Mike Chambers > Madisonville, KY > > "Best little town on Earth!" > I emailed ftpadmin at kernel.org describing the problem. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From limb at jcomserv.net Fri Jun 8 13:59:53 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 8 Jun 2007 08:59:53 -0500 (CDT) Subject: Unsigned package In-Reply-To: <23087.65.192.24.190.1181242852.squirrel@mail.jcomserv.net> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706071421.00899.jkeating@redhat.com> <23087.65.192.24.190.1181242852.squirrel@mail.jcomserv.net> Message-ID: <13717.65.192.24.190.1181311193.squirrel@mail.jcomserv.net> > >> On Thursday 07 June 2007 14:08:06 Jon Ciesla wrote: >>> Trying to upgrade, yum complains: >>> Package scons-0.97-2.fc7.noarch.rpm is not signed >>> >>> This is from my local mirror, but the one from two other official >>> mirrors >>> and d.f.r.c match it. >>> >>> rpm --checksig on all of these yields: >>> >>> scons-0.97-2.fc7.noarch.rpm: sha1 md5 OK >>> >>> Huh? >>> >>> Jon >>> >>> -- >>> novus ordo absurdum >> >> A few unsigned packages leaked out in the tree due to some tools errors >> and >> oversight. I have a new tree with signed packages and new repodata for >> the >> signed packages that I'll be uploading at some point today (once my day >> of >> meetings is over). There is some impact on users. >> >> Yum caches metadata (and packages) for a period of time (30 minutes). >> So >> changing the package checksum without changing the NVR can have some >> impact: >> >> With a warm cache, and no package in cache, it'll say your package >> doesn't >> match checksum. With a warm cache and a already cached (unsigned) >> package, >> it'll say the package is unsigned. Once cache expires, it Just >> Works(tm). >> This only effects the unsigned packages in the tree, all other >> operations >> on >> signed packages will be fine. > > So, try again tomorrow. :) Ok. Thanks. :) Still not working. Is it still a time question? I don't see a change in scons, PHP-Pear-Mail-Mime, or anything else. >> -- >> Jesse Keating >> Release Engineer: Fedora >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- > novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From ville.skytta at iki.fi Fri Jun 8 14:07:58 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 8 Jun 2007 17:07:58 +0300 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <4668D014.7090804@redhat.com> References: <46684600.3050803@hhs.nl> <4668D014.7090804@redhat.com> Message-ID: <200706081707.59063.ville.skytta@iki.fi> On Friday 08 June 2007, Jarod Wilson wrote: > > http://www.linuxtv.org/downloads/firmware/ > > Not sure whether or not someone got the okay for all of those to be > redistributed or not... I asked upstream some time ago, and got a reply recommending against doing that. From jkeating at redhat.com Fri Jun 8 14:13:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 10:13:18 -0400 Subject: Unsigned package In-Reply-To: <13717.65.192.24.190.1181311193.squirrel@mail.jcomserv.net> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <23087.65.192.24.190.1181242852.squirrel@mail.jcomserv.net> <13717.65.192.24.190.1181311193.squirrel@mail.jcomserv.net> Message-ID: <200706081013.22723.jkeating@redhat.com> On Friday 08 June 2007 09:59:53 Jon Ciesla wrote: > Still not working. ?Is it still a time question? ?I don't see a change in > scons, PHP-Pear-Mail-Mime, or anything else. I've haded the signed tree off to IS to sync to the mirror masters. Hopefully later today we'll see the changed content filtering out to the rest of the world mirrors. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From darrellpf at gmail.com Fri Jun 8 14:14:32 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 8 Jun 2007 07:14:32 -0700 Subject: rawhide report: 20070601 changes In-Reply-To: <1180969267.9788.25.camel@erebor.boston.redhat.com> References: <200706020524.l525OU7X002727@porkchop.devel.redhat.com> <1180808607.4028.7.camel@pensja.lam.pl> <1180969267.9788.25.camel@erebor.boston.redhat.com> Message-ID: On 6/4/07, Jeremy Katz wrote: > On Sat, 2007-06-02 at 20:23 +0200, Leszek Matok wrote: > > Dnia 02-06-2007, sob o godzinie 09:58 -0700, darrell pfeifer napisa?(a): > > > 4) Java (the Sun version) segfaulted > > On my system, QuakeForge (compiled by me 4 days ago, when development > > was an almost-F7) segfaults in memset() (run from > > _dl_map_object_from_fd() trying to map a shared library) when I try to > > run it, also "ldd `which nq-glx`" is crashing, but "/lib/ld-linux.so.2 > > `nq-glx`" runs the game. Weird. > > mono apps similarly based on tomboy's failure to start this morning on > my laptop; haven't gotten to actually debugging it yet. Anyone filed it > in bugzilla? > The failures in mono and java have disappeared with the 3213 kernel darrell From j.w.r.degoede at hhs.nl Fri Jun 8 14:24:07 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 08 Jun 2007 16:24:07 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <200706081707.59063.ville.skytta@iki.fi> References: <46684600.3050803@hhs.nl> <4668D014.7090804@redhat.com> <200706081707.59063.ville.skytta@iki.fi> Message-ID: <46696687.7070102@hhs.nl> Hi all, I've created a wiki page with most info from this thread collected. For lack of a better place, I've created it here: http://fedoraproject.org/wiki/SIGs/FirmWare Ville Skytt? wrote: > On Friday 08 June 2007, Jarod Wilson wrote: >> http://www.linuxtv.org/downloads/firmware/ >> >> Not sure whether or not someone got the okay for all of those to be >> redistributed or not... > > I asked upstream some time ago, and got a reply recommending against doing > that. > Do you remember why? That would be very interesting to know. Regards, Hans From a.badger at gmail.com Fri Jun 8 14:47:45 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 Jun 2007 07:47:45 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <200706080813.14360.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080734.04118.jkeating@redhat.com> <1181303072.17463.12.camel@vader.jdub.homelinux.org> <200706080813.14360.jkeating@redhat.com> Message-ID: <1181314065.2645.2.camel@localhost.localdomain> On Fri, 2007-06-08 at 08:13 -0400, Jesse Keating wrote: > On Friday 08 June 2007 07:44:32 Josh Boyer wrote: > > Which goes back to just having the upstream repo checked out there > > then... > > Only if the upstream repo is using a DSCM that we can write to, sure. But if > they're not, or if they don't have the proper release tags we need, etc... > Also, as Nicolas points out, we want to manage patches against a vendor branch where we import the released tarballs rather than upstream's raw tree. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rms at 1407.org Fri Jun 8 15:43:42 2007 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Fri, 08 Jun 2007 16:43:42 +0100 Subject: massive commercial scale copyright infringement of FC3 Message-ID: <1181317422.5132.18.camel@localhost6.localdomain6> Hello, I discovered a massive commercial scale copyright infringement of FC3. Who can I speak to, in a very private form from RedHat/Fedora? Regards, Rui ps: I'm contacting the GNU project and gpl-violations as well. -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From pemboa at gmail.com Fri Jun 8 15:48:18 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 8 Jun 2007 10:48:18 -0500 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <1181317422.5132.18.camel@localhost6.localdomain6> References: <1181317422.5132.18.camel@localhost6.localdomain6> Message-ID: <16de708d0706080848j6e36a182q4bba62d76d9565b@mail.gmail.com> On 6/8/07, Rui Miguel Silva Seabra wrote: > Hello, > > I discovered a massive commercial scale copyright infringement of FC3. > > Who can I speak to, in a very private form from RedHat/Fedora? > > Regards, > Rui > > ps: I'm contacting the GNU project and gpl-violations as well. > > -- > + No matter how much you do, you never do enough -- unknown > + Whatever you do will be insignificant, > | but it is very important that you do it -- Gandhi > + So let's do it...? There is (was?) a Fedora legal mailing list, which may now be invite only, I'll search the wiki -- Fedora Core 6 and proud From pemboa at gmail.com Fri Jun 8 15:56:01 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 8 Jun 2007 10:56:01 -0500 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <46684600.3050803@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> Message-ID: <16de708d0706080856s31400c54p32ebf70a7844f305@mail.gmail.com> On 6/7/07, Hans de Goede wrote: > Leszek Matok wrote: > > Dnia 07-06-2007, czw o godzinie 11:06 -0400, Bill Nottingham napisa?(a): > >> What cards is this useful for that we don't ship firmware > >> for? Anything other than bcm43xx and ralink? > > For example, there are millions of potential speedtch.ko users here in > > Europe. > > > > Okay, > > I think we need to build a list of all potential needed / wanted firmware, with > URL's where to download it and instructions howto unpack it. > > We then also need to start contacting the manufacturers asking for > redistribution permission. > > Here is a start of the list with things metioned sofar: > sil firmware (for prism and prism_pci) > bcm firmware > ralink firmware > speedtouch firmware > alsa firmware > > I think this is best put in the wiki, but where, maybe a firmware SIG? > > Regards, > > Hans Looks like we have a wiki page here: http://fedoraproject.org/wiki/SIGs/FirmWare -- Fedora Core 6 and proud From aphukan at fedoraproject.org Fri Jun 8 16:07:33 2007 From: aphukan at fedoraproject.org (Amitakhya Phukan) Date: Fri, 08 Jun 2007 21:37:33 +0530 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <1181317422.5132.18.camel@localhost6.localdomain6> References: <1181317422.5132.18.camel@localhost6.localdomain6> Message-ID: <46697EC5.2070301@fedoraproject.org> hi! Rui Miguel Silva Seabra wrote: > Hello, > > I discovered a massive commercial scale copyright infringement of FC3. > > Who can I speak to, in a very private form from RedHat/Fedora? > > Regards, > Rui > > ps: I'm contacting the GNU project and gpl-violations as well. > > have a look here : http://fedoraproject.org/wiki/FedoraLegalIssues?highlight=%28legal%29 regards, amit. -------------- next part -------------- A non-text attachment was scrubbed... Name: aphukan.vcf Type: text/x-vcard Size: 215 bytes Desc: not available URL: From rms at 1407.org Fri Jun 8 16:19:14 2007 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Fri, 08 Jun 2007 17:19:14 +0100 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <46697EC5.2070301@fedoraproject.org> References: <1181317422.5132.18.camel@localhost6.localdomain6> <46697EC5.2070301@fedoraproject.org> Message-ID: <1181319554.5132.32.camel@localhost6.localdomain6> Sex, 2007-06-08 ?s 21:37 +0530, Amitakhya Phukan escreveu: > hi! > > have a look here : > > http://fedoraproject.org/wiki/FedoraLegalIssues?highlight=%28legal%29 I did, but there's no information as to whom I should contact. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From pemboa at gmail.com Fri Jun 8 16:23:31 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 8 Jun 2007 11:23:31 -0500 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <1181319554.5132.32.camel@localhost6.localdomain6> References: <1181317422.5132.18.camel@localhost6.localdomain6> <46697EC5.2070301@fedoraproject.org> <1181319554.5132.32.camel@localhost6.localdomain6> Message-ID: <16de708d0706080923p4691b870wcb367f1a44cc22b0@mail.gmail.com> On 6/8/07, Rui Miguel Silva Seabra wrote: > Sex, 2007-06-08 ?s 21:37 +0530, Amitakhya Phukan escreveu: > > hi! > > > > have a look here : > > > > http://fedoraproject.org/wiki/FedoraLegalIssues?highlight=%28legal%29 > > I did, but there's no information as to whom I should contact. > > Rui > > -- > + No matter how much you do, you never do enough -- unknown > + Whatever you do will be insignificant, > | but it is very important that you do it -- Gandhi > + So let's do it...? https://www.redhat.com/mailman/listinfo/fedora-legal-list -- Fedora Core 6 and proud From sundaram at fedoraproject.org Fri Jun 8 16:24:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 21:54:57 +0530 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <1181319554.5132.32.camel@localhost6.localdomain6> References: <1181317422.5132.18.camel@localhost6.localdomain6> <46697EC5.2070301@fedoraproject.org> <1181319554.5132.32.camel@localhost6.localdomain6> Message-ID: <466982D9.60506@fedoraproject.org> Rui Miguel Silva Seabra wrote: > Sex, 2007-06-08 ?s 21:37 +0530, Amitakhya Phukan escreveu: >> hi! >> >> have a look here : >> >> http://fedoraproject.org/wiki/FedoraLegalIssues?highlight=%28legal%29 > > I did, but there's no information as to whom I should contact. > Greg Dek, gdk AT fedoraproject.org. Rahul From mspevack at redhat.com Fri Jun 8 16:25:04 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 12:25:04 -0400 (EDT) Subject: f7 images for mass production Message-ID: I wanted to throw a question out to devel-list and Will Woods. We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. I would like to know if the conventional wisdom is that we should use the GOLD images, or if it is worthwhile to use an updated image (either of the LiveCD or of the DVD), in order to pull in any of the updates that have already been published. Thanks, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From j.w.r.degoede at hhs.nl Fri Jun 8 16:25:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 08 Jun 2007 18:25:16 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <16de708d0706080856s31400c54p32ebf70a7844f305@mail.gmail.com> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> <16de708d0706080856s31400c54p32ebf70a7844f305@mail.gmail.com> Message-ID: <466982EC.6000009@hhs.nl> Arthur Pemberton wrote: > On 6/7/07, Hans de Goede wrote: >> Leszek Matok wrote: >> > Dnia 07-06-2007, czw o godzinie 11:06 -0400, Bill Nottingham >> napisa?(a): >> >> What cards is this useful for that we don't ship firmware >> >> for? Anything other than bcm43xx and ralink? >> > For example, there are millions of potential speedtch.ko users here in >> > Europe. >> > >> >> Okay, >> >> I think we need to build a list of all potential needed / wanted >> firmware, with >> URL's where to download it and instructions howto unpack it. >> >> We then also need to start contacting the manufacturers asking for >> redistribution permission. >> >> Here is a start of the list with things metioned sofar: >> sil firmware (for prism and prism_pci) >> bcm firmware >> ralink firmware >> speedtouch firmware >> alsa firmware >> >> I think this is best put in the wiki, but where, maybe a firmware SIG? >> >> Regards, >> >> Hans > > > Looks like we have a wiki page here: > http://fedoraproject.org/wiki/SIGs/FirmWare > > I know I created that page today :) Regards, Hans From fedora at camperquake.de Fri Jun 8 16:28:48 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 8 Jun 2007 18:28:48 +0200 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <1181317422.5132.18.camel@localhost6.localdomain6> References: <1181317422.5132.18.camel@localhost6.localdomain6> Message-ID: <20070608182848.61999abc@lain.camperquake.de> Hi. On Fri, 08 Jun 2007 16:43:42 +0100, Rui Miguel Silva Seabra wrote > I discovered a massive commercial scale copyright infringement of FC3. Just so that I am in the clear: did FC3 violate someones copyright, or did someone violate our/rhs/whoeveritactuallyis copyright on FC3? From wtogami at redhat.com Fri Jun 8 16:30:40 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 08 Jun 2007 12:30:40 -0400 Subject: f7 images for mass production In-Reply-To: References: Message-ID: <46698430.9060702@redhat.com> Max Spevack wrote: > I wanted to throw a question out to devel-list and Will Woods. > > We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. > > I would like to know if the conventional wisdom is that we should use > the GOLD images, or if it is worthwhile to use an updated image (either > of the LiveCD or of the DVD), in order to pull in any of the updates > that have already been published. > > Thanks, > Max > IMHO, we should try to ship with an updated kernel and anaconda that fixes the most critical bugs like: - Dell Core2Duo wont boot. - e1000 is busted on many laptops. - (I don't know exactly what, but I heard updates.img mentioned, so there might be important anaconda bugs.) Warren Togami wtogami at redhat.com From pemboa at gmail.com Fri Jun 8 16:35:20 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 8 Jun 2007 11:35:20 -0500 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <20070608182848.61999abc@lain.camperquake.de> References: <1181317422.5132.18.camel@localhost6.localdomain6> <20070608182848.61999abc@lain.camperquake.de> Message-ID: <16de708d0706080935h4e73827fwa5c0a327dc54569e@mail.gmail.com> On 6/8/07, Ralf Ertzinger wrote: > Hi. > > On Fri, 08 Jun 2007 16:43:42 +0100, Rui Miguel Silva Seabra wrote > > > I discovered a massive commercial scale copyright infringement of FC3. > > Just so that I am in the clear: did FC3 violate someones copyright, or > did someone violate our/rhs/whoeveritactuallyis copyright on FC3? My questionable comprehension skills says that someone violates FC3 copyright in some form. -- Fedora Core 6 and proud From caillon at redhat.com Fri Jun 8 16:34:09 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 08 Jun 2007 12:34:09 -0400 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <20070608182848.61999abc@lain.camperquake.de> References: <1181317422.5132.18.camel@localhost6.localdomain6> <20070608182848.61999abc@lain.camperquake.de> Message-ID: <46698501.6080108@redhat.com> Ralf Ertzinger wrote: > Hi. > > On Fri, 08 Jun 2007 16:43:42 +0100, Rui Miguel Silva Seabra wrote > >> I discovered a massive commercial scale copyright infringement of FC3. > > Just so that I am in the clear: did FC3 violate someones copyright, or > did someone violate our/rhs/whoeveritactuallyis copyright on FC3? He said he wanted to discuss in private with legal personnel. Let's respect his wishes. If it affects us, we'll find out soon enough. From sundaram at fedoraproject.org Fri Jun 8 16:39:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 22:09:45 +0530 Subject: f7 images for mass production In-Reply-To: <46698430.9060702@redhat.com> References: <46698430.9060702@redhat.com> Message-ID: <46698651.8020508@fedoraproject.org> Warren Togami wrote: > Max Spevack wrote: >> I wanted to throw a question out to devel-list and Will Woods. >> >> We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. >> >> I would like to know if the conventional wisdom is that we should use >> the GOLD images, or if it is worthwhile to use an updated image >> (either of the LiveCD or of the DVD), in order to pull in any of the >> updates that have already been published. >> >> Thanks, >> Max >> > > IMHO, we should try to ship with an updated kernel and anaconda that > fixes the most critical bugs like: > - Dell Core2Duo wont boot. > - e1000 is busted on many laptops. > - (I don't know exactly what, but I heard updates.img mentioned, so > there might be important anaconda bugs.) So the next question would be, if you are fixing important bugs and doing a respin why are you not doing a point release publicly? Rahul From pemboa at gmail.com Fri Jun 8 16:33:56 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 8 Jun 2007 11:33:56 -0500 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <466982EC.6000009@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> <16de708d0706080856s31400c54p32ebf70a7844f305@mail.gmail.com> <466982EC.6000009@hhs.nl> Message-ID: <16de708d0706080933i125d20c9u4ae83745a3b3109e@mail.gmail.com> On 6/8/07, Hans de Goede wrote: > Arthur Pemberton wrote: > > On 6/7/07, Hans de Goede wrote: > >> Leszek Matok wrote: > >> > Dnia 07-06-2007, czw o godzinie 11:06 -0400, Bill Nottingham > >> napisa?(a): > >> >> What cards is this useful for that we don't ship firmware > >> >> for? Anything other than bcm43xx and ralink? > >> > For example, there are millions of potential speedtch.ko users here in > >> > Europe. > >> > > >> > >> Okay, > >> > >> I think we need to build a list of all potential needed / wanted > >> firmware, with > >> URL's where to download it and instructions howto unpack it. > >> > >> We then also need to start contacting the manufacturers asking for > >> redistribution permission. > >> > >> Here is a start of the list with things metioned sofar: > >> sil firmware (for prism and prism_pci) > >> bcm firmware > >> ralink firmware > >> speedtouch firmware > >> alsa firmware > >> > >> I think this is best put in the wiki, but where, maybe a firmware SIG? > >> > >> Regards, > >> > >> Hans > > > > > > Looks like we have a wiki page here: > > http://fedoraproject.org/wiki/SIGs/FirmWare > > > > > > I know I created that page today :) > > Regards, > > Hans I suspected that. I have commandeered it. -- Fedora Core 6 and proud From clumens at redhat.com Fri Jun 8 16:43:23 2007 From: clumens at redhat.com (Chris Lumens) Date: Fri, 8 Jun 2007 12:43:23 -0400 Subject: f7 images for mass production In-Reply-To: <46698430.9060702@redhat.com> References: <46698430.9060702@redhat.com> Message-ID: <20070608164323.GQ32403@exeter.boston.redhat.com> > - (I don't know exactly what, but I heard updates.img mentioned, so > there might be important anaconda bugs.) There is an updates.img for anaconda that potentially fixes a variety of bugs. It's linked to off the bugs in question, but we're still developing fixes for a couple things and waiting to see what other common bugs are rolling in. In my opinion, using the updates.img in media being made for release would be useful so we don't get another batch of bug reports about the same things. - Chris From mikeb at redhat.com Fri Jun 8 16:48:47 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Fri, 08 Jun 2007 12:48:47 -0400 Subject: koji weirdness In-Reply-To: <1180735797.19774.78.camel@localhost.localdomain> References: <465A8F08.90708@hhs.nl> <200705280941.51943.jkeating@redhat.com> <465BDE48.9010606@hhs.nl> <200705290633.56160.jkeating@redhat.com> <1180639944.21359.14.camel@burren.boston.redhat.com> <1180735797.19774.78.camel@localhost.localdomain> Message-ID: <1181321327.10702.6.camel@liffey.home> On Fri, 2007-06-01 at 15:09 -0700, Toshio Kuratomi wrote: > On Thu, 2007-05-31 at 15:32 -0400, Mike Bonnet wrote: > > I just checked in an alternate chain-build implementation to > > Makefile.common, based on a target we were using internally (and have > > tested rather extensively). Update your common/ directories and run > > "make help" to see the chain-build usage. > > > > You specify the packages that the current package depends on using the > > CHAIN= parameter to "make chain-build". The packages specified in the > > CHAIN= parameter will be checked out into a temp directory and "make > > cvsurl" will be called to get their CVS URL (this will reference the > > latest tag that was applied to the package on the current branch, and > > that tag must not have been built in Koji already). The CVS URLs from > > each CHAIN= package and the current package will be used to generate the > > appropriate koji command-line to build each package in order (the > > current package will be built last, and should not appear in the CHAIN= > > parameter). > > What do you do if you have several packages that have a common > dependency? > > For instance: > bzrtools Requires: bzr >= %{majorver} bzr < %{nextver} > bzr-gtk Requires: bzr >= %{majorver} bzr < %{nextver} > > Does cd bzr-gtk/devel ; make chain-build CHAIN='bzr bzrtools' > build bzr, then bzrtools when bzr is ready, then bzr-gtk when bzrtools > is ready? Or does it attempt to make bzr and bzr-gtk independently > followed by bzr-gtk? > > Related to this is specifying more than one package. > > foo Requires: bar, bar Requires: baz. > > An update of baz requires an update of bar which requires an update of > foo. Does cd foo/devel ; make chain-build CHAIN='baz bar' do the right > thing? You want to run "make chain-build" from the last package in the chain. This makes sense because you will have needed to bump the revision in the spec and run "make tag" for each of the previous packages in the chain already. So, if foo BuildRequires bar and bar BuildRequires baz: cd foo/devel make tag cd ../../bar/devel make tag cd ../../baz/devel make tag make chain-build BUILD="foo bar" Which will build foo, wait until it appears in the repo to build bar, and then wait until bar appears in the repo to build baz. I'm going to see about rolling ajax's chain-build-expert patch in, for finer control of build groupings. From pmr at pajato.com Fri Jun 8 16:50:51 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Fri, 08 Jun 2007 12:50:51 -0400 Subject: Thunderbird and missing News Feeds Account option Message-ID: <466988EB.3070600@pajato.com> The Thunderbird I downloaded with F7 seems to have three choices in the Accout setup wizard: Email account, Gmail account and News Groups. The Gmail account option seems to replace the "News and Blog Feeds" choice that existed with Thunderbird 1.5. Nowhere can I find any indication that RSS support has been dropped with Thunderbird 2.0. Is this a Fedora "feature" perchance? FWIW, I'm using a KDE system installed from the KDE Live DVD on an x86_64 system (HP Laptop). Thanks, -pmr From tchung at fedoraproject.org Fri Jun 8 16:54:03 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Fri, 8 Jun 2007 09:54:03 -0700 Subject: f7 images for mass production In-Reply-To: References: Message-ID: <369bce3b0706080954i3720e008i6c0d2030e42f44d6@mail.gmail.com> On 6/8/07, Max Spevack wrote: > I wanted to throw a question out to devel-list and Will Woods. > > We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. > > I would like to know if the conventional wisdom is that we should use > the GOLD images, or if it is worthwhile to use an updated image (either > of the LiveCD or of the DVD), in order to pull in any of the updates > that have already been published. > > Thanks, > Max In my personal opinion, we should distribute media exact same release of F7 final images. Question. Are you producing all three archs for DVDs and two archs for Live images? Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From kwizart at gmail.com Fri Jun 8 16:59:21 2007 From: kwizart at gmail.com (KH KH) Date: Fri, 8 Jun 2007 18:59:21 +0200 Subject: Building a list of missing firmware (was Re: Fedora 8 ideas) In-Reply-To: <466982EC.6000009@hhs.nl> References: <20070607150620.GC25221@nostromo.devel.redhat.com> <1181230006.9479.2.camel@pensja.lam.pl> <46684600.3050803@hhs.nl> <16de708d0706080856s31400c54p32ebf70a7844f305@mail.gmail.com> <466982EC.6000009@hhs.nl> Message-ID: 2007/6/8, Hans de Goede : > Arthur Pemberton wrote: > > On 6/7/07, Hans de Goede wrote: > >> Leszek Matok wrote: > >> > Dnia 07-06-2007, czw o godzinie 11:06 -0400, Bill Nottingham > >> napisa?(a): > >> >> What cards is this useful for that we don't ship firmware > >> >> for? Anything other than bcm43xx and ralink? > >> > For example, there are millions of potential speedtch.ko users here in > >> > Europe. > >> > > >> > >> Okay, > >> > >> I think we need to build a list of all potential needed / wanted > >> firmware, with > >> URL's where to download it and instructions howto unpack it. > >> > >> We then also need to start contacting the manufacturers asking for > >> redistribution permission. > >> > >> Here is a start of the list with things metioned sofar: > >> sil firmware (for prism and prism_pci) > >> bcm firmware > >> ralink firmware > >> speedtouch firmware > >> alsa firmware > >> > >> I think this is best put in the wiki, but where, maybe a firmware SIG? > >> > >> Regards, > >> > >> Hans > > > > > > Looks like we have a wiki page here: > > http://fedoraproject.org/wiki/SIGs/FirmWare > > > > > > I know I created that page today :) > > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > @Hans de Goede Ralinks firmware are wifi devices (then network apply) this is rt61-firmware and rt71w-firmware in currently in review i don't know the status of these (i expect that missing license is a blocker at least) https://bugzilla.redhat.com/230164 (rt71w-firmware used by rt73usb kernel module) https://bugzilla.redhat.com/230161 (rt61-firmware used by rt61pci kernel module) others rt2400pci rt2500pci rt2500usb do not requires firmware and are recommanded by FSF because of that... rt2500usb sometimes work better with rt73usb kernel module ( reported by rt2x00 devs at serialmonkey ) About Ralink's wifi devices, RutilT is an utility that was previously design to help special function for legacies version. But it has recently added support for rt2x00. Some users reported that wifi works fine with it (not sure if they can get it work without it...) Review is here: https://bugzilla.redhat.com/202521 Current state of art is that i trying to get it work with pam (will ask on the appropriate ml for this...) There is also atmel firmwares. As far as i've checked only usb version aren't inside the kernel - May requires external kernel module for them... http://thekelleys.org.uk/atmel/ - for pci ( pcmcia if applicable) https://bugzilla.redhat.com/221677 http://developer.berlios.de/projects/at76c503a/ (usb version not merged yet (or planned to be) - but it need a confirmation...) Nicolas (kwizart) From mikeb at redhat.com Fri Jun 8 17:00:27 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Fri, 08 Jun 2007 13:00:27 -0400 Subject: koji can't find a newly build dependency In-Reply-To: <20070602075425.GA11101@free.fr> References: <20070601213351.GA27920@free.fr> <1180735311.19774.69.camel@localhost.localdomain> <20070602075425.GA11101@free.fr> Message-ID: <1181322027.10702.12.camel@liffey.home> On Sat, 2007-06-02 at 09:54 +0200, Patrice Dumas wrote: > On Fri, Jun 01, 2007 at 03:01:51PM -0700, Toshio Kuratomi wrote: > > > > > I think you need to use koji's chain-building facility to ensure that > > the libdap package is included in the repository before the next package > > is built. These mailing list posts ought to help:: > > > > https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02146.html > > > > https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01850.html > > Maybe the CHAIN= parameter should be documented in > make chain-build --help It's documented in the "make help" output. From jkeating at redhat.com Fri Jun 8 17:02:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 13:02:41 -0400 Subject: f7 images for mass production In-Reply-To: References: Message-ID: <200706081302.41603.jkeating@redhat.com> On Friday 08 June 2007 12:25:04 Max Spevack wrote: > I wanted to throw a question out to devel-list and Will Woods. > > We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. > > I would like to know if the conventional wisdom is that we should use > the GOLD images, or if it is worthwhile to use an updated image (either > of the LiveCD or of the DVD), in order to pull in any of the updates > that have already been published. > I hate questions like this (: If we don't, we'll just see more bug reports and badness from the bugs we have. If we do, we'll get slammed for our release being nothing but a Beta and /this/ one is the real release (although I'm sure we'll find some bugs in this one too) I think one part of the question can be answered by the distinct lack of an updated F7 kernel as of yet, at least not released. There is http://koji.fedoraproject.org/koji/buildinfo?buildID=8282 but I haven't seen any update requests come through bodhi for it. So it's not like we know that this solves the issues you'd want to say are fixed with a respin. Also, if we're going to respin, that's a lot more QA to toss in the mix to make sure that our included fixes don't introduce regressions, and that the compose processes itself was successful. This is just more work, nothing more, nothing less. However we have limited time before Test1 is due, so it's a balance we have to talk about. My personal opinion is that we make use of updates.img to fix any serious anaconda bugs we've found. I don't recall any /serious/ ones though, we snuck those in for the last rebuild. Adding updates.img is a simple call to mkisofs, it doesn't involve pungi, or anaconda-runtime, or anything else. It's just adding a file and recalling mkisofs. Anything more (like replacing packages) is far more risky. If possible, we could have an insert into the DVD sleeve with a print out of the known issues so that we give users a fighting chance of working around the known issues. There are going to be updates that people download after the fact, just given the sheer number of updates already available, and I really don't think we have time to suck in every existing update and give that a proper qa that a final release would get. There are already 200+ megs of i386 updates, 500+megs of updates-testing. That is a /lot/ of churn to try and stabilize again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Fri Jun 8 17:09:02 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 8 Jun 2007 19:09:02 +0200 Subject: f7 images for mass production In-Reply-To: References: Message-ID: <20070608190902.4cd3f58b@lain.camperquake.de> Hi. On Fri, 8 Jun 2007 12:25:04 -0400 (EDT), Max Spevack wrote > I would like to know if the conventional wisdom is that we should use > the GOLD images, or if it is worthwhile to use an updated image > (either of the LiveCD or of the DVD), in order to pull in any of the > updates that have already been published. Having read http://kernelslacker.livejournal.com/79957.html and after my own experiences with newer kernels I'd say we should at least ship a newer kernel. From caillon at redhat.com Fri Jun 8 17:17:35 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 08 Jun 2007 13:17:35 -0400 Subject: f7 images for mass production In-Reply-To: <200706081302.41603.jkeating@redhat.com> References: <200706081302.41603.jkeating@redhat.com> Message-ID: <46698F2F.3060206@redhat.com> Jesse Keating wrote: > On Friday 08 June 2007 12:25:04 Max Spevack wrote: >> I wanted to throw a question out to devel-list and Will Woods. >> >> We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. >> >> I would like to know if the conventional wisdom is that we should use >> the GOLD images, or if it is worthwhile to use an updated image (either >> of the LiveCD or of the DVD), in order to pull in any of the updates >> that have already been published. >> > > I hate questions like this (: If we don't, we'll just see more bug reports > and badness from the bugs we have. If we do, we'll get slammed for our > release being nothing but a Beta and /this/ one is the real release (although > I'm sure we'll find some bugs in this one too) Think we'd get slammed for security updates only? I can live with shipping with bugs, but really really hate having to ship something with known security flaws, especially in packages such as NetworkManager and wpa_supplicant which might own the user before they even get a chance to get the updates. Also, part of me is wondering why we waited to send this for pressing now, though. IMO, we should have sent them off to be pressed when we had the final images done, which would avoid having to ask this question. :-) From hughsient at gmail.com Fri Jun 8 17:20:01 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 08 Jun 2007 18:20:01 +0100 Subject: f7 images for mass production In-Reply-To: <46698430.9060702@redhat.com> References: <46698430.9060702@redhat.com> Message-ID: <1181323201.2466.0.camel@work> On Fri, 2007-06-08 at 12:30 -0400, Warren Togami wrote: > IMHO, we should try to ship with an updated kernel and anaconda that > fixes the most critical bugs like: > - Dell Core2Duo wont boot. > - e1000 is busted on many laptops. And suspend/resume is broken for many people. Richard. From sundaram at fedoraproject.org Fri Jun 8 17:24:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 22:54:00 +0530 Subject: f7 images for mass production In-Reply-To: <1181323201.2466.0.camel@work> References: <46698430.9060702@redhat.com> <1181323201.2466.0.camel@work> Message-ID: <466990B0.2000701@fedoraproject.org> Richard Hughes wrote: > On Fri, 2007-06-08 at 12:30 -0400, Warren Togami wrote: >> IMHO, we should try to ship with an updated kernel and anaconda that >> fixes the most critical bugs like: >> - Dell Core2Duo wont boot. >> - e1000 is busted on many laptops. > > And suspend/resume is broken for many people. Are there fixes readily available for that issue? Rahul From dr.diesel at gmail.com Fri Jun 8 17:32:38 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 8 Jun 2007 12:32:38 -0500 Subject: f7 images for mass production In-Reply-To: <466990B0.2000701@fedoraproject.org> References: <46698430.9060702@redhat.com> <1181323201.2466.0.camel@work> <466990B0.2000701@fedoraproject.org> Message-ID: <2a28d2ab0706081032p5dadfdb5xcd300bfda94952ca@mail.gmail.com> The network related system hangs should be considered as well. On 6/8/07, Rahul Sundaram wrote: > Richard Hughes wrote: > > On Fri, 2007-06-08 at 12:30 -0400, Warren Togami wrote: > >> IMHO, we should try to ship with an updated kernel and anaconda that > >> fixes the most critical bugs like: > >> - Dell Core2Duo wont boot. > >> - e1000 is busted on many laptops. > > > > And suspend/resume is broken for many people. > > Are there fixes readily available for that issue? > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mspevack at redhat.com Fri Jun 8 17:31:38 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 13:31:38 -0400 (EDT) Subject: f7 images for mass production In-Reply-To: <369bce3b0706080954i3720e008i6c0d2030e42f44d6@mail.gmail.com> References: <369bce3b0706080954i3720e008i6c0d2030e42f44d6@mail.gmail.com> Message-ID: On Fri, 8 Jun 2007, Thomas Chung wrote: > In my personal opinion, we should distribute media exact same release > of F7 final images. > > Question. Are you producing all three archs for DVDs and two archs for > Live images? I won't mass produce anything PPC. Certainly x86 -- there wasn't even a whole lot of demand for the mass-produced x86_64. If people *really* want it, we can. But 95% of what we're asked for is just x86. With a shorter F8, I kind of feel like x86 only for DVD and LiveCD might be the best bet. But i'm open. --Max From mspevack at redhat.com Fri Jun 8 17:33:32 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 13:33:32 -0400 (EDT) Subject: f7 images for mass production In-Reply-To: <46698651.8020508@fedoraproject.org> References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> Message-ID: On Fri, 8 Jun 2007, Rahul Sundaram wrote: > So the next question would be, if you are fixing important bugs and > doing a respin why are you not doing a point release publicly? I think that's a bit of a red herring. For me, it's just a matter of "if we're going to spend a bunch of money on physical media" I'd like to have any horrible bugs fixed, if we can. --Max From jkeating at redhat.com Fri Jun 8 17:38:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 13:38:36 -0400 Subject: f7 images for mass production In-Reply-To: <46698F2F.3060206@redhat.com> References: <200706081302.41603.jkeating@redhat.com> <46698F2F.3060206@redhat.com> Message-ID: <200706081338.36555.jkeating@redhat.com> On Friday 08 June 2007 13:17:35 Christopher Aillon wrote: > Also, part of me is wondering why we waited to send this for pressing > now, though. ?IMO, we should have sent them off to be pressed when we > had the final images done, which would avoid having to ask this > question. ?:-) +100 As we've seen in this thread there are a lot of things we'd really like to have fixed on the pressed media, simply because the release has been out for a while and things inevitably fell out of a wider audience using them. To be perfectly honest I think we should just swallow the poisen pill and press the media as shipped, with a paper insert warning people about know issues and recommending immediate update. We'll just pretend like we had these pressed weeks ago when the isos went gold. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mspevack at redhat.com Fri Jun 8 17:36:59 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 13:36:59 -0400 (EDT) Subject: f7 images for mass production In-Reply-To: <46698F2F.3060206@redhat.com> References: <200706081302.41603.jkeating@redhat.com> <46698F2F.3060206@redhat.com> Message-ID: On Fri, 8 Jun 2007, Christopher Aillon wrote: > Also, part of me is wondering why we waited to send this for pressing > now, though. IMO, we should have sent them off to be pressed when we > had the final images done, which would avoid having to ask this > question. :-) Well, the answer is simply "I haven't had time to do it until now". And because I thought it might be a worthwhile question to ask, and that if I just took the GOLD bits and DVDs appeared, I guarantee you I'd get plenty of emails saying "why didn't you ask about pulling in any updates! There's bug FOO which is horrible!". --Max From sundaram at fedoraproject.org Fri Jun 8 17:39:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 23:09:12 +0530 Subject: f7 images for mass production In-Reply-To: References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> Message-ID: <46699440.6060205@fedoraproject.org> Max Spevack wrote: > On Fri, 8 Jun 2007, Rahul Sundaram wrote: > >> So the next question would be, if you are fixing important bugs and >> doing a respin why are you not doing a point release publicly? > > I think that's a bit of a red herring. For me, it's just a matter of > "if we're going to spend a bunch of money on physical media" I'd like to > have any horrible bugs fixed, if we can. Sure. I understand the motivation but if you are doing that work I don't see any reason to prevent other people from benefiting from it. Rahul From sundaram at fedoraproject.org Fri Jun 8 17:39:35 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 23:09:35 +0530 Subject: f7 images for mass production In-Reply-To: <2a28d2ab0706081032p5dadfdb5xcd300bfda94952ca@mail.gmail.com> References: <46698430.9060702@redhat.com> <1181323201.2466.0.camel@work> <466990B0.2000701@fedoraproject.org> <2a28d2ab0706081032p5dadfdb5xcd300bfda94952ca@mail.gmail.com> Message-ID: <46699457.1040106@fedoraproject.org> Dr. Diesel wrote: > The network related system hangs should be considered as well. > This is extremely vague. Do you have any bug reports? Rahul From j.w.r.degoede at hhs.nl Fri Jun 8 17:54:18 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 08 Jun 2007 19:54:18 +0200 Subject: f7 images for mass production In-Reply-To: References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> Message-ID: <466997CA.7060505@hhs.nl> Max Spevack wrote: > On Fri, 8 Jun 2007, Rahul Sundaram wrote: > >> So the next question would be, if you are fixing important bugs and >> doing a respin why are you not doing a point release publicly? > > I think that's a bit of a red herring. For me, it's just a matter of > "if we're going to spend a bunch of money on physical media" I'd like to > have any horrible bugs fixed, if we can. > Yes, And if we spend the time to create new iso's for that, I think it would be a good idea to make those available to our end-users. Call it a .0.1 release, call it a brown paper bag release (not meant in any disrespect to DaveJ, but the kernel is kinda a brown paper bag kernel). Eitherway if we invest time and QA to make new iso's for this, we should make them available, as the time has already been invested then. I vote for doing a new spin with: -a new kernel included (we might have to wait a bit for this new kernel to become available and proven) -perhaps an updates.img included -perhaps one or two updates for very very critical no interaction needed network abusable security issues. Regards, Hans From mspevack at redhat.com Fri Jun 8 17:39:10 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 13:39:10 -0400 (EDT) Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <1181317422.5132.18.camel@localhost6.localdomain6> References: <1181317422.5132.18.camel@localhost6.localdomain6> Message-ID: On Fri, 8 Jun 2007, Rui Miguel Silva Seabra wrote: > Hello, > > I discovered a massive commercial scale copyright infringement of FC3. > > Who can I speak to, in a very private form from RedHat/Fedora? You've gotten a lot of answers. For the *most* private discussion, you'll want to email me directly. For the *second* most private discussion, you'll want to email the Fedora Board's private list -- fedora-board-list at redhat.com Chances are that if you email me and me alone, most of the people on fedora-board-list will need to know what you've said anyway. Look forward to hearing from you, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From dr.diesel at gmail.com Fri Jun 8 17:42:09 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 8 Jun 2007 12:42:09 -0500 Subject: f7 images for mass production In-Reply-To: <46699457.1040106@fedoraproject.org> References: <46698430.9060702@redhat.com> <1181323201.2466.0.camel@work> <466990B0.2000701@fedoraproject.org> <2a28d2ab0706081032p5dadfdb5xcd300bfda94952ca@mail.gmail.com> <46699457.1040106@fedoraproject.org> Message-ID: <2a28d2ab0706081042ye4cb6a2n8258467176180730@mail.gmail.com> Yes! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242317 But there are at minumum several more, and quite a few posts about it on fedoraforum. Oh yea, and ICH7 sound, but this seems a bit isolated. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240081 On 6/8/07, Rahul Sundaram wrote: > Dr. Diesel wrote: > > The network related system hangs should be considered as well. > > > > This is extremely vague. Do you have any bug reports? > > Rahul > > -- > 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 Fri Jun 8 17:35:32 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 08 Jun 2007 13:35:32 -0400 Subject: f7 images for mass production In-Reply-To: <200706081302.41603.jkeating@redhat.com> References: <200706081302.41603.jkeating@redhat.com> Message-ID: <1181324132.4583.9.camel@localhost.localdomain> On Fri, 2007-06-08 at 13:02 -0400, Jesse Keating wrote: > On Friday 08 June 2007 12:25:04 Max Spevack wrote: > > I wanted to throw a question out to devel-list and Will Woods. > > > > We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. > > > > I would like to know if the conventional wisdom is that we should use > > the GOLD images, or if it is worthwhile to use an updated image (either > > of the LiveCD or of the DVD), in order to pull in any of the updates > > that have already been published. > > > > I hate questions like this (: If we don't, we'll just see more bug reports > and badness from the bugs we have. If we do, we'll get slammed for our > release being nothing but a Beta and /this/ one is the real release (although > I'm sure we'll find some bugs in this one too) Wait, I thought Fedora is one big beta!? /me ducks... ;-) > I think one part of the question can be answered by the distinct lack of an > updated F7 kernel as of yet, at least not released. There is > http://koji.fedoraproject.org/koji/buildinfo?buildID=8282 but I haven't seen > any update requests come through bodhi for it. So it's not like we know that > this solves the issues you'd want to say are fixed with a respin. > > Also, if we're going to respin, that's a lot more QA to toss in the mix to > make sure that our included fixes don't introduce regressions, and that the > compose processes itself was successful. This is just more work, nothing > more, nothing less. However we have limited time before Test1 is due, so > it's a balance we have to talk about. > > My personal opinion is that we make use of updates.img to fix any serious > anaconda bugs we've found. I don't recall any /serious/ ones though, we > snuck those in for the last rebuild. Adding updates.img is a simple call to > mkisofs, it doesn't involve pungi, or anaconda-runtime, or anything else. > It's just adding a file and recalling mkisofs. Anything more (like replacing > packages) is far more risky. If possible, we could have an insert into the > DVD sleeve with a print out of the known issues so that we give users a > fighting chance of working around the known issues. There are going to be > updates that people download after the fact, just given the sheer number of > updates already available, and I really don't think we have time to suck in > every existing update and give that a proper qa that a final release would > get. There are already 200+ megs of i386 updates, 500+megs of > updates-testing. That is a /lot/ of churn to try and stabilize again. I know it's from my vantage point as a docs-monkey, but I consider the non-localizing release-notes bug (#241975) pretty awful. So I'm in favor of the updates.img fix at least, which should minimize drag on QA. Our volunteer translators jump through hoops very quickly to get these done timely for a release and having the work be used is a big plus. ;-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Jun 8 17:43:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 13:43:27 -0400 Subject: f7 images for mass production In-Reply-To: References: <46698F2F.3060206@redhat.com> Message-ID: <200706081343.28052.jkeating@redhat.com> On Friday 08 June 2007 13:36:59 Max Spevack wrote: > Well, the answer is simply "I haven't had time to do it until now". ?And > because I thought it might be a worthwhile question to ask, and that if > I just took the GOLD bits and DVDs appeared, I guarantee you I'd get > plenty of emails saying "why didn't you ask about pulling in any > updates! ?There's bug FOO which is horrible!". To which you answer "The DVD pressers took a long time to make them, these were sent off the first opportunity I had after F7 went GOLD." (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 8 17:45:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 13:45:11 -0400 Subject: f7 images for mass production In-Reply-To: <466997CA.7060505@hhs.nl> References: <466997CA.7060505@hhs.nl> Message-ID: <200706081345.11568.jkeating@redhat.com> On Friday 08 June 2007 13:54:18 Hans de Goede wrote: > And if we spend the time to create new iso's for that, I think it would be > a good idea to make those available to our end-users. Call it a .0.1 > release, call it a brown paper bag release (not meant in any disrespect to > DaveJ, but the kernel is kinda a brown paper bag kernel). Eitherway if we > invest time and QA to make new iso's for this, we should make them > available, as the time has already been invested then. > > I vote for doing a new spin with: > -a new kernel included (we might have to wait a bit for this new kernel to > ? become available and proven) > -perhaps an updates.img included > -perhaps one or two updates for very very critical no interaction needed > ? network abusable security issues. And if we go down this path, will we have a Fedora 7.3? I remember 7.3, it was pretty nice. I had a box running 7.3 for quite a while.... To be blunt, this isn't Red Hat Linux. This is Fedora. We're forward moving. 7 is out. Fix what you can with updates, correct mistakes with F8. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mspevack at redhat.com Fri Jun 8 17:46:57 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 13:46:57 -0400 (EDT) Subject: f7 images for mass production In-Reply-To: <200706081338.36555.jkeating@redhat.com> References: <200706081302.41603.jkeating@redhat.com> <46698F2F.3060206@redhat.com> <200706081338.36555.jkeating@redhat.com> Message-ID: On Fri, 8 Jun 2007, Jesse Keating wrote: > As we've seen in this thread there are a lot of things we'd really > like to have fixed on the pressed media, simply because the release > has been out for a while and things inevitably fell out of a wider > audience using them. To be perfectly honest I think we should just > swallow the poisen pill and press the media as shipped, with a paper > insert warning people about know issues and recommending immediate > update. We'll just pretend like we had these pressed weeks ago when > the isos went gold. I guess the main question is "is the effort that it would take to produce a new ISO worth the bug fixes that would get in, and the potential new bugs that might emerge." Jesse and Thomas Chung think no. I see that others think yes. I'm inclined to go with Jesse and Thomas's opinions on this, since Jesse feels most of the rel-eng pain and Thomas feels most of the "end user getting one of those discs" pain. If their opinions change before Monday, then so be it. Otherwise, I guess I'll just use the GOLD ISOs and that will be that. I still think it was right to ask the quesiton, though. --Max From mspevack at redhat.com Fri Jun 8 17:48:54 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 13:48:54 -0400 (EDT) Subject: f7 images for mass production In-Reply-To: <200706081345.11568.jkeating@redhat.com> References: <466997CA.7060505@hhs.nl> <200706081345.11568.jkeating@redhat.com> Message-ID: On Fri, 8 Jun 2007, Jesse Keating wrote: > To be blunt, this isn't Red Hat Linux. This is Fedora. We're forward > moving. 7 is out. Fix what you can with updates, correct mistakes > with F8. So just to be clear, Jesse: Is your recommendation: 100% GOLD images or "updates.img" If the latter, who's going to build it and hand it to me? --Max From jwboyer at jdub.homelinux.org Fri Jun 8 17:56:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 08 Jun 2007 12:56:01 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <1181314065.2645.2.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080734.04118.jkeating@redhat.com> <1181303072.17463.12.camel@vader.jdub.homelinux.org> <200706080813.14360.jkeating@redhat.com> <1181314065.2645.2.camel@localhost.localdomain> Message-ID: <1181325361.17463.19.camel@vader.jdub.homelinux.org> On Fri, 2007-06-08 at 07:47 -0700, Toshio Kuratomi wrote: > On Fri, 2007-06-08 at 08:13 -0400, Jesse Keating wrote: > > On Friday 08 June 2007 07:44:32 Josh Boyer wrote: > > > Which goes back to just having the upstream repo checked out there > > > then... > > > > Only if the upstream repo is using a DSCM that we can write to, sure. But if > > they're not, or if they don't have the proper release tags we need, etc... Huh? I'm confused. You said you want an exploded tree to have at hand for developing patches against. Why do you need write access there? > Also, as Nicolas points out, we want to manage patches against a vendor > branch where we import the released tarballs rather than upstream's raw > tree. I would expect upstream to have branches, tags, etc. for their releases. This might not be universally true though I suppose. josh From snecklifter at gmail.com Fri Jun 8 17:57:05 2007 From: snecklifter at gmail.com (Chris Brown) Date: Fri, 8 Jun 2007 18:57:05 +0100 Subject: f7 images for mass production In-Reply-To: References: <200706081302.41603.jkeating@redhat.com> <46698F2F.3060206@redhat.com> <200706081338.36555.jkeating@redhat.com> Message-ID: <364d303b0706081057s2d8b49f5h8ff887cc644ff982@mail.gmail.com> On 08/06/07, Max Spevack wrote: > > On Fri, 8 Jun 2007, Jesse Keating wrote: > > > As we've seen in this thread there are a lot of things we'd really > > like to have fixed on the pressed media, simply because the release > > has been out for a while and things inevitably fell out of a wider > > audience using them. To be perfectly honest I think we should just > > swallow the poisen pill and press the media as shipped, with a paper > > insert warning people about know issues and recommending immediate > > update. We'll just pretend like we had these pressed weeks ago when > > the isos went gold. > > I guess the main question is "is the effort that it would take to > produce a new ISO worth the bug fixes that would get in, and the > potential new bugs that might emerge." > > Jesse and Thomas Chung think no. I see that others think yes. I'm > inclined to go with Jesse and Thomas's opinions on this, since Jesse > feels most of the rel-eng pain and Thomas feels most of the "end user > getting one of those discs" pain. > > If their opinions change before Monday, then so be it. Otherwise, I > guess I'll just use the GOLD ISOs and that will be that. > > I still think it was right to ask the quesiton, though. FWIW, so do I. I'm not sure what the Fedora Unity folks are up to these days - the website looks a touch stagnant - but perhaps re-spins with updates can always be done should there be the need for them as we now know. I'd vote for shipping gold. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Jun 8 17:58:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 13:58:30 -0400 Subject: f7 images for mass production In-Reply-To: <1181324132.4583.9.camel@localhost.localdomain> References: <200706081302.41603.jkeating@redhat.com> <1181324132.4583.9.camel@localhost.localdomain> Message-ID: <200706081358.30325.jkeating@redhat.com> On Friday 08 June 2007 13:35:32 Paul W. Frields wrote: > I know it's from my vantage point as a docs-monkey, but I consider the > non-localizing release-notes bug (#241975) pretty awful. ?So I'm in > favor of the updates.img fix at least, which should minimize drag on QA. > Our volunteer translators jump through hoops very quickly to get these > done timely for a release and having the work be used is a big plus. ;-) Hrm, so that's going to be a bit more work if we want the release notes to actually be localized and not just fallback to English. The anaconda bug was that it was looking for localized files in the root of the iso, and they just weren't there. The update fixes anaconda to fall back to English which is somewhat useful, at least it's not an error. However to actually get it localized I'll have to litter the iso with all the translated stuff in the root of the CD. Not a huge deal, just something that will have to be done. Will require a bit more testing, but *shrug* -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 8 17:58:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 23:28:55 +0530 Subject: f7 images for mass production In-Reply-To: <2a28d2ab0706081042ye4cb6a2n8258467176180730@mail.gmail.com> References: <46698430.9060702@redhat.com> <1181323201.2466.0.camel@work> <466990B0.2000701@fedoraproject.org> <2a28d2ab0706081032p5dadfdb5xcd300bfda94952ca@mail.gmail.com> <46699457.1040106@fedoraproject.org> <2a28d2ab0706081042ye4cb6a2n8258467176180730@mail.gmail.com> Message-ID: <466998DF.3010709@fedoraproject.org> Dr. Diesel wrote: > Yes! > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242317 > > But there are at minumum several more, and quite a few posts about it > on fedoraforum. This was already in Warren's proposed list. Rahul From jkeating at redhat.com Fri Jun 8 18:00:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 14:00:34 -0400 Subject: f7 images for mass production In-Reply-To: References: <200706081345.11568.jkeating@redhat.com> Message-ID: <200706081400.34347.jkeating@redhat.com> On Friday 08 June 2007 13:48:54 Max Spevack wrote: > So just to be clear, Jesse: > > Is your recommendation: > > 100% GOLD images or "updates.img" Yes. The only issue I've seen that is worthy of updates.img is release notes in other languages, and we can fix that to not just fall back to English but actually display the translated notes if they're on disk. The bug was 2 part. 1) the translated notes were not on Media. They haven't been for Fedora for many releases now, this is not a new problem. 2) Anaconda wouldn't fall back to English of the translated file wasn't found, this is the "new" problem I think, and fixed in updates.img. > If the latter, who's going to build it and hand it to me? That would fall to me and the Anaconda team. Them to produce the updates.img, me to mkisofs the isos, QA to test. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dr.diesel at gmail.com Fri Jun 8 18:05:09 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 8 Jun 2007 13:05:09 -0500 Subject: f7 images for mass production In-Reply-To: <466998DF.3010709@fedoraproject.org> References: <46698430.9060702@redhat.com> <1181323201.2466.0.camel@work> <466990B0.2000701@fedoraproject.org> <2a28d2ab0706081032p5dadfdb5xcd300bfda94952ca@mail.gmail.com> <46699457.1040106@fedoraproject.org> <2a28d2ab0706081042ye4cb6a2n8258467176180730@mail.gmail.com> <466998DF.3010709@fedoraproject.org> Message-ID: <2a28d2ab0706081105s2838cbd2y5b547f2f03293845@mail.gmail.com> mmmm, your correct! Some how I missed the first 7 posts of this thread. My bad! On 6/8/07, Rahul Sundaram wrote: > Dr. Diesel wrote: > > Yes! > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242317 > > > > But there are at minumum several more, and quite a few posts about it > > on fedoraforum. > > This was already in Warren's proposed list. > > Rahul > > -- > 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 Fri Jun 8 18:07:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 08 Jun 2007 20:07:44 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181325361.17463.19.camel@vader.jdub.homelinux.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080734.04118.jkeating@redhat.com> <1181303072.17463.12.camel@vader.jdub.homelinux.org> <200706080813.14360.jkeating@redhat.com> <1181314065.2645.2.camel@localhost.localdomain> <1181325361.17463.19.camel@vader.jdub.homelinux.org> Message-ID: <1181326091.4307.0.camel@rousalka.dyndns.org> Le vendredi 08 juin 2007 ? 12:56 -0500, Josh Boyer a ?crit : > On Fri, 2007-06-08 at 07:47 -0700, Toshio Kuratomi wrote: > > Also, as Nicolas points out, we want to manage patches against a vendor > > branch where we import the released tarballs rather than upstream's raw > > tree. > > I would expect upstream to have branches, tags, etc. for their releases. > This might not be universally true though I suppose. Can't be trusted even when they exist -- 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 anthonybryan at gmail.com Fri Jun 8 18:24:47 2007 From: anthonybryan at gmail.com (Anthony Bryan) Date: Fri, 8 Jun 2007 14:24:47 -0400 Subject: Improving availability and guaranteeing integrity in ISO downloads Message-ID: Hi, I was hoping Fedora could investigate using Metalinks for their ISO downloads. Metalink is an XML format for listing all the ways you can get a file or collection of files (mirrors + their location, rsync, p2p) along with checksums to automatically repair a file in case of error, signatures, language, OS/arch, and other metadata. It's mainly used for large files like ISOs, where errors can be very frustrating. It's supported by about 20 programs on unix, mac, and win, including aria2 (already in the Fedora repos). It's used by openSUSE, OpenOffice.org, cURL, and many other distributions. Here's a screenshot of a Metalink download in the DownThemAll Firefox extension (nightly build). What you don't see are all the mirrors and checksums. http://code.downthemall.net/maierman/metaselect4.png http://en.wikipedia.org/wiki/Metalink -- (( Anthony Bryan )) Metalink [ http://www.metalinker.org ] From notting at redhat.com Fri Jun 8 18:26:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 8 Jun 2007 14:26:23 -0400 Subject: new rc questions and comments Message-ID: <20070608182623.GA9472@nostromo.devel.redhat.com> Reading http://fedoraproject.org/wiki/FCNewInit/RC: - any particular reason to not look at upstart/initng? Simply backwards compatibility? - Having all the provides/requires kept outside the script when there are already parameters for having them in the script seems strange - why not just read the script? - How does this handle the case where the package that *actually* provides something may be determined at runtime, instead of build time? (For example, $time, or $local_fs may occur at different points in the boot depending on they system's setup.) - What benefits is there to doing a lot of flat files for storing system state? Bill From walters at redhat.com Fri Jun 8 18:37:52 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 08 Jun 2007 14:37:52 -0400 Subject: Feature idea: package an installer image as a grub entry before F8. Was [ Re: Very much packages with fc6 tag instead of fc7 in the FC7 tree ] In-Reply-To: <1180816462.3783.14.camel@localhost.localdomain> References: <604aa7910706011022y2216a0d7p8fe6df7f97defa36@mail.gmail.com> <1180816462.3783.14.camel@localhost.localdomain> Message-ID: <1181327872.3366.14.camel@neutron.verbum.private> On Sat, 2007-06-02 at 22:34 +0200, Sindre Pedersen Bjordal wrote: > I just did a package like this actually, and I did send an email to > -devel about it asking for feedback. Got no response though. > > This package consist of the vmlinuz and initrd.img files from the > isolinux dir on the install media and puts them in /grub/ + it uses > grubby to add the grub boot entry to launch Anaconda with the askmethod > option. I have made packages for i386 and x86_64. I've only tested the > i386 one and it works for me. > > For FC-6 to F-7: > http://fedoraproject.org/wiki/SindrePedersenBjordal/FedoraBootAnaconda I missed this originally in this thread; what did you think about the discussion about downloading the packages to install beforehand? Have you looked at what it would take for your anaconda image to use packages from the disk? We should take the relevant things from this and turn it into a wiki page probably to be sure it doesn't get lost in the archive noise. From jkeating at redhat.com Fri Jun 8 18:41:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 14:41:42 -0400 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: References: Message-ID: <200706081441.42279.jkeating@redhat.com> On Friday 08 June 2007 14:24:47 Anthony Bryan wrote: > I was hoping Fedora could investigate using Metalinks for their ISO > downloads. Metalink is an XML format for listing all the ways you can > get a file or collection of files (mirrors + their location, rsync, > p2p) along with checksums to automatically repair a file in case of > error, signatures, language, OS/arch, and other metadata. It's mainly > used for large files like ISOs, where errors can be very frustrating. > > It's supported by about 20 programs on unix, mac, and win, including > aria2 (already in the Fedora repos). It's used by openSUSE, > OpenOffice.org, cURL, and many other distributions. > > Here's a screenshot of a Metalink download in the DownThemAll Firefox > extension (nightly build). What you don't see are all the mirrors and > checksums. > http://code.downthemall.net/maierman/metaselect4.png > > http://en.wikipedia.org/wiki/Metalink This is something interesting, and I wonder if we could make use of MirrorManager ( https://hosted.fedoraproject.org/projects/mirrormanager ) to have dynamic .metalink files created with updated mirror readiness info. Certainly something that looks worth looking into. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 8 18:46:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 09 Jun 2007 00:16:42 +0530 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: <200706081441.42279.jkeating@redhat.com> References: <200706081441.42279.jkeating@redhat.com> Message-ID: <4669A412.1070204@fedoraproject.org> Jesse Keating wrote: > On Friday 08 June 2007 14:24:47 Anthony Bryan wrote: >> I was hoping Fedora could investigate using Metalinks for their ISO >> downloads. Metalink is an XML format for listing all the ways you can >> get a file or collection of files (mirrors + their location, rsync, >> p2p) along with checksums to automatically repair a file in case of >> error, signatures, language, OS/arch, and other metadata. It's mainly >> used for large files like ISOs, where errors can be very frustrating. >> >> It's supported by about 20 programs on unix, mac, and win, including >> aria2 (already in the Fedora repos). It's used by openSUSE, >> OpenOffice.org, cURL, and many other distributions. >> >> Here's a screenshot of a Metalink download in the DownThemAll Firefox >> extension (nightly build). What you don't see are all the mirrors and >> checksums. >> http://code.downthemall.net/maierman/metaselect4.png >> >> http://en.wikipedia.org/wiki/Metalink > > This is something interesting, and I wonder if we could make use of > MirrorManager ( https://hosted.fedoraproject.org/projects/mirrormanager ) to > have dynamic .metalink files created with updated mirror readiness info. > Certainly something that looks worth looking into. Suggested by me long back in Fedora infrastructure list. Someone expressed interest but nothing happened. Rahul From a.badger at gmail.com Fri Jun 8 18:50:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 Jun 2007 11:50:41 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <2979.192.54.193.51.1181304306.squirrel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <1181254342.4070.262.camel@localhost.localdomain> <2979.192.54.193.51.1181304306.squirrel@rousalka.dyndns.org> Message-ID: <1181328641.2645.34.camel@localhost.localdomain> On Fri, 2007-06-08 at 14:05 +0200, Nicolas Mailhot wrote: > Le Ven 8 juin 2007 00:12, Toshio Kuratomi a ?crit : > > >> 2. we don't really care what happened between two upstream releases, > >> that's best traced in the upstream vcs, a giant changeset between > >> them > >> is more pertinent at the fedora level than all the upstream change > >> history > >> > > We do when we're backporting a specific fix from upstream's > > development > > tree. > > > >> 3. we don't really care what happened on the packager system either, > >> just what was pushed as a build (or attempted-to-built package) > >> > > I disagree with this one quite a bit. > >> 4. we really do not want patches that stomp on each other > >> > > Actually, we do. > > IMHO you just don't realise a srpm content and the Fedora VCS are > intended for very different audiences than an upstream VCS. > I think we agree that SRPMs serve the purposes you outline but disagree what purposes the Fedora VCS should fill. If the reasons you outline below were sufficient for the VCS role, we wouldn't really need a VCS... Just a way to access a sequence of SRPMs. I think we need a VCS because we do development just like upstream. Our goal is to get the majority of our changes (everything not specific to the distro [defaults, etc]) into upstream but that doesn't change the fact that we are programming and would be helped by having access to VCS tools. > Upstream VCS is for core developpers. You trace what changes were > made, by whom, for what reasons and people who consult it are > specialists who know the codebase. > > SRPMs and Fedora packaging VCSes have quite another target. It's : > - "did Fedora break my trust in the upstream release" > - "can I check quickly with no deep knowledge of upstream codebase > nothing is obviously wrong" > - "can I quickly revert a suspicious change" > Having quilt like commands as part of the interaction with the VCS allows you to use the exploded tree in this manner. > It's definitely not > - "are Fedora patches are correct or useful fonctionnality-wise" > - "why did the Packager did this thing" > Disagree wholeheartedly. I don't just take upstream releases and package them. I also code bugfixes, backport fixes, and make changes to the default configs. When applicable, I submit these changes to upstream. Seeing as this is code developed against the source tree, I want to be able to track the changes I make in a VCS. Simply adding and removing patches in CVS is not very good for this. Working with those patches against the exploded tree is much better. > To this end you need: > - small patches > - which are not interdependant > - and have little churn > Ideally, yes. But there are times when the ideal does not occur. A patch to install data files to a hierarchy under %{datadir} could touch all the Makefile.ams, configure.ac, and several source files. Another patch to fix library detection could affect the same files. Large patches and interdependent. Little churn is great but doesn't always occur. Maybe upstream disagrees with how to fix a problem that you've patched for rawhide. Maybe you backported a fix from upstream and they've changed their mind on how to fix it. When you review the changes to a patch between trusted release 1.0-1 and new release 1.0-2, do you really find it easier to review the diff of a diff or would it be easier to just see what the changes to the tree were between the two rpm releases? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Fri Jun 8 18:57:16 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 08 Jun 2007 14:57:16 -0400 Subject: FESCo Meeting Summary for 2007-06-07 Message-ID: <1181329036.3132.7.camel@kennedy> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Tom Callaway (spot) * Rex Dieter (rdieter) * Christian Iseli (c4chris) * Josh Boyer (jwb) * Warren Togami (warren) == Summary == OLPC * FESCo approved the proposal to allow OLPC to make use of our systems, and leaves it up to rel-eng and Infrastructure teams to make it happen reasonably, with weekly reports to FESCo. For a nice write-up of the benefits refer to: http://fedoraproject.org/wiki/OlpcFedoraPartnership * FESCo approved the proposal to make John Palmieri (J5) a sponsor. Proposal for update tool defaults * FESCo approved the rel-eng proposal to have the update tool defaults pushing to updates-testing. For more details please refer to: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html Security Updates needing Security Team approval proposal * FESCo is amenable to the idea, and is awaiting a proposal from the Security team. Bugzilla component merge status * still being worked on. warren will poke some people to try to speed this up. fedora-devel-announce list * FESCo approved warren's proposal for the fedora-devel-announce list. https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00377.html Proposal Templates * FESCo gave general approval to f13's suggestion for a template for proposals that appear before FESCo, which will include items like 'when it will happen', 'who is driving it', 'whom it will effect', 'rollback plan', 'where in wiki will need to be updated'. Misc * bpepple mentioned that he had briefly discussed with Max Spevack about possibly delaying the upcoming FESCo election a few weeks, so that the FESCo & the Fedora Project Board (FPB) could have the elections at the same time. This would also give time for the FPB to more clearly define the responsibilities of FESCo in the post-merge world. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070607 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Fri Jun 8 19:00:17 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 08 Jun 2007 14:00:17 -0500 Subject: The Future of Fedora Package Management and the RPM Philosophy Message-ID: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> It's great to see discussion about the future Fedora package SCM again. However, I think that some people (myself included) are getting a little bogged down in the details of how to manage branches in a source code repository or the details of how particular SCMs work. Before deciding on details like this, there's one big question that we need to answer before we can make intelligent decisions about SCMs and how we should use them. The question is, do we want to move away from RPM's philosophy of using pristine sources plus patches to build binary packages? Determining the answer to this question is a fundamental first step before decide ?what's next.? Currently, all of the packages in Fedora consist of pristine sources, patches to the pristine sources, and a spec file that contains instructions that tell the builders how to take the pristine source, apply the patches, and output a binary package. All of this package building information is managed in a source code repository. The build system pulls the information out of the package repository to build the binary RPMs. This process has served the Fedora Project well so far. The packages in Fedora, thanks to a lot of hard work by packager maintainers and reviewers ? guided by the packaging guidelines ? are already very high quality and getting better all of the time. What hasn't been done well so far is the management of the patches that we apply to the sources. As far as the package repository is concerned patches appear out of thin air. This is because patches have not been managed in a central and public manner by the Fedora project (other than storing them as blobs in the package repository). Package maintainers have had to devise their own systems for developing and managing patches, and this has meant that the patches have been developed in an ad-hoc and private manner. This has made life difficult in a number of ways. It's harder for package maintainers to manage patches, both on their own and in collaboration with other package maintainers. It's harder to communicate changes to upstream and downstream developers. Managing patches in a central and public manner will have the following benefits: 1. Make the packager maintainer's work easier by making it easier to forward-port patches as new releases of upstream code become available or to backport bug fixes and security patches as they are developed. It will also be easier for package maintainers to collaborate on patches. Making the the task of managing patches easier will indirectly improve the quality of the packages because it will be easier to update packages when new sources are released upstream or to backport bug or security fixes that have been committed to the upstream SCM but are not yet part of a formal release. 2. Make it easier to communicate changes to upstream developers (so that patches that fix bugs or add features can benefit the wider F/OSS community and the package maintainer doesn't need to maintain the patches indefinitely). Fairly or unfairly, there's the perception that many patches sit in our CVS and never get pushed upstream. Of course, some patches should never get pushed upstream since they represent Fedora-specific policy, but in most cases we'd all be better off if our patches were incorporated upstream. 3. Make it easier for downstream developers (e.g. the RHEL and OLPC engineers or anyone else that repackages Fedora) to add their own customizations and communicate those changes back to Fedora or the upstream developers. Of particular concern here would be making it easier for downstream distributions to apply patches that implement policies specific to those distributions while keeping it easy for them to track changes in the Fedora patches. There are (at least) two different approaches that we could take to managing patches in a central, public manner. One method would keep the traditional package repositories and add separate patch management repositories. This method would preserve the pristine source plus patches philosophy of RPM. Another more radical approach would be to integrate the package and patch management repositories into one. In the separate package and patch management repositories, the package management remains largely the same. The SCM technology used to maintain the package repository might change, but it would remain a collection of pristine source, patches, and spec files. The patch management repository for a package would be different ? it would consist of a ?vendor? branch that contained the unmodified upstream code and it would contain a number of ?patch? branches that represent the patches to the upstream code that appear in the source package repository. Ultimately, every patch that appears in the package repository would have a branch in the patch management repository. Since the development of patches now happens in a central, public manner it's easier to communicate changes upstream, downstream, and within the Fedora community. Doing things in a central, public manner means that we can develop tools and procedures that will make managing patches easier for the package maintainer. If we want to be more radical, we could integrate the package and the patch repositories. Package building would no longer use pristine sources and patches to produce a binary package. Instead, the build system would pull already-patched code out of the repository and build the binary package from there. The advantage to integrating the patch and package repositories would be reducing the package maintainer's work. With separate package repositories and patch repositories the package maintainer has to do some work to export patches from the patch repository and import them into the package repository (I believe that we could develop some tools to minimize the amount of work it takes to export/import patches, but there would always be some manual steps). The primary disadvantage to integrating patch and package management is that we move away from RPM's philosophy of using pristine sources. Pristine sources have been required because it's possible to easily verify that our copy of the sources matches the upstream copy by comparing MD5 or GPG signatures. With an integrated repository where there are no longer pristine sources, it's not possible to verify that our copy of the code matches the upstream copy by comparing signatures on tarballs. Verifying the code integrity is possible with the integrated repository, but it's potentially much more difficult. Another disadvantage of integrated management is that unless the package maintainer disciplines himself/herself it can become difficult to separate changes to the code that were done to implement Fedora-specific policies (changing defaults in configuration files, moving files around to suit the FHS, etc.) from changes that were done to fix bugs or security problems (and thus might be of interest to upstream developers). Guidelines on how to manage vendor, patch, and policy branches will help maintain that discipline (but vigilance will be necessary). So would moving to an integrated package and patch repository be worth it? It's hard to say. Some of the predecessors of RPM used modified sources to build packages ? one of the complaints about those early package management systems was that it was hard to keep track of local changes to the code. However, with the advantage of modern source code management systems keeping track of changes to the code shouldn't be an issue. In either case we need to get the development and maintenance of patches ?out in the open? and that means having patches developed in central, public repositories. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri Jun 8 19:02:52 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 Jun 2007 12:02:52 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <200706080705.11909.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706072118.04076.jkeating@redhat.com> <1181267967.4070.309.camel@localhost.localdomain> <200706080705.11909.jkeating@redhat.com> Message-ID: <1181329372.2645.38.camel@localhost.localdomain> On Fri, 2007-06-08 at 07:05 -0400, Jesse Keating wrote: > I honestly don't have deep enough knowledge of the SCMs to know how to setup > how your patches are managed. If there was a patch management system > wouldn't it allow you to remove various patches so that you could get > Bar.patch in a state that it would apply to vendor-branch without any other > patches, or with only the absolutely required patches applied as well? > It probably could be smart enough to reduce to the minimal set of patches to cleanly apply. It probably couldn't be smart enough to get down to one patch when several patches had somewhat major edits of the same file without user input to resolve conflicts. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tjb at unh.edu Fri Jun 8 19:03:21 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 08 Jun 2007 15:03:21 -0400 Subject: fedora devel mirroring? In-Reply-To: <1181307134.29370.6.camel@raptor.sr.unh.edu> References: <1181247748.4097.34.camel@raptor.sr.unh.edu> <1181254720.23696.13.camel@neuromancer> <1181273883.24214.1.camel@scrappy.miketc.com> <1181307134.29370.6.camel@raptor.sr.unh.edu> Message-ID: <1181329401.29370.29.camel@raptor.sr.unh.edu> On Fri, 2007-06-08 at 08:52 -0400, Thomas J. Baker wrote: > On Thu, 2007-06-07 at 22:38 -0500, Mike Chambers wrote: > > On Thu, 2007-06-07 at 18:18 -0400, Thomas J. Baker wrote: > > > > > I believe I'm aware of the structure change and I'm rsyncing all of > > > mirrors.kernel.org::fedora. The fedora/development and > > > fedora/core/development both seem to be the same on my mirror. In fact, > > > I just visited http://mirrors.kernel.org/fedora/development/i386/os/ and > > > it indeed is only up to May 25th. > > > > I checked it out as well and he is correct, May 27th is the last update. > > I would email someone (an admin or webmaster) and maybe there is a > > problem on their end. > > > > I do that all the time on a site I mirror from and they usually respond > > pretty quick and let me know of any problems. > > > > -- > > Mike Chambers > > Madisonville, KY > > > > "Best little town on Earth!" > > > > I emailed ftpadmin at kernel.org describing the problem. > > Thanks, > > tjb I got a reply and the mirror should be fixed soon. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From mspevack at redhat.com Fri Jun 8 19:04:19 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 15:04:19 -0400 (EDT) Subject: Fedora 8 FUDCon/Hackfest Message-ID: We'd like to do another FUDCon/Hackfest in the Fedora 8 timeframe. We're going to hold it in Raleigh, NC this time. Contrary to some of the information that has already been put out that suggested July, it looks like the two potential weekends for the hackfest are now either: August 3rd - 5th or August 10th - 12th For those of you who are likely to want to attend, which dates are best for you? --Max From ihok at hotmail.com Fri Jun 8 19:08:06 2007 From: ihok at hotmail.com (Jack Tanner) Date: Fri, 08 Jun 2007 15:08:06 -0400 Subject: f7 images for mass production In-Reply-To: <20070608190902.4cd3f58b@lain.camperquake.de> References: <20070608190902.4cd3f58b@lain.camperquake.de> Message-ID: Ralf Ertzinger wrote: > Hi. > > On Fri, 8 Jun 2007 12:25:04 -0400 (EDT), Max Spevack wrote > >> I would like to know if the conventional wisdom is that we should use >> the GOLD images, or if it is worthwhile to use an updated image >> (either of the LiveCD or of the DVD), in order to pull in any of the >> updates that have already been published. > > Having read http://kernelslacker.livejournal.com/79957.html and after > my own experiences with newer kernels I'd say we should at least ship > a newer kernel. Just a user here, but... +1 to new updates.img and new kernel and known security updates. No QA other than "did it compose and boot." We're also missing a bit of context here -- who/how/when is going to be receiving these burned discs? If the intended audience includes folks who have low bandwidth, including a couple of updates is especially considerate. From wtogami at redhat.com Fri Jun 8 19:11:23 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 08 Jun 2007 15:11:23 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: References: Message-ID: <4669A9DB.5070102@redhat.com> Max Spevack wrote: > We'd like to do another FUDCon/Hackfest in the Fedora 8 timeframe. We're > going to hold it in Raleigh, NC this time. > > Contrary to some of the information that has already been put out that > suggested July, it looks like the two potential weekends for the > hackfest are now either: > > August 3rd - 5th > > or > > August 10th - 12th > > For those of you who are likely to want to attend, which dates are best > for you? > August 3rd - 5th is most preferable for me. And more generally it is probably best to have the hackfest sooner during the F8 cycle than later. I'd like to use part of the hackfest to make some real progress on integrating LTSP into Fedora proper. Maybe we bring Eric Harrison down for the event? Warren Togami wtogami at redhat.com From jkeating at redhat.com Fri Jun 8 19:11:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 15:11:32 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> Message-ID: <200706081511.40535.jkeating@redhat.com> On Friday 08 June 2007 15:00:17 Jeffrey C. Ollie wrote: > If we want to be more radical, we could integrate the package and the > patch repositories. Package building would no longer use pristine > sources and patches to produce a binary package. Instead, the build > system would pull already-patched code out of the repository and build > the binary package from there. I have to question why the build would have to be this way? If you've got the prestine source branch, and you've got the patch branches, is there no way to extract the patches to such a format that they will apply to the prestine source, and stack them appropriately? Could we not extract a patch or patch set from each of the patch branches to a set of patch files in proper order, use them in the spec against a prestine tarball to generate the rpm? This way we get the benefit of both worlds. If we're pie in the skying, I simply don't accept that we have to sacrifice prestine tarball + patches in our srpms just to get a way to manage patches against an exploaded source. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Fri Jun 8 19:14:47 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 08 Jun 2007 14:14:47 -0500 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: References: Message-ID: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> On Fri, 2007-06-08 at 15:04 -0400, Max Spevack wrote: > We'd like to do another FUDCon/Hackfest in the Fedora 8 timeframe. > We're going to hold it in Raleigh, NC this time. I'm sure that Raleigh & Boston are wonderful cities, but would it be possible to schedule some Fedora events somewhere in the midwest? Minneapolis, Chicago, or Kansas City would be great (Des Moines would be perfect - I wouldn't have to pay for a hotel). Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Fri Jun 8 19:18:05 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 08 Jun 2007 15:18:05 -0400 Subject: f7 images for mass production In-Reply-To: References: <20070608190902.4cd3f58b@lain.camperquake.de> Message-ID: <4669AB6D.8080009@redhat.com> Jack Tanner wrote: > +1 to new updates.img and new kernel and known security updates. No QA > other than "did it compose and boot." > > We're also missing a bit of context here -- who/how/when is going to be > receiving these burned discs? If the intended audience includes folks > who have low bandwidth, including a couple of updates is especially > considerate. > If we do make any change to the spin that goes on the media, we should stick to two key rules: 1) FIX ONLY INSTALL and nasty network issues like e1000. This means anaconda, kernel and possibly others. 2) DO NOT BREAK INSTALL, this means exclude security fixes. They are unrelated to install or kernel issues. We cannot easily verify that a tree will properly upgrade or install in all scenarios especially if we pull in arbitrary changes unrelated to #1. Warren Togami wtogami at redhat.com From mspevack at redhat.com Fri Jun 8 19:16:32 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 15:16:32 -0400 (EDT) Subject: f7 images for mass production In-Reply-To: References: <20070608190902.4cd3f58b@lain.camperquake.de> Message-ID: On Fri, 8 Jun 2007, Jack Tanner wrote: > We're also missing a bit of context here -- who/how/when is going to > be receiving these burned discs? If the intended audience includes > folks who have low bandwidth, including a couple of updates is > especially considerate. It's basically the media that we produce to send to conferences, and for the FreeMedia program, or anyone else who bothers to email me and say "hey, I need 50 discs for $SOMETHING" and then emails me again a week later to ask why I haven't sent them yet :-) --Max From blc at redhat.com Fri Jun 8 19:19:08 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 08 Jun 2007 13:19:08 -0600 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <20070607114028.GH2079@xi.wantstofly.org> <466834DA.1060009@redhat.com> Message-ID: <4669ABAC.8000004@redhat.com> Krzysztof Halasa wrote: > Are they? First you need a cross-gcc, you can't build it without libc > or magic tricks like -Dinhibit_libc. For big-endian ARM, you have to > modify gcc because otherwise it won't generate normal (non-kernel) BE > code (you need BE gcc lib, but I don't recomment multilib BE/LE gcc > either). Sure, a cross compiler is a pre-requisite to cross compiling :-) Binutils too. If you have old versions of packages such as glibc (and anything else that requires headers or libraries) you can drop them into a sys-root which the cross-tools use when compiling/linking. Generally you will need one cross compiler per supported arch. > bash... can you cross-compile bash at all? Not sure about current > situation (my box can run ARM programs as well and configure thinks > it's native) but ~ 2 years ago it was impossible without much > handcraft. Bash needs a little work. It's not a beast like perl, though. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From jkeating at redhat.com Fri Jun 8 19:20:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 15:20:11 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> Message-ID: <200706081520.11252.jkeating@redhat.com> On Friday 08 June 2007 15:14:47 Jeffrey C. Ollie wrote: > I'm sure that Raleigh & Boston are wonderful cities, but would it be > possible to schedule some Fedora events somewhere in the midwest? > Minneapolis, Chicago, or Kansas City would be great (Des Moines would be > perfect - I wouldn't have to pay for a hotel). THere is some shelfishness to doing things in Raleigh or BOS, Red Hat has to pay for fewer of their employees to get to it. Not a great excuse, just a reason (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 8 19:21:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 15:21:19 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: References: Message-ID: <200706081521.19757.jkeating@redhat.com> On Friday 08 June 2007 15:04:19 Max Spevack wrote: > August 3rd - 5th > > or > > August 10th - 12th > > For those of you who are likely to want to attend, which dates are best > for you? While my wife will hate me (anniversary on the 3rd), I prefer 3rd through the 5th as well, in the interest of getting it done ASAP. That said, doing it on the 10th-12th would give us an idea of what we did wrong for Test1 and be able to coordinate some fixxin love. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mspevack at redhat.com Fri Jun 8 19:20:25 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 8 Jun 2007 15:20:25 -0400 (EDT) Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> Message-ID: On Fri, 8 Jun 2007, Jeffrey C. Ollie wrote: > On Fri, 2007-06-08 at 15:04 -0400, Max Spevack wrote: >> We'd like to do another FUDCon/Hackfest in the Fedora 8 timeframe. >> We're going to hold it in Raleigh, NC this time. > > I'm sure that Raleigh & Boston are wonderful cities, but would it be > possible to schedule some Fedora events somewhere in the midwest? > Minneapolis, Chicago, or Kansas City would be great (Des Moines would > be perfect - I wouldn't have to pay for a hotel). It's easiest for us to organize around Raleigh and Boston because Red Hat has giant operations near there, and it can make things like venues quite inexpensive (or maybe even free). I think it would be a completely reasonable goal to say that the Fedora 9 hackfest is in some "western US" location, but given the time that we have to get it organized, and with the main organizational work falling on Greg DeKoenigsberg and myself for the Fedora 8 event, I'm afraid we're going to need to stick with Raleigh this time. Also, for the few folks that come in from Europe, at least the East Coast spares them an extra several hours of travel. But point taken. --Max From jkeating at redhat.com Fri Jun 8 19:22:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 15:22:53 -0400 Subject: f7 images for mass production In-Reply-To: References: <20070608190902.4cd3f58b@lain.camperquake.de> Message-ID: <200706081522.54072.jkeating@redhat.com> On Friday 08 June 2007 15:08:06 Jack Tanner wrote: > +1 to new updates.img and new kernel and known security updates. No QA > other than "did it compose and boot." I am extremely uncomfortable publishing anything that has only this level of QA. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Fri Jun 8 19:29:29 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 08 Jun 2007 15:29:29 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <200706081521.19757.jkeating@redhat.com> References: <200706081521.19757.jkeating@redhat.com> Message-ID: <4669AE19.4050706@redhat.com> Jesse Keating wrote: > On Friday 08 June 2007 15:04:19 Max Spevack wrote: >> August 3rd - 5th >> >> or >> >> August 10th - 12th >> >> For those of you who are likely to want to attend, which dates are best >> for you? > > While my wife will hate me (anniversary on the 3rd), I prefer 3rd through the > 5th as well, in the interest of getting it done ASAP. That said, doing it on > the 10th-12th would give us an idea of what we did wrong for Test1 and be > able to coordinate some fixxin love. > > http://fedoraproject.org/wiki/Releases/8/Schedule With test1 on August 1st and and feature freeze on August 20th, an Aug 3rd-5th event would allow for more time for changes discussed in FUDCON and hacked upon in the hackfest to make it in before the August 20th timeframe. Warren Togami wtogami at redhat.com From jeff at ocjtech.us Fri Jun 8 19:31:11 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 08 Jun 2007 14:31:11 -0500 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <200706081511.40535.jkeating@redhat.com> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <200706081511.40535.jkeating@redhat.com> Message-ID: <1181331071.3903.197.camel@lt21223.campus.dmacc.edu> On Fri, 2007-06-08 at 15:11 -0400, Jesse Keating wrote: > On Friday 08 June 2007 15:00:17 Jeffrey C. Ollie wrote: > > If we want to be more radical, we could integrate the package and the > > patch repositories. Package building would no longer use pristine > > sources and patches to produce a binary package. Instead, the build > > system would pull already-patched code out of the repository and build > > the binary package from there. > > I have to question why the build would have to be this way? If you've got the > prestine source branch, and you've got the patch branches, is there no way to > extract the patches to such a format that they will apply to the prestine > source, and stack them appropriately? Could we not extract a patch or patch > set from each of the patch branches to a set of patch files in proper order, > use them in the spec against a prestine tarball to generate the rpm? This > way we get the benefit of both worlds. If we're pie in the skying, I simply > don't accept that we have to sacrifice prestine tarball + patches in our > srpms just to get a way to manage patches against an exploaded source. Yes, that's certainly a possibility. It's kind of a medium between the two extremes I proposed. Building based upon a direct checkout of already patched source means all that you have to do is specify a tag but you lose the tarball + patches. Exporting patches from the exploded source repo and importing them as files to the package repo is more work but you keep the tarball + patches. The approach you propose would mean that the package maintainer would need to do some work to specify the set of patches to be extracted and the order to apply them (but wouldn't actually have to do the extraction him/herself), but you keep the tarball+patches approach to building. The key decision though that needs to be made is whether we take that radical step of abandoning the tarball+patches approach. My feeling is that it's too radical for right now, but maybe it won't be in the future. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at lovesunix.net Fri Jun 8 19:30:31 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 08 Jun 2007 21:30:31 +0200 Subject: f7 images for mass production In-Reply-To: <200706081343.28052.jkeating@redhat.com> References: <46698F2F.3060206@redhat.com> <200706081343.28052.jkeating@redhat.com> Message-ID: <1181331031.10842.5.camel@dawkins> fre, 08 06 2007 kl. 13:43 -0400, skrev Jesse Keating: > On Friday 08 June 2007 13:36:59 Max Spevack wrote: > > Well, the answer is simply "I haven't had time to do it until now". And > > because I thought it might be a worthwhile question to ask, and that if > > I just took the GOLD bits and DVDs appeared, I guarantee you I'd get > > plenty of emails saying "why didn't you ask about pulling in any > > updates! There's bug FOO which is horrible!". > > To which you answer "The DVD pressers took a long time to make them, these > were sent off the first opportunity I had after F7 went GOLD." (: Wouldn't that basically be lying? The events didn't in fact transpire like that and if we are to provide nice pressed media doing so with updates to save people the effort of downloading them could be considered a feature. So what if it makes Fedora 7 look like a release with poor QA, issuing updates at all pretty much states that, we never promised to be bug free but at least we can promise to serve our users with the best possible OS at any given time thanks to the power of learning from our mistakes and fixing problems. What unwillingness to do that says about Fedora would IMHO be infinitely worse. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From katzj at redhat.com Fri Jun 8 19:26:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 08 Jun 2007 15:26:30 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <4669AE19.4050706@redhat.com> References: <200706081521.19757.jkeating@redhat.com> <4669AE19.4050706@redhat.com> Message-ID: <1181330790.8605.1.camel@aglarond.local> On Fri, 2007-06-08 at 15:29 -0400, Warren Togami wrote: > http://fedoraproject.org/wiki/Releases/8/Schedule > With test1 on August 1st and and feature freeze on August 20th, an Aug > 3rd-5th event would allow for more time for changes discussed in FUDCON > and hacked upon in the hackfest to make it in before the August 20th > timeframe. ... assuming that we actually stick to this schedule (it's currently just a proposal and I've seen some compelling reasons that even just a week off would be substantially better) and don't slip anything at all. As it turns out, 3-5th is probably better for me personally (although I can do either) but from the schedule perspective, I'm not quite as sure that 3-5th is really the best answer. Jeremy From blc at redhat.com Fri Jun 8 19:32:12 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 08 Jun 2007 13:32:12 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <4669171D.90906@linux-kernel.at> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> Message-ID: <4669AEBC.3070802@redhat.com> Oliver Falk wrote: > Good self introduction. Now we know, that you know what you're talking > 'bout. :-) I pretend well, anyway :-) I'll see if some more folks from my group will jump in here. > True. But is cross compilation really as reliable as native compilation > is? I'm not experienced with cross compilation... But I think some > errors will only occur on *real native hardware*... Reliable? Sure. But there are problems unique to cross compiling which must be addressed. You don't want to pull in a host-header instead of a target-header. You also can't run the resulting executables so post-build testsuites can't be run. That said, object and executable generation is pretty much the same whether your cross compile or natively compile, so you're going to get functionally identical bits. > I think that's the same as with secondary arches. Yes, there must be > some team supporting the arch, if it's done via cross compilers or on > native hardware; But with one difference: The people who are involved in > the 2ndary arch stuff, might not be very experienced with cross > compilation; Like me and Alpha for example. Right- I hope I'm not alienating the folks who want to bring Arm to the Fedora fold even if it means native compilation. New arches and cross compiling aren't directly related, but when you put them together successfully it's very beneficial, but not necessary. Still, I bet there are more people per capita in the secondary-arch camp interested in cross compiling than the primary arches. > I think for Alpha we will have enough fast machines that can get the job > done. I don't know about the other arches.... That's handy- how will you bootstrap? > If there are volunteers for a arch and you have some man power who can > support the ArchTeam, that would be great - I think. If the arch-team > doesn't want cross compilation..... Let 'em alone. :-) I'm picturing more of a CrossTeam with a similar cross-sectional responsibility. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From katzj at redhat.com Fri Jun 8 19:31:40 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 08 Jun 2007 15:31:40 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181331071.3903.197.camel@lt21223.campus.dmacc.edu> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <200706081511.40535.jkeating@redhat.com> <1181331071.3903.197.camel@lt21223.campus.dmacc.edu> Message-ID: <1181331100.8605.6.camel@aglarond.local> On Fri, 2007-06-08 at 14:31 -0500, Jeffrey C. Ollie wrote: > The key decision though that needs to be made is whether we take that > radical step of abandoning the tarball+patches approach. My feeling is > that it's too radical for right now, but maybe it won't be in the > future. As I had previously mentioned on infrastructure-list, I think that it's too radical for now and I also think that it's too radical really forever. The value of being able to cleanly separate out the changes that we have, submit them back, review them, modify them, etc is just so incredibly high as far as avoiding unnecessary forks Jeremy From sundaram at fedoraproject.org Fri Jun 8 19:38:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 09 Jun 2007 01:08:44 +0530 Subject: f7 images for mass production In-Reply-To: <1181331031.10842.5.camel@dawkins> References: <46698F2F.3060206@redhat.com> <200706081343.28052.jkeating@redhat.com> <1181331031.10842.5.camel@dawkins> Message-ID: <4669B044.3090001@fedoraproject.org> David Nielsen wrote: > fre, 08 06 2007 kl. 13:43 -0400, skrev Jesse Keating: >> On Friday 08 June 2007 13:36:59 Max Spevack wrote: >>> Well, the answer is simply "I haven't had time to do it until now". And >>> because I thought it might be a worthwhile question to ask, and that if >>> I just took the GOLD bits and DVDs appeared, I guarantee you I'd get >>> plenty of emails saying "why didn't you ask about pulling in any >>> updates! There's bug FOO which is horrible!". >> To which you answer "The DVD pressers took a long time to make them, these >> were sent off the first opportunity I had after F7 went GOLD." (: > > Wouldn't that basically be lying? The events didn't in fact transpire > like that and if we are to provide nice pressed media doing so with > updates to save people the effort of downloading them could be > considered a feature. > > So what if it makes Fedora 7 look like a release with poor QA, issuing > updates at all pretty much states that, I don't necessarily disagree but some people have automatically associated updates with bug fixes which doesn't give a complete perspective as Fedora updates policy is to be close to upstream and that frequently cover new features too. Rahul From jkeating at redhat.com Fri Jun 8 19:40:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 15:40:56 -0400 Subject: f7 images for mass production In-Reply-To: <4669B044.3090001@fedoraproject.org> References: <1181331031.10842.5.camel@dawkins> <4669B044.3090001@fedoraproject.org> Message-ID: <200706081540.57027.jkeating@redhat.com> On Friday 08 June 2007 15:38:44 Rahul Sundaram wrote: > > So what if it makes Fedora 7 look like a release with poor QA, issuing > > updates at all pretty much states that, > > I don't necessarily disagree but some people have automatically > associated updates with bug fixes which doesn't give a complete > perspective as Fedora updates policy is to be close to upstream and that > frequently cover new features too. And don't underestimate the amount of time / effort it will take to freeze the tree, stabilize, spin, QA, fix anything along the way, and oops there's more bugs to fix, wash, rinse, repeat. This is no small undertaking if we're going to do it /right/. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Fri Jun 8 19:50:40 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 08 Jun 2007 14:50:40 -0500 Subject: f7 images for mass production In-Reply-To: <200706081540.57027.jkeating@redhat.com> References: <1181331031.10842.5.camel@dawkins> <4669B044.3090001@fedoraproject.org> <200706081540.57027.jkeating@redhat.com> Message-ID: <1181332240.17463.21.camel@vader.jdub.homelinux.org> On Fri, 2007-06-08 at 15:40 -0400, Jesse Keating wrote: > On Friday 08 June 2007 15:38:44 Rahul Sundaram wrote: > > > So what if it makes Fedora 7 look like a release with poor QA, issuing > > > updates at all pretty much states that, > > > > I don't necessarily disagree but some people have automatically > > associated updates with bug fixes which doesn't give a complete > > perspective as Fedora updates policy is to be close to upstream and that > > frequently cover new features too. > > And don't underestimate the amount of time / effort it will take to freeze the > tree, stabilize, spin, QA, fix anything along the way, and oops there's more > bugs to fix, wash, rinse, repeat. This is no small undertaking if we're > going to do it /right/. Agreed. And it needs to be done the right way if it's going to be done. Otherwise, when F8 rolls around people will say "you released 7.0.1 without freezing, why can't you do the whole distro that way?" josh From a.badger at gmail.com Fri Jun 8 19:53:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 Jun 2007 12:53:44 -0700 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> Message-ID: <1181332424.2645.73.camel@localhost.localdomain> On Fri, 2007-06-08 at 14:00 -0500, Jeffrey C. Ollie wrote: > The question is, do we want to move away from RPM's philosophy of using > pristine sources plus patches to build binary packages? Determining the > answer to this question is a fundamental first step before decide > ?what's next.? > I want to stay with the pristine sources philosophy. It's one of the guiding principles of rpm that I have always appreciated. If people are against it, I'll express some more logical arguments in favor of them. As for patches... SRPMs should definitely ship with multiple patches to that pristine source as we do now. How we store and/or generate the patches in our repositories before going to the build system is what I would like to see change. [snip a lot of good analysis] > There are (at least) two different approaches that we could take to > managing patches in a central, public manner. One method would keep the > traditional package repositories and add separate patch management > repositories. This method would preserve the pristine source plus > patches philosophy of RPM. Another more radical approach would be to > integrate the package and patch management repositories into one. [snip details of the two models] The model I envision is a mixture of both of the above. It preserves pristine sources and multiple patches while doing the work inside of the SCM and the spec file. A single repository holds the spec file and the "patch management branch" (which is a branch of the vendor branch). Creating patches is done by working on separate branches inside the "patch management branch". When issuing make build, make mockbuild, make x86_64, etc patches listed in the spec file could be automatically generated from the patch management branch and the pristine tarballs either downloaded from a lookaside cache or extracted from the vendor branch. > Another disadvantage of integrated management is that unless the package > maintainer disciplines himself/herself it can become difficult to > separate changes to the code that were done to implement Fedora-specific > policies (changing defaults in configuration files, moving files around > to suit the FHS, etc.) from changes that were done to fix bugs or > security problems (and thus might be of interest to upstream > developers). Guidelines on how to manage vendor, patch, and policy > branches will help maintain that discipline (but vigilance will be > necessary). > I disagree with the assumption that this will be harder in an exploded tree. Right now I need to manually keep all my patches separate (having a vanilla tree and separate feature trees, using gendiff, or using quilt [of which the latter is the only one that scales]). With a VCS each changeset can exist in its own branch and the VCS will provide facilities to separate the changes, merge conflicts, etc. Currently there is a temptation to put separate features/bugfixes into one patch because it is hard to manage the overlap between patches. With a VCS, there are tools to help you manage that. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From blc at redhat.com Fri Jun 8 19:56:09 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 08 Jun 2007 13:56:09 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <46686D85.5000603@redhat.com> References: <46686D85.5000603@redhat.com> Message-ID: <4669B459.5070401@redhat.com> Thought I'd follow up on my own post with some specificity on what I'm imagining: Brendan Conoboy wrote: > Technical: There must be cross compilers before we can cross compile. This is actually two packages: Gcc and Binutils. Both are already quite easy to build such that they use a sys-root. If you're not familiar with sys-roots, this is path prefix to /. Thus you usually have something like $sysroot/usr/lib and $sysroot/usr/include. When the compiler sees #include it actually reads in $sysroot/usr/include/stdio.h. Same for -l. Building a cross binutils requires kernel headers for the target architecture. Building gcc requires kernel headers and glibc. There are scripts to solve the initial chicken/egg problem of where to get that glibc for a new arch. At some point in the future gcc might not require glibc to build, but we aren't there yet. > The build system must be enhanced to support cross compilation. This is a really interesting (to me) extension of the build system requiring enhancements in many areas. First, there are primitives in Koji that need to be built up such that, for instance, x86 knows it can cross build arm tools. Second, the x86 host needs to be able to retrieve and install arm dependencies in the arm sys-root (arm's glibc, arm's libX11-devel, etc). Third, a native/cross hybrid environment needs to be setup to facilitate the common assumptions made by packages. Previous cross compilation efforts inside my group have spent a lot of time on this. I bet others have as well > Finally, packages must be modified to support cross compilation. This is really a one-at-a-time process. It's often a matter of using relative paths so that #include
gets the right header. Or using headers instead of directly reading from /proc. Every package is different. Autotools using packages are frequently much easier than non. > Social: As a volunteer effort, it is unreasonable to expect existing > package maintainers to do the work necessary to support cross > compilation. There must be people to take on that responsibility and > work with upstream and package maintainers to integrate the necessary > changes. I have read the Secondary Architectures proposal and thread with great interest. While there may be some overlap of interest with cross compiling, it's not inherently true. Thus, I'd suggest a cross-team who would generally be responsible for cross-compilation efforts. This might break down like so: 1. Responsible for parts of the build system dedicated to cross compilation. 2. Maintainers of the cross compilation tools (These would presumably be rebuilds of gcc and binutils for the cross-targets). 3. Make changes to existing packages in cooperation with the package maintainer. 4. Be responsible for fixing builds that fail because of cross compiling, but succeed when natively built. Anybody whose turf I just suggested stepping on, please chime in! -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From Matt_Domsch at dell.com Fri Jun 8 20:14:28 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 8 Jun 2007 15:14:28 -0500 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: References: Message-ID: <20070608201428.GB26399@lists.us.dell.com> On Fri, Jun 08, 2007 at 03:04:19PM -0400, Max Spevack wrote: > We'd like to do another FUDCon/Hackfest in the Fedora 8 timeframe. > We're going to hold it in Raleigh, NC this time. > > Contrary to some of the information that has already been put out that > suggested July, it looks like the two potential weekends for the > hackfest are now either: > > August 3rd - 5th > > or > > August 10th - 12th > > For those of you who are likely to want to attend, which dates are best > for you? Just a note, these two weekends bookend LinuxWorldExpo San Francisco, for those people, like me, who will be there, and will find it difficult to be away from home for the extra days and an extra flight. I don't know what the intersection of (LWE Attendees) and (FUDCon Attendees) is, but suspect it's non-zero. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From ndbecker2 at gmail.com Fri Jun 8 20:47:01 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 08 Jun 2007 16:47:01 -0400 Subject: boinc anyone? Message-ID: Is there an rpm of boinc for fedora? A quick google search suggests there were rpms for fc5, but nothing in current fc7 repos. From nicolas.mailhot at laposte.net Fri Jun 8 21:48:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 08 Jun 2007 23:48:24 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181328641.2645.34.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <1181254342.4070.262.camel@localhost.localdomain> <2979.192.54.193.51.1181304306.squirrel@rousalka.dyndns.org> <1181328641.2645.34.camel@localhost.localdomain> Message-ID: <1181339304.3335.17.camel@rousalka.dyndns.org> Le vendredi 08 juin 2007 ? 11:50 -0700, Toshio Kuratomi a ?crit : > On Fri, 2007-06-08 at 14:05 +0200, Nicolas Mailhot wrote: > > It's definitely not > > - "are Fedora patches are correct or useful fonctionnality-wise" > > - "why did the Packager did this thing" > > > Disagree wholeheartedly. I don't just take upstream releases and > package them. I also code bugfixes, backport fixes, and make changes to > the default configs. When applicable, I submit these changes to > upstream. Seeing as this is code developed against the source tree, I > want to be able to track the changes I make in a VCS. Simply adding and > removing patches in CVS is not very good for this. Working with those > patches against the exploded tree is much better. But that's the VCS usefulness for you as individual packager, not its usefulness for upstream (just wants ready-to-push patches) for fedora users (just want to be able to do quick audits) or other fedora packagers (as far as I know we never have more than one people working on changes on the same package between two koji builds) Therefore, what would tracking all those changes in a public VCS instead of a private branch would accomplish? It would only flood the Fedora commit list & VCS with all your private code attempts, and make harder to identify shipped patches among all the other noise/activity (bad for everyone but you) If you actually look at the information you want published (not your local developer undo/redo queue), is it so much different from what we're already publishing today ? Exploded view may make the changes easier to grasp, but do we *actually* need any datapoint apart from each package build state published? -- 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 opensource at till.name Fri Jun 8 22:02:38 2007 From: opensource at till.name (Till Maas) Date: Sat, 09 Jun 2007 00:02:38 +0200 Subject: f7 images for mass production In-Reply-To: <200706081522.54072.jkeating@redhat.com> References: <200706081522.54072.jkeating@redhat.com> Message-ID: <200706090002.43553.opensource@till.name> On Fr Juni 8 2007, Jesse Keating wrote: > I am extremely uncomfortable publishing anything that has only this level > of QA. How about adding a copy of the updates repository in a new directory to the DVD? This will not affect anything else but allows to install the security updates without having internet access. Regards, Till From bernie at codewiz.org Fri Jun 8 22:14:14 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Fri, 08 Jun 2007 18:14:14 -0400 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <20070608100217.GA30585@neu.nirvana> References: <46689424.5030009@codewiz.org> <20070608100217.GA30585@neu.nirvana> Message-ID: <4669D4B6.5070209@codewiz.org> Axel Thimm wrote: >> could we change the list configuration not to munge >> the Reply-To header, so that when we "Reply All", we >> actually don't loose the Cc list? > > Why do you lose the Cc list with reply *all*? At least my mutt > doesn't, so perhaps its a MUA issue? It's not lost in my MUA... it's just that the original senders are not being moved to Cc by the list server before replacing the Reply-To header with the list address. See? I've selected reply-all, and got a replay to the list only, not to you *and* the list as one would expect by a function labeled "reply all". >> The way it's configured now makes it very difficult to >> notice own's replies in threads. > > Why? the From: field doesn't change, you're still the author of your > reply. e-mail clients use From: only when there's no "Reply-To" The "Reply-To" header means: "instead of replying to my from address, please reply to here". > But some of these lists you mention are not subscriber only. I also think lists should be open to posting by non-subscribers... Otherwise cross-posting is painful and doesn't work as intended (i.e.: you get half of the messages in each list). The spam argument is easily dismissed once you notice that linux-kernel@ is almost 100% spam free despite being open. So it just takes some clever filtering to solve this problem. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From jonathan.underwood at gmail.com Fri Jun 8 22:24:33 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 8 Jun 2007 23:24:33 +0100 Subject: boinc anyone? In-Reply-To: References: Message-ID: <645d17210706081524s4475da5g2d7ab2f5c7e043c2@mail.gmail.com> On 08/06/07, Neal Becker wrote: > Is there an rpm of boinc for fedora? A quick google search suggests there > were rpms for fc5, but nothing in current fc7 repos. > Not that I know of. This would make a good starting point for a package though: http://cvs.pld-linux.org/cgi-bin/cvsweb/SPECS/boinc.spec?rev=1.22 :) J. From greno at verizon.net Fri Jun 8 22:30:36 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 08 Jun 2007 18:30:36 -0400 Subject: f7 images for mass production In-Reply-To: <466997CA.7060505@hhs.nl> References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> <466997CA.7060505@hhs.nl> Message-ID: <4669D88C.7090302@verizon.net> Hans de Goede wrote: > Max Spevack wrote: >> On Fri, 8 Jun 2007, Rahul Sundaram wrote: >> >>> So the next question would be, if you are fixing important bugs and >>> doing a respin why are you not doing a point release publicly? >> >> I think that's a bit of a red herring. For me, it's just a matter of >> "if we're going to spend a bunch of money on physical media" I'd like >> to have any horrible bugs fixed, if we can. >> > > Yes, > > And if we spend the time to create new iso's for that, I think it > would be a good idea to make those available to our end-users. Call it > a .0.1 release, call it a brown paper bag release (not meant in any > disrespect to DaveJ, but the kernel is kinda a brown paper bag > kernel). Eitherway if we invest time and QA to make new iso's for > this, we should make them available, as the time has already been > invested then. > > I vote for doing a new spin with: > -a new kernel included (we might have to wait a bit for this new > kernel to > become available and proven) > -perhaps an updates.img included > -perhaps one or two updates for very very critical no interaction needed > network abusable security issues. > > Regards, > > Hans > I would second these. My initial experience with the first F7 ISOs was very bad. It won't install on my real hardware from DVD as the install won't recognize the drive. My second attempt was a LiveCD which promptly bombed with a listing of block errors on sr0. Didn 't even know I had an sr0. My third attempt was to load F7 in QEMU. Would only work with HTTP option. Once I got it loaded it wouldn't run with kqemu so I had to run it without acceleration and I don't need to tell you that it isn't even usable without acceleration. My next attempt was in Xen on a FC6 host. Setup a domain in virt mgr pointing to a good mirror. It started anaconda and then when it got to the partitioning screen it showed no drives or partitions available for installation. Completely hangs the install right there. So yes, I'm ready for something a little more tested. my 2c, Gerry From anthonybryan at gmail.com Fri Jun 8 22:31:53 2007 From: anthonybryan at gmail.com (Anthony Bryan) Date: Fri, 8 Jun 2007 18:31:53 -0400 Subject: Improving availability and guaranteeing integrity in ISO downloads Message-ID: > From: Jesse Keating > > On Friday 08 June 2007 14:24:47 Anthony Bryan wrote: > > I was hoping Fedora could investigate using Metalinks for their ISO > > downloads. Metalink is an XML format for listing all the ways you can > > get a file or collection of files (mirrors + their location, rsync, > > p2p) along with checksums to automatically repair a file in case of > > error, signatures, language, OS/arch, and other metadata. It's mainly > > used for large files like ISOs, where errors can be very frustrating. > > > > It's supported by about 20 programs on unix, mac, and win, including > > aria2 (already in the Fedora repos). It's used by openSUSE, > > OpenOffice.org, cURL, and many other distributions. > > > > Here's a screenshot of a Metalink download in the DownThemAll Firefox > > extension (nightly build). What you don't see are all the mirrors and > > checksums. > > http://code.downthemall.net/maierman/metaselect4.png > > > > http://en.wikipedia.org/wiki/Metalink > > This is something interesting, and I wonder if we could make use of > MirrorManager ( https://hosted.fedoraproject.org/projects/mirrormanager ) to > have dynamic .metalink files created with updated mirror readiness info. > Certainly something that looks worth looking into. That would be quite nice, no one else has dynamic .metalinks on a large scale. When I got the F7 ISO, I noticed it would fit in well w/ the download pages which tell which mirrors have which releases. I think it would make things less frustrating for end users trying to get things, and hopefully create less strain on mirrors. Certain metalink clients will download from domestic mirrors first, if country info is in there, which should hopefully be more efficient for everyone. What can we do to make this happen? Is this the type of thing that's easier for the maintainer of MirrorManager to add, or should we supply a patch? Here's the current tools people have done, if that helps - http://www.metalinker.org/implementation.html#generate Metalink Editor - in Python, GUI cURL - they use a short Perl script that makes them based on location. Simba/RoPkg::Metalink - Perl Bouncer - there's a patch for it. Metalink tools - CLI, C++ Thanks too, Rahul. Would it be worth posting on infrastructure to see if people are interested now? -- (( Anthony Bryan )) Metalink [ http://www.metalinker.org ] From sundaram at fedoraproject.org Fri Jun 8 22:35:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 09 Jun 2007 04:05:40 +0530 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: References: Message-ID: <4669D9BC.2040702@fedoraproject.org> Anthony Bryan wrote: > What can we do to make this happen? Is this the type of thing that's > easier for the maintainer of MirrorManager to add, or should we supply > a patch? > > Here's the current tools people have done, if that helps - > http://www.metalinker.org/implementation.html#generate > > Metalink Editor - in Python, GUI > cURL - they use a short Perl script that makes them based on location. > Simba/RoPkg::Metalink - Perl > Bouncer - there's a patch for it. > Metalink tools - CLI, C++ > > Thanks too, Rahul. Would it be worth posting on infrastructure to see > if people are interested now? Sure. Worth trying. Rahul From rms at 1407.org Fri Jun 8 23:12:49 2007 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Sat, 09 Jun 2007 00:12:49 +0100 Subject: massive commercial scale copyright infringement of FC3 In-Reply-To: <20070608182848.61999abc@lain.camperquake.de> References: <1181317422.5132.18.camel@localhost6.localdomain6> <20070608182848.61999abc@lain.camperquake.de> Message-ID: <1181344369.2710.8.camel@roque> Sex, 2007-06-08 ?s 18:28 +0200, Ralf Ertzinger escreveu: > Hi. > > On Fri, 08 Jun 2007 16:43:42 +0100, Rui Miguel Silva Seabra wrote > > > I discovered a massive commercial scale copyright infringement of FC3. > > Just so that I am in the clear: did FC3 violate someones copyright, or > did someone violate our/rhs/whoeveritactuallyis copyright on FC3? I didn't say "in FC3" but "of FC3" that should be enough ;) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From jeff at ocjtech.us Fri Jun 8 23:25:13 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 08 Jun 2007 18:25:13 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <1181339304.3335.17.camel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <1181254342.4070.262.camel@localhost.localdomain> <2979.192.54.193.51.1181304306.squirrel@rousalka.dyndns.org> <1181328641.2645.34.camel@localhost.localdomain> <1181339304.3335.17.camel@rousalka.dyndns.org> Message-ID: <1181345113.3691.8.camel@lt21223.campus.dmacc.edu> On Fri, 2007-06-08 at 23:48 +0200, Nicolas Mailhot wrote: > > If you actually look at the information you want published (not your > local developer undo/redo queue), is it so much different from what > we're already publishing today ? Exploded view may make the changes > easier to grasp, but do we *actually* need any datapoint apart from each > package build state published? Depending on the changes made between releases forward porting a patch may be made much easier by having the entire history available to you when you re-base a patch, especially if there has been a lot of code reorganization. I can recall several instances where I've been trying to update an old patch and it's been a lot easier (in some cases trivial) to check out a old copy of the upstream code from their SCM apply the patch and then merge up to the present. Without doing something like that I likely would have had to hand-apply much of those patches. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Fri Jun 8 23:58:03 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 08 Jun 2007 19:58:03 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> Message-ID: <1181347083.12195.5.camel@neutron.verbum.private> Admittedly I only skimmed this thread, but it seems like a decent opportunity to work my top three annoyances with the current system into discussion =) - Don't make me increment integers (Release); this is what computers (i.e. the build system) are for - Get rid of the redundant changelog so I don't have to type changes twice (and this would also remove the redundant version number too) - Remove the 'make tag' step (I think switching to a RCS with atomic commits would fix this). Actually I think you could reduce the whole thing to just "make build" by checking the output of $RCS status, if there are modified files $RCS commit, then invoke the current "make build". From shams at orcon.net.nz Sat Jun 9 00:40:11 2007 From: shams at orcon.net.nz (Shams) Date: Sat, 9 Jun 2007 12:40:11 +1200 Subject: Fedora 7: Gnome menu and Evolution References: <46691D87.2010505@fedoraproject.org> Message-ID: Sorry about the cross-post but for some reason some of my "valid" messages are not getting through onto either lists so I thought I'd try both for a few posts and hopefully send successfully and receive a response sucessfully. It might have something to do with moderation?? Thanks Shams -- "Rahul Sundaram" wrote in message news:46691D87.2010505 at fedoraproject.org... > Shams wrote: >> Hi, >> >> I installed Evolution and it too me a while to find where it was >> installed >> in the Gnome menu. >> >> It is Internet -> Mail >> >> but why? >> >> Shouldn't it should just be called Internet -> Evolution or Internet -> >> Evolution Email Client >> >> Just like Fiefox shows up as Internet -> Firefox Web Browser >> Just like ThunderBird shows up as Internet -> ThunderBird >> >> And just like Outlook Express shows up as All Program -> Outlook Express >> >> Why hide its identity? > > We already had a discussion along similar lines in this list before so you > might want to look at the archives in fedora-devel. I noticed that you > have been cross posting the recent mails. Don't do that. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mark at borkware.net Sat Jun 9 01:27:54 2007 From: mark at borkware.net (Mark Rosenstand) Date: Sat, 09 Jun 2007 03:27:54 +0200 Subject: sysvinit VS initng VS upstart VS launchd (Was: Future New Init for FC7?) In-Reply-To: <4613D994.8010109@fedoraproject.org> References: <6e24a8e80704011457o6fb45329l3910d6686546d448@mail.gmail.com> <6e24a8e80704011547r576e77bcj33791e37bcd1a7c8@mail.gmail.com> <1175468732.3008.190.camel@zelda.fubar.dk> <4611671E.6060605@develer.com> <1175554219.2751.63.camel@zelda.fubar.dk> <21190.1175583005@sss.pgh.pa.us> <60333.192.54.193.51.1175588723.squirrel@rousalka.dyndns.org> <6e24a8e80704030404qb10da46r25e629ef4b3ae8c1@mail.gmail.com> <46123528.8000909@gmail.com> <4613C626.4020302@develer.com> <4613D994.8010109@fedoraproject.org> Message-ID: <1181352474.23265.1.camel@pavilion> On Wed, 2007-04-04 at 22:30 +0530, Rahul Sundaram wrote: > Bernardo Innocenti wrote: > > > > > What do you mean by compatibility mode? I've only seen Upstart in > > Ubuntu Feisty. Booting was so fast that I assumed it was parallel > > already. > > Upstart does not run init scripts in parallel at all. It does, but _Ubuntu_ doesn't utilize that functionality yet. From dtimms at iinet.net.au Sat Jun 9 02:20:14 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 09 Jun 2007 12:20:14 +1000 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <200706081441.42279.jkeating@redhat.com> References: <200706081441.42279.jkeating@redhat.com> Message-ID: <466A0E5E.50201@iinet.net.au> Jesse Keating wrote: > On Friday 08 June 2007 14:24:47 Anthony Bryan wrote: >> I was hoping Fedora could investigate using Metalinks for their ISO >> downloads. Metalink is an XML format for listing all the ways you can >> get a file or collection of files (mirrors + their location, rsync, >> p2p) along with checksums to automatically repair a file in case of >> error, signatures, language, OS/arch, and other metadata. It's mainly >> used for large files like ISOs, where errors can be very frustrating. >> >> It's supported by about 20 programs on unix, mac, and win, including >> aria2 (already in the Fedora repos). It's used by openSUSE, >> OpenOffice.org, cURL, and many other distributions. >> >> Here's a screenshot of a Metalink download in the DownThemAll Firefox >> extension (nightly build). What you don't see are all the mirrors and >> checksums. >> http://code.downthemall.net/maierman/metaselect4.png >> >> http://en.wikipedia.org/wiki/Metalink > > This is something interesting, and I wonder if we could make use of > MirrorManager ( https://hosted.fedoraproject.org/projects/mirrormanager ) to > have dynamic .metalink files created with updated mirror readiness info. > Certainly something that looks worth looking into. I recently worked on a tiny tool to use already downloaded files to reconstruct a full iso-image {eg Fedora test to Fedora release iso}. I could have made this a lot more sure that it was doing the right thing by comparing sha1sum of the individual files with reference sha1sum files. {for interest see: http://www.redhat.com/archives/fedora-test-list/2007-June/msg00018.html } The simplest way to do this would be for the iso spin system to perform an sha1sum * > SHA1SUM within each directory of an iso spin, and have each result inserted into the corresponding directory. I could see other uses for embedding checksums within the iso archive : - live test the files written within an iso image: - insert media {gets automounted} - cd /media/whatever - sha1sum -c SHA1SUM - actually proves the disc/drive/PC can properly read the individual files. This could be extended to a simple tool in the root folder that can verify that all files in all folders on the cd/dvd are readable and correct. {python would be my weapon of choice, but }. - Enable fast download method like above/jigdo/bittorrent to work on per file contained within the {iso} archive, rather than the iso file {whole or in fixed sized pieces that span/split files} - This makes it easier for a download tool to verify that a file found as a potential content of an iso is actually the correct file to insert. Is inserting per folder checksum results into the iso image a do-able thing ? Would a patch to achieve such be considered ? DaveT. From spng.yang at gmail.com Sat Jun 9 05:37:25 2007 From: spng.yang at gmail.com (Ken YANG) Date: Sat, 09 Jun 2007 13:37:25 +0800 Subject: new libwnck make emerald fail to start In-Reply-To: <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> Message-ID: <466A3C95.60905@gmail.com> hi, it seems that the update about beryl still has dependence error: Error: Missing Dependency: emerald-themes >= 0.2.1 is needed by package beryl-gnome Error: Missing Dependency: heliodor >= 0.2.1 is needed by package beryl-gnome Error: Missing Dependency: emerald >= 0.2.1 is needed by package beryl-gnome i wait several days for this bug fix, but these errors still be there. please correct me if i'm wrong by the way, how can i report this sort of update dependence errors? is it appropriates to report errors to fedora-devel-list? finally, there is another dependence error about revisor: Error: Missing Dependency: nash = 6.0.9-4 is needed by package libbdevid-python my system is in fc8 rawhide with nash-6.0.9-5 Yuan Yijun wrote: > 2007/6/7, Ken YANG : >> >> >> and additionally, i have another questions: >> >> after i update, i find some errors, and i want to restore to last >> version, especially in rawhide. >> for example, the newest foo-1.0.1 is not stable, i want to restore to >> the last version foo-1.0.0, where i can get this version of foo? >> > > dig it deeply in the buildsys or on DVD > > From spng.yang at gmail.com Sat Jun 9 05:53:19 2007 From: spng.yang at gmail.com (Ken YANG) Date: Sat, 09 Jun 2007 13:53:19 +0800 Subject: reply-to-list addons cant use on fedora thunderbird version Message-ID: <466A404F.1010607@gmail.com> hi all, i notice there is a nice add-on about reply-to-mailing-list: http://lists.opensuse.org/opensuse/2006-11/msg03582.html http://alumnit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension but after i install, it can not work, as wiki said, maybe need a patch for thunderbird, it seems suse thunderbird version can run this sort of add-on is fedora has similar reply-to-list addon? thank in advance From skvidal at linux.duke.edu Sat Jun 9 06:42:12 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 09 Jun 2007 02:42:12 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181347083.12195.5.camel@neutron.verbum.private> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> Message-ID: <1181371332.4534.16.camel@rivendell> On Fri, 2007-06-08 at 19:58 -0400, Colin Walters wrote: > Admittedly I only skimmed this thread, but it seems like a decent > opportunity to work my top three annoyances with the current system into > discussion =) > > - Get rid of the redundant changelog so I don't have to type changes > twice (and this would also remove the redundant version number too) the changelog is for changes in the packaging, not in the program. -sv From Axel.Thimm at ATrpms.net Sat Jun 9 07:02:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 09:02:26 +0200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <4669D4B6.5070209@codewiz.org> References: <46689424.5030009@codewiz.org> <20070608100217.GA30585@neu.nirvana> <4669D4B6.5070209@codewiz.org> Message-ID: <20070609070226.GA4852@neu.nirvana> On Fri, Jun 08, 2007 at 06:14:14PM -0400, Bernardo Innocenti wrote: > See? I've selected reply-all, and got a replay to the list only, > not to you *and* the list as one would expect by a function labeled > "reply all". On a subscriber-only list I consider that a feature. I hate getting duplicate emails, especially ones that don't have a List-Id: header to properly sort the mail (like the Cc'd mail wouldn't have). In fact I already write a Reply-To: header myself on all lists to make sure this doesn't happen. > >>The way it's configured now makes it very difficult to notice > >>own's replies in threads. > > > >Why? the From: field doesn't change, you're still the author of > >your reply. > > e-mail clients use From: only when there's no "Reply-To" The > "Reply-To" header means: "instead of replying to my from address, > please reply to here". But that doesn't make it difficult to recognize your own posts as you wrote above, does it? > >But some of these lists you mention are not subscriber only. > > I also think lists should be open to posting by non-subscribers... > Otherwise cross-posting is painful and doesn't work as intended > (i.e.: you get half of the messages in each list). But cross-posting is discouraged anyway. > The spam argument is easily dismissed once you notice that > linux-kernel@ is almost 100% spam free despite being open. http://lkml.org/lkml/2006/8/8/146 > So it just takes some clever filtering to solve this problem. OK, there are a couple of mailing lists on this very server that are open to anyone just have a look at for example video4linux-list at redhat.com to see the amount of spam. But anyway fedora lists are not fire-and-forget. If you want to participate you will have to subscribe, and since we know that everyone is subscribed, we don't have to care about replying to external participants. -- 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 jos at xos.nl Sat Jun 9 07:13:11 2007 From: jos at xos.nl (Jos Vos) Date: Sat, 9 Jun 2007 09:13:11 +0200 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181347083.12195.5.camel@neutron.verbum.private>; from walters@redhat.com on Fri, Jun 08, 2007 at 07:58:03PM -0400 References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> Message-ID: <20070609091311.A9924@xos037.xos.nl> On Fri, Jun 08, 2007 at 07:58:03PM -0400, Colin Walters wrote: > - Don't make me increment integers (Release); this is > what computers (i.e. the build system) are for Whatever you suggest to change, be sure that the final spec file contains a real integer, not a macro defined in the build system or so. It's already very discussable that %{?dist} is now used in the release tags. I know this was introduced to overcome a - what you can maybe call - shortcome in RPM, but it has its drawbacks and every use of non-standard externally defined macros violates the principles of RPM, being able to reproduce package building. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From Axel.Thimm at ATrpms.net Sat Jun 9 07:14:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 09:14:22 +0200 Subject: f7 images for mass production In-Reply-To: References: Message-ID: <20070609071422.GB4852@neu.nirvana> Hi, On Fri, Jun 08, 2007 at 12:25:04PM -0400, Max Spevack wrote: > I wanted to throw a question out to devel-list and Will Woods. > > We're getting ready to mass-produce Fedora 7 LiveCDs and DVDs. > > I would like to know if the conventional wisdom is that we should use > the GOLD images, or if it is worthwhile to use an updated image (either > of the LiveCD or of the DVD), in order to pull in any of the updates > that have already been published. > > Thanks, > Max I've read the thread on pros and cons, and it tends to be not adding updates. Personally I'm in favour of adding them and there is an important marketing issue no one really brought up: The core features of F7 were the merger (which is not really visible to the end user) and the respin capability. Having created all tools for respinning and promoting their use, but being "afraid to using them ourselves" can create a negative tagline. I think every golden release will start with some more or less severe set of bugs which will shortly after be squashed and the updated release will be far more reliable than the golden one. People talk about QA, but during maintenance mode (e.g. after a release) we have a couple of million users that are forced to do QA anyway, so it's not the same as QA'ing a rawhide cut. Let me propose the following, not only for this specific release: Since we have the tools (which we want to promote anyway) and since every Fedora release had starter bugs that are more severe than anything that creeps up during maintenance mode, let's always do an official respin 3-4 weeks after a golden release. The need is there as well (e.g. check with the fedora-unity guys, people want to have these respins). And I'm sure there will be a lot of community testers (more than during test4->GA) available if a respin is done. -- 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 chitlesh at fedoraproject.org Sat Jun 9 07:48:48 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 9 Jun 2007 09:48:48 +0200 Subject: f7 images for mass production In-Reply-To: <369bce3b0706080954i3720e008i6c0d2030e42f44d6@mail.gmail.com> References: <369bce3b0706080954i3720e008i6c0d2030e42f44d6@mail.gmail.com> Message-ID: <13dbfe4f0706090048vb661053o46183b00472b4430@mail.gmail.com> On 6/8/07, Thomas Chung wrote: > In my personal opinion, we should distribute media exact same release > of F7 final images. +1. In fact, releasing new spins will - confuse (newbies/new fedora) users who are downloading an iso. - support theories like "fedora is not a stable platform". I don't know if you came across to the same conclusion like i do while reading the bunch of fedora 7 reviews out there. They all converge to "fedora isn't well tested before release". If not in general F7 was a great fedora release. After many battles, Fedora is now regarded as community driven project by linux communities and other companies.. Now the only 2 'bad' tags fedora has are: - distro upgrades (Fn to Fn+1) - testing before release. Chitlesh -- http://clunixchit.blogspot.com From dwmw2 at infradead.org Sat Jun 9 08:20:14 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 09 Jun 2007 09:20:14 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <4669B459.5070401@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> Message-ID: <1181377214.2801.54.camel@pmac.infradead.org> On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote: > Building a cross binutils requires kernel headers for the target > architecture. Building gcc requires kernel headers and glibc. There > are scripts to solve the initial chicken/egg problem of where to get > that glibc for a new arch. At some point in the future gcc might not > require glibc to build, but we aren't there yet. Before we get to actually cross-compiling something for release, it would be good to get cross-compilers into Fedora. Making a cross-binutils package isn't hard; it's a relatively modification to our existing binutils package to make it build for multiple %targets. Making a cross-gcc package which targets linux-elf is harder, because of the evil recursive dependencies to which you refer above. It would be good if we could get that working though. Unfortunately the scripts to which you refer just 'solve' the problem by throwing everything together into one huge lump and building gcc, then glibc, then rebuilding gcc again. That's not really very useful for us when we want the compiler and glibc to be entirely separate packages -- and in fact glibc would be a .$TARGET.rpm to be installed into the sysroot, while the compiler is a native package. I haven't looked at this for a while, but IIRC we can build gcc and libgcc.a directly, using 'only' header files which can be provided in advance. The problem is that we have to dynamically link libgcc.so with libc.so? We don't actually need a _real_ libc.so for that though, do we? We could just make a dummy DSO with the functions we want, and link against that? If we do that, what else still has recursive dependencies? -- dwmw2 From Fedora at FamilleCollet.com Sat Jun 9 08:41:40 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 09 Jun 2007 10:41:40 +0200 Subject: openvrml seems building for 2 days... Message-ID: <466A67C4.5020300@FamilleCollet.com> see http://buildsys.fedoraproject.org/build-status/job.psp?uid=34020 Regards. From nicolas.mailhot at laposte.net Sat Jun 9 09:04:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 09 Jun 2007 11:04:12 +0200 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <466A0E5E.50201@iinet.net.au> References: <200706081441.42279.jkeating@redhat.com> <466A0E5E.50201@iinet.net.au> Message-ID: <1181379852.7843.6.camel@rousalka.dyndns.org> Le samedi 09 juin 2007 ? 12:20 +1000, David Timms a ?crit : > The simplest way to do this would be for the iso spin system to perform > an sha1sum * > SHA1SUM within each directory of an iso spin, and have > each result inserted into the corresponding directory. 1. you don't want many scattered checksum files, you want one file for the whole disk, so users can find/filter it easily (use find to get a recursive file list, sort/filter, checksum it) 2. burn apps suchs as brasero/k3b? already generete this file if asked (using md5 which is IMHO a mistake today) 3. you want this checksum file signed -- 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 Sat Jun 9 09:08:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 09 Jun 2007 11:08:31 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <1181345113.3691.8.camel@lt21223.campus.dmacc.edu> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <1181254342.4070.262.camel@localhost.localdomain> <2979.192.54.193.51.1181304306.squirrel@rousalka.dyndns.org> <1181328641.2645.34.camel@localhost.localdomain> <1181339304.3335.17.camel@rousalka.dyndns.org> <1181345113.3691.8.camel@lt21223.campus.dmacc.edu> Message-ID: <1181380111.7843.10.camel@rousalka.dyndns.org> Le vendredi 08 juin 2007 ? 18:25 -0500, Jeffrey C. Ollie a ?crit : > On Fri, 2007-06-08 at 23:48 +0200, Nicolas Mailhot wrote: > > > > If you actually look at the information you want published (not your > > local developer undo/redo queue), is it so much different from what > > we're already publishing today ? Exploded view may make the changes > > easier to grasp, but do we *actually* need any datapoint apart from each > > package build state published? > > Depending on the changes made between releases I wrote about build state, and hopefully a packages sees several builds in devel between releases if it's heavily modified > I can recall several instances where I've been trying > to update an old patch and it's been a lot easier (in some cases > trivial) to check out a old copy of the upstream code from their SCM > apply the patch and then merge up to the present. That's an argument for exploded view, not for VCS-ing all the packager activity -- 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 j.w.r.degoede at hhs.nl Sat Jun 9 09:23:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 09 Jun 2007 11:23:06 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1181377214.2801.54.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> Message-ID: <466A717A.1050102@hhs.nl> David Woodhouse wrote: > On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote: >> Building a cross binutils requires kernel headers for the target >> architecture. Building gcc requires kernel headers and glibc. There >> are scripts to solve the initial chicken/egg problem of where to get >> that glibc for a new arch. At some point in the future gcc might not >> require glibc to build, but we aren't there yet. > > Before we get to actually cross-compiling something for release, it > would be good to get cross-compilers into Fedora. > > Making a cross-binutils package isn't hard; it's a relatively > modification to our existing binutils package to make it build for > multiple %targets. > > Making a cross-gcc package which targets linux-elf is harder, because of > the evil recursive dependencies to which you refer above. It would be > good if we could get that working though. > > Unfortunately the scripts to which you refer just 'solve' the problem by > throwing everything together into one huge lump and building gcc, then > glibc, then rebuilding gcc again. That's not really very useful for us > when we want the compiler and glibc to be entirely separate packages -- > and in fact glibc would be a .$TARGET.rpm to be installed into the > sysroot, while the compiler is a native package. > > I haven't looked at this for a while, but IIRC we can build gcc and > libgcc.a directly, using 'only' header files which can be provided in > advance. The problem is that we have to dynamically link libgcc.so with > libc.so? We don't actually need a _real_ libc.so for that though, do we? > We could just make a dummy DSO with the functions we want, and link > against that? If we do that, what else still has recursive dependencies? > Notice that I have spends weeks on fixing exactly the problems, with creating a cross compiling gcc targeting linux with glibc, described here to build an cross arm toolchain for the gp2x handheld for Fedora. Please check: http://people.atrpms.net/~hdegoede/ For all my SRPMS / SPECS for this, with regards to solving the above metioned problems esp arm-gp2x-linux-gcc.spec is interesting. I think I've got this one nailed, so before other people start pouring time into this please first check my work, doing this for other linux-glibc targets, using Fedora sources instead of the open2x sources I'm using should be mostly identical. I'll gladly answer any questions. Reviews would be welcome to, see: http://fedoraproject.org/wiki/SIGs/Embedded For links to all the review tickets. Regards, Hans From buildsys at redhat.com Sat Jun 9 09:56:05 2007 From: buildsys at redhat.com (Build System) Date: Sat, 9 Jun 2007 05:56:05 -0400 Subject: rawhide report: 20070609 changes Message-ID: <200706090956.l599u5Lh013806@porkchop.devel.redhat.com> New package lostirc Simple IRC client for X11 New package perl-Catalyst-Plugin-Static-Simple Make serving static pages painless New package redet Regular expression development and execution tool New package redet-doc Documentation for redet New package sipp SIP test tool / traffic generator New package wxsvg C++ library to create, manipulate and render SVG files Updated Packages: R-2.5.0-3.fc7 ------------- * Fri May 25 2007 Tom "spot" Callaway 2.5.0-3 - add missing BR: bzip2-devel, libXmu-devel - cleanup macros from changelog * Mon Apr 30 2007 Tom "spot" Callaway 2.5.0-2 - patch from Martyn Plummer fixes .pc files - add new BR: gcc-objc * Wed Apr 25 2007 Tom "spot" Callaway 2.5.0-1 - bump to 2.5.0 anthy-9006-1.fc8 ---------------- * Fri Jun 08 2007 Akira TAGOH - 9006-1 - New upstream release. - Get back the anthy-el-xemacs package. (#243078) bigboard-0.4.6-1.fc8 -------------------- * Fri Jun 08 2007 Colin Walters - 0.4.6-1 - update - disable pymod checks - remove python build requires * Fri Jun 08 2007 Colin Walters - 0.4.3-2 - disttag elfutils-0.128-2.fc8 -------------------- * Fri Jun 08 2007 Roland McGrath - 0.128-2 - Update to 0.128 - new program: unstrip - elfcmp: new option --hash-inexact - Replace Conflicts: with Provides/Requires using -arch git-1.5.2.1-1.fc8 ----------------- * Fri Jun 08 2007 James Bowes 1.5.2.1-1 - git-1.5.2.1 * Sun May 13 2007 Quy Tonthat - Added lib files for git-gui - Added Documentation/technical (As needed by Git Users Manual) * Tue May 08 2007 Quy Tonthat - Added howto files glunarclock-0.32.4-8.fc8 ------------------------ * Fri Jun 08 2007 Jon Ciesla - 0.32.4-8 - Added yelp Requires, BZ #243486. - Some SRPM permission fixes, spec cleanup. gnochm-0.9.10-1.fc8 ------------------- * Fri Jun 08 2007 Patrice Dumas 0.9.10-1 - update to 0.9.10 - add yelp Requires (fix #243387) gnomad2-2.8.13-1.fc8 -------------------- * Sat Jun 09 2007 Linus Walleij 2.8.13-1 - New upstream version fixing some minor bugs. - Candidate for backport to older releases. gnome-commander-1.2.3-7.fc8 --------------------------- * Sat Jun 09 2007 Mamoru Tasaka - 1.2.3-7 - Require yelp (#243392) gnumeric-1:1.6.3-8.fc8 ---------------------- * Fri Jun 08 2007 Hans de Goede 1:1.6.3-8 - Add yelp Requires so that the help will always work (bz 243361) gtkwave-3.0.29-1.fc8 -------------------- * Fri Jun 08 2007 Paul Howarth 3.0.29-1 - update to 3.0.29 - spec file much-simplified as gtkwave is now fully autotooled - try to retain upstream timestamps as far as possible - use parallel make gtranslator-1.1.7-3.fc8 ----------------------- * Fri Jun 08 2007 Sindre Pedersen Bj??rdal 1.1.7-3 - Add yelp dependency, closes #243401 hunspell-nl-1.00g-1.fc8 ----------------------- jsch-0:0.1.31-1jpp.1 -------------------- * Tue Jun 05 2007 Ben Konrath - 0:0.1.31-1jpp.1 - 0.1.31. kaffeine-0.8.4-1.fc8 -------------------- * Fri Jun 08 2007 Rex Dieter 0.8.4-1 - kaffeine-0.8.4 koffice-langpack-1.6.3-1.fc8 ---------------------------- * Fri Jun 01 2007 Rex Dieter 1.6.3-1 - koffice-l10n-1.6.3 lapack-3.1.1-1.fc7 ------------------ * Fri May 25 2007 Tom "spot" Callaway 3.1.1-1 - bump to 3.1.1 libgtksourceviewmm-0.3.1-1.fc8 ------------------------------ * Fri Jun 08 2007 Damien Durand - 0.3.1-1 - Upgrade to 0.3.1 libvirt-0.2.3-1.fc8 ------------------- * Fri Jun 08 2007 Daniel Veillard - 0.2.3-1.fc7 - Release of 0.2.3 - lot of assorted bugfixes and cleanups - support for Xen-3.1 - new scheduler API monkey-bubble-0.4.0-5.fc8 ------------------------- * Fri Jun 08 2007 Hans de Goede 0.4.0-5 - Add yelp Requires so that the help will always work (bz 243408) - Fix display of icon in the windows titlebar - Fix only part of the splashscreen displaying * Fri Apr 27 2007 Hans de Goede 0.4.0-4 - Fix building with newer docbook / gnome-doc tools * Sun Sep 10 2006 Hans de Goede 0.4.0-3 - Don't own /usr/share/omf (bug 205670) mrtg-2.15.1-3.fc8 ----------------- * Fri Jun 08 2007 Vitezslav Crhonek 2.15.1-3 - Rebuild net-tools-1.60-83.fc8 --------------------- * Fri Jun 08 2007 Radek Vok??l - 1.60-83 - fix netplugd init script (#242919) nfs-utils-1:1.0.12-7.fc8 ------------------------ * Thu May 24 2007 Steve Dickson 1.0.10-7 - Fixed typo in mount.nfs4 that causes a segfault during error processing (bz 241190) * Tue May 22 2007 Steve Dickson 1.0.10-6 - Make sure the condrestarts exit with a zero value (bz 240225) - Stopped /etc/sysconfig/nfs from being overwritten on updates (bz 234543) - Added -o nordirplus mount option to disable READDIRPLUS (bz 240357) - Disabled the FSCache patch, for now... * Thu May 10 2007 Steve Dickson 1.0.12-5 - Fix mount.nfs4 to display correct error message (bz 227212) - Updated mountd and showmount reverse lookup flags (bz 220772) - Eliminate timeout on nfsd shutdowns (bz 222001) - Eliminate memory leak in mountd (bz 239536) - Make sure statd uses correct uid/gid by chowning the /var/lib/nfs/statd with the rpcuser id. (bz 235216) - Correct some sanity checking in rpc.nfsd. (bz 220887) - Added missing unlock_mtab() call in moutnd - Have mountd hold open etab file to force inode number to change (bz 236823) - Create a /etc/sysconfig/nfs with all the possible init script variables (bz 234543) - Changed nfs initscript to exit with correct value (bz 221874) openldap-2.3.34-3.fc8 --------------------- * Tue May 22 2007 Jan Safranek 2.3.34-3.fc8 - do not create script in /tmp on startup (bz#188298) - add compat-slapcat to openldap-compat (bz#179378) - do not import ddp services with migrate_services.pl (bz#201183) - sort the hosts by adders, preventing duplicities in migrate*nis*.pl (bz#201540) - start slupd for each replicated database (bz#210155) - add ldconfig to devel post/postun (bz#240253) - include misc.schema in default slapd.conf (bz#147805) * Mon Apr 23 2007 Jan Safranek 2.3.34-2.fc8 - slapadd during package update is now quiet (bz#224581) - use _localstatedir instead of var/ during build (bz#220970) - bind-libbind-devel removed from BuildRequires (bz#216851) - slaptest is now quiet during service ldap start, if there is no error/warning (bz#143697) - libldap_r.so now links with pthread (bz#198226) - do not strip binaries to produce correct .debuginfo packages (bz#152516) * Mon Feb 19 2007 Jay Fenlason 2.3.34-1.fc8 - New upstream release - Upgrade the scripts for migrating the database so that they might actually work. - change bind-libbind-devel to bind-devel in BuildPreReq php-5.2.3-2 ----------- * Fri Jun 08 2007 Joe Orton 5.2.3-2 - update to 5.2.3 (thanks to Jeff Sheltren) pl-5.6.35-1.fc8 --------------- * Fri Jun 08 2007 Gerard Milmeister - 5.6.35-1 - new version 5.6.35 - add requires readline-devel * Mon Apr 23 2007 Gerard Milmeister - 5.6.34-1 - new version 5.6.34 * Fri Feb 23 2007 Gerard Milmeister - 5.6.28-1 - new version 5.6.28 planner-0.14.2-6.fc8 -------------------- * Fri Jun 08 2007 Caolan McNamara - 0.14.2-6 - Resolves: rhbz#243367 require yelp * Sat Apr 21 2007 Matthias Clasen - 0.14.2-5 - Move api docs to -devel pykickstart-1.2-2.fc8 --------------------- * Fri Jun 08 2007 Chris Lumens - 1.2-2 - Fix package review problems (#226334). python-ldap-0:2.3-1.fc8 ----------------------- * Fri Jun 08 2007 Matthew Barnes - 0:2.3.0-1.fc8 - Update to 2.3 - Spec file cleanups. system-config-printer-0.7.67-1.fc8 ---------------------------------- * Fri Jun 08 2007 Tim Waugh 0.7.67-1 - Don't put TrayIcon or SystemSetup categories in the desktop file. - Updated pycups to 1.9.24. - 0.7.67: - Fixed desktop files to have capital letters at the start of each word in the Name field (bug #242859). - Fixed crash when saving unapplied changes. - Fixed Device ID parser to always split the CMD field at commas. - New PPDs class means we no longer parse the foomatic XML database. system-config-securitylevel-1.7.0-3.fc8 --------------------------------------- * Fri Jun 08 2007 Thomas Woerner 1.7.0-3 - fixed syntax in dirty patch - fixed desktopfile for rewritten desktop-file-utils * Fri Jun 08 2007 Thomas Woerner 1.7.0-2 - use state module for IPv6 firewall again (rhbz#233725, rhbz#236035) - honour exit code of lokkit call (rhbz#227285) - gui: fixed expand of trusted services list - gui: make apply and ok button sensitive only if there are changes (rhbz#227285) - fixed url (rhbz#237723) taskjuggler-2.3.1-3.fc8 ----------------------- * Fri Jun 08 2007 Jens Petersen - 2.3.1-3 - setup QTDIR and use find_lang macro to fix build - buildrequire gettext for untranslated .po file * Thu Jun 07 2007 Ondrej Vasik -2.3.1-2 - fixed number of memory leaks (from upstream) - removed _smp_mflags to avoid build failures with 4+ cpus (#233028) vnc-4.1.2-18.fc8 ---------------- * Fri Jun 08 2007 Adam Tkac 4.1.2-18.fc8 - added 24bit support to Xvnc - handle RENDER extension better (+ moved module_crash patch into render patch) * Mon Apr 23 2007 Adam Tkac 4.1.2-17.fc7 - removed patch to #188169 because patching this bug could do more things bad than good - removed int10 module from vnc (with-int10 option) * Tue Mar 27 2007 Adam Tkac 4.1.2-16.fc7 - fixed vnc module crashing (#234124) - vncviewer has been moved from Utility group to Network group (#231765) Broken deps for i386 ---------------------------------------------------------- audacious-plugins - 1.3.4-2.fc8.i386 requires libmpcdec.so.3 bdock - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 beryl - 0.2.1-1.fc8.i386 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- audacious-plugins - 1.3.4-2.fc8.x86_64 requires libmpcdec.so.3()(64bit) bdock - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) beryl - 0.2.1-1.fc8.x86_64 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 emerald - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) k3b - 1.0.1-2.fc8.x86_64 requires libmpcdec.so.3()(64bit) k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.x86_64 requires libmpcdec.so.3()(64bit) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- audacious-plugins - 1.3.4-2.fc8.ppc requires libmpcdec.so.3 bdock - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 beryl - 0.2.1-1.fc8.ppc requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 k3b - 1.0.1-2.fc8.ppc requires libmpcdec.so.3 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.8-1.fc8.noarch requires livecd-tools syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) audacious-plugins - 1.3.4-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) beryl - 0.2.1-1.fc8.ppc64 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires aquamarine >= 0:0.2.1 emerald-themes - 0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.8-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 From bojan at rexursive.com Sat Jun 9 10:01:44 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 9 Jun 2007 10:01:44 +0000 (UTC) Subject: The Future of Fedora Package Management and the RPM Philosophy References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> Message-ID: Jeffrey C. Ollie ocjtech.us> writes: > The primary disadvantage to integrating patch and package management is > that we move away from RPM's philosophy of using pristine sources. > Pristine sources have been required because it's possible to easily > verify that our copy of the sources matches the upstream copy by > comparing MD5 or GPG signatures. With an integrated repository where > there are no longer pristine sources, it's not possible to verify that > our copy of the code matches the upstream copy by comparing signatures > on tarballs. Verifying the code integrity is possible with the > integrated repository, but it's potentially much more difficult. I think that would be the least of the problems with this approach. Because we're building from pristine sources with patches now, every maintainer is best off with zero patches to the pristine source. So, every maintainer has an incentive to fix the upstream source so that the next release comes as close as possible to the spec file created by fedora-newrpmspec. The integrated approach would turn package maintainers into fork maintainers. Having one giant integrated repository would make the work of going to a brand new upstream version very tedious, as all Fedora specific changes would have to be identified and extracted out of the repository first and then reapplied to the new tree. With the current approach, the separated patches already exist. If they don't apply to the new pristine source, it's either because they are incompatible, which the maintainer can fix, or are no longer required and the maintainer can drop them. Far less work. I personally wouldn't like to see Fedora go to such integrated repository. -- Bojan From benny+usenet at amorsen.dk Sat Jun 9 10:10:40 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 09 Jun 2007 12:10:40 +0200 Subject: Reply-To header munging for fedora-devel-list@ References: <46689424.5030009@codewiz.org> <20070608100217.GA30585@neu.nirvana> <4669D4B6.5070209@codewiz.org> <20070609070226.GA4852@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> But anyway fedora lists are not fire-and-forget. If you want to AT> participate you will have to subscribe, and since we know that AT> everyone is subscribed, we don't have to care about replying to AT> external participants. You can participate just fine without subscribing. That's what gmane is for. Requiring subscriptions breaks posting from gmane for no reason. /Benny From david at lovesunix.net Sat Jun 9 10:21:32 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 09 Jun 2007 12:21:32 +0200 Subject: f7 images for mass production In-Reply-To: <13dbfe4f0706090048vb661053o46183b00472b4430@mail.gmail.com> References: <369bce3b0706080954i3720e008i6c0d2030e42f44d6@mail.gmail.com> <13dbfe4f0706090048vb661053o46183b00472b4430@mail.gmail.com> Message-ID: <1181384492.27658.21.camel@dawkins> l?r, 09 06 2007 kl. 09:48 +0200, skrev Chitlesh GOORAH: > On 6/8/07, Thomas Chung wrote: > > In my personal opinion, we should distribute media exact same release > > of F7 final images. > > +1. > > In fact, releasing new spins will > - confuse (newbies/new fedora) users who are downloading an iso. > - support theories like "fedora is not a stable platform". I don't > know if you came across to the same conclusion like i do while reading > the bunch of fedora 7 reviews out there. They all converge to "fedora > isn't well tested before release". If not in general F7 was a great > fedora release. So.. we aren't tested, thus instead of attempting to utilize our new found freedom we should continue to issue a release with known bugs and security holes.. because it will make us look bad if we attempt to fix it? I think the damage is already done and regardless the very same updates will be downloaded after install in 99% of cases so we get to attempt to fix this and we get to save users bandwidth. Reviews are some what unreliable as they all seem to dwell on the codec issue and that kind of thing. What I hear from people on the forums I frequent even non-Fedora users are impressed with F7 and we are praised for the stability and performance especially of our Firefox build (which in quite a few cases is rated at twice the stability of what shipped in the last Ubuntu release - good work callion). > After many battles, Fedora is now regarded as community driven project > by linux communities and other companies.. > Now the only 2 'bad' tags fedora has are: > - distro upgrades (Fn to Fn+1) > - testing before release. Trust me Fedora is not regarded as a community project by anyone by people actually in the Fedora community, I had to politely correct a lot of friends in the Linux podcasting world to have them stop saying "Red Hat's distro" or "Red Hat has released Fedora X". As for testing, if you think it's such a big problem, the QA team welcomes you to join our ranks instead of passing on the causes for bad reputation. Now in the time spend saying "This hasn't been tested" don't you think someone could have written a mail to the QA list to ask us to bang on the serious updates like a new kernel and what hardware configurations need testing... no such thing is happening, instead we see constant berating of our work in the F7 cycle. Be part of the solution, not the problem - please. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jsacco at gnome.org Sat Jun 9 11:22:41 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Sat, 09 Jun 2007 07:22:41 -0400 Subject: Fedora and Cross Compiling In-Reply-To: <1181377214.2801.54.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> Message-ID: <1181388161.2845.43.camel@rt.jesacco.com> On Sat, 2007-06-09 at 09:20 +0100, David Woodhouse wrote: > On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote: > > Building a cross binutils requires kernel headers for the target > > architecture. Building gcc requires kernel headers and glibc. There > > are scripts to solve the initial chicken/egg problem of where to get > > that glibc for a new arch. At some point in the future gcc might not > > require glibc to build, but we aren't there yet. > > Before we get to actually cross-compiling something for release, it > would be good to get cross-compilers into Fedora. > > Making a cross-binutils package isn't hard; it's a relatively > modification to our existing binutils package to make it build for > multiple %targets. > > Making a cross-gcc package which targets linux-elf is harder, because of > the evil recursive dependencies to which you refer above. It would be > good if we could get that working though. > > Unfortunately the scripts to which you refer just 'solve' the problem by > throwing everything together into one huge lump and building gcc, then > glibc, then rebuilding gcc again. That's not really very useful for us > when we want the compiler and glibc to be entirely separate packages -- > and in fact glibc would be a .$TARGET.rpm to be installed into the > sysroot, while the compiler is a native package. > > I haven't looked at this for a while, but IIRC we can build gcc and > libgcc.a directly, using 'only' header files which can be provided in > advance. The problem is that we have to dynamically link libgcc.so with > libc.so? We don't actually need a _real_ libc.so for that though, do we? > We could just make a dummy DSO with the functions we want, and link > against that? If we do that, what else still has recursive dependencies? > > -- > dwmw2 [bottom post :-)] Building cross toolchains is a common exercise in the embedded systems world. Take a look at Dan Kegel's "crosstools" http://kegel.com/crosstool/ which is RPM based and extensible. crosstools "auto-magically" handles the recursive dependency problems that you mention If you are seeking an entire cross tool chain development environment, take a look at two open source offerings from the embedded systems world: * Embedded Linux Development Kit http://www.denx.de/wiki/DULG/WebHome * Linux Target Image Builder http://savannah.nongnu.org/projects/ltib/ Both are RPM based and extensible. -Joseph -- jsacco [at] gnome [dot] org From kevin.kofler at chello.at Sat Jun 9 11:59:56 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Jun 2007 11:59:56 +0000 (UTC) Subject: f7 images for mass production References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> <466997CA.7060505@hhs.nl> <4669D88C.7090302@verizon.net> Message-ID: Gerry Reno verizon.net> writes: > My third attempt was to load F7 in QEMU. Would only > work with HTTP option. Once I got it loaded it wouldn't run with kqemu > so I had to run it without acceleration and I don't need to tell you > that it isn't even usable without acceleration. I use F7 (and FC6 before that) in unaccelerated QEMU all the time to build x86_64 RPMs on my 32-bit machine. KDE is painfully slow in it (and I'm pretty sure GNOME isn't any better), but forwarding X11 apps to the main host gives you something acceptable for most apps. And luckily I don't need X11 at all to run rpmbuild. ;-) I don't dispute that it's very slow, of course. For example, a package build which takes 10 minutes on the native 32-bit hardware takes 8 hours in QEMU. Kevin Kofler From jkeating at redhat.com Sat Jun 9 12:20:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 08:20:24 -0400 Subject: f7 images for mass production In-Reply-To: <20070609071422.GB4852@neu.nirvana> References: <20070609071422.GB4852@neu.nirvana> Message-ID: <200706090820.25030.jkeating@redhat.com> On Saturday 09 June 2007 03:14:22 Axel Thimm wrote: > I think every golden release will start with some more or less severe > set of bugs which will shortly after be squashed and the updated > release will be far more reliable than the golden one. People talk > about QA, but during maintenance mode (e.g. after a release) we have a > couple of million users that are forced to do QA anyway, so it's not > the same as QA'ing a rawhide cut. > > Let me propose the following, not only for this specific release: > Since we have the tools (which we want to promote anyway) and since > every Fedora release had starter bugs that are more severe than > anything that creeps up during maintenance mode, let's always do an > official respin 3-4 weeks after a golden release. The need is there as > well (e.g. check with the fedora-unity guys, people want to have these > respins). And I'm sure there will be a lot of community testers (more > than during test4->GA) available if a respin is done. How is this any different from always having a Test4, or a Test5? Nobody is going to look at the first release because it's not good enough, a more tested one will always come later, and then we're in a vicious cycle. It's the Red Hat Linux days all over again where nobody uses a .0, they wait for a .1 or a .2. Same with the kernel and it's development branch. I just don't want to see Fedora go down this road. we get one shot to make a release point, lets do what we can to get there, and move on to the next one. Respins are great, and respins are wonderful if you want to do one for your use, or for a group, or as a contrib item. However a /Fedora/ release from the /Fedora Project/ carries some weight to it and needs to be done as right as possible, and that would mean doing another /release/ of what is in F7 + updates, which would mean another freeze period, another round of QA, public RCs, blocker bugs, etc.. We're not just going to pump something out in a day, and it puts a severe cramp on what we can do for our already short Fedora 8 schedule. And then were do we stick it on the mirrors? 7.1? Do we do an 8.0 then? And an 8.1? wait a year to do 9 so that we can do our 8.X releases? Maybe we could do quarterly respins and push our release cycle out to 18 months, that'll be Enterprisy right? Maybe we could sell subscriptions to the updates and respin service! I sense real opportunity here. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Sat Jun 9 12:09:19 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Jun 2007 12:09:19 +0000 (UTC) Subject: fedora for ARM References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <20070607103441.GB2079@xi.wantstofly.org> Message-ID: Lennert Buytenhek wantstofly.org> writes: > > # CONFIG_UTRACE is not set > > > > note that this will also disable ptrace too afaik. > > Hmm. Hmm? > > [root iop ~]# uname -a > Linux iop.wantstofly.org 2.6.21 #13 Sun May 13 23:39:28 CEST 2007 armv5tel > armv5tel armv5tel GNU/Linux That's not a Fedora kernel. Disabling utrace only disables ptrace if the kernel actually has the utrace patch. :-) (The quick hack solution to that problem is to ifarch the utrace patch, not just disable it in the config. Some other secondary arch teams have done just that.) Kevin Kofler From jkeating at redhat.com Sat Jun 9 12:22:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 08:22:47 -0400 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <466A0E5E.50201@iinet.net.au> References: <200706081441.42279.jkeating@redhat.com> <466A0E5E.50201@iinet.net.au> Message-ID: <200706090822.48020.jkeating@redhat.com> On Friday 08 June 2007 22:20:14 David Timms wrote: > The simplest way to do this would be for the iso spin system to perform > an sha1sum * > SHA1SUM within each directory of an iso spin, and have > each result inserted into the corresponding directory. What is it we do when we implantisomd5 which is used by media check? Can't you make use of that? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Sat Jun 9 12:24:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Jun 2007 12:24:08 +0000 (UTC) Subject: fedora for ARM References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <20070607114028.GH2079@xi.wantstofly.org> Message-ID: Lennert Buytenhek wantstofly.org> writes: > I think that something like qemu-system-arm is probably one of the > very few ways of speeding up package builds while still being able > to guarantee that the result is 100% identical. (Although my > fastest ARM boxes are probably faster than doing it via qemu.) Looking at the speeds of your boxes you posted in another mail in this thread, they almost definitely are. Building in QEMU emulation is about 50 times slower than native builds. Kevin Kofler From jkeating at redhat.com Sat Jun 9 12:25:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 08:25:12 -0400 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: References: Message-ID: <200706090825.12792.jkeating@redhat.com> On Friday 08 June 2007 18:31:53 Anthony Bryan wrote: > What can we do to make this happen? Is this the type of thing that's > easier for the maintainer of MirrorManager to add, or should we supply > a patch? It would be best to open a dialog with Matt Domsch about this (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Sat Jun 9 12:39:07 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 9 Jun 2007 07:39:07 -0500 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: <200706090825.12792.jkeating@redhat.com> References: <200706090825.12792.jkeating@redhat.com> Message-ID: <20070609123907.GA26897@lists.us.dell.com> On Sat, Jun 09, 2007 at 08:25:12AM -0400, Jesse Keating wrote: > On Friday 08 June 2007 18:31:53 Anthony Bryan wrote: > > What can we do to make this happen? Is this the type of thing that's > > easier for the maintainer of MirrorManager to add, or should we supply > > a patch? > > It would be best to open a dialog with Matt Domsch about this (: I replied on fedora-infrastructure-list just a bit ago. I'm happy to see this functionality get added to mirrormanager, and am happy to review patches as well. :-) The trick will be having a python module that, given a list of URL/country tuples, generates the XML pages. Which probably isn't that hard, really. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From ssorce at redhat.com Sat Jun 9 14:04:36 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 09 Jun 2007 10:04:36 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181331071.3903.197.camel@lt21223.campus.dmacc.edu> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <200706081511.40535.jkeating@redhat.com> <1181331071.3903.197.camel@lt21223.campus.dmacc.edu> Message-ID: <1181397876.3749.162.camel@willson> On Fri, 2007-06-08 at 14:31 -0500, Jeffrey C. Ollie wrote: > On Fri, 2007-06-08 at 15:11 -0400, Jesse Keating wrote: > > On Friday 08 June 2007 15:00:17 Jeffrey C. Ollie wrote: > > > If we want to be more radical, we could integrate the package and the > > > patch repositories. Package building would no longer use pristine > > > sources and patches to produce a binary package. Instead, the build > > > system would pull already-patched code out of the repository and build > > > the binary package from there. > > > > I have to question why the build would have to be this way? If you've got the > > prestine source branch, and you've got the patch branches, is there no way to > > extract the patches to such a format that they will apply to the prestine > > source, and stack them appropriately? Could we not extract a patch or patch > > set from each of the patch branches to a set of patch files in proper order, > > use them in the spec against a prestine tarball to generate the rpm? This > > way we get the benefit of both worlds. If we're pie in the skying, I simply > > don't accept that we have to sacrifice prestine tarball + patches in our > > srpms just to get a way to manage patches against an exploaded source. > > Yes, that's certainly a possibility. It's kind of a medium between the > two extremes I proposed. Building based upon a direct checkout of > already patched source means all that you have to do is specify a tag > but you lose the tarball + patches. Exporting patches from the exploded > source repo and importing them as files to the package repo is more work > but you keep the tarball + patches. The approach you propose would mean > that the package maintainer would need to do some work to specify the > set of patches to be extracted and the order to apply them (but wouldn't > actually have to do the extraction him/herself), but you keep the > tarball+patches approach to building. Have anybody thought of using quilt? It is a tool that can help _a lot_ in managing patches (especially for huge patch sets) . I think it could help reach some of the goals here without shifting us from using the orig.sourcesa+patches approach, that would be a big mistake. I've been and I am in the job of tracking changes in multiple trees (basically internal forks), it is something you _don't_ want to do unless absolutely necessary. > The key decision though that needs to be made is whether we take that > radical step of abandoning the tarball+patches approach. My feeling is > that it's too radical for right now, but maybe it won't be in the > future. No it is too radical, full stop. Keeping a parallel tree is by all means keeping a fork, make it easy to screw up and very difficult to do merges, what will happen is that packages will lag behind more and more, and syncing up with upstream will become more and more difficult. Please don't even think of doing something like that for maintaining packages. Simo. From caillon at redhat.com Sat Jun 9 14:11:42 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 09 Jun 2007 10:11:42 -0400 Subject: updates-testing is not useful Message-ID: <466AB51E.7090000@redhat.com> It seems we want to get testing on packages before they go to updates, but we lose valuable testing time by having to wait for someone to notice the package is there, sign it and push it. As it is, most of my packages do not get tested in -testing but by uploading to my people page or my gnome.org page or my fd.o page. I could either provide the packages on other webspace i control and link to it in bugs, or say "Hi. I built teh packages for you to test but you can't test them right now. I don't really know when though cuz I can't control it. Um, Real soon now! Honest! Keep checking. lolz" Can we implement some sort of auto-signing-and-pushing mechanism for _testing_ packages at least? I do see the value in having a human make a decision for the final repository, but am having a hard time coming up with a good reason for -testing. From Axel.Thimm at ATrpms.net Sat Jun 9 14:41:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 16:41:16 +0200 Subject: f7 images for mass production In-Reply-To: <200706090820.25030.jkeating@redhat.com> References: <20070609071422.GB4852@neu.nirvana> <200706090820.25030.jkeating@redhat.com> Message-ID: <20070609144116.GB10301@neu.nirvana> On Sat, Jun 09, 2007 at 08:20:24AM -0400, Jesse Keating wrote: > On Saturday 09 June 2007 03:14:22 Axel Thimm wrote: > > I think every golden release will start with some more or less severe > > set of bugs which will shortly after be squashed and the updated > > release will be far more reliable than the golden one. People talk > > about QA, but during maintenance mode (e.g. after a release) we have a > > couple of million users that are forced to do QA anyway, so it's not > > the same as QA'ing a rawhide cut. > > > > Let me propose the following, not only for this specific release: > > Since we have the tools (which we want to promote anyway) and since > > every Fedora release had starter bugs that are more severe than > > anything that creeps up during maintenance mode, let's always do an > > official respin 3-4 weeks after a golden release. The need is there as > > well (e.g. check with the fedora-unity guys, people want to have these > > respins). And I'm sure there will be a lot of community testers (more > > than during test4->GA) available if a respin is done. > > How is this any different from always having a Test4, or a Test5? It is infinitely different, test4/5/6 are per definition before the GA and therefore are expected to break. Call it marketing, if you like, but the fact is that people will "buy" GA and not "test5". > Nobody is going to look at the first release because it's not good > enough, a more tested one will always come later, and then we're in > a vicious cycle. It's the Red Hat Linux days all over again where > nobody uses a .0, they wait for a .1 or a .2. That isn't comparable at all and also not true, either. For example the 7.0/7.1/7.2/7.3 release cycles were in total more than *two years*, RHL had the same Halloween/May Day release targets as Fedora has today (in fcat that's been the case since about rhl 4.2). The 7.0/... release versioning was just marketing, they could had been called 7, 8, 9, 10 as well, just like 8.0 and 9 continued w/o minor releases. So it's really a different beast and the people around that remember the 6.x/7.x days know that this was different. There were people that hesitated to use 7.0 from 6.2 (and later anything but 7.3), but these people are the ones running RHEL or a clone thereof today. The "parents" of today's Fedora users jumped right onto 7.0 on day one. Same for 8.0 and 9. > that would mean doing another /release/ of what is in F7 + updates, > which would mean another freeze period, another round of QA, public > RCs, blocker bugs, etc.. Why the overcomplicated view? Where you had say 20 people looking at a feature/bug before GA you now have 20.000. By definition you can say that any snapshot of any F7+updates after the dust settles is already in QA by more people than you would like. Not to say that you don't need to look at what you collated, but it isn't any near the excessive QA you need to do before GA. And no freezing is needed either - you make a snapshot, which is your frozen collection of packages, rampage on it with QA to see if there is anything that falls out and in the worst case you either pull a later update or do a static fix. > And then were do we stick it on the mirrors? 7.1? Do we do an 8.0 > then? And an 8.1? wait a year to do 9 so that we can do our 8.X > releases? Maybe we could do quarterly respins and push our release > cycle out to 18 months, that'll be Enterprisy right? Maybe we could > sell subscriptions to the updates and respin service! I sense real > opportunity here. Someone needs to pull you back to earth ;) Yes, I know that's sarcasm by hyperbole, but no one implied any of the above. This is not about changing anything in Fedora's release model. Anyway, as Max said you're one of the people that needs to give the go, and since this is not the case, let's wrap up the idea for F7 and perhaps someone will pick up the idea at F8/9/10 timeframe where there will be more confidence and experience at instant respins. -- 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 at ocjtech.us Sat Jun 9 14:54:14 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 09 Jun 2007 09:54:14 -0500 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> Message-ID: <1181400854.3691.41.camel@lt21223.campus.dmacc.edu> On Sat, 2007-06-09 at 10:01 +0000, Bojan Smojver wrote: > > I think that would be the least of the problems with this approach. > Because we're building from pristine sources with patches now, every > maintainer is best off with zero patches to the pristine source. So, > every maintainer has an incentive to fix the upstream source so that > the next release comes as close as possible to the spec file created > by fedora-newrpmspec. The integrated approach would turn package > maintainers into fork maintainers. Sure, having a patch-less spec file is the ideal but it's not always possible. At the minimum there will always be some packages that have patches that implement Fedora-specific policy (e.g. changing default values in configuration files) that would be inappropriate to send upstream. There are also many instances where Fedora needs to carry a patch for a while (e.g. a security patch backported from a newer release than Fedora ships because the Fedora package can't be updated for some reason). So unless package maintainers in some sense are already and will always be "fork" maintainers - minimizing the number and size of changes from upstream is an important goal, but it's not the only goal. What this discussion has been about is bringing patch development out of a hidden corner the package maintainer's laptop hard drive and into a centrally maintained, publicly available version control repository. > Having one giant integrated repository would make the work of going to a brand > new upstream version very tedious, as all Fedora specific changes would have to > be identified and extracted out of the repository first and then reapplied to > the new tree. With the current approach, the separated patches already exist. If > they don't apply to the new pristine source, it's either because they are > incompatible, which the maintainer can fix, or are no longer required and the > maintainer can drop them. Far less work. Apparently you have never used a version control system that properly supports branching and merging. CVS and Subversion do not count. Git, Mercurial, and Bazaar are ones that do and make it easy (in some cases trivial) to maintain code/patches in branches and then rebase the patches to new versions of the upstream code as they are released. With the proper discipline, keeping track of the changes that we have made to the pristine code isn't really a problem. However, I don't want this thread to descend into a debate about the best revision control system. We need to be discussing things at a higher level right now. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Sat Jun 9 15:00:41 2007 From: greno at verizon.net (Gerry Reno) Date: Sat, 09 Jun 2007 11:00:41 -0400 Subject: f7 images for mass production In-Reply-To: <4669D88C.7090302@verizon.net> References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> <466997CA.7060505@hhs.nl> <4669D88C.7090302@verizon.net> Message-ID: <466AC099.8050604@verizon.net> Gerry Reno wrote: > Hans de Goede wrote: >> >> ... >> And if we spend the time to create new iso's for that, I think it >> would be a good idea to make those available to our end-users. Call >> it a .0.1 release, call it a brown paper bag release (not meant in >> any disrespect to DaveJ, but the kernel is kinda a brown paper bag >> kernel). Eitherway if we invest time and QA to make new iso's for >> this, we should make them available, as the time has already been >> invested then. >> >> I vote for doing a new spin with: >> -a new kernel included (we might have to wait a bit for this new >> kernel to >> become available and proven) >> -perhaps an updates.img included >> -perhaps one or two updates for very very critical no interaction needed >> network abusable security issues. >> >> Regards, >> >> Hans >> > > I would second these. My initial experience with the first F7 ISOs > was very bad. It won't install on my real hardware from DVD as the > install won't recognize the drive. My second attempt was a LiveCD > which promptly bombed with a listing of block errors on sr0. Didn 't > even know I had an sr0. My third attempt was to load F7 in QEMU. > Would only work with HTTP option. Once I got it loaded it wouldn't > run with kqemu so I had to run it without acceleration and I don't > need to tell you that it isn't even usable without acceleration. My > next attempt was in Xen on a FC6 host. Setup a domain in virt mgr > pointing to a good mirror. It started anaconda and then when it got > to the partitioning screen it showed no drives or partitions available > for installation. Completely hangs the install right there. So yes, > I'm ready for something a little more tested. > > my 2c, > Gerry > FWIW, the problem that I saw with F7 final was that all the great work that had gone into F7 was overshadowed to a great degree by a lot of installation issues. It was like having a 5-star meal served on a dirty plate. So how about this? The general end user does not download test releases that would help in shaking out any installation issues. They should but they don't. So publicly release, some time prior to the final, a Trailer, if you will, that installs exactly like the final. Then the general user community can provide feedback as to any installation issues they see. Everything in the Trailer installer works the same except that at the end you see a few promotional messages showing the new features in the release and of course the final "Coming soon to a mirror near you" or "Opens May 31st", that kind of thing. This way the installer can be broadly tested and any installer issues can be identified and it would also help to build the hype for the Fedora release. Just a fun type of thing that has some good QA benefit attached to it. Gerry From naheemzaffar at gmail.com Sat Jun 9 15:15:04 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 9 Jun 2007 16:15:04 +0100 Subject: f7 images for mass production In-Reply-To: <466AC099.8050604@verizon.net> References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> <466997CA.7060505@hhs.nl> <4669D88C.7090302@verizon.net> <466AC099.8050604@verizon.net> Message-ID: <3adc77210706090815s56411ae4w910787fb019879dd@mail.gmail.com> For the short term it will have to do with whatever rel-engineering decide (as they have to test the thing), but for the future it is probably better to do this via fedora unity respins. Come an event time distribute respins to promote the distro AND the community aspect of it all? Are Fedora Unity still around? active? the new tools must be of use to them. This will also avoid having any issues with a new "official" release - both good and bad (was the GA not good enough? why do we need a new release etc... just avoid the politics altogether.) From kevin.kofler at chello.at Sat Jun 9 15:34:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Jun 2007 15:34:08 +0000 (UTC) Subject: updates-testing is not useful References: <466AB51E.7090000@redhat.com> Message-ID: Christopher Aillon redhat.com> writes: > I could either provide the packages on other webspace i control and link > to it in bugs, or say "Hi. I built teh packages for you to test but you > can't test them right now. I don't really know when though cuz I can't > control it. Um, Real soon now! Honest! Keep checking. lolz" You can link directly to the Koji build results. Just make sure you use http links and not https, because last I checked the https refused to do anything without a client certificate (which you and I have, but the average user doesn't ;-) ). Kevin Kofler From kevin.kofler at chello.at Sat Jun 9 15:39:39 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Jun 2007 15:39:39 +0000 (UTC) Subject: f7 images for mass production References: <20070609071422.GB4852@neu.nirvana> <200706090820.25030.jkeating@redhat.com> <20070609144116.GB10301@neu.nirvana> Message-ID: Axel Thimm ATrpms.net> writes: > people are the ones running RHEL or a clone thereof today. The > "parents" of today's Fedora users jumped right onto 7.0 on day > one. Same for 8.0 and 9. I actually skipped 8 and 9 and went straight from 7.3 to FC1. :-) I didn't skip a release since though. :-) Kevin Kofler From caillon at redhat.com Sat Jun 9 16:08:54 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 09 Jun 2007 12:08:54 -0400 Subject: updates-testing is not useful In-Reply-To: References: <466AB51E.7090000@redhat.com> Message-ID: <466AD096.3090301@redhat.com> Kevin Kofler wrote: > Christopher Aillon redhat.com> writes: >> I could either provide the packages on other webspace i control and link >> to it in bugs, or say "Hi. I built teh packages for you to test but you >> can't test them right now. I don't really know when though cuz I can't >> control it. Um, Real soon now! Honest! Keep checking. lolz" > > You can link directly to the Koji build results. Just make sure you use http > links and not https, because last I checked the https refused to do anything > without a client certificate (which you and I have, but the average user > doesn't ;-) ). I was told to not do this because we don't have the bandwidth. From caillon at redhat.com Sat Jun 9 16:15:50 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 09 Jun 2007 12:15:50 -0400 Subject: updates-testing is not useful In-Reply-To: References: <466AB51E.7090000@redhat.com> Message-ID: <466AD236.8060205@redhat.com> Kevin Kofler wrote: > Christopher Aillon redhat.com> writes: >> I could either provide the packages on other webspace i control and link >> to it in bugs, or say "Hi. I built teh packages for you to test but you >> can't test them right now. I don't really know when though cuz I can't >> control it. Um, Real soon now! Honest! Keep checking. lolz" > > You can link directly to the Koji build results. Just make sure you use http > links and not https, because last I checked the https refused to do anything > without a client certificate (which you and I have, but the average user > doesn't ;-) ). That still doesn't make updates-testing useful. If it's not being downloaded from updates-testing, then updates-testing is not useful. The only benefit to updates-testing right now is that packages get signed, but that doesn't help if I'm pushing out unsigned packages to people for testing. From jkeating at redhat.com Sat Jun 9 16:25:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 12:25:31 -0400 Subject: updates-testing is not useful In-Reply-To: <466AB51E.7090000@redhat.com> References: <466AB51E.7090000@redhat.com> Message-ID: <200706091225.31422.jkeating@redhat.com> On Saturday 09 June 2007 10:11:42 Christopher Aillon wrote: > Can we implement some sort of auto-signing-and-pushing mechanism for > _testing_ packages at least? ?I do see the value in having a human make > a decision for the final repository, but am having a hard time coming up > with a good reason for -testing. Updates-testing wouldn't be useful then either as we could have all kinds of broken deps in the repo (not that we can stop it right now, but that is being worked on). We're working toward the point where we can have people in most timezones capable of pushing updates, so that you don't have to wait very long and we can easily to multiple pushes in a day. This will require a signing server which some of us are going to work on, but it won't show up tomorrow. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 9 16:34:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 12:34:23 -0400 Subject: f7 images for mass production In-Reply-To: <466AC099.8050604@verizon.net> References: <4669D88C.7090302@verizon.net> <466AC099.8050604@verizon.net> Message-ID: <200706091234.23387.jkeating@redhat.com> On Saturday 09 June 2007 11:00:41 Gerry Reno wrote: > FWIW, the problem that I saw with F7 final was that all the great work > that had gone into F7 was overshadowed to a great degree by a lot of > installation issues. ?It was like having a 5-star meal served on a dirty > plate. ?So how about this? ?The general end user does not download test > releases that would help in shaking out any installation issues. ?They > should but they don't. ?So publicly release, some time prior to the > final, a Trailer, if you will, that installs exactly like the final. ? > Then the general user community can provide feedback as to any > installation issues they see. ?Everything in the Trailer installer works > the same except that at the end you see a few promotional messages > showing the new features in the release and of course the final "Coming > soon to a mirror near you" or "Opens May 31st", that kind of thing. ? > This way the installer can be broadly tested and any installer issues > can be identified and it would also help to build the hype for the > Fedora release. ?Just a fun type of thing that has some good QA benefit > attached to it. I kind of beg to differ. What major "installer" issues did you see? I'm well aware of some issues with the kernel, but what actual installer issues did you see? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Sat Jun 9 16:47:34 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 9 Jun 2007 16:47:34 +0000 (UTC) Subject: updates-testing is not useful References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > We're working toward the point where we can have people in most timezones > capable of pushing updates, so that you don't have to wait very long and we > can easily to multiple pushes in a day. You should also make sure that they're both Red Hat and community people in the list of people who'll be able to do that, for a simple reason: payed employees tend not to work on weekends, whereas volunteers often (not always, of course) have most of their time on weekends, so by having both, you ensure full-week coverage. :-) Kevin Kofler From jkeating at redhat.com Sat Jun 9 16:47:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 12:47:02 -0400 Subject: updates-testing is not useful In-Reply-To: References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> Message-ID: <200706091247.02340.jkeating@redhat.com> On Saturday 09 June 2007 12:47:34 Kevin Kofler wrote: > You should also make sure that they're both Red Hat and community people in > the list of people who'll be able to do that, for a simple reason: payed > employees tend not to work on weekends, whereas volunteers often (not > always, of course) have most of their time on weekends, so by having both, > you ensure full-week coverage. Absolutely. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Sat Jun 9 16:48:53 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 09 Jun 2007 12:48:53 -0400 Subject: updates-testing is not useful In-Reply-To: <200706091225.31422.jkeating@redhat.com> References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> Message-ID: <466AD9F5.6010309@redhat.com> Jesse Keating wrote: > On Saturday 09 June 2007 10:11:42 Christopher Aillon wrote: >> Can we implement some sort of auto-signing-and-pushing mechanism for >> _testing_ packages at least? I do see the value in having a human make >> a decision for the final repository, but am having a hard time coming up >> with a good reason for -testing. > > Updates-testing wouldn't be useful then either as we could have all kinds of > broken deps in the repo (not that we can stop it right now, but that is being > worked on). So then run repoquery before pushing packages. If it causes the repo to break, then don't push it to testing. Of course, this requires the ability to support multiple packages per update. From bruno at wolff.to Sat Jun 9 16:59:55 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 9 Jun 2007 11:59:55 -0500 Subject: f7 images for mass production In-Reply-To: <200706090820.25030.jkeating@redhat.com> References: <20070609071422.GB4852@neu.nirvana> <200706090820.25030.jkeating@redhat.com> Message-ID: <20070609165955.GA21377@wolff.to> On Sat, Jun 09, 2007 at 08:20:24 -0400, Jesse Keating wrote: > > How is this any different from always having a Test4, or a Test5? Nobody is One important difference is that being able to upgrade from a test release to the final version is not guaranteed. There was talk this time around that people would be able to upgrade from test4 to final, but I don't think there was a prominent notice of that. Possibly being stuck with an unupgradable (well at least not conveniently upgradable) system is going to put a damper on the number of willing testers. For the kind of people Fedora is designed for, I think I think you are going to have plenty of people willing to try out a final release, even if they know there is going to be a point release in a few weeks. From bruno at wolff.to Sat Jun 9 16:59:55 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 9 Jun 2007 11:59:55 -0500 Subject: f7 images for mass production In-Reply-To: <200706090820.25030.jkeating@redhat.com> References: <20070609071422.GB4852@neu.nirvana> <200706090820.25030.jkeating@redhat.com> Message-ID: <20070609165955.GA21377@wolff.to> On Sat, Jun 09, 2007 at 08:20:24 -0400, Jesse Keating wrote: > > How is this any different from always having a Test4, or a Test5? Nobody is One important difference is that being able to upgrade from a test release to the final version is not guaranteed. There was talk this time around that people would be able to upgrade from test4 to final, but I don't think there was a prominent notice of that. Possibly being stuck with an unupgradable (well at least not conveniently upgradable) system is going to put a damper on the number of willing testers. For the kind of people Fedora is designed for, I think I think you are going to have plenty of people willing to try out a final release, even if they know there is going to be a point release in a few weeks. From walters at redhat.com Sat Jun 9 17:28:10 2007 From: walters at redhat.com (Colin Walters) Date: Sat, 09 Jun 2007 13:28:10 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181371332.4534.16.camel@rivendell> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <1181371332.4534.16.camel@rivendell> Message-ID: <1181410090.13239.1.camel@neutron.verbum.private> On Sat, 2007-06-09 at 02:42 -0400, seth vidal wrote: > On Fri, 2007-06-08 at 19:58 -0400, Colin Walters wrote: > > Admittedly I only skimmed this thread, but it seems like a decent > > opportunity to work my top three annoyances with the current system into > > discussion =) > > > > > - Get rid of the redundant changelog so I don't have to type changes > > twice (and this would also remove the redundant version number too) > > the changelog is for changes in the packaging, not in the program. Right, but there are two changelogs right now - the revision control system one, and the one in the text file. Just autogenerate the spec one from the revision control one, or get rid of it altogether and have it only stored online. From Axel.Thimm at ATrpms.net Sat Jun 9 17:33:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 19:33:35 +0200 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <20070609091311.A9924@xos037.xos.nl> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <20070609091311.A9924@xos037.xos.nl> Message-ID: <20070609173335.GA22957@neu.nirvana> On Sat, Jun 09, 2007 at 09:13:11AM +0200, Jos Vos wrote: > On Fri, Jun 08, 2007 at 07:58:03PM -0400, Colin Walters wrote: > > > - Don't make me increment integers (Release); this is > > what computers (i.e. the build system) are for > > Whatever you suggest to change, be sure that the final spec file > contains a real integer, not a macro defined in the build system > or so. > > It's already very discussable that %{?dist} is now used in the > release tags. I know this was introduced to overcome a - what > you can maybe call - shortcome in RPM, but it has its drawbacks > and every use of non-standard externally defined macros violates > the principles of RPM, being able to reproduce package building. But the disttag is designed in such a way as to also work when there is no definition for 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 Jun 9 17:39:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 19:39:39 +0200 Subject: f7 images for mass production In-Reply-To: <20070609071422.GB4852@neu.nirvana> References: <20070609071422.GB4852@neu.nirvana> Message-ID: <20070609173939.GB22957@neu.nirvana> On Sat, Jun 09, 2007 at 09:14:22AM +0200, Axel Thimm wrote: > Let me propose the following, not only for this specific release: > Since we have the tools (which we want to promote anyway) and since > every Fedora release had starter bugs that are more severe than > anything that creeps up during maintenance mode, let's always do an > official respin 3-4 weeks after a golden release. The need is there as > well (e.g. check with the fedora-unity guys, people want to have these > respins). And I'm sure there will be a lot of community testers (more > than during test4->GA) available if a respin is done. Since this is not getting the needed love: Another idea would be to have weekly respins. No QA other than ensuring the packages form a closure (and I think this is ensured in F7+updates anyway already) and no higher guarantees of working than telling people to use F7 and yum update. Would there we interest in such a project? Something like what fedora unity was delivering only on a regular basis. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Sat Jun 9 17:43:31 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 09 Jun 2007 13:43:31 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <20070609173335.GA22957@neu.nirvana> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <20070609091311.A9924@xos037.xos.nl> <20070609173335.GA22957@neu.nirvana> Message-ID: <1181411011.3749.166.camel@willson> On Sat, 2007-06-09 at 19:33 +0200, Axel Thimm wrote: > On Sat, Jun 09, 2007 at 09:13:11AM +0200, Jos Vos wrote: > > On Fri, Jun 08, 2007 at 07:58:03PM -0400, Colin Walters wrote: > > > > > - Don't make me increment integers (Release); this is > > > what computers (i.e. the build system) are for > > > > Whatever you suggest to change, be sure that the final spec file > > contains a real integer, not a macro defined in the build system > > or so. > > > > It's already very discussable that %{?dist} is now used in the > > release tags. I know this was introduced to overcome a - what > > you can maybe call - shortcome in RPM, but it has its drawbacks > > and every use of non-standard externally defined macros violates > > the principles of RPM, being able to reproduce package building. > > But the disttag is designed in such a way as to also work when there > is no definition for it. Wouldn't it make sense to add a make newrelease command that greps the existing tag from cvs and retrieves the current release number. Then use sed/awk/perl/whatever to increment it (in a sensible way) and writes it down into the spec, and, while there, also creates a new changelog entry with the current date and person/email information. This would be a useful tool and also not mandatory, if you have some specific need you can still go and do things manually. Simo. From a.badger at gmail.com Sat Jun 9 17:48:23 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 Jun 2007 10:48:23 -0700 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181397876.3749.162.camel@willson> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <200706081511.40535.jkeating@redhat.com> <1181331071.3903.197.camel@lt21223.campus.dmacc.edu> <1181397876.3749.162.camel@willson> Message-ID: <1181411303.2645.91.camel@localhost.localdomain> On Sat, 2007-06-09 at 10:04 -0400, Simo Sorce wrote: > On Fri, 2007-06-08 at 14:31 -0500, Jeffrey C. Ollie wrote: > > On Fri, 2007-06-08 at 15:11 -0400, Jesse Keating wrote: > > > I have to question why the build would have to be this way? If you've got the > > > prestine source branch, and you've got the patch branches, is there no way to > > > extract the patches to such a format that they will apply to the prestine > > > source, and stack them appropriately? Could we not extract a patch or patch > > > set from each of the patch branches to a set of patch files in proper order, > > > use them in the spec against a prestine tarball to generate the rpm? This > > > way we get the benefit of both worlds. If we're pie in the skying, I simply > > > don't accept that we have to sacrifice prestine tarball + patches in our > > > srpms just to get a way to manage patches against an exploaded source. > > > > Yes, that's certainly a possibility. It's kind of a medium between the > > two extremes I proposed. Building based upon a direct checkout of > > already patched source means all that you have to do is specify a tag > > but you lose the tarball + patches. Exporting patches from the exploded > > source repo and importing them as files to the package repo is more work > > but you keep the tarball + patches. The approach you propose would mean > > that the package maintainer would need to do some work to specify the > > set of patches to be extracted and the order to apply them (but wouldn't > > actually have to do the extraction him/herself), but you keep the > > tarball+patches approach to building. > > Have anybody thought of using quilt? > It is a tool that can help _a lot_ in managing patches (especially for > huge patch sets) . > I think it could help reach some of the goals here without shifting us > from using the orig.sourcesa+patches approach, that would be a big > mistake. > I've been and I am in the job of tracking changes in multiple trees > (basically internal forks), it is something you _don't_ want to do > unless absolutely necessary. > Absolutely. quilt is the only sane way to manage patches in our current system. What I want is to be able to add quilt like commands to a VCS to be able to manage our patches inside of a VCS. Having it integrated gives us access to the things that quilt does well and the things that a VCS does well. The important thing in my mind is that both using a VCS as simply a storage medium for patches and using a VCS as a fork of an upstream branch leave a lot to be desired. Combining quilt's patch management with a VCS's ability to track history and help merge changes across revisions is what I see as being ideal. > > The key decision though that needs to be made is whether we take that > > radical step of abandoning the tarball+patches approach. My feeling is > > that it's too radical for right now, but maybe it won't be in the > > future. > > No it is too radical, full stop. +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ruben at rubenkerkhof.com Sat Jun 9 17:51:20 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sat, 9 Jun 2007 19:51:20 +0200 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: <20070609123907.GA26897@lists.us.dell.com> References: <200706090825.12792.jkeating@redhat.com> <20070609123907.GA26897@lists.us.dell.com> Message-ID: <5C5BA6DF-6BA8-4B4C-AE97-A1887EE2DC29@rubenkerkhof.com> On 9-jun-2007, at 14:39, Matt Domsch wrote: > On Sat, Jun 09, 2007 at 08:25:12AM -0400, Jesse Keating wrote: >> On Friday 08 June 2007 18:31:53 Anthony Bryan wrote: >>> What can we do to make this happen? Is this the type of thing that's >>> easier for the maintainer of MirrorManager to add, or should we >>> supply >>> a patch? >> >> It would be best to open a dialog with Matt Domsch about this (: > > I replied on fedora-infrastructure-list just a bit ago. I'm happy to > see this functionality get added to mirrormanager, and am happy to > review patches as well. :-) The trick will be having a python module > that, given a list of URL/country tuples, generates the XML pages. > Which probably isn't that hard, really. > > Thanks, > Matt File attached :-) My Python skills suck, so feel free to improve it. It doesn't implement all fields in the MetaLink specification, but it should do the job. -------------- next part -------------- A non-text attachment was scrubbed... Name: metalink.py Type: text/x-python-script Size: 10009 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Jun 9 17:51:29 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 09 Jun 2007 19:51:29 +0200 Subject: f7 images for mass production In-Reply-To: <1181384492.27658.21.camel@dawkins> References: <369bce3b0706080954i3720e008i6c0d2030e42f44d6@mail.gmail.com> <13dbfe4f0706090048vb661053o46183b00472b4430@mail.gmail.com> <1181384492.27658.21.camel@dawkins> Message-ID: <1181411489.3980.7.camel@rousalka.dyndns.org> The problem with "fixing" isos is it's a neverending task, and people get used to re-downloading isos just because they may have changed, trash old perfectly correct shiny disks for the same reason, and the result is increased resource use (mirrors hate us) Plus regular iso re-spin *will* produce many duds, since they won't be tested thoroughly, which again is not good for the project. Better one set of well-documented problems than a shifting target no one knows the status of. -- 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 greno at verizon.net Sat Jun 9 18:08:44 2007 From: greno at verizon.net (Gerry Reno) Date: Sat, 09 Jun 2007 14:08:44 -0400 Subject: f7 images for mass production In-Reply-To: <200706091234.23387.jkeating@redhat.com> References: <4669D88C.7090302@verizon.net> <466AC099.8050604@verizon.net> <200706091234.23387.jkeating@redhat.com> Message-ID: <466AECAC.40608@verizon.net> Jesse Keating wrote: > On Saturday 09 June 2007 11:00:41 Gerry Reno wrote: > > I kind of beg to differ. What major "installer" issues did you see? I'm well > aware of some issues with the kernel, but what actual installer issues did > you see? > > When the installation does not succeed, it may be an installer issue or as you point out it may be a kernel issue. But to the user it all appears as an installer problem. So it is hard to know specifically what the source of the problem may be but the end result is no installation. From my experience with both FC6 and F7, I had a few problems with FC6 but at least I could get it installed. I have yet to be able to get a F7 install into a workable configuration - I'm excluding QEMU, which did install but is not usable without acceleration. And it's not that I've given up trying. I'm still working on trying to find a way to get the install to succeed. That's what I'm doing right now. From Axel.Thimm at ATrpms.net Sat Jun 9 18:16:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 20:16:58 +0200 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181411011.3749.166.camel@willson> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <20070609091311.A9924@xos037.xos.nl> <20070609173335.GA22957@neu.nirvana> <1181411011.3749.166.camel@willson> Message-ID: <20070609181658.GC24785@neu.nirvana> On Sat, Jun 09, 2007 at 01:43:31PM -0400, Simo Sorce wrote: > On Sat, 2007-06-09 at 19:33 +0200, Axel Thimm wrote: > > On Sat, Jun 09, 2007 at 09:13:11AM +0200, Jos Vos wrote: > > > On Fri, Jun 08, 2007 at 07:58:03PM -0400, Colin Walters wrote: > > > > > > > - Don't make me increment integers (Release); this is > > > > what computers (i.e. the build system) are for > > > > > > Whatever you suggest to change, be sure that the final spec file > > > contains a real integer, not a macro defined in the build system > > > or so. > > > > > > It's already very discussable that %{?dist} is now used in the > > > release tags. I know this was introduced to overcome a - what > > > you can maybe call - shortcome in RPM, but it has its drawbacks > > > and every use of non-standard externally defined macros violates > > > the principles of RPM, being able to reproduce package building. > > > > But the disttag is designed in such a way as to also work when there > > is no definition for it. > > Wouldn't it make sense to add a make newrelease command that greps the > existing tag from cvs and retrieves the current release number. > Then use sed/awk/perl/whatever to increment it (in a sensible way) and > writes it down into the spec, and, while there, also creates a new > changelog entry with the current date and person/email information. FWIW these things are all done in the appropriate emacs mode. Don't now if there is a vim mode as well, if not, then maybe we need one. -- 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 Sat Jun 9 18:25:22 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jun 2007 10:25:22 -0800 Subject: f7 images for mass production In-Reply-To: <46699440.6060205@fedoraproject.org> References: <46698430.9060702@redhat.com> <46698651.8020508@fedoraproject.org> <46699440.6060205@fedoraproject.org> Message-ID: <604aa7910706091125hb26902at41e66c693bc5a2b1@mail.gmail.com> On 6/8/07, Rahul Sundaram wrote: > Sure. I understand the motivation but if you are doing that work I don't > see any reason to prevent other people from benefiting from it. Since re-spins have been an extremely successful mission of Fedora Unity squad up till this point.... how about we do something like this. Max "Glorious Leader" Spevack creates his mass-produced updated iso in conjunction with Fedora Unity, with co-branded packaging and makes the iso available through Unity's normal distribution methods. AND the Fedora project itself, finds a way to help Unity make their iso more accessible if Unity would like that, perhaps we start listing their re-spins on the master torrent server and from the main webpages or find some mirror space for them as an alternative to jgdo. -jef"three cheers for vicadin!"spaleta From a.badger at gmail.com Sat Jun 9 18:36:02 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 09 Jun 2007 11:36:02 -0700 Subject: RFR: GIT Package VCS In-Reply-To: <1181339304.3335.17.camel@rousalka.dyndns.org> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <1181254342.4070.262.camel@localhost.localdomain> <2979.192.54.193.51.1181304306.squirrel@rousalka.dyndns.org> <1181328641.2645.34.camel@localhost.localdomain> <1181339304.3335.17.camel@rousalka.dyndns.org> Message-ID: <1181414163.2645.120.camel@localhost.localdomain> On Fri, 2007-06-08 at 23:48 +0200, Nicolas Mailhot wrote: > Le vendredi 08 juin 2007 ? 11:50 -0700, Toshio Kuratomi a ?crit : > > On Fri, 2007-06-08 at 14:05 +0200, Nicolas Mailhot wrote: > > > > It's definitely not > > > - "are Fedora patches are correct or useful fonctionnality-wise" > > > - "why did the Packager did this thing" > > > > > Disagree wholeheartedly. I don't just take upstream releases and > > package them. I also code bugfixes, backport fixes, and make changes to > > the default configs. When applicable, I submit these changes to > > upstream. Seeing as this is code developed against the source tree, I > > want to be able to track the changes I make in a VCS. Simply adding and > > removing patches in CVS is not very good for this. Working with those > > patches against the exploded tree is much better. > > But that's the VCS usefulness for you as individual packager, Which is one of the goals, yes? As long as we agree on that, I'll attempt to show that the other audiences you have in mind are also served by doing this. > not its > usefulness for upstream (just wants ready-to-push patches) By having quilt-like commands in the VCS we are able t manage our changes as a sequence of patches just like now and send them upstream just like now. So at the least it should be no harder to work with upstream than now. I argue that it will, in fact, be easier to work with upstream because the VCS will make it easier for us to port the patches forward to upstream's HEAD if upstream desires and take suggestions from upstream and merge it into our patch. > for fedora > users (just want to be able to do quick audits) This would be your argument about log messages, yes? I'll address that below. > or other fedora > packagers (as far as I know we never have more than one people working > on changes on the same package between two koji builds) > Which could be a limitation of our tools rather than a statement on the idealness of the system. In any case, exploded trees won't make it harder for "a single developer per koji build" to do their job. Also, as a packager, I do sometimes want to see the history of changes that went into a specific patch in a previous build. There was a regression introduced when PackagerFoo rebased to a new upstream. What were the changes that went into that rebase? Can I see the regression in the specific set of changes made then? > Therefore, what would tracking all those changes in a public VCS instead > of a private branch would accomplish? It would only flood the Fedora > commit list & VCS with all your private code attempts, and make harder > to identify shipped patches among all the other noise/activity (bad for > everyone but you) > I have two points for this: 1) As previously stated, when further development of a patch does happen, the log messages are a total mess. Looking at a diff of a diff is horrible for extracting meaning and overall context whereas a diff between the prior tree with patch-v1 and the current tree with patch-v2 applied is much easier to read and audit. 2) Using exploded trees and a DRCS does not have to send the complete logs to a mailing list. The DRCS tracks which changes occur on which branch. So I would checkout/branch/clone the current package directory. Make changes that will go into the patch locally with as many commits as are necessary to me. Then, when I have rpmbuilt it and tested the change, I would merge the changes from my local branch to the Fedora Package Branch. At this point, if we decide that we don't want to send out a complete log of the patches to the commits list, we can send only the commit message from the merge so you only have to see the message for "the final product". For someone who wants to dig deeper, the full logs would be available by checking out a branch of the package. > If you actually look at the information you want published (not your > local developer undo/redo queue), is it so much different from what > we're already publishing today ? Exploded view may make the changes > easier to grasp, but do we *actually* need any datapoint apart from each > package build state published? > As a packager, yes we do. As your Fedora User who wants to quickly audit the changes, perhaps not. But we can address both audiences here because the metainformation about what branch a commit is made to is available. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Sat Jun 9 18:54:08 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 9 Jun 2007 20:54:08 +0200 Subject: iwlwifi-firmware Message-ID: The iwlwifi-firmware package only contains the ucode image for iwl3945 but not 4945. should I file a bug against iwlwifi-firmware or should this be a different package? upstream calls them: iwlwifi-3945-ucode and iwlwifi.4945-ucode -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Sat Jun 9 18:52:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 09 Jun 2007 14:52:34 -0400 Subject: iwlwifi-firmware In-Reply-To: References: Message-ID: <1181415154.16047.0.camel@aglarond.local> On Sat, 2007-06-09 at 20:54 +0200, dragoran wrote: > The iwlwifi-firmware package only contains the ucode image for iwl3945 > but not 4945. > should I file a bug against iwlwifi-firmware or should this be a > different package? > upstream calls them: > iwlwifi-3945-ucode > and > iwlwifi.4945-ucode Probably a different package. And now that F7's out the door, it's probably a good time to get the 3945 firmware package renamed for the devel tree. They just changed the naming upstream right before final freeze, so we wanted to put it off a smidge Jeremy From bernie at codewiz.org Sat Jun 9 19:04:07 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sat, 09 Jun 2007 15:04:07 -0400 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <20070609070226.GA4852@neu.nirvana> References: <46689424.5030009@codewiz.org> <20070608100217.GA30585@neu.nirvana> <4669D4B6.5070209@codewiz.org> <20070609070226.GA4852@neu.nirvana> Message-ID: <466AF9A7.8020606@codewiz.org> Axel Thimm wrote: > On a subscriber-only list I consider that a feature. I hate getting > duplicate emails, especially ones that don't have a List-Id: header to > properly sort the mail (like the Cc'd mail wouldn't have). You probably get duplicate e-mail also for cross-postings when you're subscribed to both lists. But is it a big deal? You only read them once anyway. But how did you notice this reply for you on fedora-list? The way I do it, is very unreliable and clumsy: grou by thread, search for my own postings, look if they have any unread replies. >>> But some of these lists you mention are not subscriber only. >> I also think lists should be open to posting by non-subscribers... >> Otherwise cross-posting is painful and doesn't work as intended >> (i.e.: you get half of the messages in each list). > > But cross-posting is discouraged anyway. Discouraged by whom? If I post with a subject such as "kernel with selinux enabled slows down OpenGL", I'd cross-post to all relevant lists: fedora-devel@, linux-kernel@, selinux@, mesa3d-dev@ and dri at . People subscribed to these lists are likely to be interested. If they're not, they will just skip the thread after reading the subject. Let's not talk about bandwidth issues, please. I can comfortably read 10-20 high-traffic lists even with my slow connection at home. And web services such as gmame and gmail make it easy even from hand-helds. >> The spam argument is easily dismissed once you notice that >> linux-kernel@ is almost 100% spam free despite being open. > > http://lkml.org/lkml/2006/8/8/146 I stand corrected. (but see the replies: people /like/ open lists for the same reasons I gave) > OK, there are a couple of mailing lists on this very server that are > open to anyone just have a look at for example > video4linux-list at redhat.com to see the amount of spam. I can't see the archives without subscribing first. But what kind of filtering did RedHat put in front of their listserver? Maybe I've not ran lists with such high-profile, but I have two dozens of lists in my mailman and easily got rid of almost all the incoming spam. I see one every few days, which is very affordable. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From jos at xos.nl Sat Jun 9 19:15:28 2007 From: jos at xos.nl (Jos Vos) Date: Sat, 9 Jun 2007 21:15:28 +0200 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <20070609173335.GA22957@neu.nirvana>; from Axel.Thimm@ATrpms.net on Sat, Jun 09, 2007 at 07:33:35PM +0200 References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <20070609091311.A9924@xos037.xos.nl> <20070609173335.GA22957@neu.nirvana> Message-ID: <20070609211528.A14693@xos037.xos.nl> On Sat, Jun 09, 2007 at 07:33:35PM +0200, Axel Thimm wrote: > But the disttag is designed in such a way as to also work when there > is no definition for it. If I rebuild a src.rpm with release 1.fc6 I expect that the release of the resulted binary rpm's is 1.fc6, not 1. I don't know the exact rationale, but at least it has its drawbacks. In an automated build system, it would maybe be better to automatically insert a %define dist .fc6 (whatever is applicable for the target distro) at the beginning of the spec file, so that the resulting src.rpm is not dependent on an externally defined %dist. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From buildsys at fedoraproject.org Sat Jun 9 19:18:38 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 9 Jun 2007 15:18:38 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-09 Message-ID: <20070609191838.69C33152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 38 deltarpm-3.4-2.fc6 NEW drapes-0.5.1-4.fc6 : A wallpaper manager application for the GNOME desktop emelfm2-0.3.4-1.fc6 gdesklets-0.35.4-6.1.fc6 glunarclock-0.32.4-8.fc6 gnome-commander-1.2.4-2.fc6 gtranslator-1.1.7-3.fc6 jack-audio-connection-kit-0.103.0-1.fc6 jrtplib-3.7.1-1.fc6 NEW kflickr-0.8-3.fc6 : Standalone Flickr Uploader for KDE libgtksourceviewmm-0.3.1-1.fc6 lostirc-0.4.6-2.fc6 maxima-5.12.0-3.fc6 NEW nikto-1.36-3.fc6 : Web server scanner numpy-1.0.3-0.1.fc6 openvrml-0.16.5-1.fc6 perl-Catalyst-Plugin-Static-Simple-0.17-1.fc6 perl-GDGraph-1.44-1.fc6 perl-Log-Log4perl-1.11-1.fc6 perl-SVN-Mirror-0.73-1.fc6 perl-Test-WWW-Mechanize-1.14-1.fc6 perl-WWW-Mechanize-1.30-2.fc6 php-pear-Console-Table-1.0.7-1.fc6 php-pear-Log-1.9.11-1.fc6 php-pecl-zip-1.8.10-1.fc6 pl-5.6.35-1.fc6 NEW postgresql_autodoc-1.30-2.fc6 : PostgreSQL AutoDoc Utility python-cheetah-2.0-0.6.rc8.fc6 NEW python-gammu-0.20-1.fc6 : Python bindings for Gammu NEW python-IPy-0.53-2.fc6 : Python module for handling IPv4 and IPv6 Addresses and Networks NEW redet-8.22-4.fc6 : Regular expression development and execution tool NEW redet-doc-8.21-1.fc6 : Documentation for redet sbcl-1.0.6-2.fc6 (!) sipp-2.0-1.fc6 : INVALID rebuild, not published! specto-0.2.0-4.fc6 taskjuggler-2.3.1-2.fc6 NEW wxsvg-1.0-0.3.b7_3.fc6 : C++ library to create, manipulate and render SVG files xfce4-mixer-4.4.1-2.fc6 Packages built and released for Fedora Extras 5: 9 glunarclock-0.32.4-8.fc5 gnome-commander-1.2.4-2.fc5.1 perl-Catalyst-Plugin-Static-Simple-0.17-1.fc5 perl-GDGraph-1.44-1.fc5 perl-SVN-Mirror-0.73-1.fc5 php-pear-Console-Table-1.0.7-1.fc5 php-pear-Log-1.9.11-1.fc5 php-pecl-zip-1.8.10-1.fc5 NEW python-gammu-0.20-1.fc5 : Python bindings for Gammu Changes in Fedora Extras 6: deltarpm-3.4-2.fc6 ------------------ * Wed May 09 2007 Adam Jackson 3.4-2 - Add -a flag to work around multilib ignorance. (#238964) * Tue Mar 06 2007 Adam Jackson 3.4-1 - Update to 3.4 (#231154) * Mon Feb 12 2007 Adam Jackson 3.3-7 - Add RPM_OPT_FLAGS to make line. (#227380) drapes-0.5.1-4.fc6 ------------------ * Thu May 31 2007 Damien Durand - 0.5.1-4 - add gnome-sharp in requires * Tue May 29 2007 Damien Durand - 0.5.1-3 - Fix setup part, rename to drapes emelfm2-0.3.4-1.fc6 ------------------- * Sat Jun 09 2007 Christoph Wickert - 0.3.4-1 - Update 0.3.4. - Enable support for inotify * Wed Mar 21 2007 Christoph Wickert - 0.3.3-1 - Update 0.3.3. gdesklets-0.35.4-6.1.fc6 ------------------------ * Thu Jun 07 2007 Luya Tshimbalanga - 0.35.4-6.1 - Fixed requirement for gnome-python2-devel - Add patch to remove old Xorg 6.8 notification for transition.py - Removed no-longer needed python-abi glunarclock-0.32.4-8.fc6 ------------------------ * Fri Jun 08 2007 Jon Ciesla - 0.32.4-8 - Added yelp Requires, BZ #243486. - Some SRPM permission fixes, spec cleanup. gnome-commander-1.2.4-2.fc6 --------------------------- * Sat Jun 09 2007 Mamoru Tasaka - 1.2.4-2 - Add missing BR libgsf-devel * Sat Jun 09 2007 Mamoru Tasaka - 1.2.4-1 - Update to 1.2.4 - Support python chmlib libiptcdata - From upstream: Sun Feb 4 2007 Piotr Eljasiak - added libgsf dependencies Wed Jan 30 2007 Piotr Eljasiak - added build and runtime deps for python and gnome-python2-gnomevfs * Sat Jun 09 2007 Mamoru Tasaka - 1.2.3-7 - Require yelp (#243392) * Tue Apr 17 2007 Mamoru Tasaka - 1.2.3-6 - Add maintainer, description elements to gnome-commander.xml for newer libxslt gtranslator-1.1.7-3.fc6 ----------------------- * Fri Jun 08 2007 Sindre Pedersen Bj?rdal 1.1.7-3 - Add yelp dependency, closes #243401 jack-audio-connection-kit-0.103.0-1.fc6 --------------------------------------- * Wed May 23 2007 Andy Shevchenko 0.103.0-1 - update to the last official release - append defaults to the limits.conf (#221785, #235624) * Wed Mar 07 2007 Andy Shevchenko 0.102.20-4 - drop libtermcap-devel build requirement (#231203) - create special jackuser group (#221785) jrtplib-3.7.1-1.fc6 ------------------- * Sat Jun 09 2007 Jeffrey C. Ollie - 3.7.1-1 - Update to 3.7.1 kflickr-0.8-3.fc6 ----------------- * Mon May 14 2007 Michael Stahnke - 0.8-3 - Final touch-up for review bug # 237355 * Mon May 14 2007 Michael Stahnke - 0.8-2 - Minor fix for bug # 237355 libgtksourceviewmm-0.3.1-1.fc6 ------------------------------ * Fri Jun 08 2007 Damien Durand - 0.3.1-1 - Upgrade to 0.3.1 lostirc-0.4.6-2.fc6 ------------------- * Thu May 31 2007 Damien Durand - 0.4.6-2 - Fixed source0 url * Tue Apr 03 2007 Damien Durand - 0.4.6-1 - Initial RPM release maxima-5.12.0-3.fc6 ------------------- * Tue May 29 2007 Rex Dieter 5.12.0-3 - ExclusiveArch: %ix86 -> i386 (for koji) * Tue May 29 2007 Rex Dieter 5.12.0-2 - respin for sbcl-1.0.6 * Thu May 03 2007 Rex Dieter 5.12.0-1 - maxima-5.12.0 * Mon Apr 30 2007 Rex Dieter 5.11.99-0.4.rc3 - maxima-5.11.99rc3 * Sun Apr 29 2007 Rex Dieter 5.11.99-0.3.rc2 - fix sbcl/ppc build (#238376) * Sun Apr 29 2007 Rex Dieter 5.11.99-0.1.rc2 - maxima-5.11.99rc2 * Mon Mar 26 2007 Rex Dieter 5.11.0-8 - respin for sbcl-1.0.4 * Wed Feb 28 2007 Rex Dieter 5.11.0-7 - respin for sbcl-1.0.3 nikto-1.36-3.fc6 ---------------- * Wed May 30 2007 Sindre Pedersen Bj?rdal - 1.36-3 - Add sed magic to really replace nikto-1.36-config.patch * Mon May 28 2007 Sindre Pedersen Bj?rdal - 1.36-2 - Remove libwhisker Requires - Replace configfile patch with sed magic - Update License - Add database-license.txt to %doc numpy-1.0.3-0.1.fc6 ------------------- * Wed Jun 06 2007 Jarod Wilson 1.0.3-1 - New upstream release * Mon May 14 2007 Jarod Wilson 1.0.2-2 - Drop BR: atlas-devel, since it just provides binary-compat blas and lapack libs. Atlas can still be optionally used at runtime. (Note: this is all per the atlas maintainer). * Mon May 14 2007 Jarod Wilson 1.0.2-1 - New upstream release * Tue Apr 17 2007 Jarod Wilson 1.0.1-4 - Update gfortran patch to recognize latest gfortran f95 support - Resolves rhbz#236444 openvrml-0.16.5-1.fc6 --------------------- * Thu Jun 07 2007 Braden McDaniel - 0.16.5-1 - Updated to 0.16.5. perl-Catalyst-Plugin-Static-Simple-0.17-1.fc6 --------------------------------------------- * Fri Jun 08 2007 Chris Weyl 0.17-1 - update to 0.17 - switch build/install incantations; module switched to Module::Install perl-GDGraph-1.44-1.fc6 ----------------------- * Sat May 05 2007 Jose Pedro Oliveira - 1:1.44-1 - Update to 1.44. perl-Log-Log4perl-1.11-1.fc6 ---------------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 1.11-1 - Update to 1.11. perl-SVN-Mirror-0.73-1.fc6 -------------------------- * Tue May 29 2007 Ian Burrell - 0.73-1 - Update to 0.73 perl-Test-WWW-Mechanize-1.14-1.fc6 ---------------------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 1.14-1 - Update to 1.14. perl-WWW-Mechanize-1.30-2.fc6 ----------------------------- * Thu Jun 07 2007 Jose Pedro Oliveira - 1.30-2 - New rebuild option: "--with livetests". * Thu Jun 07 2007 Jose Pedro Oliveira - 1.30-1 - Update to 1.30. - The Makefile.PL --mech-dump option is now deprecated. * Thu Jun 07 2007 Jose Pedro Oliveira - 1.24-1 - Update to 1.24. php-pear-Console-Table-1.0.7-1.fc6 ---------------------------------- * Wed May 02 2007 Remi Collet 1.0.7-1 - update to 1.0.7 php-pear-Log-1.9.11-1.fc6 ------------------------- * Wed May 02 2007 Remi Collet 1.9.11-1 - update to 1.9.11 php-pecl-zip-1.8.10-1.fc6 ------------------------- * Thu Jun 07 2007 Remi Collet 1.8.10-1 - update to 1.8.10 * Sun Mar 25 2007 Remi Collet 1.8.8-1 - update to 1.8.8 pl-5.6.35-1.fc6 --------------- * Fri Jun 08 2007 Gerard Milmeister - 5.6.35-1 - new version 5.6.35 - add requires readline-devel postgresql_autodoc-1.30-2.fc6 ----------------------------- * Sat Jun 09 2007 - Devrim GUNDUZ 1.30-2 - Some more fixes ber bugzilla review #200630 python-cheetah-2.0-0.6.rc8.fc6 ------------------------------ * Thu May 03 2007 Mike Bonnet - 2.0-0.6.rc8 - bump release for rebuild * Mon Apr 23 2007 Mike Bonnet - 2.0-0.5.rc8 - update to 2.0rc8 * Mon Jan 08 2007 Mike Bonnet - 2.0-0.4.rc7 - use setuptools and install setuptools metadata * Sun Dec 10 2006 Mike Bonnet - 2.0-0.3.rc7 - rebuild against python 2.5 - remove obsolete python-abi Requires: python-gammu-0.20-1.fc6 ----------------------- * Wed May 23 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.20-1 - Updated release. - fixed permission on examples files. - added gammu as require (need it to work with wammu package). python-IPy-0.53-2.fc6 --------------------- * Tue Jun 05 2007 Matt Domsch 0.53-2 - simple cleanups per Fedora package review, with thanks to Nigel Jones. * Thu May 10 2007 Matt Domsch 0.53-1 - repackaged for Fedora redet-8.22-4.fc6 ---------------- * Sat Jun 09 2007 Nigel Jones 8.22-4 - + Dep on desktop-file-utils - Minor touch up for .desktop file * Tue Jun 05 2007 Nigel Jones 8.22-3 - Use kregexpeditor.png for now (until I find a better unique one) * Fri Jun 01 2007 Nigel Jones 8.22-2 - Add .desktop file * Wed May 23 2007 Nigel Jones 8.22-1 - Initial SPEC file redet-doc-8.21-1.fc6 -------------------- * Wed May 23 2007 Nigel Jones 8.21-1 - Initial SPEC file sbcl-1.0.6-2.fc6 ---------------- * Wed Jun 06 2007 Rex Dieter 1.0.6-2 - respin * Tue May 29 2007 Rex Dieter 1.0.6-1 - sbcl-1.0.6 * Sun Apr 29 2007 Rex Dieter 1.0.5-1 - sbcl-1.0.5 * Mon Apr 09 2007 Rex Dieter 1.0.4-2 - re-enable threading support (#235644) * Mon Mar 26 2007 Rex Dieter 1.0.4-1 - sbcl-1.0.4 * Wed Feb 28 2007 Rex Dieter 1.0.3-1 - sbcl-1.0.3 sipp-2.0-1.fc6 -------------- * Sat May 12 2007 Peter Lemenkov 2.0-1 - Version 2.0 specto-0.2.0-4.fc6 ------------------ * Wed Jun 06 2007 Xavier Lamien - 0.2.0-4 - Rebuilt for CVS. taskjuggler-2.3.1-2.fc6 ----------------------- * Thu Jun 07 2007 Ondrej Vasik -2.3.1-2 - fixed number of memory leaks (from upstream) - removed -j4 after make in %build LANG=C export LANG unset DISPLAY section - (caused build failure) #233028 against RHEL5, but same for FC-6 * Thu Mar 08 2007 Jens Petersen - 2.3.1-1 - update to 2.3.1 - improve taskjuggler-2.1.1-docbook.patch to remove explicit systemid (#231422) wxsvg-1.0-0.3.b7_3.fc6 ---------------------- * Wed Jun 06 2007 Matthias Saou 1.0-0.3.b7_3 - Update to 1.0b7_3. - Pass -p to install. - Remove no longer needed freetype patch, but... - ...include our own ltmain.sh because it's missing... - ...run ./autogen.sh since Makefile.in files are missing too. xfce4-mixer-4.4.1-2.fc6 ----------------------- * Wed May 30 2007 Kevin Fenzi - 4.4.1-2 - Build with ALSA instead of OSS (fixes bug #239513) Changes in Fedora Extras 5: glunarclock-0.32.4-8.fc5 ------------------------ * Fri Jun 08 2007 Jon Ciesla - 0.32.4-8 - Added yelp Requires, BZ #243486. - Some SRPM permission fixes, spec cleanup. * Mon Aug 28 2006 Joost Soeterbroek - 0.32.4-7 - rebuild for Fedora Extras 6; add buildreq perl-XML-Parser gnome-commander-1.2.4-2.fc5.1 ----------------------------- * Sat Jun 09 2007 Mamoru Tasaka - 1.2.4-2 - Add missing BR libgsf-devel * Sat Jun 09 2007 Mamoru Tasaka - 1.2.4-1 - Update to 1.2.4 - Support python chmlib libiptcdata - From upstream: Sun Feb 4 2007 Piotr Eljasiak - added libgsf dependencies Wed Jan 30 2007 Piotr Eljasiak - added build and runtime deps for python and gnome-python2-gnomevfs * Sat Jun 09 2007 Mamoru Tasaka - 1.2.3-7 - Require yelp (#243392) * Tue Apr 17 2007 Mamoru Tasaka - 1.2.3-6 - Add maintainer, description elements to gnome-commander.xml for newer libxslt perl-Catalyst-Plugin-Static-Simple-0.17-1.fc5 --------------------------------------------- * Fri Jun 08 2007 Chris Weyl 0.17-1 - update to 0.17 - switch build/install incantations; module switched to Module::Install perl-GDGraph-1.44-1.fc5 ----------------------- * Sat May 05 2007 Jose Pedro Oliveira - 1:1.44-1 - Update to 1.44. perl-SVN-Mirror-0.73-1.fc5 -------------------------- * Tue May 29 2007 Ian Burrell - 0.73-1 - Update to 0.73 php-pear-Console-Table-1.0.7-1.fc5 ---------------------------------- * Wed May 02 2007 Remi Collet 1.0.7-1 - update to 1.0.7 php-pear-Log-1.9.11-1.fc5 ------------------------- * Wed May 02 2007 Remi Collet 1.9.11-1 - update to 1.9.11 php-pecl-zip-1.8.10-1.fc5 ------------------------- * Thu Jun 07 2007 Remi Collet 1.8.10-1 - update to 1.8.10 * Sun Mar 25 2007 Remi Collet 1.8.8-1 - update to 1.8.8 python-gammu-0.20-1.fc5 ----------------------- * Wed May 23 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.20-1 - Updated release. - fixed permission on examples files. - added gammu as require (need it to work with wammu package). For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jkeating at redhat.com Sat Jun 9 19:29:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 15:29:46 -0400 Subject: f7 images for mass production In-Reply-To: <20070609173939.GB22957@neu.nirvana> References: <20070609071422.GB4852@neu.nirvana> <20070609173939.GB22957@neu.nirvana> Message-ID: <200706091529.50159.jkeating@redhat.com> On Saturday 09 June 2007 13:39:39 Axel Thimm wrote: > Since this is not getting the needed love: Another idea would be to > have weekly respins. No QA other than ensuring the packages form a > closure (and I think this is ensured in F7+updates anyway already) and > no higher guarantees of working than telling people to use F7 and yum > update. > > Would there we interest in such a project? Something like what fedora > unity was delivering only on a regular basis. Very quickly your userland drifts farther than the anaconda build can deal with, and then you get into trying to update anaconda, and taking away our installer team's time from working on the next release and... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at redhat.com Sat Jun 9 19:34:11 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 09 Jun 2007 15:34:11 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <200706081520.11252.jkeating@redhat.com> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> Message-ID: <1181417651.4813.19.camel@localhost.localdomain> On Fri, 2007-06-08 at 15:20 -0400, Jesse Keating wrote: > > THere is some shelfishness to doing things in Raleigh or BOS, Red Hat > has to > pay for fewer of their employees to get to it. Not a great excuse, > just a > reason (: Or, a better way to put it is that we'll have more money around to do other things than sending people around. (Personally, I would love to have it somewhere in the Midwest. We're too left or right focused IMHO. But plane tickets are expensive.) --Chris From jkeating at redhat.com Sat Jun 9 19:32:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 15:32:33 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <1181410090.13239.1.camel@neutron.verbum.private> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181371332.4534.16.camel@rivendell> <1181410090.13239.1.camel@neutron.verbum.private> Message-ID: <200706091532.33453.jkeating@redhat.com> On Saturday 09 June 2007 13:28:10 Colin Walters wrote: > Right, but there are two changelogs right now - the revision control > system one, and the one in the text file. ?Just autogenerate the spec > one from the revision control one, or get rid of it altogether and have > it only stored online. Have you used 'make clog' ? It drops the last srpm changelog to a file that you can use with 'make clog; cvs commit -F clog' Then you can easily use the spec file's comment for the VCS. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laxathom at fedoraproject.org Sat Jun 9 19:36:12 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 9 Jun 2007 15:36:12 -0400 Subject: iwlwifi-firmware In-Reply-To: <1181415154.16047.0.camel@aglarond.local> References: <1181415154.16047.0.camel@aglarond.local> Message-ID: <62bc09df0706091236r576f90dex84b0abe87131bbab@mail.gmail.com> It's more apropriate to have differente package instead have on package for all. that could avoid to install unused files or make able to remove unused files. So this package should be named as follow: iwl-3945-firmware iwl-4945-firmware 2007/6/9, Jeremy Katz : > > On Sat, 2007-06-09 at 20:54 +0200, dragoran wrote: > > The iwlwifi-firmware package only contains the ucode image for iwl3945 > > but not 4945. > > should I file a bug against iwlwifi-firmware or should this be a > > different package? > > upstream calls them: > > iwlwifi-3945-ucode > > and > > iwlwifi.4945-ucode > > Probably a different package. And now that F7's out the door, it's > probably a good time to get the 3945 firmware package renamed for the > devel tree. +1 They just changed the naming upstream right before final > freeze, so we wanted to put it off a smidge > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sat Jun 9 19:34:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 15:34:16 -0400 Subject: updates-testing is not useful In-Reply-To: <466AD9F5.6010309@redhat.com> References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> <466AD9F5.6010309@redhat.com> Message-ID: <200706091534.16412.jkeating@redhat.com> On Saturday 09 June 2007 12:48:53 Christopher Aillon wrote: > Jesse Keating wrote: > > On Saturday 09 June 2007 10:11:42 Christopher Aillon wrote: > >> Can we implement some sort of auto-signing-and-pushing mechanism for > >> _testing_ packages at least? I do see the value in having a human make > >> a decision for the final repository, but am having a hard time coming up > >> with a good reason for -testing. > > > > Updates-testing wouldn't be useful then either as we could have all kinds > > of broken deps in the repo (not that we can stop it right now, but that > > is being worked on). > > So then run repoquery before pushing packages. If it causes the repo to > break, then don't push it to testing. Of course, this requires the > ability to support multiple packages per update. Patches welcome. Seriously, repoquery isn't cheap nor easy, and you can't use existing repos because you're replacing packages in those repos. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Sat Jun 9 19:40:31 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 9 Jun 2007 21:40:31 +0200 Subject: iwlwifi-firmware In-Reply-To: <62bc09df0706091236r576f90dex84b0abe87131bbab@mail.gmail.com> References: <1181415154.16047.0.camel@aglarond.local> <62bc09df0706091236r576f90dex84b0abe87131bbab@mail.gmail.com> Message-ID: On 6/9/07, Xavier Lamien wrote: > > It's more apropriate to have differente package instead have on package > for all. that could avoid to install unused files or make able to remove > unused files. > So this package should be named as follow: > iwl-3945-firmware > iwl-4945-firmware ok, agreed... but I would prefer iwlwifi over iwl (to match upstream) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonynelson at georgeanelson.com Sat Jun 9 19:41:56 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sat, 9 Jun 2007 15:41:56 -0400 Subject: updates-testing is not useful In-Reply-To: <200706091225.31422.jkeating@redhat.com> References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> Message-ID: At 12:25 PM -0400 6/9/07, Jesse Keating wrote: >On Saturday 09 June 2007 10:11:42 Christopher Aillon wrote: >> Can we implement some sort of auto-signing-and-pushing mechanism for >> _testing_ packages at least? I do see the value in having a human make >> a decision for the final repository, but am having a hard time coming up >> with a good reason for -testing. > >Updates-testing wouldn't be useful then either as we could have all kinds of >broken deps in the repo (not that we can stop it right now, but that is being >worked on). (Horning in here.) What if there were a daily message to fedora-list from something like the build system, listing first the new packages in updates-testing, followed by all the packages in updates-testing? Each package entry would be accompanied by links to the bugzillas relevent to the update (the current changelog entries are nice, but what is wanted here is testing reports). At the bottom would be boilerplate on how to use updates-testing from the yum command line and what to watch out for (massive other updates at the same time: just say "N"!). What I've found in looking around the wiki, is that the procedures for updates-testing aren't well defined nor is testing that easily done. I think a daily message would put updates-testing to work. Probably all of it is easy except listing the bugzillas relevent to each updated package. -- ____________________________________________________________________ TonyN.:' ' From bruno at wolff.to Sat Jun 9 19:42:20 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 9 Jun 2007 14:42:20 -0500 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <1181417651.4813.19.camel@localhost.localdomain> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> Message-ID: <20070609194220.GA8740@wolff.to> On Sat, Jun 09, 2007 at 15:34:11 -0400, Christopher Blizzard wrote: > On Fri, 2007-06-08 at 15:20 -0400, Jesse Keating wrote: > > > > THere is some shelfishness to doing things in Raleigh or BOS, Red Hat > > has to > > pay for fewer of their employees to get to it. Not a great excuse, > > just a > > reason (: > > Or, a better way to put it is that we'll have more money around to do > other things than sending people around. > > (Personally, I would love to have it somewhere in the Midwest. We're > too left or right focused IMHO. But plane tickets are expensive.) You guys should buy a bus. You can have people playing LAN games for fun during the trip. The reduced hassel and more fun would make up for the longer travel time. From bruno at wolff.to Sat Jun 9 19:44:42 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 9 Jun 2007 14:44:42 -0500 Subject: updates-testing is not useful In-Reply-To: References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> Message-ID: <20070609194442.GB8740@wolff.to> On Sat, Jun 09, 2007 at 15:41:56 -0400, Tony Nelson wrote: > > What if there were a daily message to fedora-list from something like the > build system, listing first the new packages in updates-testing, followed > by all the packages in updates-testing? Each package entry would be fedora-test-list gets notices about new packages in updates-testing already. From blizzard at redhat.com Sat Jun 9 19:47:46 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 09 Jun 2007 15:47:46 -0400 Subject: new rc questions and comments In-Reply-To: <20070608182623.GA9472@nostromo.devel.redhat.com> References: <20070608182623.GA9472@nostromo.devel.redhat.com> Message-ID: <1181418466.4813.25.camel@localhost.localdomain> The current page also lists a set of complaints, but it's not clear to me from looking at what's out there already (based on the bottom of the page - yay, research!) what your goals are? I would strongly suggest that if you want to get something done that you pick two or three specific goals. For example: o Startup a desktop in < 25 seconds o Only start services that are required for the machine's specific task o Enable desktop services to start system-level services o Give an admin or installer the choice between a "fast laptop startup" and "startup for unix workstation environment" (by which I mean support for nfs, kerberos, etc - not usually needed for laptops.) o LSB compliance And note that things like parallelism and I/O fixes are more mechanisms for the specific goals. Break them out. And most important: MEASURE. For example, if you don't know how long a particular config takes to do what you want, you'll never know if you're making progress. Does a simple desktop startup (ala what we find on the livecd) take too long? What can we do to fix it? Just make sure you're asking the right questions. The current wiki entry is all over the place so I can't tell what the goal of a new init system is other than the usual friendly technical wankery. :D --Chris From jkeating at redhat.com Sat Jun 9 19:44:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 15:44:43 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <1181417651.4813.19.camel@localhost.localdomain> References: <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> Message-ID: <200706091544.43479.jkeating@redhat.com> On Saturday 09 June 2007 15:34:11 Christopher Blizzard wrote: > Or, a better way to put it is that we'll have more money around to do > other things than sending people around. Maybe we'll have more money to fly people that don't work for Red Hat in? (: > (Personally, I would love to have it somewhere in the Midwest. ?We're > too left or right focused IMHO. ?But plane tickets are expensive.) For serial. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at redhat.com Sat Jun 9 19:48:44 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 09 Jun 2007 15:48:44 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <20070609194220.GA8740@wolff.to> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> <20070609194220.GA8740@wolff.to> Message-ID: <1181418524.4813.27.camel@localhost.localdomain> On Sat, 2007-06-09 at 14:42 -0500, Bruno Wolff III wrote: > > You guys should buy a bus. You can have people playing LAN games for > fun > during the trip. The reduced hassel and more fun would make up for the > longer travel time. > I remember suggesting such a thing for one of our world wide corporate meetings that was being held in Raleigh. Back when we were still small enough to _do_ a world wide meeting. :) Not sure why we didn't do it, but we didn't. --Chris From blizzard at redhat.com Sat Jun 9 19:51:07 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 09 Jun 2007 15:51:07 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <200706091544.43479.jkeating@redhat.com> References: <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> <200706091544.43479.jkeating@redhat.com> Message-ID: <1181418667.4813.29.camel@localhost.localdomain> On Sat, 2007-06-09 at 15:44 -0400, Jesse Keating wrote: > > > Maybe we'll have more money to fly people that don't work for Red Hat > in? (: > That was at the back of my head but I didn't want to make any promises against Max's budget. As you might imagine, that's bad form. :) --Chris From jkeating at redhat.com Sat Jun 9 19:54:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 15:54:09 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <1181418667.4813.29.camel@localhost.localdomain> References: <200706091544.43479.jkeating@redhat.com> <1181418667.4813.29.camel@localhost.localdomain> Message-ID: <200706091554.10106.jkeating@redhat.com> On Saturday 09 June 2007 15:51:07 Christopher Blizzard wrote: > That was at the back of my head but I didn't want to make any promises > against Max's budget. ?As you might imagine, that's bad form. I seem to recall we've done it in the past. Also Danial Robbins agreed to come to our next FUDCon and share his thoughts/experiences with driving a community distribution (Gentoo). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Jun 9 20:05:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 16:05:00 -0400 Subject: The updates firehose Message-ID: <200706091605.00638.jkeating@redhat.com> Anybody else think we're issuing entirely /way/ too many updates? We've had 138 "stable" updates, and 177 current "testing" updates. If all those were to go stable, we're talking over 300 updates, in just over a week. Seriously. We're drowning our users in updates. Are all of them really necessary? I feel like we've got this culture of update whatever/whenever coming from Extras where it was just fire and forget. While that might be fun for the maintainer, is it fun for the user? Is it fun for the user with a slow connection? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bruno at wolff.to Sat Jun 9 20:15:15 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 9 Jun 2007 15:15:15 -0500 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <20070609201515.GA19734@wolff.to> On Sat, Jun 09, 2007 at 16:05:00 -0400, Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. > > Seriously. We're drowning our users in updates. Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Is it fun for the user with > a slow connection? I'd rather have the updates available as rpm's than have to switch to building a package from source, if there is an update I want. Is it possible to provide meta data to yum with some sort of indication of what the update does. Maybe a choice from Security, Critical (e.g. data loss) bug, Bug fix, New features. Then you could tell yum to only grab security and critical bug fixes if you didn't want to download lots of updates. From opensource at till.name Sat Jun 9 20:23:10 2007 From: opensource at till.name (Till Maas) Date: Sat, 09 Jun 2007 22:23:10 +0200 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <200706092223.13366.opensource@till.name> On Sa Juni 9 2007, Jesse Keating wrote: > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Is it fun for the user > with a slow connection? A slow connection is never fun ;-). But seriously, nobody is forced to update and thanks to bodhi and iirc the yum-security plugin[1] it is even possible to install only security updates. Also I guess there are many updates from Extras Packages, that are released now because of the Freeze, so the amount of updates will be less the next weeks. And the user in me likes up to date software very much. And to make it more fun for users with a slow connection, yum-presto will help a lot more. But maybe there should be also delta-xml files for the repository metadata, because it takes very long to download these, too, with a slow connection. Regards, Till [1] But I don't know, whether or not it is already in Fedora 7 From bernie at codewiz.org Sat Jun 9 20:28:41 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sat, 09 Jun 2007 16:28:41 -0400 Subject: The updates firehose In-Reply-To: <20070609201515.GA19734@wolff.to> References: <200706091605.00638.jkeating@redhat.com> <20070609201515.GA19734@wolff.to> Message-ID: <466B0D79.8020002@codewiz.org> Bruno Wolff III wrote: > I'd rather have the updates available as rpm's than have to switch to building > a package from source, if there is an update I want. Very true... > Is it possible to provide meta data to yum with some sort of indication > of what the update does. Maybe a choice from Security, Critical (e.g. > data loss) bug, Bug fix, New features. Then you could tell yum to only grab > security and critical bug fixes if you didn't want to download lots of > updates. You want something like the "urgency" attribute of debian packages. In my opinion, it belongs to RPM and not yum, but I'd second the idea in general. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From blizzard at redhat.com Sat Jun 9 20:32:07 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 09 Jun 2007 16:32:07 -0400 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <1181421127.4813.33.camel@localhost.localdomain> On Sat, 2007-06-09 at 16:05 -0400, Jesse Keating wrote: > > Seriously. We're drowning our users in updates. Are all of them > really > necessary? I feel like we've got this culture of update > whatever/whenever > coming from Extras where it was just fire and forget. While that > might be > fun for the maintainer, is it fun for the user? Is it fun for the > user with > a slow connection? Are people complaining? Are we actually breaking stuff in the process? Are you upset with the amount of bandwith we're eating or just based on principal? We're not RHEL. If an update is a good one I would rather have it go out than not. Also encouraging a re-spin of the CDs/DVDs in a couple of weeks might be a good idea ala unity. Don't know how much human bandwith we have for such a thing, though. --Chris From ssorce at redhat.com Sat Jun 9 20:32:27 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 09 Jun 2007 16:32:27 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <20070609181658.GC24785@neu.nirvana> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <20070609091311.A9924@xos037.xos.nl> <20070609173335.GA22957@neu.nirvana> <1181411011.3749.166.camel@willson> <20070609181658.GC24785@neu.nirvana> Message-ID: <1181421147.3749.169.camel@willson> On Sat, 2007-06-09 at 20:16 +0200, Axel Thimm wrote: > On Sat, Jun 09, 2007 at 01:43:31PM -0400, Simo Sorce wrote: > > On Sat, 2007-06-09 at 19:33 +0200, Axel Thimm wrote: > > > On Sat, Jun 09, 2007 at 09:13:11AM +0200, Jos Vos wrote: > > > > On Fri, Jun 08, 2007 at 07:58:03PM -0400, Colin Walters wrote: > > > > > > > > > - Don't make me increment integers (Release); this is > > > > > what computers (i.e. the build system) are for > > > > > > > > Whatever you suggest to change, be sure that the final spec file > > > > contains a real integer, not a macro defined in the build system > > > > or so. > > > > > > > > It's already very discussable that %{?dist} is now used in the > > > > release tags. I know this was introduced to overcome a - what > > > > you can maybe call - shortcome in RPM, but it has its drawbacks > > > > and every use of non-standard externally defined macros violates > > > > the principles of RPM, being able to reproduce package building. > > > > > > But the disttag is designed in such a way as to also work when there > > > is no definition for it. > > > > Wouldn't it make sense to add a make newrelease command that greps the > > existing tag from cvs and retrieves the current release number. > > Then use sed/awk/perl/whatever to increment it (in a sensible way) and > > writes it down into the spec, and, while there, also creates a new > > changelog entry with the current date and person/email information. > > FWIW these things are all done in the appropriate emacs mode. Don't now > if there is a vim mode as well, if not, then maybe we need one. I don't think emacs modes or vim modes are appropriate here, sure they will be really handy for people that use either emacs or vim (if they get to know) but they will not help people that use other editors, that's why I propose to make it a Makefile option (and visible with make help). Simo. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From email.ahmedkamal at googlemail.com Sat Jun 9 20:39:09 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 9 Jun 2007 23:39:09 +0300 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <3da3b5b40706091339y4d1b98f3o9131164f24a77f58@mail.gmail.com> > is it fun for the user? Is it fun for the user with > a slow connection? This is where presto shines :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernie at codewiz.org Sat Jun 9 20:41:12 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sat, 09 Jun 2007 16:41:12 -0400 Subject: The updates firehose In-Reply-To: <1181421127.4813.33.camel@localhost.localdomain> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> Message-ID: <466B1068.7030002@codewiz.org> Christopher Blizzard wrote: > Are people complaining? I don't complain when it happens with my own computer that's being updated daily... but it's painful when you update a dozen of desktops in the office to F7 and all them want to download 500MB worth of updates the first time they boot. Yes, I could use a local Fedora mirror. And, in fact, I do. But then I'd have to customize the yum config on all clients to go look there. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From jspaleta at gmail.com Sat Jun 9 20:49:39 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jun 2007 12:49:39 -0800 Subject: The updates firehose In-Reply-To: <1181421127.4813.33.camel@localhost.localdomain> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> Message-ID: <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> On 6/9/07, Christopher Blizzard wrote: > We're not RHEL. If an update is a good one I would rather have it go > out than not. As a maintainer, I'd appreciate some reasonable best practices to consider when pushing an update however. Guidance easily found to read over when interacting with bodhi. If I've got a bug report for a missing dep at the packaging level for example, is it worth pushing? Are all patchable non-crasher non-security application bugs worth pushing as individual updates or is it better to sit on some of them, do a build in koji and let the original reporter eat the koji package if possible? On a less personal perspective.. i wonder about unity re-spins. Would re-spins be easier or harder for unity to do if we attempted to stage updates in periodically produced lumps (in a consensus sort of gentlemanly, we'll try real hard but we aren't going to hold anyone's feet to the fire sort of way.) -jef"Do we have stats on relative number of updates compared to the number of new components entering the tree"spaleta From bernie at codewiz.org Sat Jun 9 20:56:28 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Sat, 09 Jun 2007 16:56:28 -0400 Subject: Fedora 8 ideas In-Reply-To: <200706081123.15298.opensource@till.name> References: <46688CB8.5090004@codewiz.org> <200706081123.15298.opensource@till.name> Message-ID: <466B13FC.1040804@codewiz.org> Till Maas wrote: > Is there a more general alternative to this? rpm does not support installation > by an unprivileged user afaik. > And this is what all custom packages systems > that come to my mind allow (Perl/Cpan, ruby/gems, Haskell/Cabal, > Firefox/Thunderbird/XPI). Actually, RPM can do local installations with --relocate. But no packages I know of is relocatable. If whoever packages Firefox plugins made them relocatable, it would be possible also in practice. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From jspaleta at gmail.com Sat Jun 9 21:04:20 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jun 2007 13:04:20 -0800 Subject: updates-testing is not useful In-Reply-To: <20070609194442.GB8740@wolff.to> References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> <20070609194442.GB8740@wolff.to> Message-ID: <604aa7910706091404p45c84d58m369bf9e19fca094e@mail.gmail.com> On 6/9/07, Bruno Wolff III wrote: > fedora-test-list gets notices about new packages in updates-testing already. Let me suggest, that if we would like to see these packages more widely tested, then it might not be wise to send this just to test-list.... nothing like preaching to the choir...a relatively small choir at that. You want to drive a summary of a test annoucements into the most commonly used discussion channels for end-users... to aid in the chance of noticing that crap is going into testing at all. -jef From mclasen at redhat.com Sat Jun 9 21:09:17 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 09 Jun 2007 17:09:17 -0400 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <1181423357.4092.3.camel@localhost.localdomain> On Sat, 2007-06-09 at 16:05 -0400, Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. > > Seriously. We're drowning our users in updates. Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Is it fun for the user with > a slow connection? Make it easier for users to filter out the updates they don't want then. From opensource at till.name Sat Jun 9 21:27:33 2007 From: opensource at till.name (Till Maas) Date: Sat, 09 Jun 2007 23:27:33 +0200 Subject: The updates firehose In-Reply-To: <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> Message-ID: <200706092327.37236.opensource@till.name> On Sa Juni 9 2007, Jeff Spaleta wrote: > do a build in koji and let the original reporter eat the koji package > if possible? Before recommending this procecure, imho koji packages should be signed or at least be available over https for people without a Fedora account. Regards, Till From opensource at till.name Sat Jun 9 21:32:09 2007 From: opensource at till.name (Till Maas) Date: Sat, 09 Jun 2007 23:32:09 +0200 Subject: Fedora 8 ideas In-Reply-To: <466B13FC.1040804@codewiz.org> References: <200706081123.15298.opensource@till.name> <466B13FC.1040804@codewiz.org> Message-ID: <200706092332.13183.opensource@till.name> On Sa Juni 9 2007, Bernardo Innocenti wrote: > Actually, RPM can do local installations with --relocate. But no > packages I know of is relocatable. If whoever packages Firefox > plugins made them relocatable, it would be possible also in practice. The Packaging Guidelines imply, that it is a lot of pain: http://fedoraproject.org/wiki/Packaging/Guidelines#head-fbe6710872c6c12f38b996cc64119266ece01171 Relocatable packages | The use of RPM's facility for generating relocatable packages is strongly | discouraged. It is difficult to make work properly, impossible to use from | the installer or from yum, and not generally necessary if other packaging | guidelines are followed. However, in the unlikely event that you have a good | reason to make a package relocatable, you MUST state this intent and | reasoning in the request for package review. And does --relocate really work for non root users? Regards, Till From giallu at gmail.com Sat Jun 9 21:36:01 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 9 Jun 2007 23:36:01 +0200 Subject: The updates firehose In-Reply-To: <466B1068.7030002@codewiz.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> Message-ID: On 6/9/07, Bernardo Innocenti wrote: > Yes, I could use a local Fedora mirror. And, in fact, > I do. But then I'd have to customize the yum config on > all clients to go look there. > Guru Labs have a nice howto for solving that problem (/me bookmarking it...) http://www.gurulabs.com/goodies/YUM_automatic_local_mirror.php From caillon at redhat.com Sat Jun 9 21:39:16 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 09 Jun 2007 17:39:16 -0400 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <466B1E04.5060308@redhat.com> Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. > > Seriously. We're drowning our users in updates. Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Is it fun for the user with > a slow connection? I agree that we should attempt to limit somewhat. But people always get upset at me for not pushing things out. We need to determine a policy here before you ask people to limit themselves. From Axel.Thimm at ATrpms.net Sat Jun 9 21:46:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 23:46:59 +0200 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <466AF9A7.8020606@codewiz.org> References: <46689424.5030009@codewiz.org> <20070608100217.GA30585@neu.nirvana> <4669D4B6.5070209@codewiz.org> <20070609070226.GA4852@neu.nirvana> <466AF9A7.8020606@codewiz.org> Message-ID: <20070609214659.GA3873@neu.nirvana> On Sat, Jun 09, 2007 at 03:04:07PM -0400, Bernardo Innocenti wrote: > >But cross-posting is discouraged anyway. > > Discouraged by whom? If I post with a subject such as > "kernel with selinux enabled slows down OpenGL", I'd > cross-post to all relevant lists: fedora-devel@, > linux-kernel@, selinux@, mesa3d-dev@ and dri at . Crossposting to 5 lists? Mailman would probably already hold back your post due to excessive number of recipients. > People subscribed to these lists are likely to be interested. > If they're not, they will just skip the thread after reading > the subject. > > Let's not talk about bandwidth issues, please. I can > comfortably read 10-20 high-traffic lists even with my > slow connection at home. And web services such as gmame > and gmail make it easy even from hand-helds. Bandwidth, no, but if you cross-post the same question on 5 lists, or even just pose the same question with single posts w/o waiting for someone to answer the question you are wasting people on this. You will probably spawn 5 different threads on each list for the same topic, and people will feel fooled. > >>The spam argument is easily dismissed once you notice that > >>linux-kernel@ is almost 100% spam free despite being open. > > > >http://lkml.org/lkml/2006/8/8/146 > > I stand corrected. (but see the replies: people /like/ open > lists for the same reasons I gave) Bug reports from non-subscribers? We have bugzilla.redhat.com for bug reports. > I can't see the archives without subscribing first. But what > kind of filtering did RedHat put in front of their listserver? I don't know. -- 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 Jun 9 21:50:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 23:50:02 +0200 Subject: f7 images for mass production In-Reply-To: <200706091529.50159.jkeating@redhat.com> References: <20070609071422.GB4852@neu.nirvana> <20070609173939.GB22957@neu.nirvana> <200706091529.50159.jkeating@redhat.com> Message-ID: <20070609215002.GB3873@neu.nirvana> On Sat, Jun 09, 2007 at 03:29:46PM -0400, Jesse Keating wrote: > On Saturday 09 June 2007 13:39:39 Axel Thimm wrote: > > Since this is not getting the needed love: Another idea would be to > > have weekly respins. No QA other than ensuring the packages form a > > closure (and I think this is ensured in F7+updates anyway already) and > > no higher guarantees of working than telling people to use F7 and yum > > update. > > > > Would there we interest in such a project? Something like what fedora > > unity was delivering only on a regular basis. > > Very quickly your userland drifts farther than the anaconda build can deal > with, and then you get into trying to update anaconda, and taking away our > installer team's time from working on the next release and... It ain't as bad, I've been using anaconda with updated trees since ages for PXE booting including updates, and many other large site admins have been doing the same for security concerns. I guess the media spins are not that different than creating PXE trees concerning anaconda. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sat Jun 9 21:51:23 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 09 Jun 2007 21:51:23 -0000 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-09 Message-ID: <20070609215123.5651.24171@extras64.linux.duke.edu> Summary of broken packages (by owner): cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (7 days) dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (7 days) fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 (7 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (7 days) glest-data - 2.0.0-2.fc7.noarch (7 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (7 days) jonathansteffan AT gmail.com revisor - 2.0.3.8-1.fc7.noarch revisor - 2.0.3.8-1.fc7.noarch jwilson AT redhat.com beryl-gnome - 0.2.1-1.fc7.ppc64 (3 days) beryl-kde - 0.2.1-1.fc7.ppc64 (3 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (7 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (7 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (7 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (7 days) mdehaan AT redhat.com koan - 0.4.0-1.fc7.noarch (7 days) orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 (7 days) rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 (7 days) rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (7 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (7 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (7 days) tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 (7 days) Democracy - 0.9.5.1-8.fc7.ppc (7 days) Democracy - 0.9.5.1-8.fc7.ppc64 (7 days) Democracy - 0.9.5.1-8.fc7.x86_64 (7 days) ====================================================================== Broken packages in fedora-7-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-7-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in fedora-7-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-7-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-updates-7-ppc64: revisor-2.0.3.8-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-7-ppc: revisor-2.0.3.8-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-testing-7-ppc64: beryl-gnome-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 beryl-kde-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 koan-0.4.0-1.fc7.noarch requires syslinux From Axel.Thimm at ATrpms.net Sat Jun 9 21:52:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 9 Jun 2007 23:52:34 +0200 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <20070609211528.A14693@xos037.xos.nl> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <20070609091311.A9924@xos037.xos.nl> <20070609173335.GA22957@neu.nirvana> <20070609211528.A14693@xos037.xos.nl> Message-ID: <20070609215234.GC3873@neu.nirvana> On Sat, Jun 09, 2007 at 09:15:28PM +0200, Jos Vos wrote: > On Sat, Jun 09, 2007 at 07:33:35PM +0200, Axel Thimm wrote: > > > But the disttag is designed in such a way as to also work when there > > is no definition for it. > > If I rebuild a src.rpm with release 1.fc6 I expect that the release of > the resulted binary rpm's is 1.fc6, not 1. > > I don't know the exact rationale, but at least it has its drawbacks. Which ones? > In an automated build system, it would maybe be better to automatically > insert a > > %define dist .fc6 > > (whatever is applicable for the target distro) at the beginning of the > spec file, so that the resulting src.rpm is not dependent on an > externally defined %dist. But that would give 1.fc6 on RHEL5, Fedora 7 etc. I think the current solution is OK. -- 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 Jun 9 22:01:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 10 Jun 2007 00:01:07 +0200 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <20070609220107.GD3873@neu.nirvana> On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. But is that different than at FC6 release time (I don't know, but I assume it was similar if not even more)? We're not really doing anything different that made updates increase, I would even think that it is more difficult to pass updates since they have to be pushed through bodhi. You only feel like there are that many updates, because they are now all using bodhi while before F7 only 1/4th (Core) would become visible that way. > Seriously. We're drowning our users in updates. Are all of them > really necessary? I feel like we've got this culture of update > whatever/whenever coming from Extras where it was just fire and > forget. While that might be fun for the maintainer, is it fun for > the user? Is it fun for the user with a slow connection? I think Fedora's success is partly due to being updated that way. -- 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 vonbrand at inf.utfsm.cl Sat Jun 9 22:20:00 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 09 Jun 2007 18:20:00 -0400 Subject: tetex-doc is not noarch? In-Reply-To: References: Message-ID: <25129.1181427600@laptop13.inf.utfsm.cl> Rex Dieter wrote: > Neal Becker wrote: > > > Seems a bit odd: > > tetex-doc x86_64 > > It's built along with the rest of tetex, which *is* arch-specific. Yep. RPM bug/shortcomming (can't build several different arches (in this case, x86_64 + noarch) in one go). I complained about that a long time ago, was told it wasn't worth fixing. > The only way to get this to be noarch, would be to build it separately, and > the extra work/maintainance may or may not be worth the payoff. There's > lots of similar cases, kdelibs-apidocs is one that comes to mind. :) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jwboyer at jdub.homelinux.org Sat Jun 9 22:47:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 09 Jun 2007 17:47:36 -0500 Subject: updates-testing is not useful In-Reply-To: <200706091247.02340.jkeating@redhat.com> References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> <200706091247.02340.jkeating@redhat.com> Message-ID: <1181429257.17463.27.camel@vader.jdub.homelinux.org> On Sat, 2007-06-09 at 12:47 -0400, Jesse Keating wrote: > On Saturday 09 June 2007 12:47:34 Kevin Kofler wrote: > > You should also make sure that they're both Red Hat and community people in > > the list of people who'll be able to do that, for a simple reason: payed > > employees tend not to work on weekends, whereas volunteers often (not > > always, of course) have most of their time on weekends, so by having both, > > you ensure full-week coverage. > > Absolutely. And by "Absolutely." he really means Absolutely. The immediate goal is to expand the sign+push capability to rel-eng, which already includes community people. As an aside, I'm not sure your paid employees argument really holds. I've never seen people "work" more than the current Red Hat people on rel-eng. For them, I think it's also fun to some degree. Either that, or they're masochists. josh From Matt_Domsch at dell.com Sat Jun 9 22:58:55 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 9 Jun 2007 17:58:55 -0500 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: <5C5BA6DF-6BA8-4B4C-AE97-A1887EE2DC29@rubenkerkhof.com> References: <200706090825.12792.jkeating@redhat.com> <20070609123907.GA26897@lists.us.dell.com> <5C5BA6DF-6BA8-4B4C-AE97-A1887EE2DC29@rubenkerkhof.com> Message-ID: <20070609225855.GD26897@lists.us.dell.com> On Sat, Jun 09, 2007 at 07:51:20PM +0200, Ruben Kerkhof wrote: > On 9-jun-2007, at 14:39, Matt Domsch wrote: > > > >I replied on fedora-infrastructure-list just a bit ago. I'm happy to > >see this functionality get added to mirrormanager, and am happy to > >review patches as well. :-) The trick will be having a python module > >that, given a list of URL/country tuples, generates the XML pages. > >Which probably isn't that hard, really. > > > >Thanks, > >Matt > > File attached :-) > > My Python skills suck, so feel free to improve it. It doesn't > implement all fields in the MetaLink specification, but it should do > the job. Wow, that was fast. I'll look at this, but would you mind using the MIT/X11 license (the same license as Python and TurboGears themselves use, as does mirrormanager) rather than the GNU GPL? I'd rather not get into a license incompatibility mess this early in mirrormanager's life. :-) Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From katzj at redhat.com Sat Jun 9 23:37:39 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 09 Jun 2007 19:37:39 -0400 Subject: updates-testing is not useful In-Reply-To: <1181429257.17463.27.camel@vader.jdub.homelinux.org> References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> <200706091247.02340.jkeating@redhat.com> <1181429257.17463.27.camel@vader.jdub.homelinux.org> Message-ID: <1181432259.16047.6.camel@aglarond.local> On Sat, 2007-06-09 at 17:47 -0500, Josh Boyer wrote: > As an aside, I'm not sure your paid employees argument really holds. > I've never seen people "work" more than the current Red Hat people on > rel-eng. For them, I think it's also fun to some degree. > > Either that, or they're masochists. Oh definitely ;-) Jeremy PS Interpretation intentionally left to the reader. Consider it my weekend present :-) From jkeating at redhat.com Sun Jun 10 00:13:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 20:13:16 -0400 Subject: f7 images for mass production In-Reply-To: <20070609215002.GB3873@neu.nirvana> References: <200706091529.50159.jkeating@redhat.com> <20070609215002.GB3873@neu.nirvana> Message-ID: <200706092013.19675.jkeating@redhat.com> On Saturday 09 June 2007 17:50:02 Axel Thimm wrote: > It ain't as bad, I've been using anaconda with updated trees since > ages for PXE booting including updates, and many other large site > admins have been doing the same for security concerns. > > I guess the media spins are not that different than creating PXE > trees concerning anaconda. Ah, but you're mostly just refreshing the repodata no? Are you actually building new install images with buildinstall? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 00:17:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 20:17:25 -0400 Subject: The updates firehose In-Reply-To: <1181421127.4813.33.camel@localhost.localdomain> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> Message-ID: <200706092017.25476.jkeating@redhat.com> On Saturday 09 June 2007 16:32:07 Christopher Blizzard wrote: > Are people complaining? I don't know. I can't consume #fedora or fedora-list. I'm mostly seeking opinions with my posting. > Are we actually breaking stuff in the process? Well, we're still not checking for broken deps, so maybe. Things like multilib make this somewhat difficult to detect and prevent pushing, or detect and provide a way to deliver just the security ones, etc... I don't really know though, I'm off in rawhide land, but the amount of churn on the release makes it feel like rawhide too. > Are you upset with the amount of bandwith we're eating or just based on > principal? Somewhat on principal. The amount of churn in Extras went somewhat unnoticed to me because there wasn't something like bodhi for them. Now that everything goes through it it is very apparent that there is an enormous amount of updates issued. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 00:19:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 20:19:38 -0400 Subject: The updates firehose In-Reply-To: <20070609201515.GA19734@wolff.to> References: <200706091605.00638.jkeating@redhat.com> <20070609201515.GA19734@wolff.to> Message-ID: <200706092019.38404.jkeating@redhat.com> On Saturday 09 June 2007 16:15:15 Bruno Wolff III wrote: > Is it possible to provide meta data to yum with some sort of indication > of what the update does. Maybe a choice from Security, Critical (e.g. > data loss) bug, Bug fix, New features. Then you could tell yum to only grab > security and critical bug fixes if you didn't want to download lots of > updates. Actually we're going to re-implement that. We had it for the Core updater tool, Luke will hook us up with it for bodhi soon. It'll contain the contents of the "notes" you put into bodhi so that when you look at a list of updates in pup you can see what the update is for. However when you're staring down 60+ updates (or 90 or 120 depending on when you look) how many people are actually going to look through or are they going to just apply and hope for the best? I don't know if this is a real problem or not, just an observation on the weekend (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From qspencer at ieee.org Sun Jun 10 00:28:58 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Sat, 09 Jun 2007 19:28:58 -0500 Subject: The updates firehose In-Reply-To: <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> Message-ID: <466B45CA.6070605@ieee.org> Jeff Spaleta wrote: > On 6/9/07, Christopher Blizzard wrote: >> We're not RHEL. If an update is a good one I would rather have it go >> out than not. > > As a maintainer, I'd appreciate some reasonable best practices to > consider when pushing an update however. Guidance easily found to read > over when interacting with bodhi. If I've got a bug report for a > missing dep at the packaging level for example, is it worth pushing? > Are all patchable non-crasher non-security application bugs worth > pushing as individual updates or is it better to sit on some of them, > do a build in koji and let the original reporter eat the koji package > if possible? I agree with this. I also think the packager should take into account the size of the package. It doesn't bother me too much if some 100K package is updated every week, but it seemed to me like openoffice.org was updated 5-10 times during FC-6. I've got a high bandwidth connection, and it was still annoying enough to make me start looking at changelogs before I updated. Quentin From kevin.kofler at chello.at Sun Jun 10 00:35:16 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 Jun 2007 00:35:16 +0000 (UTC) Subject: updates-testing is not useful References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> <200706091247.02340.jkeating@redhat.com> <1181429257.17463.27.camel@vader.jdub.homelinux.org> Message-ID: Josh Boyer jdub.homelinux.org> writes: > As an aside, I'm not sure your paid employees argument really holds. > I've never seen people "work" more than the current Red Hat people on > rel-eng. For them, I think it's also fun to some degree. I agree with you here, the Red Hat folks working on Fedora are doing impressive work and working even at times of the day and/or week very few people would want to even _think_ about work. ;-) Many thanks for your dedication! Kevin Kofler From tibbs at math.uh.edu Sun Jun 10 00:56:53 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Jun 2007 19:56:53 -0500 Subject: The updates firehose In-Reply-To: <466B45CA.6070605@ieee.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> <466B45CA.6070605@ieee.org> Message-ID: >>>>> "QS" == Quentin Spencer writes: QS> It doesn't bother me too much if some 100K package is updated QS> every week, but it seemed to me like openoffice.org was updated QS> 5-10 times during FC-6. But also consider that openoffice.org is one of our high-profile applications, and that bugs in it affect a significant portion of the user base. I think that most of the updates we're seeing are: 1) New packages. We're burning through the review queue but we still have hundreds backlogged. All of the packages that are built for F-7 will generate an update announcement. 2) Updates to packages that, frankly, almost nobody has installed. Yes, there are a ton of updates, but we have thousands upon thousands of maintained packages. Most users who run the regular update tools simply won't see the vast majority of these updates. (People who install everything, however, get what they deserve/explicitly requested.) It just looks like a massive amount on the mailing list. One useful bit might be to use a different notice for new packages. That way you can look for "security" first, "new package" to see if it's something that interests you and ignore everything else. We might also elect to give people a list that just gets security update notices. - J< From kevin.kofler at chello.at Sun Jun 10 01:06:39 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 Jun 2007 01:06:39 +0000 (UTC) Subject: The updates firehose References: <200706091605.00638.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > Seriously. We're drowning our users in updates. Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Is it fun for the user with > a slow connection? The many updates are really Fedora's strength, and the one reason I can run a stable distro. :-) I don't want old software with known bugs which are already fixed upstream, and sometimes feature upgrades are also possible without breaking things (think leaf applications here, or backwards-compatible library upgrades like KDE 3.4.2->3.5.0 was, but of course not core libraries with an soname bump ;-) ) so I'd like to have them. Otherwise I'd have to run an unstable distribution like Rawhide and those are subject to the usual dependency breakages and such. Fedora is usually pretty good about pushing things which break stuff (because they're still under development) to Rawhide only while still pushing many updates which work fine to the stable release. I'm pretty sure many people picked Fedora for that reason. There's plenty of other distributions which follow strict "security fixes and critical bugfixes only" policies, Red Hat even produces such a distribution (and people who don't want to pay for it can use CentOS or Scientific Linux), so IMHO if that's what the users want, that's what they should be pointed to. Throwing away the frequent upgrades would be losing Fedora's main "selling" point. I also love it when there's a newsitem about KOffice at dot.kde.org and I can comment that the new version is already in F7 updates-testing and will be in updates soon. That whereas all the other distros only offer the new version in some strange per-package repository (which doesn't scale, you end up with hundreds of repos if you want all your packages up to date, and who knows how many conflicts) or not at all. As for slow connections, I think a combination of deltarpms and filters like yum-security can help a lot. Kevin Kofler From kevin.kofler at chello.at Sun Jun 10 01:10:52 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 10 Jun 2007 01:10:52 +0000 (UTC) Subject: The updates firehose References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> <466B45CA.6070605@ieee.org> Message-ID: Jason L Tibbitts III math.uh.edu> writes: > One useful bit might be to use a different notice for new packages. > That way you can look for "security" first, "new package" to see if > it's something that interests you and ignore everything else. We > might also elect to give people a list that just gets security update > notices. That's something which can be done in the updater. For security vs. non-security, that's what the updates metadata which the old Core updates tool had and which is being implemented in Bodhi too is for. New packages can be detected automatically, in fact Synaptic already does this: each time you update your metadata (apt separates updating metadata from upgrading packages), you get a list of packages which are new in your repositories. (This also catches bugs like debuginfo packages suddenly showing up in the regular updates repository, by the way. :-) This has been fixed now.) Kevin Kofler From sundaram at fedoraproject.org Sun Jun 10 01:21:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 06:51:16 +0530 Subject: The updates firehose In-Reply-To: <200706092019.38404.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070609201515.GA19734@wolff.to> <200706092019.38404.jkeating@redhat.com> Message-ID: <466B520C.70402@fedoraproject.org> Jesse Keating wrote: > On Saturday 09 June 2007 16:15:15 Bruno Wolff III wrote: >> Is it possible to provide meta data to yum with some sort of indication >> of what the update does. Maybe a choice from Security, Critical (e.g. >> data loss) bug, Bug fix, New features. Then you could tell yum to only grab >> security and critical bug fixes if you didn't want to download lots of >> updates. > > Actually we're going to re-implement that. We had it for the Core updater > tool, Luke will hook us up with it for bodhi soon. It'll contain the > contents of the "notes" you put into bodhi so that when you look at a list of > updates in pup you can see what the update is for. However when you're > staring down 60+ updates (or 90 or 120 depending on when you look) how many > people are actually going to look through or are they going to just apply and > hope for the best? > > I don't know if this is a real problem or not, just an observation on the > weekend (: If the classification of updates get exposed through Pup with a easy way to set preferences then it will get used much more. Rahul From sundaram at fedoraproject.org Sun Jun 10 01:24:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 06:54:41 +0530 Subject: reply-to-list addons cant use on fedora thunderbird version In-Reply-To: <466A404F.1010607@gmail.com> References: <466A404F.1010607@gmail.com> Message-ID: <466B52D9.4090203@fedoraproject.org> Ken YANG wrote: > hi all, > > i notice there is a nice add-on about reply-to-mailing-list: > > http://lists.opensuse.org/opensuse/2006-11/msg03582.html > http://alumnit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension > > but after i install, it can not work, as wiki said, maybe need a > patch for thunderbird, it seems suse thunderbird version can run > this sort of add-on > > is fedora has similar reply-to-list addon? If it is not upstream and requires a patch that is unlikely to be in Fedora. Rahul From Matt_Domsch at dell.com Sun Jun 10 01:31:24 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 9 Jun 2007 20:31:24 -0500 Subject: The updates firehose In-Reply-To: <466B1068.7030002@codewiz.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> Message-ID: <20070610013123.GE26897@lists.us.dell.com> On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote: > Christopher Blizzard wrote: > > >Are people complaining? > > I don't complain when it happens with my own computer that's > being updated daily... but it's painful when you update a > dozen of desktops in the office to F7 and all them want to > download 500MB worth of updates the first time they boot. > > Yes, I could use a local Fedora mirror. And, in fact, > I do. But then I'd have to customize the yum config on > all clients to go look there. You can add your local private mirror to mirrormanager, add a netblock that covers your address space, and all your clients will then pull from your local mirror rather than public mirrors, with no change on the clients. https://admin.fedoraproject.org/mirrormanager http://fedoraproject.org/wiki/Infrastructure/Mirroring Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From sundaram at fedoraproject.org Sun Jun 10 02:25:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 07:55:11 +0530 Subject: The updates firehose In-Reply-To: <20070610013123.GE26897@lists.us.dell.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> Message-ID: <466B6107.7090904@fedoraproject.org> Matt Domsch wrote: > On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote: >> Christopher Blizzard wrote: >> >>> Are people complaining? >> I don't complain when it happens with my own computer that's >> being updated daily... but it's painful when you update a >> dozen of desktops in the office to F7 and all them want to >> download 500MB worth of updates the first time they boot. >> >> Yes, I could use a local Fedora mirror. And, in fact, >> I do. But then I'd have to customize the yum config on >> all clients to go look there. > > You can add your local private mirror to mirrormanager, add a netblock > that covers your address space, and all your clients will then pull > from your local mirror rather than public mirrors, with no change on > the clients. > > https://admin.fedoraproject.org/mirrormanager > http://fedoraproject.org/wiki/Infrastructure/Mirroring Matt, would you be interested in writing a updated mirror guide? The one at http://docs.fedoraproject.org is pretty outdated and we need to cover all the new configurations and features in the new mirror manager. Rahul From Matt_Domsch at dell.com Sun Jun 10 02:52:55 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 9 Jun 2007 21:52:55 -0500 Subject: The updates firehose In-Reply-To: <466B6107.7090904@fedoraproject.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <466B6107.7090904@fedoraproject.org> Message-ID: <20070610025254.GF26897@lists.us.dell.com> On Sun, Jun 10, 2007 at 07:55:11AM +0530, Rahul Sundaram wrote: > Matt Domsch wrote: > >On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote: > >>Christopher Blizzard wrote: > >> > >>>Are people complaining? > >>I don't complain when it happens with my own computer that's > >>being updated daily... but it's painful when you update a > >>dozen of desktops in the office to F7 and all them want to > >>download 500MB worth of updates the first time they boot. > >> > >>Yes, I could use a local Fedora mirror. And, in fact, > >>I do. But then I'd have to customize the yum config on > >>all clients to go look there. > > > >You can add your local private mirror to mirrormanager, add a netblock > >that covers your address space, and all your clients will then pull > >from your local mirror rather than public mirrors, with no change on > >the clients. > > > >https://admin.fedoraproject.org/mirrormanager > >http://fedoraproject.org/wiki/Infrastructure/Mirroring > > Matt, would you be interested in writing a updated mirror guide? The one > at http://docs.fedoraproject.org is pretty outdated and we need to cover > all the new configurations and features in the new mirror manager. Yeah, somehow I found that link the other day, and thought it needed to be reworked somewhat. That doc is nice in that works regardless of any new features Fedora Infrastructure provides (like mirrormanager), and is good for anyone anywhere that has a copy of the packages, either from media or downloaded. But it could certainly be enhanced to describe using the publicly available mirrors to keep your own tree up-to-date, as well as pointers to perhaps another doc describing how to use MirrorManager. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tibbs at math.uh.edu Sun Jun 10 03:08:55 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Jun 2007 22:08:55 -0500 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> <466B45CA.6070605@ieee.org> Message-ID: >>>>> "KK" == Kevin Kofler writes: KK> That's something which can be done in the updater. Well, not really. Consider that I administer some hundreds of desktops, and none of them runs the updater. I have to stage packages in a local repository and push them to my clients. But hey, I know how to filter things, so I'm not the primary use case. - J< From vonbrand at inf.utfsm.cl Sun Jun 10 03:09:40 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 09 Jun 2007 23:09:40 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <200706080814.55539.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080713.27067.jkeating@redhat.com> <19181.192.54.193.51.1181302924.squirrel@rousalka.dyndns.org> <200706080814.55539.jkeating@redhat.com> Message-ID: <489.1181444980@laptop13.inf.utfsm.cl> Jesse Keating wrote: > On Friday 08 June 2007 07:42:04 Nicolas Mailhot wrote: > > ??? -> archive + patches -> exploded tree (exploded tree as a way to > > export data) can probably be done easily > > > > ???? -> exploded tree -> archive + patches OTOH hand is a dangerous > > can of worms > > I'm not following. In my scenario the exploaded tree is used only for patch > management and for interacting with upstream when possible/acceptable. What > goes into the buildsystem would continue to be prestine upstream tarball > unmodified + spec + patches from patch management to make an srpm. Patches > still get applied in the rpmbuild task. You lost me here. If I am futzing around with the foo package, I'll have checked out sources /here/ and work against that. Perhaps I'll be following its upstream SCM, but that loses WRT pristine source tarball (exported version of today's changes, or even of tag 1.2.3, won't be exactly the released tarball foo-1.2.3.tar.bz2), so tracking all this centrally doesn't make much sense to me. Sure, tracking the tarballs making up any released RPMs is a must, otherwise I don't see the point. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From sundaram at fedoraproject.org Sun Jun 10 03:14:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 08:44:10 +0530 Subject: Web based interface for custom spins Message-ID: <466B6C82.5050902@fedoraproject.org> Is anyone looking into writing a web interface that can do custom spins using pungi and livecd-tools in the background? Revisor is useful as a graphical wrapper but it requires Fedora to be installed already. Having a web interface would allow anyone to select the package groups and individual packages and get a ISO image for download. I posted to fedora-infrastructure list before but we need a web app before talking about deploying it. There is new effort launched in http://respins.org to provide a forum and encourage community respins or derivatives of Fedora and they have expressed a interest in this too. Rahul From jspaleta at gmail.com Sun Jun 10 03:34:15 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jun 2007 19:34:15 -0800 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> <466B45CA.6070605@ieee.org> Message-ID: <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> On 09 Jun 2007 19:56:53 -0500, Jason L Tibbitts III wrote: > 1) New packages. > 2) Updates to packages that, frankly, almost nobody has installed. I wish we had quantifiable numbers to go along with this to aid discussion. If a large majority of the updates really are new packages or niche package updates then i doubt there's much of a concern from a userbase pov. But we don't have hard numbers for either 1 or 2. -jef"If wishes were horses we'd all be eating steak--name the tv show this quote is from"spaleta From dev at nigelj.com Sun Jun 10 03:45:27 2007 From: dev at nigelj.com (Nigel Jones) Date: Sun, 10 Jun 2007 15:45:27 +1200 Subject: The updates firehose In-Reply-To: <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> <466B45CA.6070605@ieee.org> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> Message-ID: <466B73D7.4050201@nigelj.com> Jeff Spaleta wrote: > On 09 Jun 2007 19:56:53 -0500, Jason L Tibbitts III > wrote: >> 1) New packages. http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?r1=1.2922&r2=1.3050 Should be a decent indication >> 2) Updates to packages that, frankly, almost nobody has installed. > > I wish we had quantifiable numbers to go along with this to aid > discussion. If a large majority of the updates really are new > packages or niche package updates then i doubt there's much of a > concern from a userbase pov. But we don't have hard numbers for either > 1 or 2. > > -jef"If wishes were horses we'd all be eating steak--name the tv show > this quote is from"spaleta Firefly? N.J. From bojan at rexursive.com Sun Jun 10 03:49:53 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sun, 10 Jun 2007 03:49:53 +0000 (UTC) Subject: The updates firehose References: <200706091605.00638.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. Maybe some of those updates aren't really updates, but packages that didn't make it into F7 final because there was no way to label them as such by maintainers? I have one such package in updates-testing right now. > Seriously. We're drowning our users in updates. Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Personally, I'm a new software junkie, so I don't mind at all as a user. > Is it fun for the user with > a slow connection? That may be a real problem. Not sure how many people fall in that category though. Maybe smolt could also have the "available bandwidth" statistics... -- Bojan From vonbrand at inf.utfsm.cl Sun Jun 10 03:52:07 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 09 Jun 2007 23:52:07 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <1181252698.4070.234.camel@localhost.localdomain> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181252698.4070.234.camel@localhost.localdomain> Message-ID: <2241.1181447527@laptop13.inf.utfsm.cl> Toshio Kuratomi wrote: > On Thu, 2007-06-07 at 22:25 +0200, Nicolas Mailhot wrote: [...] > > You're describing heavy forking which is not Fedora's target and not > > needed by the overwhelming majority of fedora packages. > > > Not at all. > > Config files -- local changes that shouldn't be merged upstream but we > might change over time. They would benefit from being revision > controlled. This is essentially the SourceX: tags that aren't source tarballs. Have to be tracked by Fedora's SCM. > Backports -- Our backport would benefit from a DRCS's history and > merging features to help update the patch when the upstream fix changes. That is a job for the individual maintainer, presumably using whatever SCM (if any) is used upstream plus assorted extra tools. > Local changes that are submitted upstream -- We would want to track the > history of changes that make up each patch just as if we were doing the > changes directly in upstream's tree. If upstream asks us to modify the > patch in any of the ways that I described the DRCS helps us do that. Again, a job for the individual maintainer. Keeping a copy of (or tracking) patches submitted to upstream might be useful, but really not essential. [...] > Having things in an exploded tree DRCS makes it easy to work locally > because you can make a local feature branch of the Fedora exploded tree, Why should all this be in Fedora repos? This smells an awful lot like centralized SCM (CVS-like) mentality. It will /not/ scale! It will be a horrible pain for anybody tring to work with this if they have a slow network connection to Fedora (yes, that means almost the whole world). [...] > > And upstream will ask targeted localised patches not huge vcs feeds it > > has to sift through The maintainer of the package has to work with upstream. Why should Fedora as a whole be somehow be involved here? > Right. Which is why you can't just drop everything into an exploded > tree but have to construct something like the Ubuntu page describes. > This allows you to easily manage logical changesets within the DRCS and > send them upstream as discrete patches. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From bojan at rexursive.com Sun Jun 10 04:01:57 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sun, 10 Jun 2007 04:01:57 +0000 (UTC) Subject: The updates firehose References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> Message-ID: Bernardo Innocenti codewiz.org> writes: > I don't complain when it happens with my own computer that's > being updated daily... but it's painful when you update a > dozen of desktops in the office to F7 and all them want to > download 500MB worth of updates the first time they boot. Or, Fedora could do a gold release (i.e. released on the release day) and then have "unofficial" weekly install snapshots, done automatically and not passed through any sort of testing, based on current RPMS, so that all you need to do is download that current install ISO and you're off. If it works, OK, if it doesn't, you can always go to the gold release that's been tested and then apply updates. -- Bojan From vonbrand at inf.utfsm.cl Sun Jun 10 04:15:26 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 10 Jun 2007 00:15:26 -0400 Subject: Future SCM Technology In-Reply-To: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> Message-ID: <2489.1181448926@laptop13.inf.utfsm.cl> [I'm a long time RH/Fedora user, but I don't maintain any packages and don't know much about the exact workflow being considered here.] Jeffrey C. Ollie wrote: > It's F7+5 and F8T1-57 (yes, less than two months until F8T1 under the > current schedule[1]). If we are going to replace CVS[2] with another > SCM for hosting the Fedora Package Repository we need to get started > now! And to get things started, we need to discuss what kinds of > workflow we want our new SCM to support. > > Here's a list of things to think about (thanks to Jeremy Katz): You need to split this up into what the individual maintainer has to do, and what has to be done centrally. Consider tools for the maintainer, not centrally handled stuff. > * How do we make it easier for a maintainer to rebase their package to a > newer upstream? Maintainer only, depends too much on what upstream does. Better tools for this are generally useful, getting various upstreams to work in a more uniform/structured way would be much help... > * How do we make it easier for a maintainer to develop, test, and create > a patch to fix a problem that's being experienced in Fedora? Maintainer mostly, I see little help possible here. Perhaps easy access to bugzilla'd testcases, tools for automated testdrives? Again, better tools for doing all this in general would be most helpful. e> * How do we make it easy to send these patches to the upstream of the > project being worked on? Ask upstream how they want it done... Maintainer only. > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? Who is "downstream" here? Derived distributions? They will probably just take the SRPMs and add their own patches/tweaks. > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? Not by forcing them to melt into whatever wonderful mesh Fedora builds for this, for sure. In the preceding I see little any centrally managed infrastructure can do to help the individual maintainer with their relationship to upstream. Assorted better tools are needed, but that is not a Fedora exclusive, and far from SCM-bound. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jeff at ocjtech.us Sun Jun 10 04:17:10 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 09 Jun 2007 23:17:10 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <489.1181444980@laptop13.inf.utfsm.cl> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706080713.27067.jkeating@redhat.com> <19181.192.54.193.51.1181302924.squirrel@rousalka.dyndns.org> <200706080814.55539.jkeating@redhat.com> <489.1181444980@laptop13.inf.utfsm.cl> Message-ID: <1181449030.3691.104.camel@lt21223.campus.dmacc.edu> On Sat, 2007-06-09 at 23:09 -0400, Horst H. von Brand wrote: > > You lost me here. If I am futzing around with the foo package, I'll have > checked out sources /here/ and work against that. Perhaps I'll be > following its upstream SCM, but that loses WRT pristine source tarball > (exported version of today's changes, or even of tag 1.2.3, won't be > exactly the released tarball foo-1.2.3.tar.bz2), so tracking all this > centrally doesn't make much sense to me. Sure, tracking the tarballs > making up any released RPMs is a must, otherwise I don't see the point. Checking exploded tarballs into a VCS might work ok, but there are issues that make that more difficult that you might first realize. Take hypothetical project foobar, that has been developed thusly: +-1.0 +-2.0 v v A--B--C--D--E--F--G \ W--X--Y--Z ^ +-3.0 Each letter represents a commit into the project's source code repository. The numbers represent releases. Now imagine that you have been packaging foobar for inclusion in Fedora. You have been checking the exploded tarballs into a source code repository and end up with something like this: +-1.0 | +-2.0 | | +-3.0 v v v A--B--C Now, forward-porting your patches from 1.0 to 2.0 went relatively smoothly, but for some reason forward-porting the patches from 2.0 to 3.0 was very difficult! If you compare the two graphs you can see that the code in your private source code repository has a very different history from the code in the upstream source code repository. VCSs like Git and Mercurial can take advantage of that history to make rebasing patches much more automatic. It's not perfect, you may end up doing some manual, but it's a darn sight easier than doing it without the full history. It's true that many projects do not have the exact same content checked into and tagged in their source code repository, but most of the time that's not going to matter, and if it does there are methods of dealing with that (which I won't go into now because this is already getting long enough). It's also true that some open source projects do not make their source code repositories public. In that situation we'd just have to live with checking in exploded tarballs into our source code repository. The other point is to get the development of these patches off of the maintainer's hard drive and into a central, public repository. Sure, all of the patches that we apply to the pristine source are stored in the package repository, but that's a very difficult format to work with for anything but applying them to the code. It's especially difficult if the patch has evolved over time and you want to look back at the history of the patch. Have you ever tried to read the diff of a diff? Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From vonbrand at inf.utfsm.cl Sun Jun 10 04:20:05 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 10 Jun 2007 00:20:05 -0400 Subject: Future SCM Technology In-Reply-To: <200706071443.48136.jkeating@redhat.com> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706070723.04824.jkeating@redhat.com> <20070607184141.GB12450@neu.nirvana> <200706071443.48136.jkeating@redhat.com> Message-ID: <2550.1181449205@laptop13.inf.utfsm.cl> Jesse Keating wrote: > On Thursday 07 June 2007 14:41:41 Axel Thimm wrote: > > On Thu, Jun 07, 2007 at 07:23:04AM -0400, Jesse Keating wrote: > > > On Thursday 07 June 2007 06:12:14 Dominik 'Rathann' Mierzejewski wrote: > > > > I, for one, would welcome something similar to svn cp and svn mv, > > > > which allows you to copy and rename files (I'm thinking patches) > > > > while preserving change history. > > > > > > Could we better frame this as "I wish our SCM would allow for renaming > > > and/or copying source controlled files to new names, while preserving the > > > recorded history of the file within the SCM." ? (I just don't want to > > > see a lot of requests be tied to a particular SCM or another, just pure > > > features. git for one doesn't "preserve recorded history for a file", and can't do it by fundamental design (it just records snapshots after changes). It has tools that help in finding out where the stuff you see (presumably) came from. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From dtimms at iinet.net.au Sun Jun 10 04:31:51 2007 From: dtimms at iinet.net.au (David Timms) Date: Sun, 10 Jun 2007 14:31:51 +1000 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <200706090822.48020.jkeating@redhat.com> References: <200706081441.42279.jkeating@redhat.com> <466A0E5E.50201@iinet.net.au> <200706090822.48020.jkeating@redhat.com> Message-ID: <466B7EB7.4000006@iinet.net.au> Jesse Keating wrote: > On Friday 08 June 2007 22:20:14 David Timms wrote: >> The simplest way to do this would be for the iso spin system to perform >> an sha1sum * > SHA1SUM within each directory of an iso spin, and have >> each result inserted into the corresponding directory. > > What is it we do when we implantisomd5 which is used by media check? Can't > you make use of that? I am not sure how you do that - how can you include inside a piece of data a checksum that uses the data {including itself} to calculate the checksum ? {sounds like one for the crytologists}. Perhaps it is outside the data area, but then you have no way to know if the implanted checksum is broken or that data itself {although I imagine it is likely to be the data}. What I am after is a checksum for each file present within the iso, not the result for the whole iso. Is there such a thing already present ? DaveT. From dtimms at iinet.net.au Sun Jun 10 04:37:28 2007 From: dtimms at iinet.net.au (David Timms) Date: Sun, 10 Jun 2007 14:37:28 +1000 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <1181379852.7843.6.camel@rousalka.dyndns.org> References: <200706081441.42279.jkeating@redhat.com> <466A0E5E.50201@iinet.net.au> <1181379852.7843.6.camel@rousalka.dyndns.org> Message-ID: <466B8008.4000900@iinet.net.au> Nicolas Mailhot wrote: > Le samedi 09 juin 2007 ? 12:20 +1000, David Timms a ?crit : > >> The simplest way to do this would be for the iso spin system to perform >> an sha1sum * > SHA1SUM within each directory of an iso spin, and have >> each result inserted into the corresponding directory. > > 1. you don't want many scattered checksum files, you want one file for > the whole disk, so users can find/filter it easily (use find to get a > recursive file list, sort/filter, checksum it) That would be nice, but the standard tools don't do this AFAIK ? {no recursive option ?} > 2. burn apps suchs as brasero/k3b? already generete this file if asked > (using md5 which is IMHO a mistake today) It is done as far as I understand for the whole image {perhaps excluding the header where this gets embedded ?}. > 3. you want this checksum file signed Yes. This would already be done by the checksum process that is already in place - signed sha1sum of the whole .iso file, published along side the iso file. DaveT. From tibbs at math.uh.edu Sun Jun 10 04:44:15 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Jun 2007 23:44:15 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <2241.1181447527@laptop13.inf.utfsm.cl> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181252698.4070.234.camel@localhost.localdomain> <2241.1181447527@laptop13.inf.utfsm.cl> Message-ID: >>>>> "HHvB" == Horst H von Brand writes: HHvB> Toshio Kuratomi wrote: >> Having things in an exploded tree DRCS makes it easy to work >> locally because you can make a local feature branch of the Fedora >> exploded tree, HHvB> Why should all this be in Fedora repos? This smells an awful lot HHvB> like centralized SCM (CVS-like) mentality. Actually, I think the point is precisely that it doesn't have to be in the Fedora repos. I can make a local feature branch without even have to access the Fedora server. So it's exactly the opposite of a centralized SCM mentality. - J< From bojan at rexursive.com Sun Jun 10 04:29:43 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sun, 10 Jun 2007 04:29:43 +0000 (UTC) Subject: The Future of Fedora Package Management and the RPM Philosophy References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181400854.3691.41.camel@lt21223.campus.dmacc.edu> Message-ID: Jeffrey C. Ollie ocjtech.us> writes: > What this > discussion has been about is bringing patch development out of a hidden > corner the package maintainer's laptop hard drive and into a centrally > maintained, publicly available version control repository. I thought that all patches already existed in CVS. What's hidden? > Apparently you have never used a version control system that properly > supports branching and merging. CVS and Subversion do not count. Git, > Mercurial, and Bazaar are ones that do and make it easy (in some cases > trivial) to maintain code/patches in branches and then rebase the > patches to new versions of the upstream code as they are released. With > the proper discipline, keeping track of the changes that we have made to > the pristine code isn't really a problem. You are right, I didn't. I saw Linus talk about git and I kind of get the bit about identifying what's what, but I'm still not sure how such a system knows how to redo the patch so it applies to a completely new version of the software. But maybe it does - I never used it, so I really don't know. > However, I don't want this thread to descend into a debate about the > best revision control system. We need to be discussing things at a > higher level right now. No, that's OK. I think Fedora should switch version control software anyway. CVS most definitely had its day. -- Bojan From jeff at ocjtech.us Sun Jun 10 04:57:55 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 09 Jun 2007 23:57:55 -0500 Subject: RFR: GIT Package VCS In-Reply-To: <2241.1181447527@laptop13.inf.utfsm.cl> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <4666C1F4.3010500@redhat.com> <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181252698.4070.234.camel@localhost.localdomain> <2241.1181447527@laptop13.inf.utfsm.cl> Message-ID: <1181451475.3691.140.camel@lt21223.campus.dmacc.edu> Horst, I'm not going to quote your email but I'm going to reply in summary to the points you raise: 1. Fedora isn't just a downstream, we're an upstream too - RHEL, OLPC, and several other projects take Fedora and make changes on top of our changes to suit their particular needs. 2. Patches stored as binary blobs in CVS are very ugly to deal with if you need to update that patch as conditions change. 3. Patches stored as binary blobs in CVS loose the history that went into developing those patches. Sure, some patches are trivial, but there are some patches in our packages that are HUGE and have had a complex history. Having the history that went into developing those patches is immensely useful. 4. There are some patches in our packages that will never be sent upstream because they represent Fedora-specific policy (e.g. changes to default values in configuration files). The history of these files certainly. 5. You won't be maintainer of a package forever, and you likely won't be the maintainer of packages in downstream products either. Putting the history of how you developed your patches in a central, public location is make the job of the next person that has to touch your packages much much easier. 6. Regarding slow (or non-existent) network connections in much of the world: unfortunately, the reality is that the people in these areas probably aren't contributors to Fedora anyway. Just keeping up with mailing list traffic that you at least need to skim over to be an effective Fedora contributor is going to give a dial-up connection some serious trouble. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Sun Jun 10 05:06:43 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Jun 2007 01:06:43 -0400 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <1181418524.4813.27.camel@localhost.localdomain> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> <20070609194220.GA8740@wolff.to> <1181418524.4813.27.camel@localhost.localdomain> Message-ID: <1181452003.4534.21.camel@rivendell> On Sat, 2007-06-09 at 15:48 -0400, Christopher Blizzard wrote: > On Sat, 2007-06-09 at 14:42 -0500, Bruno Wolff III wrote: > > > > You guys should buy a bus. You can have people playing LAN games for > > fun > > during the trip. The reduced hassel and more fun would make up for the > > longer travel time. > > > > I remember suggesting such a thing for one of our world wide corporate > meetings that was being held in Raleigh. Back when we were still small > enough to _do_ a world wide meeting. :) > > Not sure why we didn't do it, but we didn't. Maybe we should think hard about not doing anything which drastically pushes up our carbon production. Flying people all over the place is not the best example to be setting. It might be a good idea to see about tying a few good locations together using some genre of video teleconferencing. If we can get that working better then the hackfests wouldn't be quite as damaging as we wing people from one side of the world to the other. -sv From jeff at ocjtech.us Sun Jun 10 05:17:13 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sun, 10 Jun 2007 00:17:13 -0500 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181400854.3691.41.camel@lt21223.campus.dmacc.edu> Message-ID: <1181452633.3691.153.camel@lt21223.campus.dmacc.edu> On Sun, 2007-06-10 at 04:29 +0000, Bojan Smojver wrote: > Jeffrey C. Ollie ocjtech.us> writes: > > > What this > > discussion has been about is bringing patch development out of a hidden > > corner the package maintainer's laptop hard drive and into a centrally > > maintained, publicly available version control repository. > > I thought that all patches already existed in CVS. What's hidden? Yes, the patches are all there in CVS. But they are stored there as binary blobs, which is a very difficult format to deal with when you want to update it for whatever reason (so that it applies to a new version of the upstream code, to fix a bug in the patch itself, etc.). Basically, the patches stored in CVS throw away all of the history that went into developing them. Once you know more about source code control you'll understand that having the history that went into a patch (and into the source code that the patch is for) lets you do amazing things with patches, like rebase them so that they apply to new versions of released software. > > Apparently you have never used a version control system that properly > > supports branching and merging. CVS and Subversion do not count. Git, > > Mercurial, and Bazaar are ones that do and make it easy (in some cases > > trivial) to maintain code/patches in branches and then rebase the > > patches to new versions of the upstream code as they are released. With > > the proper discipline, keeping track of the changes that we have made to > > the pristine code isn't really a problem. > > You are right, I didn't. I saw Linus talk about git and I kind of get the bit > about identifying what's what, but I'm still not sure how such a system knows > how to redo the patch so it applies to a completely new version of the software. > But maybe it does - I never used it, so I really don't know. Branches are the key. I'd recommend taking the time to learn one of the distributed revision control systems. Once you've grokked the concepts of branching and merging you'll wonder how you ever did without them. > > However, I don't want this thread to descend into a debate about the > > best revision control system. We need to be discussing things at a > > higher level right now. > > No, that's OK. I think Fedora should switch version control software anyway. CVS > most definitely had its day. CVS should have been dead long ago, but like Bernie[1] it just doesn't seem to want to die. [1] http://www.imdb.com/title/tt0098627/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sun Jun 10 05:43:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 11:13:18 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1181294808.3782.0.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> Message-ID: <466B8F76.1080301@fedoraproject.org> Stefan Held wrote: > Am Donnerstag, den 07.06.2007, 10:57 -0400 schrieb Bill Nottingham: > >> fedora-logos is mentioned by name in the EULA. I'd prefer to keep it simple >> (especially if we're deprecating the theming of grub) > > I would prefer to have such a package so that those of us who want the > "normal" grub behavior back could do that. Behavior or look? Behavior is controlled by fedora-logos package. Rahul From sundaram at fedoraproject.org Sun Jun 10 05:43:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 11:13:34 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1181294808.3782.0.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> Message-ID: <466B8F86.1010003@fedoraproject.org> Stefan Held wrote: > Am Donnerstag, den 07.06.2007, 10:57 -0400 schrieb Bill Nottingham: > >> fedora-logos is mentioned by name in the EULA. I'd prefer to keep it simple >> (especially if we're deprecating the theming of grub) > > I would prefer to have such a package so that those of us who want the > "normal" grub behavior back could do that. Behavior or look? Behavior is not controlled by fedora-logos package. Rahul From ssorce at redhat.com Sat Jun 9 20:32:27 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 09 Jun 2007 16:32:27 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <20070609181658.GC24785@neu.nirvana> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181347083.12195.5.camel@neutron.verbum.private> <20070609091311.A9924@xos037.xos.nl> <20070609173335.GA22957@neu.nirvana> <1181411011.3749.166.camel@willson> <20070609181658.GC24785@neu.nirvana> Message-ID: <1181421147.3749.169.camel@willson> On Sat, 2007-06-09 at 20:16 +0200, Axel Thimm wrote: > On Sat, Jun 09, 2007 at 01:43:31PM -0400, Simo Sorce wrote: > > On Sat, 2007-06-09 at 19:33 +0200, Axel Thimm wrote: > > > On Sat, Jun 09, 2007 at 09:13:11AM +0200, Jos Vos wrote: > > > > On Fri, Jun 08, 2007 at 07:58:03PM -0400, Colin Walters wrote: > > > > > > > > > - Don't make me increment integers (Release); this is > > > > > what computers (i.e. the build system) are for > > > > > > > > Whatever you suggest to change, be sure that the final spec file > > > > contains a real integer, not a macro defined in the build system > > > > or so. > > > > > > > > It's already very discussable that %{?dist} is now used in the > > > > release tags. I know this was introduced to overcome a - what > > > > you can maybe call - shortcome in RPM, but it has its drawbacks > > > > and every use of non-standard externally defined macros violates > > > > the principles of RPM, being able to reproduce package building. > > > > > > But the disttag is designed in such a way as to also work when there > > > is no definition for it. > > > > Wouldn't it make sense to add a make newrelease command that greps the > > existing tag from cvs and retrieves the current release number. > > Then use sed/awk/perl/whatever to increment it (in a sensible way) and > > writes it down into the spec, and, while there, also creates a new > > changelog entry with the current date and person/email information. > > FWIW these things are all done in the appropriate emacs mode. Don't now > if there is a vim mode as well, if not, then maybe we need one. I don't think emacs modes or vim modes are appropriate here, sure they will be really handy for people that use either emacs or vim (if they get to know) but they will not help people that use other editors, that's why I propose to make it a Makefile option (and visible with make help). Simo. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From bojan at rexursive.com Sun Jun 10 06:17:39 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sun, 10 Jun 2007 06:17:39 +0000 (UTC) Subject: The Future of Fedora Package Management and the RPM Philosophy References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181400854.3691.41.camel@lt21223.campus.dmacc.edu> <1181452633.3691.153.camel@lt21223.campus.dmacc.edu> Message-ID: Jeffrey C. Ollie ocjtech.us> writes: > Once you know more about source code control you'll understand that > having the history that went into a patch (and into the source code that > the patch is for) lets you do amazing things with patches, like rebase > them so that they apply to new versions of released software. Just reading Git crash course for SVN lusers (http://git.or.cz/course/svn.html) and they are taking about conflicts during a merge: "[...] if any changes conflicted, git merge will report them and let you resolve them, updating the rest of the tree already to the result state; you can git commit when you resolve the conflicts." To me, this reads as if each maintainer still needs to understand the new upstream code in order to rework the patches so that they apply. Is that what you mean by "rebase"? Fix them by hand so that they actually work? I get the point about branch history etc. -- Bojan From j.w.r.degoede at hhs.nl Sun Jun 10 06:43:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 10 Jun 2007 08:43:16 +0200 Subject: [Fwd: [Fedora Update] [comment] blobAndConquer-0.91-1.fc7] Message-ID: <466B9D84.9040905@hhs.nl> Hi All, See the forward comment, I could just push the mark as stable button, but I thought the whole idea of updates-testing was that some QA would be done and that the QA-team would them do the marking as stable. So what is the procedure for this? Regards, Hans -------------- next part -------------- An embedded message was scrubbed... From: updates at fedoraproject.org Subject: [Fedora Update] [comment] blobAndConquer-0.91-1.fc7 Date: Sat, 09 Jun 2007 18:28:26 -0700 Size: 2311 URL: From j.w.r.degoede at hhs.nl Sun Jun 10 06:48:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 10 Jun 2007 08:48:58 +0200 Subject: The updates firehose In-Reply-To: <200706092019.38404.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070609201515.GA19734@wolff.to> <200706092019.38404.jkeating@redhat.com> Message-ID: <466B9EDA.1060205@hhs.nl> Jesse Keating wrote: > On Saturday 09 June 2007 16:15:15 Bruno Wolff III wrote: >> Is it possible to provide meta data to yum with some sort of indication >> of what the update does. Maybe a choice from Security, Critical (e.g. >> data loss) bug, Bug fix, New features. Then you could tell yum to only grab >> security and critical bug fixes if you didn't want to download lots of >> updates. > > Actually we're going to re-implement that. We had it for the Core updater > tool, Luke will hook us up with it for bodhi soon. It'll contain the > contents of the "notes" you put into bodhi so that when you look at a list of > updates in pup you can see what the update is for. However when you're > staring down 60+ updates (or 90 or 120 depending on when you look) how many > people are actually going to look through or are they going to just apply and > hope for the best? > > I don't know if this is a real problem or not, just an observation on the > weekend (: > Do keep in mind when assessing wether this is a real problem or not, that many people will not have all updated packages installed, in the case of formaer extras packages many people will actually not have them installed, and thus they won't notice a thing about them being updated. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jun 10 06:57:26 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 10 Jun 2007 08:57:26 +0200 Subject: To Require yelp or not to require yelp Message-ID: <466BA0D6.8050603@hhs.nl> Hi all, 2 days ago I got 4 bugs requesting me to add Requires: yelp to packages using it for their help system. So I issued 3 rawhide updates (one bug was a false positive). However yesterday I received a comment in all 4 bugs to please not Require yelp ????? See for example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243330 Well Hurray! Thats just brilliant communication (not). So which way will it be tomorrow? Hence I'm bringing this issue here for debating, as I don't want to have to keep following the trend of the day in this. Can we please make up our mind on this people? My 2 cents: I actually didn't have yelp installed and without it the help menu entry of the 3 updates apps didn't do anything, it didn't even throw an error. So I do believe that Requiring yelp is the right thing, as clicking on help without anything happying is a bug in my view. If OLPC or some other downstream really doesn't want yelp, they should have some other package providing it, call it fake-yelp for all I care. Not Requiring: yelp is not the answer IMHO. Regards, Hans From caillon at redhat.com Sun Jun 10 06:51:37 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 10 Jun 2007 02:51:37 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <466BA0D6.8050603@hhs.nl> References: <466BA0D6.8050603@hhs.nl> Message-ID: <466B9F79.2040601@redhat.com> Hans de Goede wrote: > Hi all, > > 2 days ago I got 4 bugs requesting me to add Requires: yelp to packages > using it for their help system. > > So I issued 3 rawhide updates (one bug was a false positive). > > However yesterday I received a comment in all 4 bugs to please not > Require yelp ????? Here's another way of looking at it: why should 100+ gnome packages require something that should be installed as a base part of GNOME? If we want to make it a requires, I'd say that gnome-desktop or something ought to require it, not every f-ing package. From mschwendt.tmp0701.nospam at arcor.de Sun Jun 10 07:04:24 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 10 Jun 2007 09:04:24 +0200 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> Message-ID: <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote: > The many updates are really Fedora's strength, ... and also one of its weaknesses, since the users don't like it at all if an update breaks something. From mschwendt.tmp0701.nospam at arcor.de Sun Jun 10 07:22:25 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 10 Jun 2007 09:22:25 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <466B9F79.2040601@redhat.com> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> Message-ID: <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> On Sun, 10 Jun 2007 02:51:37 -0400, Christopher Aillon wrote: > Hans de Goede wrote: > > Hi all, > > > > 2 days ago I got 4 bugs requesting me to add Requires: yelp to packages > > using it for their help system. > > > > So I issued 3 rawhide updates (one bug was a false positive). > > > > However yesterday I received a comment in all 4 bugs to please not > > Require yelp ????? > > Here's another way of looking at it: why should 100+ gnome packages > require something that should be installed as a base part of GNOME? If > we want to make it a requires, I'd say that gnome-desktop or something > ought to require it, not every f-ing package. What happens if you install the app in KDE, XFCE or a desktop env other than GNOME? Will the help menu fail silently? If an application specifically needs yelp (spelled out in its code or config) it ought to require yelp or give an error dialog if yelp is missing. If, on the contrary, it only uses yelp via some GNOME component, there also ought to be an error dialog if yelp is missing. From caillon at redhat.com Sun Jun 10 07:19:51 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 10 Jun 2007 03:19:51 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <466BA617.9070408@redhat.com> Michael Schwendt wrote: > On Sun, 10 Jun 2007 02:51:37 -0400, Christopher Aillon wrote: > >> Hans de Goede wrote: >> > Hi all, >> > >> > 2 days ago I got 4 bugs requesting me to add Requires: yelp to packages >> > using it for their help system. >> > >> > So I issued 3 rawhide updates (one bug was a false positive). >> > >> > However yesterday I received a comment in all 4 bugs to please not >> > Require yelp ????? >> >> Here's another way of looking at it: why should 100+ gnome packages >> require something that should be installed as a base part of GNOME? If >> we want to make it a requires, I'd say that gnome-desktop or something >> ought to require it, not every f-ing package. > > What happens if you install the app in KDE, XFCE or a desktop env other > than GNOME? Will the help menu fail silently? > > If an application specifically needs yelp (spelled out in its code or > config) it ought to require yelp or give an error dialog if yelp is > missing. If, on the contrary, it only uses yelp via some GNOME component, > there also ought to be an error dialog if yelp is missing. You'd still need the gnome libraries which should pull in the right stuff. From frank-buettner at gmx.net Sun Jun 10 07:39:44 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 10 Jun 2007 09:39:44 +0200 Subject: buid system for FC5-FC6 bocken? Message-ID: <466BAAC0.3070308@gmx.net> Hello, at now it is impossible to build packages. Are jobs freeze and will be killed after 30 minutes. At the log files you can see this: Waiting for repository to unlock before starting the build... Job waited too long for repo to unlock. Killing it... Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From mschwendt.tmp0701.nospam at arcor.de Sun Jun 10 08:05:05 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 10 Jun 2007 10:05:05 +0200 Subject: buid system for FC5-FC6 bocken? In-Reply-To: <466BAAC0.3070308@gmx.net> References: <466BAAC0.3070308@gmx.net> Message-ID: <20070610100505.ae7ba0e0.mschwendt.tmp0701.nospam@arcor.de> On Sun, 10 Jun 2007 09:39:44 +0200, Frank B?ttner wrote: > Hello, > at now it is impossible to build packages. > Are jobs freeze and will be killed after 30 minutes. > At the log files you can see this: > > Waiting for repository to unlock before starting the build... > Job waited too long for repo to unlock. Killing it... I've kicked the build master, and job 34097 has completed. I cannot requeue other people's failed build-jobs, however. You need to do this yourself. From dominik at greysector.net Sun Jun 10 08:48:16 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 10 Jun 2007 10:48:16 +0200 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <20070610084816.GC30166@ryvius.pekin.waw.pl> On Saturday, 09 June 2007 at 22:05, Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. That's normal, I'd say. Same thing happened right after FC6 release. > Seriously. We're drowning our users in updates. Are all of them really > necessary? Fedora is known for having the latest software. I'm actually happy to see those, because it means you haven't killed maintainers' willingness to keep updating their packages despite adding new hoops to jump through. > I feel like we've got this culture of update whatever/whenever coming > from Extras where it was just fire and forget. I feel like you're saying that Core's "culture" (whatever you mean by that) should have precedence over Extras' and that "your way" is better than "our way". I assure you that Extras maintainers didn't just "fire and forget" their updates. They were tested. Yes, some accidents happened, but that was the price of greater freedom the maintainers used to have. So please don't try to discourage those who managed to put up with all the new obstacles any further. > While that might be fun for the maintainer, is it fun for the user? Is > it fun for the user with a slow connection? Presto. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Sun Jun 10 08:57:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 10 Jun 2007 10:57:00 +0200 Subject: f7 images for mass production In-Reply-To: <200706092013.19675.jkeating@redhat.com> References: <200706091529.50159.jkeating@redhat.com> <20070609215002.GB3873@neu.nirvana> <200706092013.19675.jkeating@redhat.com> Message-ID: <20070610085700.GA6255@neu.nirvana> On Sat, Jun 09, 2007 at 08:13:16PM -0400, Jesse Keating wrote: > On Saturday 09 June 2007 17:50:02 Axel Thimm wrote: > > It ain't as bad, I've been using anaconda with updated trees since > > ages for PXE booting including updates, and many other large site > > admins have been doing the same for security concerns. > > > > I guess the media spins are not that different than creating PXE > > trees concerning anaconda. > > Ah, but you're mostly just refreshing the repodata no? Are you actually > building new install images with buildinstall? No need to in 99% of what I've been doing. And the 1% was the transition to repomd. Why should you buildinstall if there wasn't a bug in anaconda? -- 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 frank-buettner at gmx.net Sun Jun 10 09:07:04 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 10 Jun 2007 11:07:04 +0200 Subject: buid system for FC5-FC6 bocken? In-Reply-To: <20070610100505.ae7ba0e0.mschwendt.tmp0701.nospam@arcor.de> References: <466BAAC0.3070308@gmx.net> <20070610100505.ae7ba0e0.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <466BBF38.4090209@gmx.net> Michael Schwendt schrieb: > On Sun, 10 Jun 2007 09:39:44 +0200, Frank B?ttner wrote: > >> Hello, >> at now it is impossible to build packages. >> Are jobs freeze and will be killed after 30 minutes. >> At the log files you can see this: >> >> Waiting for repository to unlock before starting the build... >> Job waited too long for repo to unlock. Killing it... > > I've kicked the build master, and job 34097 has completed. > > I cannot requeue other people's failed build-jobs, however. > You need to do this yourself. > Yes, all is now ok again. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Sun Jun 10 09:24:09 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 10 Jun 2007 12:24:09 +0300 Subject: To Require yelp or not to require yelp In-Reply-To: <466BA617.9070408@redhat.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> Message-ID: <200706101224.09692.ville.skytta@iki.fi> On Sunday 10 June 2007, Christopher Aillon wrote: > Michael Schwendt wrote: > > > > If an application specifically needs yelp (spelled out in its code or > > config) it ought to require yelp or give an error dialog if yelp is > > missing. If, on the contrary, it only uses yelp via some GNOME component, > > there also ought to be an error dialog if yelp is missing. +1 > You'd still need the gnome libraries which should pull in the right stuff. yelp comes with a dependency chain. In the case of dia, adding a dependency on yelp (whether directly or indirectly if the dep is in some gnome lib packages), that right stuff would result in the need to additionally install yelp, desktop-file-utils, docbook-dtds, fedora-bookmarks, firefox, gnome-doc-utils, libXt, libbeagle, nspr, nss, openjade, opensp, scrollkeeper, sgml-common, and xml-common. In some cases the number of additional dependencies is probably smaller and in some others even larger. Either way, various GNOME things already suffer from dependency bloat, please let's try to work towards reducing, not adding to it. I think having yelp installed by default (if GNOME is selected) and fixing apps to output sensible error dialogs if it's missing, and not adding the dependencies in packages [0] would be an ok solution for this case. [0] Requires(hint)/Suggests support in depsolvers could also help here. From nicolas.mailhot at laposte.net Sun Jun 10 09:30:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 10 Jun 2007 11:30:47 +0200 Subject: The updates firehose In-Reply-To: <20070610013123.GE26897@lists.us.dell.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> Message-ID: <1181467847.28023.6.camel@rousalka.dyndns.org> Le samedi 09 juin 2007 ? 20:31 -0500, Matt Domsch a ?crit : > You can add your local private mirror to mirrormanager, add a netblock > that covers your address space, and all your clients will then pull > from your local mirror rather than public mirrors, with no change on > the clients. That's nice but if the infrastructure was friendlier to proxies most big entities wouldn't have to setup any mirror but could just rely on their existing proxy infrastructure - mirrormanager should return data with high expire values and/or detect squid/mod_proxy whatever and direct it to a static mirror - yum should generate proxy-friendly metadata -- 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 sundaram at fedoraproject.org Sun Jun 10 09:34:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 15:04:32 +0530 Subject: The updates firehose In-Reply-To: <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <466BC5A8.4000707@fedoraproject.org> Michael Schwendt wrote: > On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote: > >> The many updates are really Fedora's strength, > > ... and also one of its weaknesses, since the users don't like it at all > if an update breaks something. This is one thing I suspect is being lost in all the talk about trust and freedom. Maintainer's freedom doesn't mean much if there is a avalanche of updates where updates-testing time can be reduced or skipped any time and where every update increases the chances of breaking stuff Anyone wants to write a policy on updates? Rahul From nicolas.mailhot at laposte.net Sun Jun 10 09:48:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 10 Jun 2007 11:48:41 +0200 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <466B8008.4000900@iinet.net.au> References: <200706081441.42279.jkeating@redhat.com> <466A0E5E.50201@iinet.net.au> <1181379852.7843.6.camel@rousalka.dyndns.org> <466B8008.4000900@iinet.net.au> Message-ID: <1181468921.28023.13.camel@rousalka.dyndns.org> Le dimanche 10 juin 2007 ? 14:37 +1000, David Timms a ?crit : > Nicolas Mailhot wrote: > > Le samedi 09 juin 2007 ? 12:20 +1000, David Timms a ?crit : > > > >> The simplest way to do this would be for the iso spin system to perform > >> an sha1sum * > SHA1SUM within each directory of an iso spin, and have > >> each result inserted into the corresponding directory. > > > > 1. you don't want many scattered checksum files, you want one file for > > the whole disk, so users can find/filter it easily (use find to get a > > recursive file list, sort/filter, checksum it) > That would be nice, but the standard tools don't do this AFAIK ? {no > recursive option ?} so you use find and friends to generate a list for the checksumming tool (testing for symlinks, spaces, etc). Though a standard receipe would be nice > > 2. burn apps suchs as brasero/k3b? already generete this file if asked > > (using md5 which is IMHO a mistake today) > It is done as far as I understand for the whole image No. On the file list > > 3. you want this checksum file signed > Yes. This would already be done by the checksum process that is already > in place - signed sha1sum of the whole .iso file, published along side > the iso file. Useless. Either you want file-level checksumming (implying you want to use the disk if you don't need a damaged part) and everything done at the iso level can't be used, or you want to check the whole disk, and file-level checksums are overkill -- 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 Sun Jun 10 09:51:07 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 10 Jun 2007 11:51:07 +0200 Subject: Web based interface for custom spins In-Reply-To: <466B6C82.5050902@fedoraproject.org> References: <466B6C82.5050902@fedoraproject.org> Message-ID: <1181469067.28023.15.camel@rousalka.dyndns.org> Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : > Having a web interface would allow anyone to select the package groups > and individual packages and get a ISO image for download. I posted to > fedora-infrastructure list before but we need a web app before talking > about deploying it. Yay for killing bandwidth -- 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 opensource at till.name Sun Jun 10 09:52:41 2007 From: opensource at till.name (Till Maas) Date: Sun, 10 Jun 2007 11:52:41 +0200 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <1181468921.28023.13.camel@rousalka.dyndns.org> References: <466B8008.4000900@iinet.net.au> <1181468921.28023.13.camel@rousalka.dyndns.org> Message-ID: <200706101152.43378.opensource@till.name> On So Juni 10 2007, Nicolas Mailhot wrote: > so you use find and friends to generate a list for the checksumming tool > (testing for symlinks, spaces, etc). Though a standard receipe would be > nice The following should do the job: $ find -type f -print0 | xargs -0 md5sum Regards, Till From sundaram at fedoraproject.org Sun Jun 10 09:53:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 15:23:33 +0530 Subject: Web based interface for custom spins In-Reply-To: <1181469067.28023.15.camel@rousalka.dyndns.org> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> Message-ID: <466BCA1D.5060601@fedoraproject.org> Nicolas Mailhot wrote: > Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : > >> Having a web interface would allow anyone to select the package groups >> and individual packages and get a ISO image for download. I posted to >> fedora-infrastructure list before but we need a web app before talking >> about deploying it. > > Yay for killing bandwidth Ignoring the obvious end user benefits? Rahul From jfrieben at gmx.de Sun Jun 10 09:54:34 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 10 Jun 2007 11:54:34 +0200 Subject: The updates firehose In-Reply-To: <200706092223.13366.opensource@till.name> References: <200706091605.00638.jkeating@redhat.com> <200706092223.13366.opensource@till.name> Message-ID: <20070610095434.83350@gmx.net> > yum-presto will help a lot more. But maybe there should be also delta-xml > files for the repository metadata, because it takes very long to download > these, too, with a slow connection. > > Regards, > Till Right, this is a very serious point. Right now, the meta data in my /var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to download via a standard analog modem connection! -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger From j.w.r.degoede at hhs.nl Sun Jun 10 10:11:21 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 10 Jun 2007 12:11:21 +0200 Subject: The updates firehose In-Reply-To: <466BC5A8.4000707@fedoraproject.org> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> Message-ID: <466BCE49.9090107@hhs.nl> Rahul Sundaram wrote: > Michael Schwendt wrote: >> On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote: >> >>> The many updates are really Fedora's strength, >> >> ... and also one of its weaknesses, since the users don't like it at all >> if an update breaks something. > > This is one thing I suspect is being lost in all the talk about trust > and freedom. Maintainer's freedom doesn't mean much if there is a > avalanche of updates where updates-testing time can be reduced or > skipped any time and where every update increases the chances of > breaking stuff > Here we go again. Before regulating everything to dead, first please try to objectively measure that which you are trying to regulate, then analyze those objective measurements, deducting whats working well and what isn't and then try to steer things, using little adjustments so that what isn't working well becomes better without causing regressions all over the place. More to the point, the last couple of releases extras updates and even extras rolling release model have been causing not all that many upgrade issues / pains. Yes there are things to improve, like not allowing updates which will result in broken dep chains. But overall extras didn't do all that bad. Most of time there is an update which causes all kinda troubles its a former core update and not a former extras update. Regards, Hans (who has queued only 2 updates on 125+ packages, since F-7 release). From nicolas.mailhot at laposte.net Sun Jun 10 09:58:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 10 Jun 2007 11:58:27 +0200 Subject: Web based interface for custom spins In-Reply-To: <466BCA1D.5060601@fedoraproject.org> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> Message-ID: <1181469507.28023.18.camel@rousalka.dyndns.org> Le dimanche 10 juin 2007 ? 15:23 +0530, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: > > Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : > > > >> Having a web interface would allow anyone to select the package groups > >> and individual packages and get a ISO image for download. I posted to > >> fedora-infrastructure list before but we need a web app before talking > >> about deploying it. > > > > Yay for killing bandwidth > > Ignoring the obvious end user benefits? There are no obvious end-user benefits if an infrastructure that could handle lots of users melts under a few doing iso spins (I suppose you want dvd images in there too right?) -- 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 buildsys at redhat.com Sun Jun 10 09:58:44 2007 From: buildsys at redhat.com (Build System) Date: Sun, 10 Jun 2007 05:58:44 -0400 Subject: rawhide report: 20070610 changes Message-ID: <200706100958.l5A9wi75014233@porkchop.devel.redhat.com> New package glump A small web application to glue files from multiple sources Updated Packages: agave-0.4.2-3.fc8 ----------------- * Sat Jun 09 2007 Aurelien Bompard 0.4.2-3 - Require yelp for the help system (#243375) audacious-plugins-1.3.5-1.fc8 ----------------------------- * Sat Jun 09 2007 Ralf Ertzinger 1.3.5-1.fc8 - Update to 1.3.5 cairo-1.4.8-1.fc8 ----------------- * Sat Jun 09 2007 Behdad Esfahbod 1.4.8-1 - Update to 1.4.8 * Tue May 01 2007 Carl Worth 1.4.6-1 - Update to 1.4.6 * Mon Apr 16 2007 Carl Worth 1.4.4-1 - Update to 1.4.4 dia-1:0.96.1-1.fc8 ------------------ * Sat Jun 09 2007 Hans de Goede 1:0.96.1-1 - New upstream release 0.96.1 - Add yelp Requires so that the help will always work (bz 243330) emelfm2-0.3.4-1.fc8 ------------------- * Wed Mar 21 2007 Christoph Wickert - 0.3.4-1 - Update 0.3.4. - Enable support for inotify empathy-0.7-1.fc8 ----------------- * Sat Jun 09 2007 David Nielsen - 0.7-1 - bump to 0.7 epiphany-extensions-2.19.2-5 ---------------------------- * Sat Jun 09 2007 Peter Gordon - 2.19.2-5 - Revert previous Yelp dependency addition. It's in the default install (via comps) and the only bad thing to happen if it's not available is that clicking the "Help" option simply does nothing. It's not a strict requirement in this case. * Fri Jun 08 2007 Peter Gordon - 2.19.2-4 - Add yelp dependency to ensure that its built-in "Help" functionality works as expected. (Resolves bug 243378; Thanks to Matej Cepl for his script.) gnome-commander-1.2.4-2.fc8 --------------------------- * Sat Jun 09 2007 Mamoru Tasaka - 1.2.4-2 - Add missing BR libgsf-devel * Sat Jun 09 2007 Mamoru Tasaka - 1.2.4-1 - Update to 1.2.4 - Support python chmlib libiptcdata - From upstream: Sun Feb 4 2007 Piotr Eljasiak - added libgsf dependencies Wed Jan 30 2007 Piotr Eljasiak - added build and runtime deps for python and gnome-python2-gnomevfs gnomebaker-0.6.0-3.fc8 ---------------------- * Sat Jun 09 2007 Brian Pepple - 0.6.0-3 - Add requires on yelp. (#243391) gnomesword-2.2.3-3.fc8 ---------------------- * Sat Jun 09 2007 Deji Akingunola - 2.2.3-3 - Require 'yelp' for the Help menu (BZ #243395) - Remove extraneous key from the desktop file gossip-0.26-2.fc8 ----------------- * Sat Jun 09 2007 Brian Pepple - 0.26-2 - Add requires on yelp. (#243398) gramps-2.2.8-3.fc8 ------------------ * Sat Jun 09 2007 Brian Pepple - 2.2.8-3 - Remove depreciated desktop file categories, and add category on gtk. * Sat Jun 09 2007 Brian Pepple - 2.2.8-2 - Add requires on yelp. (#243399) gwget-0.99-1.fc8 ---------------- * Sat Jun 09 2007 Christoph Wickert 0.99-1 - Update to 0.99 - Add support for epiphany 2.19 - Update desktop file * Thu May 17 2007 Christoph Wickert 0.98.2-2 - Rebuild for Fedora 7 - Add support for epiphany 2.18 hunspell-pl-0.20070609-1.fc8 ---------------------------- * Sat Jun 09 2007 Caolan McNamara - 0.20070606-1 - latest version jakarta-commons-collections-0:3.1-9jpp.2.fc7.1 ---------------------------------------------- * Wed Jun 06 2007 Vivek Lakshmanan - 0:3.1-9jpp.2.fc7.1 - Rebuild to make sure directory indexes in INDEX.LIST is not clobbered by redhat-rpm-config's brp-java-repack-jars - Resolves: bug 241245 * Wed Apr 25 2007 Matt Wringe - 0:3.1-9jpp.2 - A couple of spec file cleanups for Fedora Review jakarta-commons-pool-0:1.3-9jpp.2.fc7.1 --------------------------------------- * Thu Jun 07 2007 Vivek Lakshmanan 0:1.3-9jpp.2.fc7.1 - Rebuild to make sure directory indexes in INDEX.LIST is not clobbered by redhat-rpm-config's brp-java-repack-jars - Resolves: bug 241245 * Wed Apr 25 2007 Matt Wringe 0:1.3-9jpp.2 - A couple of minor spec file changes for Fedora review jokosher-0.9-3.fc8 ------------------ * Sat Jun 09 2007 Christopher Brown - 0.9-3 - desktop file fixes * Sat Jun 09 2007 Christopher Brown - 0.9-2 - Add yelp requires - fixes #243402 jrtplib-3.7.1-1.fc8 ------------------- * Sat Jun 09 2007 Jeffrey C. Ollie - 3.7.1-1 - Update to 3.7.1 kernel-2.6.21-1.3218.fc8 ------------------------ * Sat Jun 09 2007 Dave Jones - 2.6.22-rc4-git3 * Fri Jun 08 2007 Roland McGrath - Add spec hacks to enable building alternate vanilla and git-based rpms. - Enable sparse checking in build for F7 and later. * Thu Jun 07 2007 John W. Linville - Re-introduce iwlwifi patch w/ update to version 0.0.24 kvm-27-1.fc8 ------------ * Sat Jun 09 2007 Jeremy Katz - 27-1 - update to kvm-27 lat-1.2.2-3.fc8 --------------- * Sat Jun 09 2007 Paul Howarth 1.2.2-3 - ExcludeArch ppc64 due to missing mono support on that arch (#241911) - Require yelp (#243403) libuser-0.56.3-1 ---------------- * Sat Jun 09 2007 Miloslav Trma?? - 0.56.3-1 - Allow specifying a SASL mechanism (original patch by Simo Sorce) Resolves: #240904 meld-1.1.5-1.fc8 ---------------- * Sat Jun 09 2007 Brian Pepple - 1.1.5-1 - Update to 1.1.5. - Drop gettext patch. fixed upstream. * Sat Jun 09 2007 Brian Pepple - 1.1.4-7 - Add requires on yelp. mod_perl-2.0.3-9.1.fc7 ---------------------- * Fri Jun 08 2007 Joe Orton 2.0.3-9.1.fc7 - add security fix for CVE-2007-1349 * Fri Apr 20 2007 Joe Orton 2.0.3-8 - filter provide of perl(warnings) (#228429) perl-GDGraph-1:1.44-2.fc8 ------------------------- * Sat Jun 09 2007 Jose Pedro Oliveira - 1:1.44-2 - Bumping release (due to dist tag mismatches). * Sat May 05 2007 Jose Pedro Oliveira - 1:1.44-1 - Update to 1.44. perl-Log-Dispatch-2.18-1.fc8 ---------------------------- * Sat Jun 09 2007 Jose Pedro Oliveira - 2.18-1 - Update to 2.18. * Wed Dec 20 2006 Jose Pedro Oliveira - 2.16-1 - Update to 2.16. - Removed perl(IO::String) from the BR list (no longer needed). * Sat Dec 16 2006 Jose Pedro Oliveira - 2.15-2 - New build requirement: perl(IO::String). qalculate-gtk-0.9.5-2.fc8 ------------------------- * Sat Jun 09 2007 Deji Akingunola - 0.9.5-2 - Modify the Name field in the desktop file to distinguish it from that of qalculate-kde (BZ #241024) - Require 'yelp' for the Help menu (BZ #243395) qalculate-kde-0.9.5-2.fc8 ------------------------- * Sat Jun 09 2007 Deji Akingunola - 0.9.5-2 - Modify the Name field in the desktop file to distinguish it from that of qalculate-gtk (BZ #241024) scribes-0.3.2.8-3.fc8 --------------------- * Sat Jun 09 2007 Peter Gordon - 0.3.2.8-3 - Revert previous Yelp dependency addition. It's in the default install (via comps) and the only bad thing to happen if it's not available is that clicking the "Help" option simply does nothing. It's not a strict requirement in this case. * Fri Jun 08 2007 Peter Gordon - 0.3.2.8-2 - Add yelp dependency to ensure that its built-in "Help" functionality works as expected. (Resolves bug 243413; Thanks to Matej Cepl for his script.) wuja-0.0.8-2.fc8 ---------------- * Sat Jun 02 2007 Devan Goodwin 0.0.8-1 - Releasing 0.0.8. xchat-gnome-0.17-6.fc8 ---------------------- * Sat Jun 09 2007 Brian Pepple - 0.17-6 - Add requires on yelp. (#243417) xfce4-datetime-plugin-0.5.0-2.fc8 --------------------------------- * Sat Jun 09 2007 Christoph Wickert - 0.5.0-2 - Multilib fix for desktop file. xfce4-minicmd-plugin-0.4-6.fc8 ------------------------------ * Sat Jun 09 2007 Christoph Wickert - 0.4-6 - Multilib fix for desktop file. xfce4-quicklauncher-plugin-1.9.2-4.fc8 -------------------------------------- * Sat Jun 09 2007 Christoph Wickert - 1.9.2-4 - Multilib fix for desktop file. xfce4-smartbookmark-plugin-0.4.2-4.fc8 -------------------------------------- * Sat Jun 09 2007 Christoph Wickert - 0.4.2-4 - Multilib fix for desktop file. xfce4-websearch-plugin-0.1.1-0.6.20070428svn2704.fc8 ---------------------------------------------------- * Sat Jun 09 2007 Christoph Wickert - 0.1.1-0.6.20070428svn2704 - Multilib fix for desktop file. Broken deps for i386 ---------------------------------------------------------- bdock - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 beryl - 0.2.1-1.fc8.i386 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 gstreamer-plugins-farsight - 0.12.1-2.fc8.i386 requires libjrtp-3.7.0.so gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- bdock - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) beryl - 0.2.1-1.fc8.x86_64 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 emerald - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) gstreamer-plugins-farsight - 0.12.1-2.fc8.x86_64 requires libjrtp-3.7.0.so()(64bit) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) k3b - 1.0.1-2.fc8.x86_64 requires libmpcdec.so.3()(64bit) k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.x86_64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- bdock - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 beryl - 0.2.1-1.fc8.ppc requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gstreamer-plugins-farsight - 0.12.1-2.fc8.ppc requires libjrtp-3.7.0.so gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 k3b - 1.0.1-2.fc8.ppc requires libmpcdec.so.3 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.8-1.fc8.noarch requires livecd-tools syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) beryl - 0.2.1-1.fc8.ppc64 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires aquamarine >= 0:0.2.1 emerald-themes - 0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gstreamer-plugins-farsight - 0.12.1-2.fc8.ppc64 requires libjrtp-3.7.0.so()(64bit) k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.8-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 From nicolas.mailhot at laposte.net Sun Jun 10 10:01:17 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 10 Jun 2007 12:01:17 +0200 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <200706101152.43378.opensource@till.name> References: <466B8008.4000900@iinet.net.au> <1181468921.28023.13.camel@rousalka.dyndns.org> <200706101152.43378.opensource@till.name> Message-ID: <1181469677.28023.22.camel@rousalka.dyndns.org> Le dimanche 10 juin 2007 ? 11:52 +0200, Till Maas a ?crit : > On So Juni 10 2007, Nicolas Mailhot wrote: > > > so you use find and friends to generate a list for the checksumming tool > > (testing for symlinks, spaces, etc). Though a standard receipe would be > > nice > > The following should do the job: > > $ find -type f -print0 | xargs -0 md5sum If you actually try to use it you'll find there are many small problems to take care of (such as sanitizing find output so absolute/relative files names are not embedded in the checksum files) -- 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 abraxis at telkomsa.net Sun Jun 10 10:14:02 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Sun, 10 Jun 2007 12:14:02 +0200 Subject: The updates firehose In-Reply-To: <466BC5A8.4000707@fedoraproject.org> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> Message-ID: <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> On Sun, Jun 10, 2007 at 03:04:32PM +0530, Rahul Sundaram wrote: > Michael Schwendt wrote: > >On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote: > > > >>The many updates are really Fedora's strength, > > > >... and also one of its weaknesses, since the users don't like it at all > >if an update breaks something. > > This is one thing I suspect is being lost in all the talk about trust > and freedom. Maintainer's freedom doesn't mean much if there is a > avalanche of updates where updates-testing time can be reduced or > skipped any time and where every update increases the chances of > breaking stuff > > Anyone wants to write a policy on updates? > And very shortly you're going to be asking for a policy to be written which defines when the maintainers are going to be allowed to have bowel movements, aren't you? The strengths of Fedora are its leading (even bleeding, at times) edge software and its maintainers. I had hoped that the merge would lead to more freedom and faster throughput for new software, but it looks as though we're on the verge of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it worries me) Please folks - if you're going to build a community, make sure that you have only the governance that is necessary and NO MORE! Leave the maintainers (who have been appointed to look after the packages) to do their jobs. Address mistakes and issues on a case-by-case basis and don't hamstring everyone with a bunch of pettifogging rules. -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From opensource at till.name Sun Jun 10 10:20:34 2007 From: opensource at till.name (Till Maas) Date: Sun, 10 Jun 2007 12:20:34 +0200 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <1181469677.28023.22.camel@rousalka.dyndns.org> References: <200706101152.43378.opensource@till.name> <1181469677.28023.22.camel@rousalka.dyndns.org> Message-ID: <200706101220.36967.opensource@till.name> On So Juni 10 2007, Nicolas Mailhot wrote: > Le dimanche 10 juin 2007 ? 11:52 +0200, Till Maas a ?crit : > > $ find -type f -print0 | xargs -0 md5sum > > If you actually try to use it you'll find there are many small problems > to take care of (such as sanitizing find output so absolute/relative > files names are not embedded in the checksum files) I do not understand the problem, when the commandline is invoked in the root directory of the iso, the file paths are all correct, i.e. relative to the root directory of the iso. If one wants to store the checksum file in a subdirectory of the iso, he only needs to run the command from this directory with enough ".." in the search path for find. Regards, Till From fedora at leemhuis.info Sun Jun 10 10:23:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 10 Jun 2007 12:23:42 +0200 Subject: apt-proxy for yum? (Re: The updates firehose) In-Reply-To: <20070610013123.GE26897@lists.us.dell.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> Message-ID: <466BD12E.10403@leemhuis.info> On 10.06.2007 03:31, Matt Domsch wrote: > On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote: >> Christopher Blizzard wrote: >> >>> Are people complaining? >> I don't complain when it happens with my own computer that's >> being updated daily... but it's painful when you update a >> dozen of desktops in the office to F7 and all them want to >> download 500MB worth of updates the first time they boot. >> >> Yes, I could use a local Fedora mirror. And, in fact, >> I do. But then I'd have to customize the yum config on >> all clients to go look there. > > You can add your local private mirror to mirrormanager, add a netblock > that covers your address space, and all your clients will then pull > from your local mirror rather than public mirrors, with no change on > the clients. > > https://admin.fedoraproject.org/mirrormanager > http://fedoraproject.org/wiki/Infrastructure/Mirroring Nice solution. But as a side note to that: I in fact had a local update mirror for Core in the past, but with the Core and Extras merge I don't have one, as the space and download requirements drastically increased. So much that having a local mirror is not worth the trouble if you don't have more then 10 (?) machines with Fedora afaics. So in this regard the merge made things worse for me. What I'd like to have these days is a kind transparent apt-proxy ( http://apt-proxy.sourceforge.net/ ) for yum, that keeps packages in a cache. Sure, squid can help with that, but a more intelligent solution (package still in the repo? only one ppc machine in the network, so don't cache ppc download, ...; package part of standard-install, so keep in in the cache if possible) could do a whole lot better. CU thl From jdieter at gmail.com Sun Jun 10 10:25:49 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 10 Jun 2007 13:25:49 +0300 Subject: The updates firehose In-Reply-To: <20070610095434.83350@gmx.net> References: <200706091605.00638.jkeating@redhat.com> <200706092223.13366.opensource@till.name> <20070610095434.83350@gmx.net> Message-ID: <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> On Sun, 2007-06-10 at 11:54 +0200, Joachim Frieben wrote: > > yum-presto will help a lot more. But maybe there should be also delta-xml > > files for the repository metadata, because it takes very long to download > > these, too, with a slow connection. > > > > Regards, > > Till > > Right, this is a very serious point. Right now, the meta data in my /var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to download via a standard analog modem connection! I'm looking into generating deltas for the xml, but there are a few other things on my plate at the moment. The real issue is that it's not always xml files that we download...sometimes we get sqlite files. What we need is to have a program that uses the modified bsdiff algorithm in deltarpm to generate differences between regular files, not just deltarpms. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Jun 10 10:26:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 10 Jun 2007 12:26:50 +0200 Subject: The updates firehose In-Reply-To: <20070609220107.GD3873@neu.nirvana> References: <200706091605.00638.jkeating@redhat.com> <20070609220107.GD3873@neu.nirvana> Message-ID: <466BD1EA.7020706@leemhuis.info> On 10.06.2007 00:01, Axel Thimm wrote: > On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote: > [...] >> Seriously. We're drowning our users in updates. Are all of them >> really necessary? I feel like we've got this culture of update >> whatever/whenever coming from Extras where it was just fire and >> forget. While that might be fun for the maintainer, is it fun for >> the user? Is it fun for the user with a slow connection? > > I think Fedora's success is partly due to being updated that way. Strong +1 from me to this! CU thl From obi at unixkiste.org Sun Jun 10 10:30:30 2007 From: obi at unixkiste.org (Stefan Held) Date: Sun, 10 Jun 2007 12:30:30 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <466B8F76.1080301@fedoraproject.org> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> Message-ID: <1181471430.7684.3.camel@bigbox.unixkiste.local> Am Sonntag, den 10.06.2007, 11:13 +0530 schrieb Rahul Sundaram: > Behavior or look? Behavior is controlled by fedora-logos package. Both. As in the "Better Boot" Feature described it is prefered to shut down grub output and therefore there will be no grub grafic. But what if i want the default grub behavior (showing a menu) with a graphic back? We should make this optional. And therefore it would be great to have a small fedora-logo-grub.fc8.rpm which does not depend on 1000 rpms afterwards. > Rahul > -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From kanarip at kanarip.com Sun Jun 10 10:36:12 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 10 Jun 2007 12:36:12 +0200 Subject: Web based interface for custom spins In-Reply-To: <466B6C82.5050902@fedoraproject.org> References: <466B6C82.5050902@fedoraproject.org> Message-ID: <466BD41C.5070407@kanarip.com> Rahul Sundaram wrote: > > > Is anyone looking into writing a web interface that can do custom spins > using pungi and livecd-tools in the background? Revisor is useful as a > graphical wrapper but it requires Fedora to be installed already. > > Having a web interface would allow anyone to select the package groups > and individual packages and get a ISO image for download. I posted to > fedora-infrastructure list before but we need a web app before talking > about deploying it. > > There is new effort launched in http://respins.org to provide a forum > and encourage community respins or derivatives of Fedora and they have > expressed a interest in this too. > > Rahul > Rahul, Revisor is aiming to also do a web-interface driven mode. The implicit CLI mode that comes with this is already in Revisor, although we may need to clean it up a little since we haven't been giving it that much love lately. Revisor doesn't necessarily require Fedora to be installed already though, as we have also done successful Fedora spins from a CentOS box. Basically, from where we stand now, we can (or should be able to) run on any RPM/YUM enabled machine. Kind regards, Jeroen van Meeuwen -kanarip From opensource at till.name Sun Jun 10 10:39:56 2007 From: opensource at till.name (Till Maas) Date: Sun, 10 Jun 2007 12:39:56 +0200 Subject: The updates firehose In-Reply-To: <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> References: <200706091605.00638.jkeating@redhat.com> <20070610095434.83350@gmx.net> <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> Message-ID: <200706101239.58845.opensource@till.name> On So Juni 10 2007, Jonathan Dieter wrote: > I'm looking into generating deltas for the xml, but there are a few > other things on my plate at the moment. The real issue is that it's not > always xml files that we download...sometimes we get sqlite files. Is the information in the xml and sqlite files different? Afaik the sqlite files only increase the speed of yum, so when downloading the sqlite files needs more time than processing the xml files, it is better to skip them. Regards, Till From sundaram at fedoraproject.org Sun Jun 10 10:45:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 16:15:25 +0530 Subject: Web based interface for custom spins In-Reply-To: <1181469507.28023.18.camel@rousalka.dyndns.org> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> Message-ID: <466BD645.1070401@fedoraproject.org> Nicolas Mailhot wrote: > Le dimanche 10 juin 2007 ? 15:23 +0530, Rahul Sundaram a ?crit : >> Nicolas Mailhot wrote: >>> Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : >>> >>>> Having a web interface would allow anyone to select the package groups >>>> and individual packages and get a ISO image for download. I posted to >>>> fedora-infrastructure list before but we need a web app before talking >>>> about deploying it. >>> Yay for killing bandwidth >> Ignoring the obvious end user benefits? > > There are no obvious end-user benefits if an infrastructure that could > handle lots of users melts under a few doing iso spins (I suppose you > want dvd images in there too right?) Yes and infrastructure team would have let me know when I posted in that list if there are any issues with bandwidth or anything else. There is no need to be a stop energy assuming there is a problem. A web app once written can be deployed elsewhere too. Rahul From sundaram at fedoraproject.org Sun Jun 10 10:47:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 16:17:04 +0530 Subject: Web based interface for custom spins In-Reply-To: <466BD41C.5070407@kanarip.com> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> Message-ID: <466BD6A8.7090704@fedoraproject.org> Jeroen van Meeuwen wrote: > Rahul, > > Revisor is aiming to also do a web-interface driven mode. The implicit > CLI mode that comes with this is already in Revisor, although we may > need to clean it up a little since we haven't been giving it that much > love lately. That's cool. Any ETA? Revisor doesn't necessarily require Fedora to be installed > already though, as we have also done successful Fedora spins from a > CentOS box. Basically, from where we stand now, we can (or should be > able to) run on any RPM/YUM enabled machine. Right but a web app significantly increases the scope of respins beyond just RPM based Linux systems. Rahul From sundaram at fedoraproject.org Sun Jun 10 10:50:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 16:20:29 +0530 Subject: The updates firehose In-Reply-To: <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> Message-ID: <466BD775.5000902@fedoraproject.org> Neil Thompson wrote: > > And very shortly you're going to be asking for a policy to be written which > defines when the maintainers are going to be allowed to have bowel movements, > aren't you? Completely Unrelated. > > The strengths of Fedora are its leading (even bleeding, at times) edge software > and its maintainers. I had hoped that the merge would lead to more freedom and > faster throughput for new software, but it looks as though we're on the verge > of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it > worries me) Who exactly are you calling that? > Please folks - if you're going to build a community, make sure that you have only > the governance that is necessary and NO MORE! Leave the maintainers (who have been > appointed to look after the packages) to do their jobs. Address mistakes and issues > on a case-by-case basis and don't hamstring everyone with a bunch of pettifogging > rules. Updates policy has been requested before by community folks too. You don't even have to necessarily change your current practises. Just document them explicitly. Rahul From jeevanullas at gmail.com Sun Jun 10 10:51:41 2007 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Sun, 10 Jun 2007 16:21:41 +0530 Subject: python-twisted needs a newer version Message-ID: <1181472701.8369.3.camel@localhost.localdomain> Hi, Do the package maintainer of python-twisted doesn't feels that we need a newer version of it. Right now fedora 7 has 2.4.0-6.fc7 and twisted 2.5 was released in Jan. 2007. Today I was thinking to implement a XMPP client from python but saw that we don't have support for XMPP client in twisted 2.4 and only available in 2.5. Please clarify on this. Thanks From sundaram at fedoraproject.org Sun Jun 10 10:53:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 16:23:25 +0530 Subject: The updates firehose In-Reply-To: <466BCE49.9090107@hhs.nl> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <466BCE49.9090107@hhs.nl> Message-ID: <466BD825.4080101@fedoraproject.org> Hans de Goede wrote: > > More to the point, the last couple of releases extras updates and even > extras rolling release model have been causing not all that many upgrade > issues / pains. Yes there are things to improve, like not allowing > updates which will result in broken dep chains. But overall extras > didn't do all that bad. Most of time there is an update which causes all > kinda troubles its a former core update and not a former extras update. Setting aside the fact that I didn't claim that core packages weren't doing any better, core and extras packages weren't on the same footing for end users before. None of the extras packages were being installed by default or available in the media that limits its impact significantly. Rahul From kanarip at kanarip.com Sun Jun 10 10:57:54 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 10 Jun 2007 12:57:54 +0200 Subject: Web based interface for custom spins In-Reply-To: <1181469507.28023.18.camel@rousalka.dyndns.org> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> Message-ID: <466BD932.5090804@kanarip.com> Nicolas Mailhot wrote: > Le dimanche 10 juin 2007 ? 15:23 +0530, Rahul Sundaram a ?crit : >> Nicolas Mailhot wrote: >>> Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : >>> >>>> Having a web interface would allow anyone to select the package groups >>>> and individual packages and get a ISO image for download. I posted to >>>> fedora-infrastructure list before but we need a web app before talking >>>> about deploying it. >>> Yay for killing bandwidth >> Ignoring the obvious end user benefits? > > There are no obvious end-user benefits if an infrastructure that could > handle lots of users melts under a few doing iso spins (I suppose you > want dvd images in there too right?) > This is not just about end-users. This is also not about what kind of infrastructure one would need to offer respins via a web-interface. I'd like to see where this is going, especially because Revisor already has the enhancement request for a web-interface driven model -this is one of the reasons why we have a CLI mode in Revisor as well-. Jeroen van Meeuwen -kanarip From galibert at pobox.com Sun Jun 10 10:58:52 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sun, 10 Jun 2007 12:58:52 +0200 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <466B7EB7.4000006@iinet.net.au> References: <200706081441.42279.jkeating@redhat.com> <466A0E5E.50201@iinet.net.au> <200706090822.48020.jkeating@redhat.com> <466B7EB7.4000006@iinet.net.au> Message-ID: <20070610105852.GA86555@dspnet.fr.eu.org> On Sun, Jun 10, 2007 at 02:31:51PM +1000, David Timms wrote: > I am not sure how you do that - how can you include inside a piece of > data a checksum that uses the data {including itself} to calculate the > checksum ? Standard method is "zero the checksum area, compute the checksum, write it". At verification time, copy the checksum area in memory, zero it and compute the checksum. OG. From sundaram at fedoraproject.org Sun Jun 10 11:02:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 16:32:03 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1181471430.7684.3.camel@bigbox.unixkiste.local> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> <1181471430.7684.3.camel@bigbox.unixkiste.local> Message-ID: <466BDA2B.9040400@fedoraproject.org> Stefan Held wrote: > Am Sonntag, den 10.06.2007, 11:13 +0530 schrieb Rahul Sundaram: > >> Behavior or look? Behavior is controlled by fedora-logos package. > > Both. As in the "Better Boot" Feature described it is prefered to shut > down grub output and therefore there will be no grub grafic. > > But what if i want the default grub behavior (showing a menu) with a > graphic back? If you want the graphics back, a more logical place would be a option in grub.conf and not this theoretical sub package. Rahul From kanarip at kanarip.com Sun Jun 10 11:08:18 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 10 Jun 2007 13:08:18 +0200 Subject: Web based interface for custom spins In-Reply-To: <466BD6A8.7090704@fedoraproject.org> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> <466BD6A8.7090704@fedoraproject.org> Message-ID: <466BDBA2.7050408@kanarip.com> Rahul Sundaram wrote: > Jeroen van Meeuwen wrote: > >> Rahul, >> >> Revisor is aiming to also do a web-interface driven mode. The implicit >> CLI mode that comes with this is already in Revisor, although we may >> need to clean it up a little since we haven't been giving it that much >> love lately. > > That's cool. Any ETA? Nope. We have so many enhancement requests at this moment, that we (the two of us), cannot just code and release anything anymore. We're getting a little closer to releasing a bug-fixed 2.0 version right now, we will then start adding features once more. Check http://hosted.fedoraproject.org/projects/revisor/report/9 for all our tickets. -49 open. > > Revisor doesn't necessarily require Fedora to be installed >> already though, as we have also done successful Fedora spins from a >> CentOS box. Basically, from where we stand now, we can (or should be >> able to) run on any RPM/YUM enabled machine. > > Right but a web app significantly increases the scope of respins beyond > just RPM based Linux systems. > True, although our scope is not beyond any RPM/YUM driven systems. Neither is livecd-tool's or pungi's, afaik. It doesn't mean we are blind to whatever else is out there, though. A web-interface driven model would certainly be the best solution to enable non-RPM/YUM driven distros to also do respins, I think we all agree on that. Basically a web-interface driven model of doing respins is going to allow the user to do his own respins rather then download any of the other respins anyone else has done. For starters, we could also host some of the respins that are still made of genuine Fedora packages. A web-interface driven model at this point is... going to take a while. If anyone is willing to contribute... ;-) Kind regards, Jeroen van Meeuwen -kanarip From sundaram at fedoraproject.org Sun Jun 10 11:14:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 16:44:39 +0530 Subject: Web based interface for custom spins In-Reply-To: <466BDBA2.7050408@kanarip.com> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> <466BD6A8.7090704@fedoraproject.org> <466BDBA2.7050408@kanarip.com> Message-ID: <466BDD1F.8030403@fedoraproject.org> Jeroen van Meeuwen wrote: > > True, although our scope is not beyond any RPM/YUM driven systems. > Neither is livecd-tool's or pungi's, afaik. Beyond RPM based systems in the sense that, anyone with a web browser can do respins of Fedora. I wasn't talking about porting Revisor to other package management systems. Rahul From sdl.web at gmail.com Sun Jun 10 11:15:14 2007 From: sdl.web at gmail.com (Leo) Date: Sun, 10 Jun 2007 12:15:14 +0100 Subject: python-twisted needs a newer version References: <1181472701.8369.3.camel@localhost.localdomain> Message-ID: ----- Deependra Singh Shekhawat (2007-06-10) wrote:----- > Hi, > > Do the package maintainer of python-twisted doesn't feels that we need a > newer version of it. Right now fedora 7 has 2.4.0-6.fc7 and twisted 2.5 > was released in Jan. 2007. > > Today I was thinking to implement a XMPP client from python but saw that > we don't have support for XMPP client in twisted 2.4 and only available > in 2.5. > > Please clarify on this. > Thanks Please file a bug. -- Leo (GPG Key: 9283AA3F) From kanarip at kanarip.com Sun Jun 10 11:25:12 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 10 Jun 2007 13:25:12 +0200 Subject: Web based interface for custom spins In-Reply-To: <466BDD1F.8030403@fedoraproject.org> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> <466BD6A8.7090704@fedoraproject.org> <466BDBA2.7050408@kanarip.com> <466BDD1F.8030403@fedoraproject.org> Message-ID: <466BDF98.4010403@kanarip.com> Rahul Sundaram wrote: > Jeroen van Meeuwen wrote: > >> >> True, although our scope is not beyond any RPM/YUM driven systems. >> Neither is livecd-tool's or pungi's, afaik. > > Beyond RPM based systems in the sense that, anyone with a web browser > can do respins of Fedora. I wasn't talking about porting Revisor to > other package management systems. > Like I said, a web-interface would be the best solution to enable non-RPM/YUM driven systems to do repins (not just Fedora respins, again, all RPM/YUM driven distros). Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Sun Jun 10 11:31:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:31:59 -0400 Subject: The updates firehose In-Reply-To: <20070610084816.GC30166@ryvius.pekin.waw.pl> References: <200706091605.00638.jkeating@redhat.com> <20070610084816.GC30166@ryvius.pekin.waw.pl> Message-ID: <200706100732.03368.jkeating@redhat.com> On Sunday 10 June 2007 04:48:16 Dominik 'Rathann' Mierzejewski wrote: > I feel like you're saying that Core's "culture" (whatever you mean by that) > should have precedence over Extras' and that "your way" is better than > "our way". I assure you that Extras maintainers didn't just "fire and > forget" their updates. They were tested. Yes, some accidents happened, but > that was the price of greater freedom the maintainers used to have. So > please don't try to discourage those who managed to put up with all the new > obstacles any further. I didn't mean to say that Core's was better. Just different. I was mostly seeking opinions on the matter, not urging change or even expecting it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 11:35:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:35:48 -0400 Subject: [Fwd: [Fedora Update] [comment] blobAndConquer-0.91-1.fc7] In-Reply-To: <466B9D84.9040905@hhs.nl> References: <466B9D84.9040905@hhs.nl> Message-ID: <200706100735.48664.jkeating@redhat.com> On Sunday 10 June 2007 02:43:16 Hans de Goede wrote: > See the forward comment, I could just push the mark as stable button, but I > thought the whole idea of updates-testing was that some QA would be done > and that the QA-team would them do the marking as stable. > > So what is the procedure for this? Perhaps Kevin could have tested it and noted if it was working for him at the same time he was requesting it go out. Perhaps the Games SIG could chew through the updates-testing games and verify that they fell out of the buildsystem correctly and mark them as such? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 11:40:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:40:01 -0400 Subject: Future SCM Technology In-Reply-To: <2550.1181449205@laptop13.inf.utfsm.cl> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <200706071443.48136.jkeating@redhat.com> <2550.1181449205@laptop13.inf.utfsm.cl> Message-ID: <200706100740.01893.jkeating@redhat.com> On Sunday 10 June 2007 00:20:05 Horst H. von Brand wrote: > git for one doesn't "preserve recorded history for a file", and can't do > it by fundamental design (it just records snapshots after changes). It > has tools that help in finding out where the stuff you see (presumably) > came from. I talked with the git folks a bit about this. They /do/ track some path information. I can do a 'git log ' and only see commits that effect that path. When a file is moved, there is no reason a path table couldn't be updated with the new path location, so that if I do 'git log ' it would know to search for too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 11:42:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:42:05 -0400 Subject: Future SCM Technology In-Reply-To: <2489.1181448926@laptop13.inf.utfsm.cl> References: <1181159929.4009.99.camel@lt21223.campus.dmacc.edu> <2489.1181448926@laptop13.inf.utfsm.cl> Message-ID: <200706100742.05620.jkeating@redhat.com> On Sunday 10 June 2007 00:15:26 Horst H. von Brand wrote: > Who is "downstream" here? Derived distributions? They will probably just > take the SRPMs and add their own patches/tweaks. Not if they don't have to. This method is incredibly bad at continuing to track "upstream" changes while preserving "downstream" modifications. If they could just pull the upstream and have it merge with the downstream it would be far far easier to keep their modifications (adjusting over time) but get the upstream changes as well. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazqueznet at gmail.com Sun Jun 10 11:47:53 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 10 Jun 2007 07:47:53 -0400 Subject: Web based interface for custom spins In-Reply-To: <466BDF98.4010403@kanarip.com> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> <466BD6A8.7090704@fedoraproject.org> <466BDBA2.7050408@kanarip.com> <466BDD1F.8030403@fedoraproject.org> <466BDF98.4010403@kanarip.com> Message-ID: <1181476074.3686.20.camel@ignacio.lan> On Sun, 2007-06-10 at 13:25 +0200, Jeroen van Meeuwen wrote: > Rahul Sundaram wrote: > > Jeroen van Meeuwen wrote: > > > >> > >> True, although our scope is not beyond any RPM/YUM driven systems. > >> Neither is livecd-tool's or pungi's, afaik. > > > > Beyond RPM based systems in the sense that, anyone with a web browser > > can do respins of Fedora. I wasn't talking about porting Revisor to > > other package management systems. > > > > Like I said, a web-interface would be the best solution to enable > non-RPM/YUM driven systems to do repins (not just Fedora respins, again, > all RPM/YUM driven distros). What about having the web-based interface generate a set of scripts that could be used to pull down the packages (with wget or curl, and using mirrormanager for the package base), create the administrivial files (initrd, modules.cgz, etc.), and create the .iso (with mkisofs et al)? That way all they'd need is tools that are available on any distro (I'm sure we can toss rpm2cpio.sh in). Heck, they might even be able to do it under cygwin. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sheltren at cs.ucsb.edu Sun Jun 10 11:48:45 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sun, 10 Jun 2007 07:48:45 -0400 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 9, 2007, at 4:05 PM, Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? > We've had > 138 "stable" updates, and 177 current "testing" updates. If all > those were > to go stable, we're talking over 300 updates, in just over a week. > This doesn't seem so bad to me -- and for the record, yes, I'm on a very slow and unreliable connection :) Even if we say that there are 300 updates at this point, that is still a small percentage of the total number of packages. In my 'Everything' SRPMs directory, I see 4229 packages. That means that only 7% of packages have been updated (including updates-testing) since release. I know that in my case, I would have updated before release but I waited for the freeze to unthaw -- I'm sure there were many other packagers in the same boat. The point is, we're bound to see a larger number of updates just after release than we should expect to see in general for the lifetime of the release. - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGa+UeKe7MLJjUbNMRAp2HAKCHMmfkRyj4C71PZAEWUKE4AUSLoACgt1ZV 4LwGq27vYNcEhXEbGgo3xqo= =zwjE -----END PGP SIGNATURE----- From jkeating at redhat.com Sun Jun 10 11:45:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:45:21 -0400 Subject: f7 images for mass production In-Reply-To: <20070610085700.GA6255@neu.nirvana> References: <200706092013.19675.jkeating@redhat.com> <20070610085700.GA6255@neu.nirvana> Message-ID: <200706100745.21324.jkeating@redhat.com> On Sunday 10 June 2007 04:57:00 Axel Thimm wrote: > No need to in 99% of what I've been doing. And the 1% was the > transition to repomd. Why should you buildinstall if there wasn't a > bug in anaconda? Right, but we're talking about fixing bugs in anaconda, or making anaconda use a new kernel, or various other things. This is where things get tricky, so your past history doesn't necessarily apply to the problem. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 11:47:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:47:17 -0400 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <466B7EB7.4000006@iinet.net.au> References: <200706090822.48020.jkeating@redhat.com> <466B7EB7.4000006@iinet.net.au> Message-ID: <200706100747.17802.jkeating@redhat.com> On Sunday 10 June 2007 00:31:51 David Timms wrote: > I am not sure how you do that - how can you include inside a piece of > data a checksum that uses the data {including itself} to calculate the > checksum ? {sounds like one for the crytologists}. Perhaps it is outside > the data area, but then you have no way to know if the implanted > checksum is broken or that data itself {although I imagine it is likely > to be the data}. > > What I am after is a checksum for each file present within the iso, not > the result for the whole iso. Is there such a thing already present ? Check out /usr/lib/anaconda-runtime/implantisomd5 for what it does. I'm not actually sure how / what it calculates, would be worth a read. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 11:49:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:49:46 -0400 Subject: The updates firehose In-Reply-To: <466B9EDA.1060205@hhs.nl> References: <200706091605.00638.jkeating@redhat.com> <200706092019.38404.jkeating@redhat.com> <466B9EDA.1060205@hhs.nl> Message-ID: <200706100749.46277.jkeating@redhat.com> On Sunday 10 June 2007 02:48:58 Hans de Goede wrote: > Do keep in mind when assessing wether this is a real problem or not, that > many people will not have all updated packages installed, in the case of > formaer extras packages many people will actually not have them installed, > and thus they won't notice a thing about them being updated. Well there is lots of masochists that yell and scream every release for the Everything option again... (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 11:51:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:51:37 -0400 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <466B1068.7030002@codewiz.org> Message-ID: <200706100751.37931.jkeating@redhat.com> On Sunday 10 June 2007 00:01:57 Bojan Smojver wrote: > Or, Fedora could do a gold release (i.e. released on the release day) and > then have "unofficial" weekly install snapshots, done automatically and not > passed through any sort of testing, based on current RPMS, so that all you > need to do is download that current install ISO and you're off. If it > works, OK, if it doesn't, you can always go to the gold release that's been > tested and then apply updates. Except people aren't going to understand that it's a fire and forget iso set, and thus our bug spam and bad press is going to sky rocket because the release didn't work. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sun Jun 10 12:17:03 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 10 Jun 2007 14:17:03 +0200 Subject: [Fwd: [Fedora Update] [comment] blobAndConquer-0.91-1.fc7] In-Reply-To: <200706100735.48664.jkeating@redhat.com> References: <466B9D84.9040905@hhs.nl> <200706100735.48664.jkeating@redhat.com> Message-ID: <466BEBBF.8000208@hhs.nl> Jesse Keating wrote: > On Sunday 10 June 2007 02:43:16 Hans de Goede wrote: >> See the forward comment, I could just push the mark as stable button, but I >> thought the whole idea of updates-testing was that some QA would be done >> and that the QA-team would them do the marking as stable. >> >> So what is the procedure for this? > > Perhaps Kevin could have tested it and noted if it was working for him at the > same time he was requesting it go out. Perhaps the Games SIG could chew > through the updates-testing games and verify that they fell out of the > buildsystem correctly and mark them as such? > > Well I'm the most active member of the Games SIG and testing my own updates doesn't feel right (ofcourse I test them, but I shouldn't be the only tester). As for Keving, thats hardly a procedure one can count on for future updates. So I guess I'll just push the mark as stable button then. Regards, Hans From kanarip at kanarip.com Sun Jun 10 12:06:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 10 Jun 2007 14:06:40 +0200 Subject: Web based interface for custom spins In-Reply-To: <1181476074.3686.20.camel@ignacio.lan> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> <466BD6A8.7090704@fedoraproject.org> <466BDBA2.7050408@kanarip.com> <466BDD1F.8030403@fedoraproject.org> <466BDF98.4010403@kanarip.com> <1181476074.3686.20.camel@ignacio.lan> Message-ID: <466BE950.5030804@kanarip.com> Ignacio Vazquez-Abrams wrote: > On Sun, 2007-06-10 at 13:25 +0200, Jeroen van Meeuwen wrote: >> Rahul Sundaram wrote: >>> Jeroen van Meeuwen wrote: >>> >>>> True, although our scope is not beyond any RPM/YUM driven systems. >>>> Neither is livecd-tool's or pungi's, afaik. >>> Beyond RPM based systems in the sense that, anyone with a web browser >>> can do respins of Fedora. I wasn't talking about porting Revisor to >>> other package management systems. >>> >> Like I said, a web-interface would be the best solution to enable >> non-RPM/YUM driven systems to do repins (not just Fedora respins, again, >> all RPM/YUM driven distros). > > What about having the web-based interface generate a set of scripts that > could be used to pull down the packages (with wget or curl, and using > mirrormanager for the package base), create the administrivial files > (initrd, modules.cgz, etc.), and create the .iso (with mkisofs et al)? > That way all they'd need is tools that are available on any distro (I'm > sure we can toss rpm2cpio.sh in). Heck, they might even be able to do it > under cygwin. > > It wouldn't make sense to me to do things this way. Basically, we have the application in place, all it needs is a web interface to get some configuration file or settings, and trigger the build. It sounds simpler then it is though ;-) Kind regards, Jeroen van Meeuwen -kanarip From sundaram at fedoraproject.org Sun Jun 10 12:08:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 17:38:32 +0530 Subject: [Fwd: [Fedora Update] [comment] blobAndConquer-0.91-1.fc7] In-Reply-To: <466BEBBF.8000208@hhs.nl> References: <466B9D84.9040905@hhs.nl> <200706100735.48664.jkeating@redhat.com> <466BEBBF.8000208@hhs.nl> Message-ID: <466BE9C0.4070301@fedoraproject.org> Hans de Goede wrote: > Jesse Keating wrote: >> On Sunday 10 June 2007 02:43:16 Hans de Goede wrote: >>> See the forward comment, I could just push the mark as stable button, >>> but I >>> thought the whole idea of updates-testing was that some QA would be done >>> and that the QA-team would them do the marking as stable. >>> >>> So what is the procedure for this? I thought the policy was to automatically move packages from updates-testing to updates if bugs are not filed during that time against that particular package. With the number of updates being pushed and the ability of maintainers to skip updates-testing I don't think anyone can count on a QA team to verify every update. For the current policy a automated move makes more sense. Rahul From Axel.Thimm at ATrpms.net Sun Jun 10 12:09:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 10 Jun 2007 14:09:33 +0200 Subject: f7 images for mass production In-Reply-To: <200706100745.21324.jkeating@redhat.com> References: <200706092013.19675.jkeating@redhat.com> <20070610085700.GA6255@neu.nirvana> <200706100745.21324.jkeating@redhat.com> Message-ID: <20070610120933.GE19591@neu.nirvana> On Sun, Jun 10, 2007 at 07:45:21AM -0400, Jesse Keating wrote: > On Sunday 10 June 2007 04:57:00 Axel Thimm wrote: > > No need to in 99% of what I've been doing. And the 1% was the > > transition to repomd. Why should you buildinstall if there wasn't a > > bug in anaconda? > > Right, but we're talking about fixing bugs in anaconda, or making anaconda use > a new kernel, or various other things. This is where things get tricky, so > your past history doesn't necessarily apply to the problem. Sure, but anaconda bugs are not the majority of bugs encountered. And replacing a kernel has never been a problem, I never boot any PXE system into the standard kernel, but always the updated one. So, true for fixing the i586 -> i686 bug of FC6 you need updates.img or a new anaconda spin. So if you are afraid to touch these parts, then let these bugs in - you still capture the 99% of the rest. -- 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 jeevanullas at gmail.com Sun Jun 10 12:11:22 2007 From: jeevanullas at gmail.com (Deependra Shekhawat) Date: Sun, 10 Jun 2007 17:41:22 +0530 Subject: python-twisted needs a newer version In-Reply-To: References: <1181472701.8369.3.camel@localhost.localdomain> Message-ID: <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> There already is a bug Bug 236254 But it seems like no-one wants to see it. :( pLEASE. On 6/10/07, Leo wrote: > > ----- Deependra Singh Shekhawat (2007-06-10) wrote:----- > > > Hi, > > > > Do the package maintainer of python-twisted doesn't feels that we need a > > newer version of it. Right now fedora 7 has 2.4.0-6.fc7 and twisted 2.5 > > was released in Jan. 2007. > > > > Today I was thinking to implement a XMPP client from python but saw that > > we don't have support for XMPP client in twisted 2.4 and only available > > in 2.5. > > > > Please clarify on this. > > Thanks > > Please file a bug. > > -- > Leo (GPG Key: 9283AA3F) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Enjoy Life ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcepl at redhat.com Sun Jun 10 12:10:10 2007 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 10 Jun 2007 14:10:10 +0200 Subject: To Require yelp or not to require yelp References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> Message-ID: On 2007-06-10, 06:51 GMT, Christopher Aillon wrote: > Hans de Goede wrote: >> 2 days ago I got 4 bugs requesting me to add Requires: yelp to >> packages using it for their help system. >> >> So I issued 3 rawhide updates (one bug was a false positive). >> >> However yesterday I received a comment in all 4 bugs to please not >> Require yelp ????? > > Here's another way of looking at it: why should 100+ gnome packages > require something that should be installed as a base part of GNOME? If > we want to make it a requires, I'd say that gnome-desktop or something > ought to require it, not every f-ing package. Hi, Hans, let me apologise for this mess -- problem was lack of communication or miscommunication among the RH people of the desktop team. With some people I have agreed upon this change, but Christopher (and other people) missed this discussion (and I probably haven't shouted loud enough). Yes, I should probably learn to discuss Fedora matters on #fedora-devel instead of the internal IRC -- I am sorry. @Christopher: I have this scenario (taken out of bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242673) -- user removes firefox from his system (for example, because he wants to install firefox.i386 instead of firefox.x86_64). Yum dutifuly notes, that depending package yelp will be also removed. Our user has no clue, what yelp does, name doesn't mena anything to him, and he things that it is yet another package uselessly installed by Fedora installer (rightly or wrongly, it is the fame of Fedora installer), so with a light heart presses yes. Then he reinstalls firefox-32 and hopes that everything is as it was, except that his beloved flash player could be installed (yes, I agree, we should have nspluginwrapper in the Fedora repos; we don't). And suddenly most Gnome applications don't have help. He might forgot about removal of yelp, he stil has no clue what it does, and so he has no clue what happened (and blames firefox in this case). IMHO, the problem is that our system doesn't have Debianish Recommends: and Suggests: soft dependencies. In my ideal world yum would say not only that package yum will be removed, but also that functionality of all these packages (list of 96 packages) will be affected, because yum would know that yelp is recommended by all those packages. See for definitions of these relationships. And yes I know it is hopeless to suggest any change in rpm, so we are stuck in this far-from-ideal world. Any ideas? Matej From jkeating at redhat.com Sun Jun 10 12:12:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 08:12:50 -0400 Subject: [Fwd: [Fedora Update] [comment] blobAndConquer-0.91-1.fc7] In-Reply-To: <466BE9C0.4070301@fedoraproject.org> References: <466B9D84.9040905@hhs.nl> <466BEBBF.8000208@hhs.nl> <466BE9C0.4070301@fedoraproject.org> Message-ID: <200706100812.50722.jkeating@redhat.com> On Sunday 10 June 2007 08:08:32 Rahul Sundaram wrote: > I thought the policy was to automatically move packages from > updates-testing to updates if bugs are not filed during that time > against that particular package. With the number of updates being pushed > and the ability of maintainers to skip updates-testing I don't think > anyone can count on a QA team to verify every update. > > For the current policy a automated move makes more sense. Automation is not developed yet, and no governing Fedora body that I know of has voted on or approved automatic moves of updates. It just hasn't been presented as an overall updates workflow and usage policy (of which there seems to be resistance to having one at all) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 12:17:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 08:17:01 -0400 Subject: [Fwd: [Fedora Update] [comment] blobAndConquer-0.91-1.fc7] In-Reply-To: <466BEBBF.8000208@hhs.nl> References: <466B9D84.9040905@hhs.nl> <200706100735.48664.jkeating@redhat.com> <466BEBBF.8000208@hhs.nl> Message-ID: <200706100817.01988.jkeating@redhat.com> On Sunday 10 June 2007 08:17:03 Hans de Goede wrote: > Well I'm the most active member of the Games SIG and testing my own updates > doesn't feel right (ofcourse I test them, but I shouldn't be the only > tester). > > As for Keving, thats hardly a procedure one can count on for future > updates. > > So I guess I'll just push the mark as stable button then. I don't think we're ever going to be able to come up with a policy that will work for every package / every update. How one gets a package from -testing to stable is really up to that person and/or group that the package resides in. This gives the maintainer and SIG the flexibility to define their own policy, hopefully with some overall project level guidelines. Overall like "please use updates-testing first" and "please address bugs / comments filed during -testing". As for games, couldn't the games SIG come up with a strategy for making game updates to a released platform? One that is geared specifically for games and makes use of the people in the SIG? Sometimes you as the maintainer /are/ the best person to test things, and part of that is verifying that A) it fell out of the buildsystem correctly, B) it has the right information in the update ticket and the email content got generated correctly, C) it upgrades cleanly from the previously shipped one through the public repo. If you've been able to verify all of this, and the application itself tests out fine, I see no problem with marking your own update as stable. By being in updates-testing you've given others the opportunity to verify this and more as well. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gemi at bluewin.ch Sun Jun 10 12:22:03 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 10 Jun 2007 14:22:03 +0200 Subject: New restructured ocaml packages Message-ID: <1181478123.4042.5.camel@localhost.localdomain> Hi all, I created restructured ocaml packages (3.10) that should fit in the new ocaml packaging guidelines. They are available at: http://math.ifi.unizh.ch/fedora/tmp Everyone interested in ocaml packaging, please test them, especially look for any wrongly packaged files and dependencies. Comments should go to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 Regards, -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From mcepl at redhat.com Sun Jun 10 12:19:23 2007 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 10 Jun 2007 14:19:23 +0200 Subject: The updates firehose References: <200706091605.00638.jkeating@redhat.com> <466B1E04.5060308@redhat.com> Message-ID: On 2007-06-09, 21:39 GMT, Christopher Aillon wrote: >> Seriously. We're drowning our users in updates. Are all of >> them really necessary? I feel like we've got this culture of >> update whatever/whenever coming from Extras where it was just >> fire and forget. While that might be fun for the maintainer, >> is it fun for the user? Is it fun for the user with a slow >> connection? > > I agree that we should attempt to limit somewhat. But people > always get upset at me for not pushing things out. We need to > determine a policy here before you ask people to limit > themselves. And the some idiots make 96 packages to get updated uselessly. Oh well, I got those 66+MB of updates today as well. Matej From jkeating at redhat.com Sun Jun 10 12:19:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 08:19:46 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> Message-ID: <200706100819.46335.jkeating@redhat.com> On Sunday 10 June 2007 08:10:10 Matej Cepl wrote: > IMHO, the problem is that our system doesn't have Debianish > Recommends: and Suggests: soft dependencies. In my ideal world > yum would say not only that package yum will be removed, but also > that functionality of all these packages (list of 96 packages) > will be affected, because yum would know that yelp is recommended > by all those packages. ?See > > for definitions of these relationships. > > And yes I know it is hopeless to suggest any change in rpm, so we > are stuck in this far-from-ideal world. How does yum/rpm know what functionality yelp provides to these packages? Do we then have to list in the Requires (and auto requires?!) what each required package does for a given package? Even if the user saw that this would remove yelp from all the packages, and he said yes anyway, how does that get yelp back for them in your firefox-32 scenario? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 12:24:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 08:24:03 -0400 Subject: f7 images for mass production In-Reply-To: <20070610120933.GE19591@neu.nirvana> References: <200706100745.21324.jkeating@redhat.com> <20070610120933.GE19591@neu.nirvana> Message-ID: <200706100824.04059.jkeating@redhat.com> On Sunday 10 June 2007 08:09:33 Axel Thimm wrote: > Sure, but anaconda bugs are not the majority of bugs encountered. And > replacing a kernel has never been a problem, I never boot any PXE > system into the standard kernel, but always the updated one. > > So, true for fixing the i586 -> i686 bug of FC6 you need updates.img > or a new anaconda spin. So if you are afraid to touch these parts, > then let these bugs in - you still capture the 99% of the rest. Replacing the on media kernel and making sure the userland tools embedded in the stage1/2 files work with said updated kernel is not an easy task, nor does it always work. Our Fedora kernel moves very fast. My overall opinion / experience here is that one release every 6 months is plenty of releases. To do any more is going to start to have negative effects on the rest. I'd certainly like to be able to do more test releases for those every 6 months, but not in the way we've been doing them currently. But even this is all forward moving rather than backward looking. In Fedora we're always trying to move forward. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazqueznet at gmail.com Sun Jun 10 12:43:45 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 10 Jun 2007 08:43:45 -0400 Subject: Web based interface for custom spins In-Reply-To: <466BE950.5030804@kanarip.com> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> <466BD6A8.7090704@fedoraproject.org> <466BDBA2.7050408@kanarip.com> <466BDD1F.8030403@fedoraproject.org> <466BDF98.4010403@kanarip.com> <1181476074.3686.20.camel@ignacio.lan> <466BE950.5030804@kanarip.com> Message-ID: <1181479425.3686.30.camel@ignacio.lan> On Sun, 2007-06-10 at 14:06 +0200, Jeroen van Meeuwen wrote: > Ignacio Vazquez-Abrams wrote: > > What about having the web-based interface generate a set of scripts that > > could be used to pull down the packages (with wget or curl, and using > > mirrormanager for the package base), create the administrivial files > > (initrd, modules.cgz, etc.), and create the .iso (with mkisofs et al)? > > That way all they'd need is tools that are available on any distro (I'm > > sure we can toss rpm2cpio.sh in). Heck, they might even be able to do it > > under cygwin. > > It wouldn't make sense to me to do things this way. Basically, we have > the application in place, all it needs is a web interface to get some > configuration file or settings, and trigger the build. It sounds simpler > then it is though ;-) True, but then they don't have to chew up the bandwith of the web server or whatnot downloading the iso once it's done. Yes, they could deploy the web service locally, but then they would need to have a rpm/yum-capable system. And if they use a remote system then they'll be using that remote system's bandwidth. And it's not likely that the respins will be mirrored anywhere; it will most likely be a "use once and destroy" situation. By supplying them with only the scripts we reduce the bandwidth from the single server and spread it around to the mirrors. Yes, the respinner will still have to do a bit of work, but it's probably *far* less than setting up another system and deploying the application. And most of the scripts will be the same from user to user anyways, with only the package list changing. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at miketc.com Sun Jun 10 12:46:55 2007 From: mike at miketc.com (Mike Chambers) Date: Sun, 10 Jun 2007 07:46:55 -0500 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> <466B45CA.6070605@ieee.org> Message-ID: <1181479616.10270.6.camel@scrappy.miketc.com> On Sat, 2007-06-09 at 19:56 -0500, Jason L Tibbitts III wrote: > I think that most of the updates we're seeing are: > > 1) New packages. We're burning through the review queue but we still > have hundreds backlogged. All of the packages that are built for > F-7 will generate an update announcement. > > 2) Updates to packages that, frankly, almost nobody has installed. > Yes, there are a ton of updates, but we have thousands upon > thousands of maintained packages. Most users who run the regular > update tools simply won't see the vast majority of these updates. > (People who install everything, however, get what they > deserve/explicitly requested.) It just looks like a massive amount > on the mailing list. Not knowing the build environment or seeing the insides or being a packages/maintainer, I would agree with Jason on both accounts above as the reason for updates. And #2 is especially dead on. Yes your going to see lots more updates, or at least the perception, but actually *look* at the updates and see what they are. More than 25%, if not 50%, are not even the *core* packages, just addons. Not everyone is updating to those, and I bet not even 50% of the userbase is even using the addons part. So I wouldn't worry so much about how many updates. And besides, I see it all the time, someone reports that "upstream released a new version, 1.2.3-5", can you please put out an update. Anyway, just my $.02 (not that it counts or anything hehe) -- Mike Chambers Madisonville, KY "Best little town on Earth!" From nicolas.mailhot at laposte.net Sun Jun 10 12:49:16 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 10 Jun 2007 14:49:16 +0200 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <200706101220.36967.opensource@till.name> References: <200706101152.43378.opensource@till.name> <1181469677.28023.22.camel@rousalka.dyndns.org> <200706101220.36967.opensource@till.name> Message-ID: <1181479756.3161.4.camel@rousalka.dyndns.org> Le dimanche 10 juin 2007 ? 12:20 +0200, Till Maas a ?crit : > On So Juni 10 2007, Nicolas Mailhot wrote: > > Le dimanche 10 juin 2007 ? 11:52 +0200, Till Maas a ?crit : > > > > $ find -type f -print0 | xargs -0 md5sum > > > > If you actually try to use it you'll find there are many small problems > > to take care of (such as sanitizing find output so absolute/relative > > files names are not embedded in the checksum files) > > > I do not understand the problem, when the commandline is invoked in the root > directory of the iso, the file paths are all correct, i.e. relative to the > root directory of the iso. foo.bar will be ./foo.bar instead of foo.bar as expected by checksum scripts (will probably work most of the times, but is ugly) you need to sort the result if you want to diff the lists someday (can't sort once gpg clear-signed the files) if you're not in the right dir find will embed directory info not relevant to the produced iso in the checksum files etc Nothing real difficult, but a lot of hassle to reinvent the right recursive checksumming recipe all the time -- 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 obi at unixkiste.org Sun Jun 10 12:49:49 2007 From: obi at unixkiste.org (Stefan Held) Date: Sun, 10 Jun 2007 14:49:49 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <466BDA2B.9040400@fedoraproject.org> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> <1181471430.7684.3.camel@bigbox.unixkiste.local> <466BDA2B.9040400@fedoraproject.org> Message-ID: <1181479789.7684.12.camel@bigbox.unixkiste.local> Am Sonntag, den 10.06.2007, 16:32 +0530 schrieb Rahul Sundaram: > If you want the graphics back, a more logical place would be a option in > grub.conf and not this theoretical sub package. The issue of this Thread was the dependency hell on fedora-logos.... which needs X and other libs as dependency which means: Install dozens of unneeded packages. Then this discussion drifted to: We don't need this because on F8 we will have "Better Boot" which is intendend to disable the output of grub, which then resulted into: As long as we have an option to switch back the default behavior i am on this. Now, for this: If we remove the grub graphics from the fedora-logos file we either should have fedora-logos-grub as a subpackage from fedora-logos (which resolves also the dependency issue for server installations) > Rahul Or we leave everything with a ugly grub default menu. I am asking again, what would be so bad about a small subpackage with a small file in it? -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sundaram at fedoraproject.org Sun Jun 10 12:52:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 18:22:33 +0530 Subject: Unwanted RPM dependencies In-Reply-To: <1181479789.7684.12.camel@bigbox.unixkiste.local> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> <1181471430.7684.3.camel@bigbox.unixkiste.local> <466BDA2B.9040400@fedoraproject.org> <1181479789.7684.12.camel@bigbox.unixkiste.local> Message-ID: <466BF411.2010509@fedoraproject.org> Stefan Held wrote: > > Or we leave everything with a ugly grub default menu. I am asking again, > what would be so bad about a small subpackage with a small file in it? Nothing. File a RFE. Rahul From root at martin-papadopoulos.de Sun Jun 10 13:14:02 2007 From: root at martin-papadopoulos.de (Martin Papadopoulos) Date: Sun, 10 Jun 2007 15:14:02 +0200 Subject: grsecurity Message-ID: <466BF91A.7030300@martin-papadopoulos.de> has anyone considerd grsecurity as part of fedora ? greetz martin papadopoulos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mclasen at redhat.com Sun Jun 10 13:18:44 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 10 Jun 2007 09:18:44 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <1181471430.7684.3.camel@bigbox.unixkiste.local> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> <1181471430.7684.3.camel@bigbox.unixkiste.local> Message-ID: <1181481524.3445.2.camel@localhost.localdomain> On Sun, 2007-06-10 at 12:30 +0200, Stefan Held wrote: > Am Sonntag, den 10.06.2007, 11:13 +0530 schrieb Rahul Sundaram: > > > Behavior or look? Behavior is controlled by fedora-logos package. > > Both. As in the "Better Boot" Feature described it is prefered to shut > down grub output and therefore there will be no grub grafic. > > But what if i want the default grub behavior (showing a menu) with a > graphic back? We should make this optional. We are not going to remove your ability to configure grub in whatever way you want, in exactly the same way as you always could. > And therefore it would be > great to have a small fedora-logo-grub.fc8.rpm which does not depend on > 1000 rpms afterwards. Jeremy already stated why we can't do that. From ivazqueznet at gmail.com Sun Jun 10 13:35:54 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 10 Jun 2007 09:35:54 -0400 Subject: grsecurity In-Reply-To: <466BF91A.7030300@martin-papadopoulos.de> References: <466BF91A.7030300@martin-papadopoulos.de> Message-ID: <1181482554.3686.33.camel@ignacio.lan> On Sun, 2007-06-10 at 15:14 +0200, Martin Papadopoulos wrote: > has anyone considerd grsecurity as part of fedora ? Are you suggesting that Fedora ship both SELinux AND grsecurity? -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From root at martin-papadopoulos.de Sun Jun 10 13:39:22 2007 From: root at martin-papadopoulos.de (Martin Papadopoulos) Date: Sun, 10 Jun 2007 15:39:22 +0200 Subject: grsecurity In-Reply-To: <1181482554.3686.33.camel@ignacio.lan> References: <466BF91A.7030300@martin-papadopoulos.de> <1181482554.3686.33.camel@ignacio.lan> Message-ID: <466BFF0A.3070405@martin-papadopoulos.de> Ignacio Vazquez-Abrams schrieb: > On Sun, 2007-06-10 at 15:14 +0200, Martin Papadopoulos wrote: > >> has anyone considerd grsecurity as part of fedora ? >> > > Are you suggesting that Fedora ship both SELinux AND grsecurity? > > that is a good idea, i would say yes ! greetz martin papadopoulos -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mclasen at redhat.com Sun Jun 10 13:36:59 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 10 Jun 2007 09:36:59 -0400 Subject: The updates firehose In-Reply-To: <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> Message-ID: <1181482619.3445.9.camel@localhost.localdomain> On Sun, 2007-06-10 at 12:14 +0200, Neil Thompson wrote: > > And very shortly you're going to be asking for a policy to be written which > defines when the maintainers are going to be allowed to have bowel movements, > aren't you? > > The strengths of Fedora are its leading (even bleeding, at times) edge software > and its maintainers. I had hoped that the merge would lead to more freedom and > faster throughput for new software, but it looks as though we're on the verge > of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it > worries me) > > Please folks - if you're going to build a community, make sure that you have only > the governance that is necessary and NO MORE! Leave the maintainers (who have been > appointed to look after the packages) to do their jobs. Address mistakes and issues > on a case-by-case basis and don't hamstring everyone with a bunch of pettifogging > rules. Ignoring the abusive language in the above, I think what we need is not so much rules about what kind of updates are allowed, but a bit more finegrained classification of updates, plus easy ways to filter by this classification on the client side, and I mean some easy to use ui in pup/pirut, not some manually installable and configurable yum plugin. The current classification we have is just "bugfix - enhancement - security". It would be nice add some more categories to this, like "cosmetic" (for minor packaging cleanups like directory ownership handling), and some way to differentiate by severity. From jdieter at gmail.com Sun Jun 10 14:23:35 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 10 Jun 2007 17:23:35 +0300 Subject: The updates firehose In-Reply-To: <200706101239.58845.opensource@till.name> References: <200706091605.00638.jkeating@redhat.com> <20070610095434.83350@gmx.net> <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> <200706101239.58845.opensource@till.name> Message-ID: <1181485415.5341.7.camel@jndwidescreen.lesbg.loc> On Sun, 2007-06-10 at 12:39 +0200, Till Maas wrote: > Is the information in the xml and sqlite files different? Afaik the sqlite > files only increase the speed of yum, so when downloading the sqlite files > needs more time than processing the xml files, it is better to skip them. It's not so much that the data is different as it is the fact that making an efficient diff of two xml files is easy, but making an effecient diff of two sqlite files is a bit more difficult. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abraxis at telkomsa.net Sun Jun 10 14:43:49 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Sun, 10 Jun 2007 16:43:49 +0200 Subject: The updates firehose In-Reply-To: <1181482619.3445.9.camel@localhost.localdomain> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> <1181482619.3445.9.camel@localhost.localdomain> Message-ID: <20070610144349.GB30423@eeyore.32.boerneef.vornavalley> On Sun, Jun 10, 2007 at 09:36:59AM -0400, Matthias Clasen wrote: > > Ignoring the abusive language in the above, I think what we need is not Hardly abusive, although I will admit to being somewhat intemperate - I'm just sick and tired of the midset which attempts to introduce policies and rules to cover every conceivable (and some not even) eventuality. > so much rules about what kind of updates are allowed, but a bit more > finegrained classification of updates, plus easy ways to filter by this > classification on the client side, and I mean some easy to use ui in > pup/pirut, not some manually installable and configurable yum plugin. > Agreed - that's much more the thing. > The current classification we have is just > "bugfix - enhancement - security". It would be nice add some more > categories to this, like "cosmetic" (for minor packaging cleanups like > directory ownership handling), and some way to differentiate by > severity. This will pretty much have to be driven by the maintainer, though, as she's the only person who will have enough knowledge about the package to make those kind of distinctions. You really don't want to introduce any more approval-type steps into the process - there'll be even more push-back at that. -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From mmcgrath at redhat.com Sun Jun 10 14:55:29 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 10 Jun 2007 09:55:29 -0500 Subject: Web based interface for custom spins In-Reply-To: <466BD645.1070401@fedoraproject.org> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> <466BD645.1070401@fedoraproject.org> Message-ID: <466C10E1.6000502@redhat.com> Rahul Sundaram wrote: > Nicolas Mailhot wrote: >> Le dimanche 10 juin 2007 ? 15:23 +0530, Rahul Sundaram a ?crit : >>> Nicolas Mailhot wrote: >>>> Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : >>>> >>>>> Having a web interface would allow anyone to select the package >>>>> groups and individual packages and get a ISO image for download. I >>>>> posted to fedora-infrastructure list before but we need a web app >>>>> before talking about deploying it. >>>> Yay for killing bandwidth >>> Ignoring the obvious end user benefits? >> >> There are no obvious end-user benefits if an infrastructure that could >> handle lots of users melts under a few doing iso spins (I suppose you >> want dvd images in there too right?) > > Yes and infrastructure team would have let me know when I posted in > that list if there are any issues with bandwidth or anything else. > There is no need to be a stop energy assuming there is a problem. Huh? You told us to ignore that thread so we did: https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00150.html And without any bandwidth requirements from the project owner, we have no way to tell you whether or not we can host such a project: http://fedoraproject.org/wiki/Infrastructure/RFR Check with max, there are interns working on this right already. -Mike From kanarip at kanarip.com Sun Jun 10 14:55:55 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 10 Jun 2007 16:55:55 +0200 Subject: Web based interface for custom spins In-Reply-To: <1181479425.3686.30.camel@ignacio.lan> References: <466B6C82.5050902@fedoraproject.org> <466BD41C.5070407@kanarip.com> <466BD6A8.7090704@fedoraproject.org> <466BDBA2.7050408@kanarip.com> <466BDD1F.8030403@fedoraproject.org> <466BDF98.4010403@kanarip.com> <1181476074.3686.20.camel@ignacio.lan> <466BE950.5030804@kanarip.com> <1181479425.3686.30.camel@ignacio.lan> Message-ID: <466C10FB.20603@kanarip.com> Ignacio Vazquez-Abrams wrote: > On Sun, 2007-06-10 at 14:06 +0200, Jeroen van Meeuwen wrote: >> Ignacio Vazquez-Abrams wrote: >>> What about having the web-based interface generate a set of scripts that >>> could be used to pull down the packages (with wget or curl, and using >>> mirrormanager for the package base), create the administrivial files >>> (initrd, modules.cgz, etc.), and create the .iso (with mkisofs et al)? >>> That way all they'd need is tools that are available on any distro (I'm >>> sure we can toss rpm2cpio.sh in). Heck, they might even be able to do it >>> under cygwin. >> It wouldn't make sense to me to do things this way. Basically, we have >> the application in place, all it needs is a web interface to get some >> configuration file or settings, and trigger the build. It sounds simpler >> then it is though ;-) > > True, but then they don't have to chew up the bandwith of the web server > or whatnot downloading the iso once it's done. > > Yes, they could deploy the web service locally, but then they would need > to have a rpm/yum-capable system. And if they use a remote system then > they'll be using that remote system's bandwidth. And it's not likely > that the respins will be mirrored anywhere; it will most likely be a > "use once and destroy" situation. > > By supplying them with only the scripts we reduce the bandwidth from the > single server and spread it around to the mirrors. Yes, the respinner > will still have to do a bit of work, but it's probably *far* less than > setting up another system and deploying the application. And most of the > scripts will be the same from user to user anyways, with only the > package list changing. > > Basically, the web-interface driven model is in. Frankly I don't care if anyone wants to do a "public" build server with it. From my perspective a web-interface helps those who want to do (multiple) builds but don't have the workstation to run the Revisor client (assuming the XML-RPC client/server model gets in place). Whether that build server faces the public or is a private, local build server, is not for me to decide, I just do the coding. About possibly eating bandwidth: it's not my choice or problem either. We can do "dump-some-scripts-and-binaries-rather-then-fully-run-the-build-so-that-users-can-build -off-line-not-eating-the-web-server's-bandwidth', but to me it has no added value compared to a fully web-interface driven build-server, so expect it to get a low priority. Feel free to request the enhancement at our ticketing system; the more open everything is, the better. That includes porting (some of) the scripts or distributing binary stuff from a build server so that workstation can do builds themselves. Also, feel free to submit the code or assist us in getting things done if you feel we're getting behind ;-) Kind regards, Jeroen van Meeuwen -kanarip From linux_4ever at yahoo.com Sun Jun 10 14:34:13 2007 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 10 Jun 2007 07:34:13 -0700 (PDT) Subject: grsecurity In-Reply-To: <466BF91A.7030300@martin-papadopoulos.de> Message-ID: <20070610143413.45564.qmail@web51503.mail.re2.yahoo.com> >has anyone considered grsecurity as part of fedora ? No. Effort would be better spent improving security mechanisms that are upstreamed and maintained by the community. Grsecurity has some design issues that are incompatible with kernel.org originating kernels. As far as security goes, I'm not sure it would buy you anything you don't already have. -Steve ___________________________________________________________________________________ You snooze, you lose. Get messages ASAP with AutoCheck in the all-new Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_html.html From sundaram at fedoraproject.org Sun Jun 10 14:58:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 20:28:05 +0530 Subject: Web based interface for custom spins In-Reply-To: <466C10E1.6000502@redhat.com> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> <466BD645.1070401@fedoraproject.org> <466C10E1.6000502@redhat.com> Message-ID: <466C117D.7030206@fedoraproject.org> Mike McGrath wrote: > > Huh? You told us to ignore that thread so we did: > > https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00150.html There was a post before this at https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00077.html Rahul From caillon at redhat.com Sun Jun 10 14:56:48 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 10 Jun 2007 10:56:48 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <200706101224.09692.ville.skytta@iki.fi> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> Message-ID: <466C1130.4030508@redhat.com> Ville Skytt? wrote: > yelp comes with a dependency chain. In the case of dia, adding a dependency > on yelp (whether directly or indirectly if the dep is in some gnome lib > packages), that right stuff would result in the need to additionally install > yelp, desktop-file-utils, docbook-dtds, fedora-bookmarks, firefox, > gnome-doc-utils, libXt, libbeagle, nspr, nss, openjade, opensp, scrollkeeper, > sgml-common, and xml-common. I think your example is a great one. Do we really want to force an app like dia to pull in all this crap just to use it? Do we want to basically force everyone that uses a GUI to install firefox and libbeagle? nspluginwrapper is going to be a requirement of the browser stack soon. XULrunner is going to come with an additional set of dependencies. From giallu at gmail.com Sun Jun 10 15:01:56 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 10 Jun 2007 17:01:56 +0200 Subject: python-twisted needs a newer version In-Reply-To: <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> Message-ID: Hugh. My eyes hurt... From caillon at redhat.com Sun Jun 10 15:08:35 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 10 Jun 2007 11:08:35 -0400 Subject: The updates firehose In-Reply-To: <20070609220107.GD3873@neu.nirvana> References: <200706091605.00638.jkeating@redhat.com> <20070609220107.GD3873@neu.nirvana> Message-ID: <466C13F3.7020800@redhat.com> Axel Thimm wrote: > On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote: >> Anybody else think we're issuing entirely /way/ too many updates? We've had >> 138 "stable" updates, and 177 current "testing" updates. If all those were >> to go stable, we're talking over 300 updates, in just over a week. > > But is that different than at FC6 release time (I don't know, but I > assume it was similar if not even more)? We're not really doing > anything different that made updates increase, I would even think that > it is more difficult to pass updates since they have to be pushed > through bodhi. > > You only feel like there are that many updates, because they are now > all using bodhi while before F7 only 1/4th (Core) would become visible > that way. > >> Seriously. We're drowning our users in updates. Are all of them >> really necessary? I feel like we've got this culture of update >> whatever/whenever coming from Extras where it was just fire and >> forget. While that might be fun for the maintainer, is it fun for >> the user? Is it fun for the user with a slow connection? > > I think Fedora's success is partly due to being updated that way. I think the ugpradeability is a factor, but I think you've got it wrong. If every time someone built a change into rawhide, they also pushed a fix to F-7 for example because there's a new version of , then what's the point in upgrading to F-8 when that's ready? Most extras packages have the same version across the board. I understand the pros of doing that, but do we really want to turn each Fedora release into the next RHL 7.3? From fedora at camperquake.de Sun Jun 10 15:22:17 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 10 Jun 2007 17:22:17 +0200 Subject: The updates firehose In-Reply-To: <466C13F3.7020800@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070609220107.GD3873@neu.nirvana> <466C13F3.7020800@redhat.com> Message-ID: <20070610172217.22ec7d4c@lain.camperquake.de> Hi. On Sun, 10 Jun 2007 11:08:35 -0400, Christopher Aillon wrote > I think the ugpradeability is a factor, but I think you've got it > wrong. If every time someone built a change into rawhide, they also > pushed a fix to F-7 for example because there's a new version of > , then what's the point in upgrading to F-8 > when that's ready? Well... if the update is in the same branch, I push it to F, too (after having had it in rawhide for some time). For example, 1.3.4->1.3.5 will get into F7. Major version releases do usually not get into F, unless there is a very convincing reason. For example, 1.3.5->1.4.0 would get into rawhide, but probably not into F7. That's just my style, however. From opensource at till.name Sun Jun 10 15:26:34 2007 From: opensource at till.name (Till Maas) Date: Sun, 10 Jun 2007 17:26:34 +0200 Subject: The updates firehose In-Reply-To: <466C13F3.7020800@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070609220107.GD3873@neu.nirvana> <466C13F3.7020800@redhat.com> Message-ID: <200706101726.36818.opensource@till.name> On So Juni 10 2007, Christopher Aillon wrote: > I think the ugpradeability is a factor, but I think you've got it wrong. > If every time someone built a change into rawhide, they also pushed a > fix to F-7 for example because there's a new version of app here>, then what's the point in upgrading to F-8 when that's ready? Holding back updates only to make a new release interesting is not a good reason imho. But there are sometimes technical reasons, why updates are done from one release to another. The other way round, when bugs are not fixed with a new update in a current release but left open until the release is end of life is much more annoying imho and causes me more problems than often updates. > Most extras packages have the same version across the board. I > understand the pros of doing that, but do we really want to turn each > Fedora release into the next RHL 7.3? What was the property of RHL 7.3 you are refering to? I did not use Redhat then, so I do not know. Regards, Till From caillon at redhat.com Sun Jun 10 16:08:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 10 Jun 2007 12:08:05 -0400 Subject: The updates firehose In-Reply-To: <200706101726.36818.opensource@till.name> References: <200706091605.00638.jkeating@redhat.com> <20070609220107.GD3873@neu.nirvana> <466C13F3.7020800@redhat.com> <200706101726.36818.opensource@till.name> Message-ID: <466C21E5.3050201@redhat.com> Till Maas wrote: > On So Juni 10 2007, Christopher Aillon wrote: > >> I think the ugpradeability is a factor, but I think you've got it wrong. >> If every time someone built a change into rawhide, they also pushed a >> fix to F-7 for example because there's a new version of > app here>, then what's the point in upgrading to F-8 when that's ready? > > Holding back updates only to make a new release interesting is not a good > reason imho. But there are sometimes technical reasons, why updates are done > from one release to another. The other way round, when bugs are not fixed > with a new update in a current release but left open until the release is end > of life is much more annoying imho and causes me more problems than often > updates. But there are always bugs. Are we going to fix every one? We need to fix the important ones. I don't think that pulling in every latest version is important enough against a release. From bpepple at fedoraproject.org Sun Jun 10 16:16:26 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 10 Jun 2007 12:16:26 -0400 Subject: The updates firehose In-Reply-To: <466C21E5.3050201@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070609220107.GD3873@neu.nirvana> <466C13F3.7020800@redhat.com> <200706101726.36818.opensource@till.name> <466C21E5.3050201@redhat.com> Message-ID: <1181492186.2828.2.camel@kennedy> On Sun, 2007-06-10 at 12:08 -0400, Christopher Aillon wrote: > Till Maas wrote: > > On So Juni 10 2007, Christopher Aillon wrote: > > > >> I think the ugpradeability is a factor, but I think you've got it wrong. > >> If every time someone built a change into rawhide, they also pushed a > >> fix to F-7 for example because there's a new version of >> app here>, then what's the point in upgrading to F-8 when that's ready? > > > > Holding back updates only to make a new release interesting is not a good > > reason imho. But there are sometimes technical reasons, why updates are done > > from one release to another. The other way round, when bugs are not fixed > > with a new update in a current release but left open until the release is end > > of life is much more annoying imho and causes me more problems than often > > updates. > > But there are always bugs. Are we going to fix every one? We need to > fix the important ones. I don't think that pulling in every latest > version is important enough against a release. +1. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeevanullas at gmail.com Sun Jun 10 16:48:33 2007 From: jeevanullas at gmail.com (Deependra Shekhawat) Date: Sun, 10 Jun 2007 22:18:33 +0530 Subject: python-twisted needs a newer version In-Reply-To: References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> Message-ID: <57127b5f0706100948l205cdda3v149581bac37b3ed9@mail.gmail.com> Sorry. I copy pasted from the bugzilla never noticed it would look so ugly. LOL. But it made my point more stronger i guess. On 6/10/07, Gianluca Sforna wrote: > > Hugh. My eyes hurt... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Enjoy Life ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Sun Jun 10 16:54:37 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Jun 2007 12:54:37 -0400 Subject: Web based interface for custom spins In-Reply-To: <466B6C82.5050902@fedoraproject.org> References: <466B6C82.5050902@fedoraproject.org> Message-ID: <1181494477.14809.6.camel@rivendell> On Sun, 2007-06-10 at 08:44 +0530, Rahul Sundaram wrote: > > Is anyone looking into writing a web interface that can do custom spins > using pungi and livecd-tools in the background? Revisor is useful as a > graphical wrapper but it requires Fedora to be installed already. > > Having a web interface would allow anyone to select the package groups > and individual packages and get a ISO image for download. I posted to > fedora-infrastructure list before but we need a web app before talking > about deploying it. > There are some folks working on revisor working on this. As well as some interns working for someone at red hat. Jack knows about it, too. The gist of how it will be is: - web interface lets a user specify what they want in their distro. - this information if submitted to a database or some other backend - another set of machines build these distros/isos as they work through the others in the queue. - the backends update the database to tell the user where their isos are available - the user comes back to the web interface and is told where to go to collect their isos. that's the gist of it, really. -sv From opensource at till.name Sun Jun 10 17:10:20 2007 From: opensource at till.name (Till Maas) Date: Sun, 10 Jun 2007 19:10:20 +0200 Subject: The updates firehose In-Reply-To: <466C21E5.3050201@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <200706101726.36818.opensource@till.name> <466C21E5.3050201@redhat.com> Message-ID: <200706101910.22912.opensource@till.name> On So Juni 10 2007, Christopher Aillon wrote: > But there are always bugs. Are we going to fix every one? We need to > fix the important ones. I don't think that pulling in every latest > version is important enough against a release. When an update that fixes an not very important bug causes a lot of work, e.g. a new python version, than imho it is worth waiting till the next release. Also, when there are no bug reports from Fedora users, than imho it is also ok to delay an update. What does a maintainer gain when he maintains an old version of a package in one release and a newer one in another instead of maintaining the same new version in both releases? Also there are cases, when a user cannot easiely upgrade to a new release, e.g. all zope users cannot use Fedora 7 afaik, because there is no Zope in Fedora 7 anymore. And last but not least it is also depressing to fill bug reports, when they are ignored. Regards, Till From Axel.Thimm at ATrpms.net Sun Jun 10 17:12:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 10 Jun 2007 19:12:40 +0200 Subject: The updates firehose In-Reply-To: <466C13F3.7020800@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070609220107.GD3873@neu.nirvana> <466C13F3.7020800@redhat.com> Message-ID: <20070610171240.GB2371@neu.nirvana> On Sun, Jun 10, 2007 at 11:08:35AM -0400, Christopher Aillon wrote: > Axel Thimm wrote: > >On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote: > >>Anybody else think we're issuing entirely /way/ too many updates? We've > >>had 138 "stable" updates, and 177 current "testing" updates. If all > >>those were to go stable, we're talking over 300 updates, in just over a > >>week. > > > >But is that different than at FC6 release time (I don't know, but I > >assume it was similar if not even more)? We're not really doing > >anything different that made updates increase, I would even think that > >it is more difficult to pass updates since they have to be pushed > >through bodhi. > > > >You only feel like there are that many updates, because they are now > >all using bodhi while before F7 only 1/4th (Core) would become visible > >that way. > > > >>Seriously. We're drowning our users in updates. Are all of them > >>really necessary? I feel like we've got this culture of update > >>whatever/whenever coming from Extras where it was just fire and > >>forget. While that might be fun for the maintainer, is it fun for > >>the user? Is it fun for the user with a slow connection? > > > >I think Fedora's success is partly due to being updated that way. > > I think the ugpradeability is a factor, but I think you've got it wrong. > If every time someone built a change into rawhide, they also pushed a > fix to F-7 for example because there's a new version of app here>, then what's the point in upgrading to F-8 when that's ready? Well, blindly upgrading everything wasn't advocated, but still, we have 12/13 of the time 3 releases and 1/13 of the time 4 releases to support and it often makes sense to keep the same version across the releases (especially for voluntary contributors). If we were only pushing into rawhide F7 would had been far more buggier as many bugs had been found and fixed during FC6. Furthermore this *is* by definition Fedora's style of existance. And don't look at the former Extras, the kernel from the former Core is giving the best example: Perhaps one of foure kernel upgrades are due to security fixes, and the kernel upgrades are one of the worst nightmares given 3rd party repos offering kernel module packages. > Most extras packages have the same version across the board. I > understand the pros of doing that, but do we really want to turn each > Fedora release into the next RHL 7.3? I don't quite understand the comparison, but FWIW RHEL 7.3 was a very popular release, and if we could have each Fedora release as pupular, then why now. Also we're not turning into anything, Fedora has been like that at least since mid-FC3 when Fedora Extras launched (and as said the kernel is the best example for this happening outside of Extras anyway), nothing has changed other than pushing stuff through bodhi. And I still don't see any drawbacks mentioned. F8 not being worth to upgrade to because F7 is already that good? A (or every) Fedora release becoming as popular as RHL 7.3 (but maybe I missed what is being compared)? These are not really arguments against the current (and old) workflow model in Fedora, but more in favour. :=) Hey, let's not forget what Fedora is: The Fedora Project is a Red Hat-sponsored and community-supported open source project that promotes RAPID DEVELOPMENT of INNOVATIVE open source software through a collaborative, community effort. As a community forum for ADVANCED DEVELOPMENT, the Fedora Project provides EARLY VISIBILITY to the LATEST open source technology and serves as a PROVING GROUND for technology that may eventually make its way into Red Hat's fully-supported commercial solutions such as Red Hat Enterprise Linux. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Sun Jun 10 17:21:59 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Jun 2007 13:21:59 -0400 Subject: The updates firehose In-Reply-To: <20070610095434.83350@gmx.net> References: <200706091605.00638.jkeating@redhat.com> <200706092223.13366.opensource@till.name> <20070610095434.83350@gmx.net> Message-ID: <1181496119.14809.16.camel@rivendell> On Sun, 2007-06-10 at 11:54 +0200, Joachim Frieben wrote: > > yum-presto will help a lot more. But maybe there should be also delta-xml > > files for the repository metadata, because it takes very long to download > > these, too, with a slow connection. > > > > Regards, > > Till > > Right, this is a very serious point. Right now, the meta data in my /var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to download via a standard analog modem connection! which metadata? Can you list the files? thanks, -sv From skvidal at linux.duke.edu Sun Jun 10 17:33:56 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Jun 2007 13:33:56 -0400 Subject: Web based interface for custom spins In-Reply-To: <1181469507.28023.18.camel@rousalka.dyndns.org> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> Message-ID: <1181496836.14809.23.camel@rivendell> On Sun, 2007-06-10 at 11:58 +0200, Nicolas Mailhot wrote: > Le dimanche 10 juin 2007 ? 15:23 +0530, Rahul Sundaram a ?crit : > > Nicolas Mailhot wrote: > > > Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : > > > > > >> Having a web interface would allow anyone to select the package groups > > >> and individual packages and get a ISO image for download. I posted to > > >> fedora-infrastructure list before but we need a web app before talking > > >> about deploying it. > > > > > > Yay for killing bandwidth > > > > Ignoring the obvious end user benefits? > > There are no obvious end-user benefits if an infrastructure that could > handle lots of users melts under a few doing iso spins (I suppose you > want dvd images in there too right?) I'm going to say something here which I'm sure will cause a bit of a fit but I'll say it anyway. The bandwidth and server costs of running a service like this would be huge. What has been discussed (briefly and without much detail is this) 1. produce an open source tool to produce web-based respins of fedora (and related) distros. 2. release this tool so anyone could set up their own site to make respinds 3. setup a site so people can respin fedora with updates or with a different set of packages. There won't be much guarantee that the distro will work perfectly but its package set should produce dependency closure. 4. charge a fee for access to the site we run. That would help us offset the costs and constrain the set of users a bit. That's what has been discussed and only a little bit. Right now the important part is making a program work to do this, everything after that is extra. let the angst and flames begin. -sv From opensource at till.name Sun Jun 10 17:41:50 2007 From: opensource at till.name (Till Maas) Date: Sun, 10 Jun 2007 19:41:50 +0200 Subject: The updates firehose In-Reply-To: <1181496119.14809.16.camel@rivendell> References: <200706091605.00638.jkeating@redhat.com> <20070610095434.83350@gmx.net> <1181496119.14809.16.camel@rivendell> Message-ID: <200706101941.52473.opensource@till.name> [big metadata] On So Juni 10 2007, seth vidal wrote: > which metadata? Can you list the files? With Fedora 6 I have similiar results: $ LANG=C du -hcs /var/cache/yum/{extras,core,updates}/*xml* 4.5M /var/cache/yum/extras/filelists.xml.gz 23M /var/cache/yum/extras/filelists.xml.gz.sqlite 1.6M /var/cache/yum/extras/primary.xml.gz 13M /var/cache/yum/extras/primary.xml.gz.sqlite 8.0K /var/cache/yum/extras/repomd.xml 2.5M /var/cache/yum/core/filelists.xml.gz 12M /var/cache/yum/core/filelists.xml.gz.sqlite 836K /var/cache/yum/core/primary.xml.gz 4.6M /var/cache/yum/core/primary.xml.gz.sqlite 8.0K /var/cache/yum/core/repomd.xml 2.8M /var/cache/yum/updates/filelists.xml.gz 16M /var/cache/yum/updates/filelists.xml.gz.sqlite 476K /var/cache/yum/updates/primary.xml.gz 3.5M /var/cache/yum/updates/primary.xml.gz.sqlite 8.0K /var/cache/yum/updates/repomd.xml 83M total Regards, Till From skvidal at linux.duke.edu Sun Jun 10 17:44:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Jun 2007 13:44:21 -0400 Subject: The updates firehose In-Reply-To: <200706101941.52473.opensource@till.name> References: <200706091605.00638.jkeating@redhat.com> <20070610095434.83350@gmx.net> <1181496119.14809.16.camel@rivendell> <200706101941.52473.opensource@till.name> Message-ID: <1181497461.14809.29.camel@rivendell> On Sun, 2007-06-10 at 19:41 +0200, Till Maas wrote: > [big metadata] > > On So Juni 10 2007, seth vidal wrote: > > > which metadata? Can you list the files? > > With Fedora 6 I have similiar results: > > $ LANG=C du -hcs /var/cache/yum/{extras,core,updates}/*xml* > 4.5M /var/cache/yum/extras/filelists.xml.gz > 23M /var/cache/yum/extras/filelists.xml.gz.sqlite > 1.6M /var/cache/yum/extras/primary.xml.gz > 13M /var/cache/yum/extras/primary.xml.gz.sqlite > 8.0K /var/cache/yum/extras/repomd.xml > 2.5M /var/cache/yum/core/filelists.xml.gz > 12M /var/cache/yum/core/filelists.xml.gz.sqlite > 836K /var/cache/yum/core/primary.xml.gz > 4.6M /var/cache/yum/core/primary.xml.gz.sqlite > 8.0K /var/cache/yum/core/repomd.xml > 2.8M /var/cache/yum/updates/filelists.xml.gz > 16M /var/cache/yum/updates/filelists.xml.gz.sqlite > 476K /var/cache/yum/updates/primary.xml.gz > 3.5M /var/cache/yum/updates/primary.xml.gz.sqlite > 8.0K /var/cache/yum/updates/repomd.xml > 83M total > some of these are downloaded, some are generated. the xml.gz files are used to make the xml.gz.sqlite files. So you downloaded .gz files only. in fedora 7 you should only have *.sqlite files - no .gz files at all. -sv From skvidal at linux.duke.edu Sun Jun 10 17:59:42 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Jun 2007 13:59:42 -0400 Subject: The updates firehose In-Reply-To: <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> References: <200706091605.00638.jkeating@redhat.com> <200706092223.13366.opensource@till.name> <20070610095434.83350@gmx.net> <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> Message-ID: <1181498382.14809.31.camel@rivendell> On Sun, 2007-06-10 at 13:25 +0300, Jonathan Dieter wrote: > On Sun, 2007-06-10 at 11:54 +0200, Joachim Frieben wrote: > > > yum-presto will help a lot more. But maybe there should be also delta-xml > > > files for the repository metadata, because it takes very long to download > > > these, too, with a slow connection. > > > > > > Regards, > > > Till > > > > Right, this is a very serious point. Right now, the meta data in my /var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to download via a standard analog modem connection! > > I'm looking into generating deltas for the xml, but there are a few > other things on my plate at the moment. The real issue is that it's not > always xml files that we download...sometimes we get sqlite files. > > What we need is to have a program that uses the modified bsdiff > algorithm in deltarpm to generate differences between regular files, not > just deltarpms. What's been discussed on yum-devel is generating a textual diff from old-repodata to new-repodata so we can produce a comparable sqlite w/o downloading as much. -sv From skvidal at linux.duke.edu Sun Jun 10 18:04:04 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Jun 2007 14:04:04 -0400 Subject: apt-proxy for yum? (Re: The updates firehose) In-Reply-To: <466BD12E.10403@leemhuis.info> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <466BD12E.10403@leemhuis.info> Message-ID: <1181498644.14809.35.camel@rivendell> On Sun, 2007-06-10 at 12:23 +0200, Thorsten Leemhuis wrote: > Nice solution. > > But as a side note to that: I in fact had a local update mirror for Core > in the past, but with the Core and Extras merge I don't have one, as the > space and download requirements drastically increased. So much that > having a local mirror is not worth the trouble if you don't have more > then 10 (?) machines with Fedora afaics. So in this regard the merge > made things worse for me. > > What I'd like to have these days is a kind transparent apt-proxy ( > http://apt-proxy.sourceforge.net/ ) for yum, that keeps packages in a cache. > repotrack. it'll download the packages you want and all of the dependencies for those packages (recursively) to a local cache. or reposync which is like rsync for yum repos. > Sure, squid can help with that, but a more intelligent solution (package > still in the repo? only one ppc machine in the network, so don't cache > ppc download, ...; package part of standard-install, so keep in in the > cache if possible) could do a whole lot better. that intelligence is in the form of scripting, at some point there is a diminishing return on the scripting versus just downloading everything in a single swath. -sv From davej at redhat.com Sun Jun 10 18:20:23 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 10 Jun 2007 14:20:23 -0400 Subject: RFR: GIT Package VCS In-Reply-To: <20070608001130.GP16879@petra.dvoda.cz> References: <1181140282.8071.9.camel@erebor.boston.redhat.com> <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <20070608001130.GP16879@petra.dvoda.cz> Message-ID: <20070610182023.GA29512@redhat.com> On Fri, Jun 08, 2007 at 02:11:30AM +0200, Karel Zak wrote: > On Thu, Jun 07, 2007 at 11:04:56PM +0200, Nicolas Mailhot wrote: > > Not surprisingly, someone like Andrew Morton that needs to rebase > > regularly from Linus *and* trace transient patches uses quilt instead of > > an exploded vcs > > Ask Linus what he thinks about Andrew's quilt :-) I think that's > personal choice only. It's not. They're doing two different jobs, and the tools to do each efficiently are different. Linus' role is to pull from many disparate sources and end up with a consistent tree. For this git wins, hands down. However, stuff that gets into Linus' tree usually stays there. If something is merged that turns out to be broken, it's usually patched with a follow-up patch, or very rarely.. reverted. Andrew on the other juggles thousands of patches, and regularly just drops a bunch of them if they turn out to not work out. The ability to do this easily is why quilt wins over git. Doing a dozen git reverts on patches you merged earlier _really_ sucks if you've got subsequent patches that sit on top of those. > I'm almost sure that someone other (for example > Linus) will use GIT instead quilt for same job. I tried it during F7 after FUDCon. I thought it'd work out too. It didn't. As soon as rebasing broke Xen, it became a nightmare, as I couldn't easily drop it. It became easier to just regenerate the tree from scratch without xen ever having been included. (This however kills your history). Compare this to the method we use today, where I just comment out some %patch's, and maybe rediff 1-2 of the follow-on patches. This approach isn't too unlike quilt. Dave -- http://www.codemonkey.org.uk From lmacken at redhat.com Sun Jun 10 19:31:55 2007 From: lmacken at redhat.com (Luke Macken) Date: Sun, 10 Jun 2007 15:31:55 -0400 Subject: The updates firehose In-Reply-To: <200706092223.13366.opensource@till.name> References: <200706091605.00638.jkeating@redhat.com> <200706092223.13366.opensource@till.name> Message-ID: <20070610193155.GA27167@tomservo.rochester.rr.com> On Sat, Jun 09, 2007 at 10:23:10PM +0200, Till Maas wrote: > On Sa Juni 9 2007, Jesse Keating wrote: > > > coming from Extras where it was just fire and forget. While that might be > > fun for the maintainer, is it fun for the user? Is it fun for the user > > with a slow connection? > > A slow connection is never fun ;-). But seriously, nobody is forced to update > and thanks to bodhi and iirc the yum-security plugin[1] it is even possible > to install only security updates. Also I guess there are many updates from > Extras Packages, that are released now because of the Freeze, so the amount > of updates will be less the next weeks. And the user in me likes up to date > software very much. And to make it more fun for users with a slow connection, > yum-presto will help a lot more. But maybe there should be also delta-xml > files for the repository metadata, because it takes very long to download > these, too, with a slow connection. > > Regards, > Till > > [1] But I don't know, whether or not it is already in Fedora 7 yum-security is in Fedora 7 repos, but will not yet work properly with Fedora 7 updates at the moment, as bodhi does not currently insert the updateinfo.xml into the repository yet. We recently changed how we create our update repositories, so I need tweak bodhi to have it insert this updateinfo post-mashing. Give me a day or so and I'll have it in there. luke From pertusus at free.fr Sun Jun 10 19:44:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 10 Jun 2007 21:44:07 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <466C1130.4030508@redhat.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <466C1130.4030508@redhat.com> Message-ID: <20070610194407.GA3907@free.fr> On Sun, Jun 10, 2007 at 10:56:48AM -0400, Christopher Aillon wrote: > Ville Skytt? wrote: > >yelp comes with a dependency chain. In the case of dia, adding a > >dependency on yelp (whether directly or indirectly if the dep is in some > >gnome lib packages), that right stuff would result in the need to > >additionally install yelp, desktop-file-utils, docbook-dtds, > >fedora-bookmarks, firefox, gnome-doc-utils, libXt, libbeagle, nspr, nss, > >openjade, opensp, scrollkeeper, sgml-common, and xml-common. > > I think your example is a great one. Do we really want to force an app > like dia to pull in all this crap just to use it? Do we want to > basically force everyone that uses a GUI to install firefox and > libbeagle? nspluginwrapper is going to be a requirement of the browser > stack soon. XULrunner is going to come with an additional set of > dependencies. In the case of gnochm, requiring yelp doesn't seem to me to add that much dependencies, it only adds firefox, but I don't think it is very common to want gnochm and don't want firefox. yelp allows to have a working help, so it seems to me that it is better to require yelp in this case. So, to me, the right thing should be to leave the packager choice. It doesn't prevent somebody to come up with a document explaining the pro and cons of adding this Requires, on the contrary it should certainly be helpful. -- Pat From otaylor at redhat.com Sun Jun 10 19:49:53 2007 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 10 Jun 2007 15:49:53 -0400 Subject: python-twisted needs a newer version In-Reply-To: <1181472701.8369.3.camel@localhost.localdomain> References: <1181472701.8369.3.camel@localhost.localdomain> Message-ID: <1181504993.21221.10.camel@huygens.home.fishsoup.net> On Sun, 2007-06-10 at 16:21 +0530, Deependra Singh Shekhawat wrote: > Hi, > > Do the package maintainer of python-twisted doesn't feels that we need a > newer version of it. Right now fedora 7 has 2.4.0-6.fc7 and twisted 2.5 > was released in Jan. 2007. > > Today I was thinking to implement a XMPP client from python but saw that > we don't have support for XMPP client in twisted 2.4 and only available > in 2.5. I'm not really sure what the "official" twisted XMPP client is ... there seems to be several of them. But the XMPP support in python-twisted-words-0.4.0 (what's in Fedora currently) worked fine for me recently. - Owen (Not saying that that python-twisted-core shouldn't be updated...) From kanarip at kanarip.com Sun Jun 10 20:05:06 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 10 Jun 2007 22:05:06 +0200 Subject: Web based interface for custom spins In-Reply-To: <1181496836.14809.23.camel@rivendell> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> <1181496836.14809.23.camel@rivendell> Message-ID: <466C5972.8030703@kanarip.com> seth vidal wrote: > > let the angst and flames begin. > -sv > Not exactly starting yet, but here's my $ 0.02: It doesn't really matter what purpose or plan is behind all this, but for me it certainly adds to the weight being given to a web-interface driven model. I'd like to know who's involved here, so that we can get our ducks in a row and start shooting. Kind regards, Jeroen van Meeuwen -kanarip From ml at deadbabylon.de Sun Jun 10 20:09:53 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 10 Jun 2007 22:09:53 +0200 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <20070609191838.69C33152131@buildsys.fedoraproject.org> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> Message-ID: <20070610220953.54ccbc56@localhost.localdomain> Am Sat, 9 Jun 2007 15:18:38 -0400 (EDT) schrieb buildsys at fedoraproject.org: > > Packages built and released for Fedora Extras 6: 38 > Packages built and released for Fedora Extras 5: 9 What about f7? Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Jun 10 20:15:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 11 Jun 2007 01:45:43 +0530 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <20070610220953.54ccbc56@localhost.localdomain> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <20070610220953.54ccbc56@localhost.localdomain> Message-ID: <466C5BEF.80802@fedoraproject.org> Sebastian Vahl wrote: > Am Sat, 9 Jun 2007 15:18:38 -0400 (EDT) > schrieb buildsys at fedoraproject.org: > >> Packages built and released for Fedora Extras 6: 38 > >> Packages built and released for Fedora Extras 5: 9 > > What about f7? F7 doesn't have extras. It is part of the rawhide report. Rahul From jon at fedoraunity.org Sun Jun 10 20:21:07 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Sun, 10 Jun 2007 14:21:07 -0600 Subject: Web based interface for custom spins In-Reply-To: <1181496836.14809.23.camel@rivendell> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> <1181496836.14809.23.camel@rivendell> Message-ID: <1181506867.5885.21.camel@damaestro> On Sun, 2007-06-10 at 13:33 -0400, seth vidal wrote: > On Sun, 2007-06-10 at 11:58 +0200, Nicolas Mailhot wrote: > > Le dimanche 10 juin 2007 ? 15:23 +0530, Rahul Sundaram a ?crit : > > > Nicolas Mailhot wrote: > > > > Le dimanche 10 juin 2007 ? 08:44 +0530, Rahul Sundaram a ?crit : > > > > > > > >> Having a web interface would allow anyone to select the package groups > > > >> and individual packages and get a ISO image for download. I posted to > > > >> fedora-infrastructure list before but we need a web app before talking > > > >> about deploying it. > > > > > > > > Yay for killing bandwidth > > > > > > Ignoring the obvious end user benefits? > > > > There are no obvious end-user benefits if an infrastructure that could > > handle lots of users melts under a few doing iso spins (I suppose you > > want dvd images in there too right?) > > I'm going to say something here which I'm sure will cause a bit of a fit > but I'll say it anyway. The bandwidth and server costs of running a > service like this would be huge. What has been discussed (briefly and > without much detail is this) > > 1. produce an open source tool to produce web-based respins of fedora > (and related) distros. > 2. release this tool so anyone could set up their own site to make > respinds > 3. setup a site so people can respin fedora with updates or with a > different set of packages. There won't be much guarantee that the distro > will work perfectly but its package set should produce dependency > closure. > 4. charge a fee for access to the site we run. That would help us offset > the costs and constrain the set of users a bit. > > That's what has been discussed and only a little bit. Right now the > important part is making a program work to do this, everything after > that is extra. > > let the angst and flames begin. > -sv I just want to step in a weigh in on this. Basically, a web based front-end has already been planned. From the beginning, we had planned on making multiple front-ends. Just because Revisor as it is seen now is a gtk desktop tool, that does not mean we are not working to make *everything* modular and allow *many* front-ends to be written. I hope I don't step on toes when outlining this but I don't want things to be over discussed. Right now what we need is coding. We know what needs to be done, we have a good model. Now it is time to do it. Basic Outline: * Front-end: This will be anything. It will continue to be the gtk client, it will be a web interface, it could be a Qt client, etc. Basically, all this component is supposed to do is poop out a Revisor "template" (as I have been calling it) that will then be moved onto the next step. * "Glue": This step is to take the Revisor "template" and go to action on it. It will setup the needed tasks and do any additional work before the actual tasks are run. * Build Server: Ok, it seems we (as a collective) have misunderstood what I would like Revisor to do at this stage. The current "Revisor", being just a Gtk application, is misleading in the way that it actually does all the work for the end-user. We tried to express our goal of being able to run the Gtk application in "client" mode and define the compose(s) and then send the definition off to a build server by including elements in the application workflow that designate when we would actually had off the process to a remote build server. From the very first day, at the Redhat Summit, we have expressed we will be working on multiple front-ends and will be designing around the fact we want to see a Revisor client and a Revisor server. The build server code will be FOSS, just like everything else has been (pungi, livecd-creator, koji, revisor, etc) and anyone will be able to set one up. As to not go into much implementation detail, *we are working on a web front-end, we are working on a client server model, we are working on allowing anyone to setup a full revisor build system*. This Revisor "build" system could be a single machine running the Revisor gtk application in standalone mode, it could be the Revisor gtk application running in client mode and sending the "template" off to another machine (server) for actually doing the build, it could be a user defining their build on the web-based front-end and then downloading the template to build it locally on their own build server or by feeding the template to the Revisor Gtk application, it could be a user building everything via a web front-end and then waiting for the notification their download is ready. To try to keep it somewhat short -> etc. etc. etc. * Archive Network: This will be like CPAN. Optionally, a user would be able to submit their "template" to the archive so others can build it later. There will be an archive network browser in all the front-ends I am going to be involved with (and at this point that is all of them.) These templates could be built by any of the methods available. A few clicks in the Revisor application, a few clicks on a website, a few clicks to submit the "template" build request off to a server. In the interest of time, there is a brief outline. There are actually 5,000^9999 more things we want to do with the concept. We also welcome ideas and additional "things" we should be doing. We are going to try to be as transparent with Revisor as possible but there are some cases where we are going to end up "just doing it". It seems we need to get more information out to everyone. I will try to get everything we displayed at the Redhat Summit onto the Revisor site. Revisor Site: http://revisor.fedoraunity.org/ Jonathan Steffan daMaestro From jon at fedoraunity.org Sun Jun 10 20:23:47 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Sun, 10 Jun 2007 14:23:47 -0600 Subject: Web based interface for custom spins In-Reply-To: <466C5972.8030703@kanarip.com> References: <466B6C82.5050902@fedoraproject.org> <1181469067.28023.15.camel@rousalka.dyndns.org> <466BCA1D.5060601@fedoraproject.org> <1181469507.28023.18.camel@rousalka.dyndns.org> <1181496836.14809.23.camel@rivendell> <466C5972.8030703@kanarip.com> Message-ID: <1181507028.5885.24.camel@damaestro> On Sun, 2007-06-10 at 22:05 +0200, Jeroen van Meeuwen wrote: > seth vidal wrote: > > > > let the angst and flames begin. > > -sv > > > > Not exactly starting yet, but here's my $ 0.02: > > It doesn't really matter what purpose or plan is behind all this, but > for me it certainly adds to the weight being given to a web-interface > driven model. I'd like to know who's involved here, so that we can get > our ducks in a row and start shooting. Per the web interface, we have a team of Redhat interns working on this. Maybe they will identify themselves so they can take the pounding of this thread as a good initiation. ;-) Jonathan Steffan daMaestro From ml at deadbabylon.de Sun Jun 10 20:30:59 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 10 Jun 2007 22:30:59 +0200 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <466C5BEF.80802@fedoraproject.org> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <20070610220953.54ccbc56@localhost.localdomain> <466C5BEF.80802@fedoraproject.org> Message-ID: <20070610223059.66ed508e@localhost.localdomain> Am Mon, 11 Jun 2007 01:45:43 +0530 schrieb Rahul Sundaram : > Sebastian Vahl wrote: > > Am Sat, 9 Jun 2007 15:18:38 -0400 (EDT) > > schrieb buildsys at fedoraproject.org: > > > >> Packages built and released for Fedora Extras 6: 38 > > > >> Packages built and released for Fedora Extras 5: 9 > > > > What about f7? > > F7 doesn't have extras. Sure. My fault to not explain this. :) > It is part of the rawhide report. But is there existing a report for new packages in Fedora 7? Not all packages that were pushed to rawhide must find their way into f7 (or at least in the same day/week/month). Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mcepl at redhat.com Sun Jun 10 20:38:28 2007 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 10 Jun 2007 22:38:28 +0200 Subject: To Require yelp or not to require yelp References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <200706100819.46335.jkeating@redhat.com> Message-ID: On 2007-06-10, 12:19 GMT, Jesse Keating wrote: > How does yum/rpm know what functionality yelp provides to these > packages? Do we then have to list in the Requires (and auto > requires?!) what each required package does for a given > package? Even if the user saw that this would remove yelp from > all the packages, and he said yes anyway, how does that get > yelp back for them in your firefox-32 scenario? Well, the difference would be that there would be a big noise for the system administrator, so he would know that something significant is going on (major functionality of 96 packages affected; just length of the list would make me think again). And no, in my scenario they wouldn't know WHAT EXACTLY will happen to them, just that some significant functionality of the packages will be affected (because broken soft-dependency Recommends:). Actually, even what you seem to be suggesting was proposed in Debian so than you would have in spec file something like (quoting the Debian list post): Package: mutt Suggests: ispell [adds spell cheking while composing emails] Suggests: urlview [extracts urls from email and can lanuch a web browser] Suggests: mixmaster [allows you to compose anonymized email] Why not? But note that this IS NOT what I suggested. My example would be: Package: epiphany Recommends: yelp Then yum would know that when it removes yelp, some (unknown to yum) functionality of epiphany package will be affected, and it may ask system administrator something in the line of ``Are you sure?'' question. And if confirmed (or if these Recommends: confirmations would be switched off in /etc/yum.conf) then it would just go ahead and remove yelp. We cannot avoid stupid decisions (and we probably even shouldn't try), but IMHO we could (and we should) try to avoid uninformed decisions and we should follow the path of the least surprise -- when something significant is going to happen in the system, then there should be a bang big enough for sysadmin to notice. Does it make more sense? Matej From laurent.rineau__fedora_extras at normalesup.org Sun Jun 10 20:44:29 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Sun, 10 Jun 2007 22:44:29 +0200 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <20070610223059.66ed508e@localhost.localdomain> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <466C5BEF.80802@fedoraproject.org> <20070610223059.66ed508e@localhost.localdomain> Message-ID: <200706102244.29700@rineau.tsetse> On Sunday 10 June 2007 22:30:59 Sebastian Vahl wrote: > But is there existing a report for new packages in Fedora 7? Not all > packages that were pushed to rawhide must find their way into f7 (or at > least in the same day/week/month). You can find that information at: https://admin.fedoraproject.org/updates/F7 -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From mmcgrath at redhat.com Sun Jun 10 20:55:30 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 10 Jun 2007 15:55:30 -0500 Subject: grsecurity In-Reply-To: <466BFF0A.3070405@martin-papadopoulos.de> References: <466BF91A.7030300@martin-papadopoulos.de> <1181482554.3686.33.camel@ignacio.lan> <466BFF0A.3070405@martin-papadopoulos.de> Message-ID: <466C6542.4080102@redhat.com> Martin Papadopoulos wrote: > Ignacio Vazquez-Abrams schrieb: > >> On Sun, 2007-06-10 at 15:14 +0200, Martin Papadopoulos wrote: >> >> >>> has anyone considerd grsecurity as part of fedora ? >>> >>> >> Are you suggesting that Fedora ship both SELinux AND grsecurity? >> >> >> > that is a good idea, i would say yes ! > heh, I love it. When someone asks "do you run kde or gnome" someone usually says "kde" or someone may say "gnome", now when we ask "do you run SELinux or grsecurity?" They'll just say 'no' :) -Mike From mschwendt.tmp0701.nospam at arcor.de Sun Jun 10 21:00:58 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 10 Jun 2007 23:00:58 +0200 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <466C5BEF.80802@fedoraproject.org> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <20070610220953.54ccbc56@localhost.localdomain> <466C5BEF.80802@fedoraproject.org> Message-ID: <20070610230058.41c240e2.mschwendt.tmp0701.nospam@arcor.de> On Mon, 11 Jun 2007 01:45:43 +0530, Rahul Sundaram wrote: > Sebastian Vahl wrote: > > Am Sat, 9 Jun 2007 15:18:38 -0400 (EDT) > > schrieb buildsys fedoraproject org: > > > >> Packages built and released for Fedora Extras 6: 38 > > > >> Packages built and released for Fedora Extras 5: 9 > > > > What about f7? > > F7 doesn't have extras. It is part of the rawhide report. No, it isn't. Rawhide is not F7. From wtogami at redhat.com Sun Jun 10 21:17:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 10 Jun 2007 17:17:01 -0400 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <466C6A4D.8070207@redhat.com> Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. > > Seriously. We're drowning our users in updates. Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Is it fun for the user with > a slow connection? > > Keep in mind that updates now encompass Core/Extras and *new* added packages. A better question would be to ask, of the packages users actually have INSTALLED are updates really churning faster now than before? I would expect no if you look at Core + Extras of previous releases. Presto would be the next important step to formalize to make the updating process more tolerable to users. Warren Togami wtogami at redhat.com From Axel.Thimm at ATrpms.net Sun Jun 10 21:23:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 10 Jun 2007 23:23:49 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> Message-ID: <20070610212349.GE2371@neu.nirvana> On Sun, Jun 10, 2007 at 02:10:10PM +0200, Matej Cepl wrote: > @Christopher: I have this scenario (taken out of bug > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242673) -- > user removes firefox from his system (for example, because he > wants to install firefox.i386 instead of firefox.x86_64). Yum > dutifuly notes, that depending package yelp will be also removed. Doesn't this remind a bit like the ten year old "Windows needs Explorer" issues, only now "Fedora needs Firefox"? Maybe firefox should be split into libs and non-libs? yelp only needs libgtkembedmoz.so, libxpcom.so, libxpcom_core.so and gecko-libs, not firefox itself. Requiring yelp only because an app ships a yelp file is like requiring evince for shipping pdf docu or firefox for shipping html docu. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Sun Jun 10 21:34:04 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 10 Jun 2007 23:34:04 +0200 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <200706102244.29700@rineau.tsetse> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <466C5BEF.80802@fedoraproject.org> <20070610223059.66ed508e@localhost.localdomain> <200706102244.29700@rineau.tsetse> Message-ID: <20070610233404.8c2bb132.mschwendt.tmp0701.nospam@arcor.de> On Sun, 10 Jun 2007 22:44:29 +0200, Laurent Rineau wrote: > On Sunday 10 June 2007 22:30:59 Sebastian Vahl wrote: > > But is there existing a report for new packages in Fedora 7? Not all > > packages that were pushed to rawhide must find their way into f7 (or at > > least in the same day/week/month). > > You can find that information at: > https://admin.fedoraproject.org/updates/F7 http://www.redhat.com/mailman/listinfo/fedora-package-announce From ml at deadbabylon.de Sun Jun 10 21:51:49 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 10 Jun 2007 23:51:49 +0200 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <200706102244.29700@rineau.tsetse> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <466C5BEF.80802@fedoraproject.org> <20070610223059.66ed508e@localhost.localdomain> <200706102244.29700@rineau.tsetse> Message-ID: <20070610235149.1896aa84@localhost.localdomain> Am Sun, 10 Jun 2007 22:44:29 +0200 schrieb Laurent Rineau : > On Sunday 10 June 2007 22:30:59 Sebastian Vahl wrote: > > But is there existing a report for new packages in Fedora 7? Not all > > packages that were pushed to rawhide must find their way into f7 > > (or at least in the same day/week/month). > > You can find that information at: > https://admin.fedoraproject.org/updates/F7 On this page only the updated packages are shown. I'm searching for the newly integrated packages in f7? Or am I missing something there? Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kzak at redhat.com Sun Jun 10 23:18:59 2007 From: kzak at redhat.com (Karel Zak) Date: Mon, 11 Jun 2007 01:18:59 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <20070610182023.GA29512@redhat.com> References: <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <20070608001130.GP16879@petra.dvoda.cz> <20070610182023.GA29512@redhat.com> Message-ID: <20070610231859.GQ16879@petra.dvoda.cz> On Sun, Jun 10, 2007 at 02:20:23PM -0400, Dave Jones wrote: > > I'm almost sure that someone other (for example > > Linus) will use GIT instead quilt for same job. > > I tried it during F7 after FUDCon. I thought it'd work out too. > It didn't. As soon as rebasing broke Xen, it became a nightmare, > as I couldn't easily drop it. It became easier to just What not? You need to 1/ checkout code to a temporary branch, 2/ remove the patch (reset --hard) and 3/ rebase (--onto tmp) to the original branch. Well, I agree this is definitely less elegant than comment out some %patch. > regenerate the tree from scratch without xen ever having been > included. (This however kills your history). > > Compare this to the method we use today, where I just comment > out some %patch's, and maybe rediff 1-2 of the follow-on patches. The problem is that the method we use today doesn't support anything like rediffing. The "rediff 1-2" is nightmare with rpmbuild + gendiff. > This approach isn't too unlike quilt. Yes, but the quilt is better. It supports rediffing ("quilt refresh"). When I think about the way how I use CVS for Fedora packages -- I have to say: I needn't SCM for *patches management*. I need SCM when I work on changes to source code. The method we use today is silly -- we use (ugly, centralized) *source code* management tool for *patches management*. The other disadvantage is that the method isn't integrated with spec file management (you still need to manually edit your spec files). Karel -- Karel Zak From jkeating at redhat.com Sun Jun 10 23:24:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 19:24:46 -0400 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <20070610235149.1896aa84@localhost.localdomain> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <200706102244.29700@rineau.tsetse> <20070610235149.1896aa84@localhost.localdomain> Message-ID: <200706101924.49346.jkeating@redhat.com> On Sunday 10 June 2007 17:51:49 Sebastian Vahl wrote: > > You can find that information at: > > ? https://admin.fedoraproject.org/updates/F7 > > On this page only the updated packages are shown. I'm searching for the > newly integrated packages in f7? Or am I missing something there? New packages for Fedora 7 are released as updates. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 23:29:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 19:29:15 -0400 Subject: The updates firehose In-Reply-To: <466C6A4D.8070207@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <466C6A4D.8070207@redhat.com> Message-ID: <200706101929.15205.jkeating@redhat.com> On Sunday 10 June 2007 17:17:01 Warren Togami wrote: > Keep in mind that updates now encompass Core/Extras and *new* added > packages. ?A better question would be to ask, of the packages users > actually have INSTALLED are updates really churning faster now than > before? ?I would expect no if you look at Core + Extras of previous > releases. > > Presto would be the next important step to formalize to make the > updating process more tolerable to users. I know that we're seeing more because previous Extras is going through bodhi now. The point is that we're noticing how many they are now (: Just seeking opinions. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jun 10 23:38:41 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 Jun 2007 01:38:41 +0200 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <1181518722.3233.7.camel@mccallum.corsepiu.local> On Sat, 2007-06-09 at 16:05 -0400, Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? No. > We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. Yes, and ... IMO, this is expected and not unusual. > Seriously. We're drowning our users in updates. You aren't, because users will only receive those updated packages they have install. > Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? It's partially a consequence of a "release early/release often policy", which applied to released packages means "release once a bug is fixed". Though you repeatedly have stated not to be wanting to accept this kind of policy, it is the policy which many people (comprising me) consider the only viable release policy. > Is it fun for the user with a slow connection? Is Fedora usable for users with slow connections? No, it has never been and has always required tricks. Ralf From rc040203 at freenet.de Mon Jun 11 00:06:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 Jun 2007 02:06:36 +0200 Subject: The updates firehose In-Reply-To: <200706100732.03368.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070610084816.GC30166@ryvius.pekin.waw.pl> <200706100732.03368.jkeating@redhat.com> Message-ID: <1181520396.3233.10.camel@mccallum.corsepiu.local> On Sun, 2007-06-10 at 07:31 -0400, Jesse Keating wrote: > On Sunday 10 June 2007 04:48:16 Dominik 'Rathann' Mierzejewski wrote: > > I feel like you're saying that Core's "culture" (whatever you mean by that) > > should have precedence over Extras' and that "your way" is better than > > "our way". I assure you that Extras maintainers didn't just "fire and > > forget" their updates. They were tested. Yes, some accidents happened, but > > that was the price of greater freedom the maintainers used to have. So > > please don't try to discourage those who managed to put up with all the new > > obstacles any further. > > I didn't mean to say that Core's was better. Just different. Core was worse ... Core maintainers not shipping updated packages was/is the reason for me to locally rebuild "up-distro" packages or locally build patched packages. Ralf From pertusus at free.fr Sun Jun 10 19:50:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 10 Jun 2007 21:50:00 +0200 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <20070610195000.GB3907@free.fr> On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. These numbers are useless, in my opinion. Among those updates how many are problematic? Still nn my opinion those are not problematic: * fix important bug * interesting new features, without important and backward incompatible changes * new package * soname change, but with a compat (including a compat-devel) package * specialzed software with small userbase and a packager knowing what he is doing So, how much left after removing those? -- Pat From linux_4ever at yahoo.com Sun Jun 10 22:00:55 2007 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 10 Jun 2007 15:00:55 -0700 (PDT) Subject: The updates firehose In-Reply-To: <466C6A4D.8070207@redhat.com> Message-ID: <461898.64541.qm@web51509.mail.re2.yahoo.com> >Keep in mind that updates now encompass Core/Extras and *new* added >packages. A better question would be to ask, of the packages users >actually have INSTALLED are updates really churning faster now than >before? Yes they are. Here's a couple packages that should be rock solid steady that are being updated *way* to much: xinetd, tcp_wrappers, bind. I can cite more, but these should be easily verifiable. The fact that there is a mad rush to pump out updates says something about the process is broken. Either the freeze did not let packages that had real problems get fixed, we are not doing a good enough QA job in rawhide, or people's standards have lowered as to when to do a release for a stable series. >Presto would be the next important step to formalize to make the >updating process more tolerable to users. Presto will help download speed, but we still have a problem where too many updates are being issued in a stable release. Seriously, we need a speedbump to force some restraint if we don't slow it down. All these updates can cause a package to get out of sync with SE Linux, which then causes us to rush out a new SE Linux policy package. -Steve ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php From jamatos at fc.up.pt Mon Jun 11 00:14:31 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Mon, 11 Jun 2007 01:14:31 +0100 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <200706110114.33068.jamatos@fc.up.pt> On Saturday 09 June 2007 21:05:00 Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? ?We've > had 138 "stable" updates, and 177 current "testing" updates. ?If all those > were to go stable, we're talking over 300 updates, in just over a week. Jesse you know that due to the freeze policy there are lots of 0-day updates, I assume that your numbers don't take into account that. So in a sense that number should represent (more or less) three weeks worth of updates. Ironically this message remembered me one article by Jon Corbet about RHL y.x (I don't remember which x and 5<=y<=7) when there were over 100 Mb of updates since the initial release (one CD at the time), that meant that the updates represented almost 20% of the original release. Some years after that post I am still reading (and subscribing) Linux Weekly News and using a distribution with a high number of updates (and in some cases being the responsible for them). I like both. :-) -- Jos? Ab?lio From spng.yang at gmail.com Mon Jun 11 01:38:09 2007 From: spng.yang at gmail.com (Ken YANG) Date: Mon, 11 Jun 2007 09:38:09 +0800 Subject: reply-to-list addons cant use on fedora thunderbird version In-Reply-To: <466B52D9.4090203@fedoraproject.org> References: <466A404F.1010607@gmail.com> <466B52D9.4090203@fedoraproject.org> Message-ID: <466CA781.9080202@gmail.com> Rahul Sundaram wrote: > Ken YANG wrote: >> hi all, >> >> i notice there is a nice add-on about reply-to-mailing-list: >> >> http://lists.opensuse.org/opensuse/2006-11/msg03582.html >> http://alumnit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension >> >> but after i install, it can not work, as wiki said, maybe need a >> patch for thunderbird, it seems suse thunderbird version can run >> this sort of add-on >> >> is fedora has similar reply-to-list addon? > > If it is not upstream and requires a patch that is unlikely to be in > Fedora. i see, thank you very much > > Rahul > From jeff at ocjtech.us Mon Jun 11 02:28:34 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sun, 10 Jun 2007 21:28:34 -0500 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181400854.3691.41.camel@lt21223.campus.dmacc.edu> <1181452633.3691.153.camel@lt21223.campus.dmacc.edu> Message-ID: <1181528914.3691.173.camel@lt21223.campus.dmacc.edu> On Sun, 2007-06-10 at 06:17 +0000, Bojan Smojver wrote: > Jeffrey C. Ollie ocjtech.us> writes: > > > Once you know more about source code control you'll understand that > > having the history that went into a patch (and into the source code that > > the patch is for) lets you do amazing things with patches, like rebase > > them so that they apply to new versions of released software. > > Just reading Git crash course for SVN lusers (http://git.or.cz/course/svn.html) > and they are taking about conflicts during a merge: > > "[...] if any changes conflicted, git merge will report them and let you resolve > them, updating the rest of the tree already to the result state; you can git > commit when you resolve the conflicts." > > To me, this reads as if each maintainer still needs to understand the new > upstream code in order to rework the patches so that they apply. Is that what > you mean by "rebase"? Fix them by hand so that they actually work? Let's say that when project foobar released v1.0, their source code repository looked like this: +-1.0 V A--B--C When foobar v1.0 gets packaged up by Fedora, the package maintainer adds some patches to change some defaults or fix some compiler warnings, and ends up with something that looks like this: +-1.0 V A--B--C \ X--Y--Z Later, project foobar releases v2.0: +-1.0 +-2.0 V V A--B--C--D--E--F \ X--Y--Z "Rebasing" is taking patches X, Y and Z, and computing patches X', Y' and Z' so that the history looks like this: +-1.0 +-2.0 V V A--B--C--D--E--F \ X'--Y'--Z' X', Y' and Z' may be the same patches, just with different line numbers, or maybe sections of the patches are no longer needed since upstream may have incorporated parts of X, Y, or Z in commits D, E, or F. Source code management systems like Git can automate a lot of the work of rebasing a series of patches, but they can't do everything. Conflicts will have to be resolved by hand. And even once the new patches apply cleanly, the maintainer will still have to test the patches to make sure that they still work. Conflicts happen during the rebasing process when commits D, E, or F alter the same code as patches X, Y, or Z. Yes, then the package maintainer will need to understand the code well enough to resolve the conflicts manually. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Mon Jun 11 03:12:23 2007 From: walters at redhat.com (Colin Walters) Date: Sun, 10 Jun 2007 23:12:23 -0400 Subject: The updates firehose In-Reply-To: <1181482619.3445.9.camel@localhost.localdomain> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> <1181482619.3445.9.camel@localhost.localdomain> Message-ID: <1181531543.3840.4.camel@neutron.verbum.private> On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote: > The current classification we have is just > "bugfix - enhancement - security". It would be nice add some more > categories to this, like "cosmetic" (for minor packaging cleanups like > directory ownership handling), and some way to differentiate by > severity. Why would someone push an update for cosmetic issues? From orion at cora.nwra.com Mon Jun 11 04:27:11 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Sun, 10 Jun 2007 22:27:11 -0600 (MDT) Subject: The updates firehose In-Reply-To: <466B1068.7030002@codewiz.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> Message-ID: <3689.71.208.222.235.1181536031.squirrel@www.cora.nwra.com> > Christopher Blizzard wrote: > >> Are people complaining? > > I don't complain when it happens with my own computer that's > being updated daily... but it's painful when you update a > dozen of desktops in the office to F7 and all them want to > download 500MB worth of updates the first time they boot. > > Yes, I could use a local Fedora mirror. And, in fact, > I do. But then I'd have to customize the yum config on > all clients to go look there. > Add the updates repo at upgrade/install time. - Orion From notting at redhat.com Mon Jun 11 05:01:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 01:01:08 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <200706101224.09692.ville.skytta@iki.fi> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> Message-ID: <20070611050108.GB18869@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > > You'd still need the gnome libraries which should pull in the right stuff. > > yelp comes with a dependency chain. In the case of dia, adding a dependency > on yelp (whether directly or indirectly if the dep is in some gnome lib > packages), that right stuff would result in the need to additionally install > yelp, desktop-file-utils, docbook-dtds, fedora-bookmarks, firefox, > gnome-doc-utils, libXt, libbeagle, nspr, nss, openjade, opensp, scrollkeeper, > sgml-common, and xml-common. Surely this is a function call in a common gnome library? gnome_show_help, or whatever? Then, that library should require yelp. Of course, I suppose the app it launches with the help URL is configurable via gconf, so the requires needs dynamically generated based on the union of all users' current gconf keys and AAAAARGH. Bill From chitlesh at fedoraproject.org Mon Jun 11 05:03:26 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 11 Jun 2007 07:03:26 +0200 Subject: reply-to-list addons cant use on fedora thunderbird version In-Reply-To: <466CA781.9080202@gmail.com> References: <466A404F.1010607@gmail.com> <466B52D9.4090203@fedoraproject.org> <466CA781.9080202@gmail.com> Message-ID: <13dbfe4f0706102203l79d3c537y2bf7ad922f206699@mail.gmail.com> On 6/11/07, Ken YANG wrote: > > If it is not upstream and requires a patch that is unlikely to be in > > Fedora. > > i see, thank you very much Just for the sake of FYI, if you really need such feature on fedora, _at least_ kmail (yum install kdepim) can be useful to you. Chitlesh -- http://clunixchit.blogspot.com From notting at redhat.com Mon Jun 11 05:05:45 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 01:05:45 -0400 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> Message-ID: <20070611050545.GC18869@nostromo.devel.redhat.com> Gianluca Sforna (giallu at gmail.com) said: > On 6/9/07, Bernardo Innocenti wrote: > >Yes, I could use a local Fedora mirror. And, in fact, > >I do. But then I'd have to customize the yum config on > >all clients to go look there. > > > > Guru Labs have a nice howto for solving that problem (/me bookmarking it...) > > http://www.gurulabs.com/goodies/YUM_automatic_local_mirror.php Why not just use: https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003654.html ? Bill From pekkas at netcore.fi Mon Jun 11 05:06:39 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 11 Jun 2007 08:06:39 +0300 (EEST) Subject: The updates firehose - automatic local mirrors In-Reply-To: <20070610013123.GE26897@lists.us.dell.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> Message-ID: On Sat, 9 Jun 2007, Matt Domsch wrote: > On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote: >> Christopher Blizzard wrote: >> >>> Are people complaining? >> >> I don't complain when it happens with my own computer that's >> being updated daily... but it's painful when you update a >> dozen of desktops in the office to F7 and all them want to >> download 500MB worth of updates the first time they boot. >> >> Yes, I could use a local Fedora mirror. And, in fact, >> I do. But then I'd have to customize the yum config on >> all clients to go look there. > > You can add your local private mirror to mirrormanager, add a netblock > that covers your address space, and all your clients will then pull > from your local mirror rather than public mirrors, with no change on > the clients. > > https://admin.fedoraproject.org/mirrormanager > http://fedoraproject.org/wiki/Infrastructure/Mirroring (My definition of 'local' = in the same country or region of countries. As shown in later messages, others want to create custom repositories for organization's internal use, but that requires different tools.) Even better would be that only local mirrors would be shown automatically. Nowadays, countries with less than 3 mirrors don't get this optimization. This would require rather simple updates to the http://mirrors.fedoraproject.org/mirrorlist script. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From notting at redhat.com Mon Jun 11 05:08:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 01:08:40 -0400 Subject: The updates firehose In-Reply-To: <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <604aa7910706091349v59e75896w1ccde9783082b61d@mail.gmail.com> <466B45CA.6070605@ieee.org> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> Message-ID: <20070611050840.GD18869@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > I wish we had quantifiable numbers to go along with this to aid > discussion. If a large majority of the updates really are new > packages or niche package updates then i doubt there's much of a > concern from a userbase pov. But we don't have hard numbers for either > 1 or 2. So, this is something I'd *love* to have - some sort of stats on how many people have installed package X; useful for doing checks to see what should or shouldn't be on the DVDs, and so on. I know the mugshot stats exist, but that's not the same. Bill From notting at redhat.com Mon Jun 11 05:09:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 01:09:35 -0400 Subject: The updates firehose In-Reply-To: <200706092017.25476.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <200706092017.25476.jkeating@redhat.com> Message-ID: <20070611050935.GE18869@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > Are you upset with the amount of bandwith we're eating or just based on > > principal? > > Somewhat on principal. The amount of churn in Extras went somewhat unnoticed > to me because there wasn't something like bodhi for them. Now that > everything goes through it it is very apparent that there is an enormous > amount of updates issued. So, let's just stop sending mail. Problem solved! (Seriously, I'm thinking that e-mail with its complete lack of categorization is the wrong method for package updates. Perhaps RSS?) Bill From pekkas at netcore.fi Mon Jun 11 05:12:34 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 11 Jun 2007 08:12:34 +0300 (EEST) Subject: The updates firehose - major updates breaking In-Reply-To: <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Sun, 10 Jun 2007, Michael Schwendt wrote: > On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote: >> The many updates are really Fedora's strength, > > ... and also one of its weaknesses, since the users don't like it at all > if an update breaks something. .. and it's not clear if anyone is interested in hearing about such breakages, or doing anything about them. For example, 'pan' newsreader broke back in 2006. It was upgraded from 'stable' train to 'beta'. Unfortunately, the group configuration is incompatible and you'd need to redo your newsgroups to use it. Neither upstream or the Fedora Extras maintainer has responded to my complaints. I suggested that either there needs to be a better transition path, or the new pan should be shipped as 'pan2' or something else that won't obsolete the old one. The package is still broken in this respect. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From notting at redhat.com Mon Jun 11 05:15:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 01:15:31 -0400 Subject: The Future of Fedora Package Management and the RPM Philosophy In-Reply-To: <200706091532.33453.jkeating@redhat.com> References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181371332.4534.16.camel@rivendell> <1181410090.13239.1.camel@neutron.verbum.private> <200706091532.33453.jkeating@redhat.com> Message-ID: <20070611051531.GF18869@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > Have you used 'make clog' ? It drops the last srpm changelog to a file that > you can use with 'make clog; cvs commit -F clog' Then you can easily use the > spec file's comment for the VCS. It's still duplication of data. Bill From a.badger at gmail.com Mon Jun 11 05:31:20 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 Jun 2007 22:31:20 -0700 Subject: To Require yelp or not to require yelp In-Reply-To: <20070611050108.GB18869@nostromo.devel.redhat.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> Message-ID: <1181539880.19531.26.camel@localhost.localdomain> On Mon, 2007-06-11 at 01:01 -0400, Bill Nottingham wrote: > Ville Skytt? (ville.skytta at iki.fi) said: > > > You'd still need the gnome libraries which should pull in the right stuff. > > > > yelp comes with a dependency chain. In the case of dia, adding a dependency > > on yelp (whether directly or indirectly if the dep is in some gnome lib > > packages), that right stuff would result in the need to additionally install > > yelp, desktop-file-utils, docbook-dtds, fedora-bookmarks, firefox, > > gnome-doc-utils, libXt, libbeagle, nspr, nss, openjade, opensp, scrollkeeper, > > sgml-common, and xml-common. > > Surely this is a function call in a common gnome library? gnome_show_help, > or whatever? > > Then, that library should require yelp. Of course, I suppose the app > it launches with the help URL is configurable via gconf, so the requires > needs dynamically generated based on the union of all users' current > gconf keys and AAAAARGH. > I was notified of this for one of my packages via Matej's script. After talking to people on fedora-desktop I opened this bug against libgnomeui:: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243478 The recommendation there is to have libgnomeui depend on yelp. Creating a virtual provide of HelpBrowser or DocbookXmlViewer in yelp and having libgnomeui require that might work even better. In addition, I spent a little time tracing the code to see what was happening. There is an API in libgnomeui for help that calls an API in libgnome. The API in libgnome is (I suspect) what is called from most programs. The API uses gnome-vfs2 to invoke a program that can display documents of mime-type application/docbook+xml. yelp is registered for this document type (MimeType=application/docbook+xml in the /usr/share/applications/gnome-yelp.desktop file) I suspect (but have not tried) that a KDE desktop that has a program to display application/docbook+xml would not need yelp installed to display help in a gnome program. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bojan at rexursive.com Mon Jun 11 05:54:25 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 11 Jun 2007 05:54:25 +0000 (UTC) Subject: The Future of Fedora Package Management and the RPM Philosophy References: <1181329218.3903.179.camel@lt21223.campus.dmacc.edu> <1181400854.3691.41.camel@lt21223.campus.dmacc.edu> <1181452633.3691.153.camel@lt21223.campus.dmacc.edu> <1181528914.3691.173.camel@lt21223.campus.dmacc.edu> Message-ID: Jeffrey C. Ollie ocjtech.us> writes: > Conflicts happen during the rebasing process when commits D, E, or F > alter the same code as patches X, Y, or Z. Yes, then the package > maintainer will need to understand the code well enough to resolve the > conflicts manually. That's how understood things to be as well. The important work will actually be in making sure those things work again. Going with an integrated repository instead of pristine source + patches + spec files is a great overkill, IMHO. However, feel free to kill CVS and replace it with something better any day you like :-) -- Bojan From oliver at linux-kernel.at Mon Jun 11 06:47:34 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jun 2007 08:47:34 +0200 Subject: grsecurity In-Reply-To: <466C6542.4080102@redhat.com> References: <466BF91A.7030300@martin-papadopoulos.de> <1181482554.3686.33.camel@ignacio.lan> <466BFF0A.3070405@martin-papadopoulos.de> <466C6542.4080102@redhat.com> Message-ID: <466CF006.8010806@linux-kernel.at> On 06/10/2007 10:55 PM, Mike McGrath wrote: > Martin Papadopoulos wrote: >> Ignacio Vazquez-Abrams schrieb: >> >>> On Sun, 2007-06-10 at 15:14 +0200, Martin Papadopoulos wrote: >>> >>>> has anyone considerd grsecurity as part of fedora ? >>>> >>> Are you suggesting that Fedora ship both SELinux AND grsecurity? >>> >>> >> that is a good idea, i would say yes ! >> > > heh, I love it. When someone asks "do you run kde or gnome" someone > usually says "kde" or someone may say "gnome", xfce :-P > now when we ask "do you > run SELinux or grsecurity?" They'll just say 'no' :) Hmmm. If you ask me two years before, grsec. Now. SELinux. grsec was nice as long as SELinux wasn't in upstream kernel. Now, I see grsec deprecated... -of From oliver at linux-kernel.at Mon Jun 11 07:47:35 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jun 2007 09:47:35 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46691FB4.1090508@warmcat.com> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <46691FB4.1090508@warmcat.com> Message-ID: <466CFE17.7020304@linux-kernel.at> On 06/08/2007 11:21 AM, Andy Green wrote: > Oliver Falk wrote: > >>> I would like to see cross compilation become a standard method in >>> Fedora. It scales where native builds don't. There might be faster arm >>> chips these days, but lets not forget all the underpowered embedded CPUs >>> and costly systems like s390. Bootstrapping is simplified. People >>> without access to hardware can work on build problems (Simulators are >>> good for this too). >> True. But is cross compilation really as reliable as native compilation >> is? I'm not experienced with cross compilation... But I think some >> errors will only occur on *real native hardware*... > > Cross toolchains are made like this: you use your normal host compiler, > for i386 say, to compile the gcc sources configured to emit target, say > ARM, code. So you end up with an i386 executable compiler that emits > ARM code. > > Native compilers would be built on an ARM box or emulation creating an > ARM executable compiler that emits ARM code. But in both cases, the > compiler is coming from the same gcc sources. Of course so far I understood the system already. :-) [ ... ] >> If there are volunteers for a arch and you have some man power who can >> support the ArchTeam, that would be great - I think. If the arch-team >> doesn't want cross compilation..... Let 'em alone. :-) > > Cross is a lot less mysterious and magical than it sounds. Once it is > sorted out according to Fedora's high engineering standards, being able > to build for any supported arch on one physical platform with one > filesystem at native platform speed will in fact be simpler, faster, > more conistent and cheaper than the workarounds. Sure it's not much magic and mystery, but there are some issues we need to think about... (See later posts that I'll write now :-) ). -of From oliver at linux-kernel.at Mon Jun 11 08:00:05 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jun 2007 10:00:05 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <4669AEBC.3070802@redhat.com> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <4669AEBC.3070802@redhat.com> Message-ID: <466D0105.7090608@linux-kernel.at> On 06/08/2007 09:32 PM, Brendan Conoboy wrote: > Oliver Falk wrote: >> Good self introduction. Now we know, that you know what you're talking >> 'bout. :-) > > I pretend well, anyway :-) I'll see if some more folks from my group > will jump in here. > >> True. But is cross compilation really as reliable as native compilation >> is? I'm not experienced with cross compilation... But I think some >> errors will only occur on *real native hardware*... > > Reliable? Sure. But there are problems unique to cross compiling which > must be addressed. You don't want to pull in a host-header instead of a > target-header. Issue number 1. > You also can't run the resulting executables so > post-build testsuites can't be run. Issue number 2. > That said, object and executable > generation is pretty much the same whether your cross compile or > natively compile, so you're going to get functionally identical bits. OK. That might be true for gcc, but how about gcj? Or other compilers? I'm also thinking about python that emits byte-code. Is this code machine independent? I'm not sure; Could google or read, but just want to mention.... >> I think that's the same as with secondary arches. Yes, there must be >> some team supporting the arch, if it's done via cross compilers or on >> native hardware; But with one difference: The people who are involved in >> the 2ndary arch stuff, might not be very experienced with cross >> compilation; Like me and Alpha for example. > > Right- I hope I'm not alienating the folks who want to bring Arm to the > Fedora fold even if it means native compilation. New arches and cross > compiling aren't directly related, but when you put them together > successfully it's very beneficial, but not necessary. Still, I bet > there are more people per capita in the secondary-arch camp interested > in cross compiling than the primary arches. Yes, cross compilation is an interesting; At least for me and I would be happy to be a bit involved; You never stop learning... >> I think for Alpha we will have enough fast machines that can get the job >> done. I don't know about the other arches.... > > That's handy- how will you bootstrap? alphacore.info. We have AC3 (FC5 based). I also was able to update large parts to FC6 and fcdevel. glibc and gcc, well and also a newer 2.6.21 kernel: [root at tyskie ~]# uname -a Linux tyskie.linux-kernel.at 2.6.21-1.3125.fc7 #1 Tue May 15 14:52:47 CEST 2007 alpha alpha alpha GNU/Linux Not all pieces of my/our specs are perfect to be commited to fedora cvs... But I'm bugzilla-ing as much as I can and most pkg-maintainers are helpful and willing to include alpha support; Thinking of secondary arch support... [ ... ] -of From obi at unixkiste.org Mon Jun 11 08:10:00 2007 From: obi at unixkiste.org (Stefan Held) Date: Mon, 11 Jun 2007 10:10:00 +0200 Subject: Unwanted RPM dependencies In-Reply-To: <1181481524.3445.2.camel@localhost.localdomain> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> <1181471430.7684.3.camel@bigbox.unixkiste.local> <1181481524.3445.2.camel@localhost.localdomain> Message-ID: <1181549400.3827.17.camel@workstation.unixkiste.local> Am Sonntag, den 10.06.2007, 09:18 -0400 schrieb Matthias Clasen: > We are not going to remove your ability to configure grub in whatever > way you want, in exactly the same way as you always could. Did i say something else? > > And therefore it would be > > great to have a small fedora-logo-grub.fc8.rpm which does not depend on > > 1000 rpms afterwards. > > Jeremy already stated why we can't do that. Come on. Somebody who set up koji, mock and other stuff for building his own derivate of Fedora should be afraid about 3 lines in the fedora-logos.spec file which declares a sub package should be made for the grub grafic? This doesn't sound like why we "can't" do that. As i said allready all what i am asking for is: generate a grub-logo-rpm which does not need half of the base rpms. Is that really so hard to do? https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00519.html Read this mail again and decide for yourself why this is a good plan. Please. I ever thought this is the place for improvements of Fedora. There is one. Take the chance to do it. Maybe we come to a minimal install without 250Mb not needed stuff on the harddisk. Greetings Stefan. (I will stop this now and file a RFE in Bugzilla) -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jun 11 08:21:50 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 11 Jun 2007 10:21:50 +0200 Subject: x86_64 nightmare on F7 In-Reply-To: References: <1181254357.3950.20.camel@hal9000.oberschlesier.lan> <20070607233137.GE31520@nostromo.devel.redhat.com> <1181263090.6806.5.camel@hal9000.oberschlesier.lan> <20070608113136.54c51426@python3.es.egwn.lan> Message-ID: <20070611102150.5a635ddb@python3.es.egwn.lan> P. Martinez wrote : > For now i do very minimal install with anaconda. > After that i remove all i386 packages. To get > all x86_64 packages sane i do remove and reinstall > them. > Attention - you can't do this with all rpms. For > them that need special attention (rpm itself depends > on some ones) i do an rpm --force -iv . Hint : rpm -e --justdb glibc yum install glibc.x86_64 Of course, you need to beware of scriplets... possibly also passing --noscripts to the erasure. Don't blame me if your system ends up broken, though ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 1.30 1.35 1.09 From andy at warmcat.com Mon Jun 11 08:22:51 2007 From: andy at warmcat.com (Andy Green) Date: Mon, 11 Jun 2007 09:22:51 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466CFE17.7020304@linux-kernel.at> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <46691FB4.1090508@warmcat.com> <466CFE17.7020304@linux-kernel.at> Message-ID: <466D065B.3020604@warmcat.com> Oliver Falk wrote: >>> True. But is cross compilation really as reliable as native compilation >>> is? I'm not experienced with cross compilation... But I think some >>> errors will only occur on *real native hardware*... >> Cross toolchains are made like this: you use your normal host compiler, >> for i386 say, to compile the gcc sources configured to emit target, say >> ARM, code. So you end up with an i386 executable compiler that emits >> ARM code. >> >> Native compilers would be built on an ARM box or emulation creating an >> ARM executable compiler that emits ARM code. But in both cases, the >> compiler is coming from the same gcc sources. > > Of course so far I understood the system already. :-) I wrote it because you mentioned "real native hardware". For testing the resulting packages I completely agree, but for building them it shouldn't matter. If it does matter it's a problem with the compiler or how the package is being built. -Andy From andy at warmcat.com Mon Jun 11 08:28:33 2007 From: andy at warmcat.com (Andy Green) Date: Mon, 11 Jun 2007 09:28:33 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466D0105.7090608@linux-kernel.at> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <4669AEBC.3070802@redhat.com> <466D0105.7090608@linux-kernel.at> Message-ID: <466D07B1.9020802@warmcat.com> Oliver Falk wrote: > On 06/08/2007 09:32 PM, Brendan Conoboy wrote: >> Oliver Falk wrote: >>> Good self introduction. Now we know, that you know what you're talking >>> 'bout. :-) >> I pretend well, anyway :-) I'll see if some more folks from my group >> will jump in here. >> >>> True. But is cross compilation really as reliable as native compilation >>> is? I'm not experienced with cross compilation... But I think some >>> errors will only occur on *real native hardware*... >> Reliable? Sure. But there are problems unique to cross compiling which >> must be addressed. You don't want to pull in a host-header instead of a >> target-header. > > Issue number 1. >From gcc manpage --sysroot=dir Use dir as the logical root directory for headers and libraries. For example, if the compiler would normally search for headers in /usr/include and libraries in /usr/lib, it will instead search dir/usr/include and dir/usr/lib. >> You also can't run the resulting executables so >> post-build testsuites can't be run. > > Issue number 2. Well they can't be run on the build box, that is true. But they can be packaged and run on the real target along with the binary itself, which will still need testing on a real target anyway. >> That said, object and executable >> generation is pretty much the same whether your cross compile or >> natively compile, so you're going to get functionally identical bits. > > OK. That might be true for gcc, but how about gcj? Or other compilers? > I'm also thinking about python that emits byte-code. Is this code > machine independent? I'm not sure; Could google or read, but just want > to mention.... Well look, if I compile "Hello World" on an ARM using an ARM native compiler, it should do the same result as if I compile it on an x86 using an x86 native compiler or I cross compile it somehow, right? All of them print "Hello World" when run on something that can run the result. gcc shouldn't be any different, bugs in the compiler notwithstanding, no matter how you build the same sources they should work identically when you run them, no matter what platform or CPU. -Andy From oliver at linux-kernel.at Mon Jun 11 08:31:22 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jun 2007 10:31:22 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <4669B459.5070401@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> Message-ID: <466D085A.90001@linux-kernel.at> On 06/08/2007 09:56 PM, Brendan Conoboy wrote: [ ... ] >> The build system must be enhanced to support cross compilation. > > This is a really interesting (to me) extension of the build system > requiring enhancements in many areas. > > First, there are primitives in Koji that need to be built up such that, > for instance, x86 knows it can cross build arm tools. To make koji believe it can build arm on x86 should be no problem. But how to tell koji to don't do the %test's. We need to do this on rpm level... > Second, the x86 host needs to be able to retrieve and install arm > dependencies in the arm sys-root (arm's glibc, arm's libX11-devel, etc). Now we need to touch yum... I'm sure Seth can hack up that bit of code. :-) Also mock needs to understand it. > Third, a native/cross hybrid environment needs to be setup to facilitate > the common assumptions made by packages. Previous cross compilation > efforts inside my group have spent a lot of time on this. I bet others > have as well If I'm picturing myself this process: # koji build 1) koji finds deps 2) mock uses yum to retrieve deps 2.1) if it sees gcc, it need to get gcc-cross- 2.2) also true for binutils-cross- 2.3) It needs to retrieve the binaries for the machine running on, else it will not be able to run it (I'm thinking of autoconf, automake, python, etc.) 3) rpm --rebuild --target -$v-$r.src.rpm So for the buildsystem I see at least 4 tools we need to touch: rpm, yum, mock, koji; And eventually setarch. So far the big picture that came up to my mind; Quick'n'dirty of course... [ ... ] >> Social: As a volunteer effort, it is unreasonable to expect existing >> package maintainers to do the work necessary to support cross >> compilation. There must be people to take on that responsibility and >> work with upstream and package maintainers to integrate the necessary >> changes. > > I have read the Secondary Architectures proposal and thread with great > interest. While there may be some overlap of interest with cross > compiling, it's not inherently true. Thus, I'd suggest a cross-team who > would generally be responsible for cross-compilation efforts. This > might break down like so: > > 1. Responsible for parts of the build system dedicated to cross > compilation. > > 2. Maintainers of the cross compilation tools (These would presumably be > rebuilds of gcc and binutils for the cross-targets). > > 3. Make changes to existing packages in cooperation with the package > maintainer. > > 4. Be responsible for fixing builds that fail because of cross > compiling, but succeed when natively built. > > Anybody whose turf I just suggested stepping on, please chime in! At this point the big picture might be the goal, but to reach it, small steps must be taken: *) Bring working cross-tools into Fedora I'm sure this is something more people would be happy to have; Not only the ArchTeam's. *) Make rpm --rebuild ? do something that _makes sense_ :-) Eg. Set the $sysroot and set gcc to gcc-, ...... *) THINK: Do we need to touch setarch? <...> Add more <...> My few cent. :-) -of ------- Footnotes: ?) in this case is a *strange* target for the platform running the command; eg. arm/ppc/alpha/s390 on x86. ?) in this case is the host running yum (eg. i386, but downloading arm/ppc/alpha/s390 packages) From oliver at linux-kernel.at Mon Jun 11 08:36:17 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jun 2007 10:36:17 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466A717A.1050102@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466A717A.1050102@hhs.nl> Message-ID: <466D0981.90009@linux-kernel.at> On 06/09/2007 11:23 AM, Hans de Goede wrote: > David Woodhouse wrote: >> On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote: >>> Building a cross binutils requires kernel headers for the target >>> architecture. Building gcc requires kernel headers and glibc. There >>> are scripts to solve the initial chicken/egg problem of where to get >>> that glibc for a new arch. At some point in the future gcc might not >>> require glibc to build, but we aren't there yet. >> >> Before we get to actually cross-compiling something for release, it >> would be good to get cross-compilers into Fedora. >> >> Making a cross-binutils package isn't hard; it's a relatively >> modification to our existing binutils package to make it build for >> multiple %targets. >> >> Making a cross-gcc package which targets linux-elf is harder, because of >> the evil recursive dependencies to which you refer above. It would be >> good if we could get that working though. >> >> Unfortunately the scripts to which you refer just 'solve' the problem by >> throwing everything together into one huge lump and building gcc, then >> glibc, then rebuilding gcc again. That's not really very useful for us >> when we want the compiler and glibc to be entirely separate packages -- >> and in fact glibc would be a .$TARGET.rpm to be installed into the >> sysroot, while the compiler is a native package. >> >> I haven't looked at this for a while, but IIRC we can build gcc and >> libgcc.a directly, using 'only' header files which can be provided in >> advance. The problem is that we have to dynamically link libgcc.so with >> libc.so? We don't actually need a _real_ libc.so for that though, do we? >> We could just make a dummy DSO with the functions we want, and link >> against that? If we do that, what else still has recursive dependencies? >> > > Notice that I have spends weeks on fixing exactly the problems, with > creating a cross compiling gcc targeting linux with glibc, described > here to build an cross arm toolchain for the gp2x handheld for Fedora. > > Please check: > http://people.atrpms.net/~hdegoede/ > > For all my SRPMS / SPECS for this, with regards to solving the above > metioned problems esp arm-gp2x-linux-gcc.spec is interesting. I think > I've got this one nailed, so before other people start pouring time into > this please first check my work, doing this for other linux-glibc > targets, using Fedora sources instead of the open2x sources I'm using > should be mostly identical. I'll gladly answer any questions. > > Reviews would be welcome to, see: > http://fedoraproject.org/wiki/SIGs/Embedded > > For links to all the review tickets. Thanks for your post Hans; Didn't knew there already is an Embedded SIG; And also that there are already people working on good cross compilers. So there's another cross specialist :-) -of From oliver at linux-kernel.at Mon Jun 11 08:52:17 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 11 Jun 2007 10:52:17 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466D07B1.9020802@warmcat.com> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <4669AEBC.3070802@redhat.com> <466D0105.7090608@linux-kernel.at> <466D07B1.9020802@warmcat.com> Message-ID: <466D0D41.2030903@linux-kernel.at> On 06/11/2007 10:28 AM, Andy Green wrote: > Oliver Falk wrote: >> On 06/08/2007 09:32 PM, Brendan Conoboy wrote: >>> Oliver Falk wrote: >>>> Good self introduction. Now we know, that you know what you're talking >>>> 'bout. :-) >>> I pretend well, anyway :-) I'll see if some more folks from my group >>> will jump in here. >>> >>>> True. But is cross compilation really as reliable as native compilation >>>> is? I'm not experienced with cross compilation... But I think some >>>> errors will only occur on *real native hardware*... >>> Reliable? Sure. But there are problems unique to cross compiling which >>> must be addressed. You don't want to pull in a host-header instead of a >>> target-header. >> Issue number 1. > >>From gcc manpage > > --sysroot=dir > Use dir as the logical root directory for headers and > libraries. For example, if the compiler would normally search for > headers in /usr/include and libraries in /usr/lib, it will > instead search dir/usr/include and dir/usr/lib. Sure, Andy I got it. :-) I just wanted to address it. I understand that there is an easy solution to use another sysroot, but we need to get the packages/headers/libs there :-) >>> You also can't run the resulting executables so >>> post-build testsuites can't be run. >> Issue number 2. > > Well they can't be run on the build box, that is true. But they can be > packaged and run on the real target along with the binary itself, which > will still need testing on a real target anyway. Sure, testing is needed anyway, but if testing at %build level doesn't work, we normally stop and don't build packages... If there would be some automation for this, that would be great. >>> That said, object and executable >>> generation is pretty much the same whether your cross compile or >>> natively compile, so you're going to get functionally identical bits. >> OK. That might be true for gcc, but how about gcj? Or other compilers? >> I'm also thinking about python that emits byte-code. Is this code >> machine independent? I'm not sure; Could google or read, but just want >> to mention.... > > Well look, if I compile "Hello World" on an ARM using an ARM native > compiler, it should do the same result as if I compile it on an x86 > using an x86 native compiler or I cross compile it somehow, right? All > of them print "Hello World" when run on something that can run the > result. gcc shouldn't be any different, bugs in the compiler > notwithstanding, no matter how you build the same sources they should > work identically when you run them, no matter what platform or CPU. Andy, I guess you have enough experience with cross compilers and so I have to believe you. I'm not so ("cross-)experienced(") and that's why I don't *trust* it until I haven't *tried* it :-) -of From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jun 11 08:52:52 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 11 Jun 2007 10:52:52 +0200 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <20070611105252.1d2faa44@python3.es.egwn.lan> Jesse Keating wrote : > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. Keep in mind that quite a few of those are actually new packages. I know that I haven't yet had to issue a single "update" to the F7 packages I maintain, but have already gotten a few new ones in ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 1.47 1.35 1.29 From markmc at redhat.com Mon Jun 11 09:23:50 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 11 Jun 2007 10:23:50 +0100 Subject: RFR: GIT Package VCS In-Reply-To: <200706080705.11909.jkeating@redhat.com> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706072118.04076.jkeating@redhat.com> <1181267967.4070.309.camel@localhost.localdomain> <200706080705.11909.jkeating@redhat.com> Message-ID: <1181553831.3705.74.camel@blaa> > On Thursday 07 June 2007 21:59:27 Toshio Kuratomi wrote: > > On Thu, 2007-06-07 at 21:18 -0400, Jesse Keating wrote: > > > > > > We have two things for the upstream in our package SCM. We have the > > > prestine tarball stashed away in a lookaside, and we have an exploaded > > > tree of the source. We use the exploaded tree of the source to manage > > > our patches to that source and to help with rebases. However the patches > > > we manage always apply to the prestine point. At package build time, the > > > patches we manage + the spec file + the prestine tarball stashed away are > > > combined to make an srpm, and that is shoved through the build system. > > > I wonder. What are we trying to do here? 1) Make hacking on a stack of patches easier 2) Make it easier to re-base - i.e. new upstream tarball, re-generate each of the patches against the new upstream, resolving any conflicts 3) Allow someone to fork a set of patches? e.g. OLPC has their own version of a package with an additional patch, but wants to keep in sync with the Fedora version of the package I'd suggest quilt as a nice simple tool for (1). Stacked git (stg) looks like it makes sense if upstream uses git. The pain point with (2) which quilt doesn't solve well is resolving conflicts. But diff3 style merging is all that's needed there. We could solve (3) by managing patches in an SCM with something like stg, but it might turn out to be too complicated to be useful. > > So I see two ways to store patches: > > vendor-branch > > > > |-- Foo.patch branch > > | > > |-- Bar.patch branch > > > > Foo.patch and Bar.patch both directly apply to the upstream vendor > > branch. > > > > vendor-branch > > > > |-- Foo.patch branch > > | > > |-- Bar.patch branch > > > > Foo.patch is the first patch against vendor-branch. Bar.patch is > > committed to the combination of vendor-branch and Foo.patch. > > > > At first I was hoping to do the first way as it makes it easier to > > cherrypick changes for upstream. However, it quickly became complex as > > we had to manage a separate merge branch that was equivalent to the > > second storage graph. Whenever we rebased we would potentially have to > > remove conflicts from the second graph as well as the first. > > > > So I decided that going directly to the second style was preferable. > > That does not have the enhanced cherrypicking benefits to upstream but > > it still allows us to work with individual patches within the VCS more > > easily than when they were simply patches stored in CVS. > > > > Do you see a way around this limitation? Not really. The way to cherry-pick for upstream is to re-order the graph so that the patches you want to upstream are first in the graph. But the graph can't be ignored when cherrypicking. Cheers, Mark. From vnpenguin at vnoss.org Mon Jun 11 09:20:29 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Mon, 11 Jun 2007 11:20:29 +0200 Subject: pungi : question about dependency of "devel" packages Message-ID: Hi, I try to build customized CD with pungi without any "devel" package. In my manifest file there is no devel at all, but the final iso has a lot of "devel" rpm in this :( In log file of pungi I see: ... DEBUG:yum.verbose.YumBase:Matched metacity-devel - 2.18.0-2.fc7.i386 to require for libmetacity-private.so.0 DEBUG:yum.verbose.YumBase:Matched metacity - 2.18.0-2.fc7.i386 to require for libmetacity-private.so.0 DEBUG:yum.verbose.YumBase:Matched metacity-devel - 2.18.0-2.fc7.i386 to require for libmetacity-private.so.0 DEBUG:yum.verbose.YumBase:Matched metacity - 2.18.0-2.fc7.i386 to require for libmetacity-private.so.0 DEBUG:yum.verbose.YumBase:Matched metacity - 2.18.3-1.fc7.i386 to require for libmetacity-private.so.0 DEBUG:yum.verbose.YumBase:Matched metacity-devel - 2.18.3-1.fc7.i386 to require for libmetacity-private.so.0 INFO:yum.verbose.pungi:Added metacity-devel.i386 for control-center.i386 INFO:yum.verbose.pungi:Added metacity.i386 for control-center.i386 INFO:yum.verbose.pungi:Added metacity.i386 for control-center.i386 INFO:yum.verbose.pungi:Added metacity-devel.i386 for control-center.i386 INFO:yum.verbose.pungi:Added metacity-devel.i386 for control-center.i386 INFO:yum.verbose.pungi:Added metacity.i386 for control-center.i386 ... INFO:yum.verbose.pungi:Checking deps of metacity-devel.i386 DEBUG:yum.verbose.YumBase:Matched gtk2-devel - 2.10.11-7.fc7.i386 to require for gtk2-devel DEBUG:yum.verbose.YumBase:Matched gtk2-devel - 2.10.11-7.fc7.i386 to require for gtk2-devel DEBUG:yum.verbose.YumBase:Matched gtk2-devel - 2.10.12-2.fc7.i386 to require for gtk2-devel INFO:yum.verbose.pungi:Added gtk2-devel.i386 for metacity-devel.i386 INFO:yum.verbose.pungi:Added gtk2-devel.i386 for metacity-devel.i386 INFO:yum.verbose.pungi:Added gtk2-devel.i386 for metacity-devel.i386 DEBUG:yum.verbose.YumBase:Matched libX11-devel - 1.0.3-8.fc7.i386 to require for libX11-devel DEBUG:yum.verbose.YumBase:Matched libX11-devel - 1.0.3-8.fc7.i386 to require for libX11-devel INFO:yum.verbose.pungi:Added libX11-devel.i386 for metacity-devel.i386 INFO:yum.verbose.pungi:Added libX11-devel.i386 for metacity-devel.i386 DEBUG:yum.verbose.YumBase:Matched metacity - 2.18.0-2.fc7.i386 to require for metacity DEBUG:yum.verbose.YumBase:Matched metacity - 2.18.0-2.fc7.i386 to require for metacity INFO:yum.verbose.pungi:Added metacity.i386 for metacity-devel.i386 INFO:yum.verbose.pungi:Added metacity.i386 for metacity-devel.i386 ... Howto fix this please ? Thank you in advance, Regards, -- http://vnoss.org From jdieter at gmail.com Mon Jun 11 09:31:36 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 11 Jun 2007 12:31:36 +0300 Subject: The updates firehose In-Reply-To: <1181498382.14809.31.camel@rivendell> References: <200706091605.00638.jkeating@redhat.com> <200706092223.13366.opensource@till.name> <20070610095434.83350@gmx.net> <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> <1181498382.14809.31.camel@rivendell> Message-ID: <1181554296.12843.0.camel@jndwidescreen.lesbg.loc> On Sun, 2007-06-10 at 13:59 -0400, seth vidal wrote: > What's been discussed on yum-devel is generating a textual diff from > old-repodata to new-repodata so we can produce a comparable sqlite w/o > downloading as much. > Makes sense. Are you planning on implementing that as part of yum or do you want me to implement it as part of yum-presto? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Mon Jun 11 09:32:58 2007 From: buildsys at redhat.com (Build System) Date: Mon, 11 Jun 2007 05:32:58 -0400 Subject: rawhide report: 20070611 changes Message-ID: <200706110932.l5B9WwWP008818@porkchop.devel.redhat.com> New package digitemp Dallas Semiconductor 1-wire device reading console application New package muParser A fast math parser library New package python-genshi Toolkit for stream-based generation of output for the web New package python-pgsql Enhanced python interface to PostgreSQL Updated Packages: NetworkManager-1:0.6.5-6.fc8 ---------------------------- * Sun Jun 10 2007 Dan Williams 1:0.6.5-5 - Fix applet crash on 64-bit platforms when choosing "Connect to other wireless network..." (gnome.org #435036) - Add debug output for ethernet device link changes * Thu Jun 07 2007 Dan Williams 1:0.6.5-5 - Fix ethernet link detection (gnome #354565, rh #194124) - Fix perpetual credentials request with private key passwords in the applet - Sleep a bit before activating wireless cards to work around driver bugs * Mon Jun 04 2007 Dan Williams 1:0.6.5-4 - Don't spawn wpa_supplicant with -o agave-0.4.2-4.fc8 ----------------- * Sun Jun 10 2007 Aurelien Bompard 0.4.2-4 - reverted yelp requirement (should be optional) dia-1:0.96.1-2.fc8 ------------------ * Sun Jun 10 2007 Hans de Goede 1:0.96.1-2 - Remove yelp Requires again (bz 243330) dirac-0.7.0-1.fc8 ----------------- gnome-commander-1.2.4-3.fc8 --------------------------- * Mon Jun 11 2007 Mamoru Tasaka - 1.2.4-3 - Drop dependency for yelp gnomebaker-0.6.0-4.fc8 ---------------------- * Sun Jun 10 2007 Brian Pepple - 0.6.0-4 - Drop requires on yelp. (#243391) gnumeric-1:1.6.3-9.fc8 ---------------------- * Sun Jun 10 2007 Hans de Goede 1:1.6.3-9 - Remove yelp Requires again (bz 243361) iverilog-0.9.20070608-1.fc8 --------------------------- * Sun Jun 10 2007 Balint Cristian 0.9.20070608-1 - new snapshot release upstream. jd-1.9.5-0.3.svn1121.fc8 ------------------------ * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.3.svn1121 - svn 1121 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta 070528 * Tue May 22 2007 Mamoru Tasaka - 1.9.5-0.2.beta070516 - Support C/Migemo search lirc-0.8.2-1.fc8 ---------------- * Sun Jun 10 2007 Ville Skytt?? - 0.8.2-1 - 0.8.2. loudmouth-1.2.3-1.fc8 --------------------- * Sun Jun 10 2007 Brian Pepple - 1.2.3-1 - Update to 1.2.3. - Drop stream-error patch. fixed upstream. mecab-0.96-1.fc8 ---------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release * Fri May 04 2007 Mamoru Tasaka - 0.95-2.dist.2 - rebuild * Sun Apr 01 2007 Mamoru Tasaka - 0.95-2 - remove -lstdc++ from mecab-config (#233424) mecab-ipadic-2.7.0.20070610-1.fc8 --------------------------------- monkey-bubble-0.4.0-6.fc8 ------------------------- * Sun Jun 10 2007 Hans de Goede 0.4.0-6 - Remove yelp Requires again (bz 243408) nss-3.11.7-3.fc8 ---------------- * Sun Jun 10 2007 Kai Engert - 3.11.7-3 - Fix unowned directories, rhbz#233890 * Fri Jun 01 2007 Kai Engert - 3.11.7-2 - Update to 3.11.7, but freebl/softokn remain at 3.11.5. - Use a workaround to avoid mozilla bug 51429. * Fri Mar 02 2007 Kai Engert - 3.11.5-2 - Fix rhbz#230545, failure to enable FIPS mode - Fix rhbz#220542, make NSS more tolerant of resets when in the middle of prompting for a user password. perl-mecab-0.96-1.fc8 --------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release planner-0.14.2-7.fc8 -------------------- * Sun Jun 10 2007 Caolan McNamara - 0.14.2-7 - Resolves: rhbz#243367 don't require yelp (on the bright side we picked up on evo 2.12) python-mecab-0.96-1.fc8 ----------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release python-pycurl-7.16.2.1-1.fc8 ---------------------------- * Sat Jun 09 2007 Jeffrey C. Ollie - 7.16.2.1-1 - Update to released version. python-pyspf-2.0.3-1.fc8 ------------------------ * Sat Jun 09 2007 Sean Reifschneider 2.0.3-1 - Upgrading to 2.0.3 release. python-setuptools-0.6c6-1.fc8 ----------------------------- * Sun Jun 10 2007 Konstantin Ryabitsev - 0.6c6-1 - Upstream 0.6c6 - Require python-devel (#240707) revisor-2.0.3.9-1.fc8 --------------------- * Sun Jun 10 2007 Jeroen van Meeuwen 2.0.3.9-1 - Bugfixes, more bugfixes ruby-mecab-0.96-1.fc8 --------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release sipp-2.0.1-2.fc8 ---------------- * Sun Jun 10 2007 Peter Lemenkov 2.0.1-2 - rebuild Broken deps for i386 ---------------------------------------------------------- bdock - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 beryl - 0.2.1-1.fc8.i386 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.i386 requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 gstreamer-plugins-farsight - 0.12.1-2.fc8.i386 requires libjrtp-3.7.0.so gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- bdock - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) beryl - 0.2.1-1.fc8.x86_64 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.x86_64 requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.i386 requires libwnck-1.so.18 emerald - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) gstreamer-plugins-farsight - 0.12.1-2.fc8.x86_64 requires libjrtp-3.7.0.so()(64bit) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.x86_64 requires libwnck-1.so.18()(64bit) k3b - 1.0.1-2.fc8.x86_64 requires libmpcdec.so.3()(64bit) k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.x86_64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- bdock - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 beryl - 0.2.1-1.fc8.ppc requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc requires aquamarine >= 0:0.2.1 emerald - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gstreamer-plugins-farsight - 0.12.1-2.fc8.ppc requires libjrtp-3.7.0.so gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 heliodor - 0.2.0-1.fc7.ppc requires libwnck-1.so.18 k3b - 1.0.1-2.fc8.ppc requires libmpcdec.so.3 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) beryl - 0.2.1-1.fc8.ppc64 requires bdock >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires heliodor >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 beryl-gnome - 0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires emerald-themes >= 0:0.2.1 beryl-kde - 0.2.1-1.fc8.ppc64 requires aquamarine >= 0:0.2.1 emerald-themes - 0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gstreamer-plugins-farsight - 0.12.1-2.fc8.ppc64 requires libjrtp-3.7.0.so()(64bit) k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 From markmc at redhat.com Mon Jun 11 09:43:39 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 11 Jun 2007 10:43:39 +0100 Subject: RFR: GIT Package VCS In-Reply-To: <1181553831.3705.74.camel@blaa> References: <1181138741.4009.13.camel@lt21223.campus.dmacc.edu> <200706072118.04076.jkeating@redhat.com> <1181267967.4070.309.camel@localhost.localdomain> <200706080705.11909.jkeating@redhat.com> <1181553831.3705.74.camel@blaa> Message-ID: <1181555020.3705.83.camel@blaa> On Mon, 2007-06-11 at 10:23 +0100, Mark McLoughlin wrote: > > On Thursday 07 June 2007 21:59:27 Toshio Kuratomi wrote: > > > On Thu, 2007-06-07 at 21:18 -0400, Jesse Keating wrote: > > > > > > > > We have two things for the upstream in our package SCM. We have the > > > > prestine tarball stashed away in a lookaside, and we have an exploaded > > > > tree of the source. We use the exploaded tree of the source to manage > > > > our patches to that source and to help with rebases. However the patches > > > > we manage always apply to the prestine point. At package build time, the > > > > patches we manage + the spec file + the prestine tarball stashed away are > > > > combined to make an srpm, and that is shoved through the build system. > > > > > > I wonder. What are we trying to do here? > > 1) Make hacking on a stack of patches easier > > 2) Make it easier to re-base - i.e. new upstream tarball, re-generate > each of the patches against the new upstream, resolving any > conflicts > > 3) Allow someone to fork a set of patches? e.g. OLPC has their own > version of a package with an additional patch, but wants to keep > in sync with the Fedora version of the package > > I'd suggest quilt as a nice simple tool for (1). Stacked git (stg) > looks like it makes sense if upstream uses git. I forgot about patch history, which others have mentioned. Very useful in some cases. Perhaps it'd be worth prototyping this with stg: - "make stg-init" to create a new stg/git repo, import the current upstream tarball - "make stg-push" to push that repo to some well-defined location for each package - "make stg-rebase" to import the current source tarball into stg, re-push all patches and manually resolve any conflicts - "make stg-patches" to export all the patches from stg, add them to pkgs cvs and create $package.patches and $package.applies files, both of which can be %included from the spec file Cheers, Mark. From simon.andrews at bbsrc.ac.uk Mon Jun 11 10:15:15 2007 From: simon.andrews at bbsrc.ac.uk (Simon Andrews) Date: Mon, 11 Jun 2007 11:15:15 +0100 Subject: The updates firehose In-Reply-To: <3689.71.208.222.235.1181536031.squirrel@www.cora.nwra.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <3689.71.208.222.235.1181536031.squirrel@www.cora.nwra.com> Message-ID: orion at cora.nwra.com wrote: >> Christopher Blizzard wrote: >> >>> Are people complaining? >> I don't complain when it happens with my own computer that's >> being updated daily... but it's painful when you update a >> dozen of desktops in the office to F7 and all them want to >> download 500MB worth of updates the first time they boot. >> >> Yes, I could use a local Fedora mirror. And, in fact, >> I do. But then I'd have to customize the yum config on >> all clients to go look there. >> > > Add the updates repo at upgrade/install time. Is this currently possible? I've just upgraded a load of servers from FC6 to F7 and saw no option to add in extra repositories. This was a text based nfs upgrade. I remember hearing that including extra repository support in anaconda was slated for F7, but is this installs only? Simon. From dwmw2 at infradead.org Mon Jun 11 10:20:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 11 Jun 2007 11:20:02 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466A717A.1050102@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466A717A.1050102@hhs.nl> Message-ID: <1181557202.2801.74.camel@pmac.infradead.org> On Sat, 2007-06-09 at 11:23 +0200, Hans de Goede wrote: > Notice that I have spends weeks on fixing exactly the problems, with creating a > cross compiling gcc targeting linux with glibc, described here to build an > cross arm toolchain for the gp2x handheld for Fedora. > > Please check: > http://people.atrpms.net/~hdegoede/ > > For all my SRPMS / SPECS for this, with regards to solving the above metioned > problems esp arm-gp2x-linux-gcc.spec is interesting. I think I've got this one > nailed, so before other people start pouring time into this please first check > my work, doing this for other linux-glibc targets, using Fedora sources instead > of the open2x sources I'm using should be mostly identical. I'll gladly answer > any questions. I see you've actually pulled in glibc sources and you're using them in the gcc build. I was trying to avoid that. I suppose if we can depend on having a sysroot populated with appropriate glibc-*.$ARCH.rpm packages then the bootstrap approach isn't _so_ bad, but that might be a lot to expect of yum/koji. -- dwmw2 From skvidal at linux.duke.edu Mon Jun 11 10:27:47 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 11 Jun 2007 06:27:47 -0400 Subject: The updates firehose In-Reply-To: <1181554296.12843.0.camel@jndwidescreen.lesbg.loc> References: <200706091605.00638.jkeating@redhat.com> <200706092223.13366.opensource@till.name> <20070610095434.83350@gmx.net> <1181471149.5341.4.camel@jndwidescreen.lesbg.loc> <1181498382.14809.31.camel@rivendell> <1181554296.12843.0.camel@jndwidescreen.lesbg.loc> Message-ID: <1181557667.14809.37.camel@rivendell> On Mon, 2007-06-11 at 12:31 +0300, Jonathan Dieter wrote: > On Sun, 2007-06-10 at 13:59 -0400, seth vidal wrote: > > What's been discussed on yum-devel is generating a textual diff from > > old-repodata to new-repodata so we can produce a comparable sqlite w/o > > downloading as much. > > > Makes sense. Are you planning on implementing that as part of yum or do > you want me to implement it as part of yum-presto? > It probably makes sense in base yum and in createrepo since the repository side would need this information, too. -sv From vnpenguin at vnoss.org Mon Jun 11 10:43:49 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Mon, 11 Jun 2007 12:43:49 +0200 Subject: pungi : question about dependency of "devel" packages In-Reply-To: References: Message-ID: Try: > yum provides libmetacity-private.so.0 metacity-devel.i386 2.18.0-2.fc7 fedora Matched from: libmetacity-private.so.0 metacity.i386 2.18.0-2.fc7 fedora Matched from: libmetacity-private.so.0 metacity.i386 2.18.3-1.fc7 updates Matched from: libmetacity-private.so.0 metacity-devel.i386 2.18.3-1.fc7 updates Matched from: libmetacity-private.so.0 metacity.i386 2.18.3-1.fc7 installed Matched from: Provides-match: libmetacity-private.so.0 So "libmetacity-private.so.0" is provided by both metacity & metacity-devel ???? -- http://vnoss.org From foolish at guezz.net Mon Jun 11 11:05:51 2007 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Mon, 11 Jun 2007 13:05:51 +0200 Subject: The updates firehose In-Reply-To: <466BD775.5000902@fedoraproject.org> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> <466BD775.5000902@fedoraproject.org> Message-ID: <1181559951.2351.7.camel@localhost.localdomain> For the record, I'm a community guy requesting a policy on updates. Leaving it up to the packagers is fine if the packagers feel confident that they can themselves decide on the best updates policy for users for each package, I'm not that confident. I'd like to see some guidelines on when to push updates for certain types of packages, simply because I just don't know what makes sense. And I feel really guilty, I alone am responsible for 22 of the updates in updates-testing, of which 21 are new packages that didn't make it in before the merge. Then again, the rest of the 300 or so packages have the same new package/real update ratio as mine do, we're only dealing with a minor number of real updates. s?n, 10.06.2007 kl. 16.20 +0530, skrev Rahul Sundaram: > Neil Thompson wrote: > > > > > And very shortly you're going to be asking for a policy to be written which > > defines when the maintainers are going to be allowed to have bowel movements, > > aren't you? > > Completely Unrelated. > > > > > The strengths of Fedora are its leading (even bleeding, at times) edge software > > and its maintainers. I had hoped that the merge would lead to more freedom and > > faster throughput for new software, but it looks as though we're on the verge > > of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it > > worries me) > > Who exactly are you calling that? > > > Please folks - if you're going to build a community, make sure that you have only > > the governance that is necessary and NO MORE! Leave the maintainers (who have been > > appointed to look after the packages) to do their jobs. Address mistakes and issues > > on a case-by-case basis and don't hamstring everyone with a bunch of pettifogging > > rules. > > Updates policy has been requested before by community folks too. You > don't even have to necessarily change your current practises. Just > document them explicitly. > > Rahul -- Sindre Pedersen Bj?rdal - http://www.fedoraproject.org/wiki/SindrePedersenBjordal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From foolish at guezz.net Mon Jun 11 11:23:23 2007 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Mon, 11 Jun 2007 13:23:23 +0200 Subject: boinc anyone? In-Reply-To: <645d17210706081524s4475da5g2d7ab2f5c7e043c2@mail.gmail.com> References: <645d17210706081524s4475da5g2d7ab2f5c7e043c2@mail.gmail.com> Message-ID: <1181561003.2351.10.camel@localhost.localdomain> Addded boinc to the wishlist at: http://fedoraproject.org/wiki/PackageMaintainers/WishList I wish more people would use the wishlist. fre, 08.06.2007 kl. 23.24 +0100, skrev Jonathan Underwood: > On 08/06/07, Neal Becker wrote: > > Is there an rpm of boinc for fedora? A quick google search suggests there > > were rpms for fc5, but nothing in current fc7 repos. > > > > Not that I know of. This would make a good starting point for a package though: > > http://cvs.pld-linux.org/cgi-bin/cvsweb/SPECS/boinc.spec?rev=1.22 > > :) > > J. > -- Sindre Pedersen Bjordal -- Sindre Pedersen Bj?rdal - http://www.fedoraproject.org/wiki/SindrePedersenBjordal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From kanarip at kanarip.com Mon Jun 11 11:38:36 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 11 Jun 2007 13:38:36 +0200 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <20070609194220.GA8740@wolff.to> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> <20070609194220.GA8740@wolff.to> Message-ID: <466D343C.6000501@kanarip.com> Bruno Wolff III wrote: > You guys should buy a bus. That oughta be fun, from Europe... -kanarip From kanarip at kanarip.com Mon Jun 11 11:45:47 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 11 Jun 2007 13:45:47 +0200 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: References: Message-ID: <466D35EB.600@kanarip.com> Max Spevack wrote: > August 3rd - 5th > > or > > August 10th - 12th > > For those of you who are likely to want to attend, which dates are best > for you? Either will do fine, preferably August 3rd - 5th though, given the timeframe that gives us for the next freeze. Kind regards, Jeroen van Meeuwen -kanarip From nigel.metheringham at dev.intechnology.co.uk Mon Jun 11 12:18:19 2007 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 11 Jun 2007 13:18:19 +0100 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <466D343C.6000501@kanarip.com> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> <20070609194220.GA8740@wolff.to> <466D343C.6000501@kanarip.com> Message-ID: <267C4A57-E1D0-4515-9398-1BE1214210A8@dev.intechnology.co.uk> On 11 Jun 2007, at 12:38, Jeroen van Meeuwen wrote: > Bruno Wolff III wrote: >> You guys should buy a bus. > > That oughta be fun, from Europe... You could hire one of these... http://www.vikingsplash.ie/gallery1.htm Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From mattdm at mattdm.org Mon Jun 11 12:20:57 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 11 Jun 2007 08:20:57 -0400 Subject: rawhide gdm: "1=Standard" broken? Message-ID: <20070611122057.GA23273@jadzia.bu.edu> For years now, I've been implementing "fast user switching" by putting 1=Standard in gdm.conf (and more recently /etc/gdm/custom.conf). Sometime in the last few weeks, though, something has broken. (Not sure exactly when, because I just now rebooted.) GDM isn't starting the second X server and second greeter. Any idea what might be causing this? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Jun 11 12:25:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 08:25:44 -0400 Subject: pungi : question about dependency of "devel" packages In-Reply-To: References: Message-ID: <200706110825.45160.jkeating@redhat.com> On Monday 11 June 2007 06:43:49 Vnpenguin wrote: > So "libmetacity-private.so.0" is provided by both metacity & metacity-devel > ???? That looks like a packaging bug to me. File it against metacity? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 11 12:30:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 08:30:21 -0400 Subject: The updates firehose In-Reply-To: <3689.71.208.222.235.1181536031.squirrel@www.cora.nwra.com> References: <200706091605.00638.jkeating@redhat.com> <466B1068.7030002@codewiz.org> <3689.71.208.222.235.1181536031.squirrel@www.cora.nwra.com> Message-ID: <200706110830.21529.jkeating@redhat.com> On Monday 11 June 2007 00:27:11 orion at cora.nwra.com wrote: > Add the updates repo at upgrade/install time. This only works if you're doing a non iso/media based install, IE an exploaded tree via network. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 11 12:31:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 08:31:21 -0400 Subject: The updates firehose In-Reply-To: <20070611050840.GD18869@nostromo.devel.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> <20070611050840.GD18869@nostromo.devel.redhat.com> Message-ID: <200706110831.22069.jkeating@redhat.com> On Monday 11 June 2007 01:08:40 Bill Nottingham wrote: > So, this is something I'd *love* to have - some sort of stats on > how many people have installed package X; useful for doing checks > to see what should or shouldn't be on the DVDs, and so on. I know > the mugshot stats exist, but that's not the same. And how thrown off is this data by people who install Everything, or all in a group but never use the data? More important than 'how many people installed package X' is perhaps "how many people installed package X that wasn't on the media" and even more importantly "how many people launched package X and what was X's deps?". -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Mon Jun 11 13:05:33 2007 From: laroche at redhat.com (Florian La Roche) Date: Mon, 11 Jun 2007 15:05:33 +0200 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <267C4A57-E1D0-4515-9398-1BE1214210A8@dev.intechnology.co.uk> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> <20070609194220.GA8740@wolff.to> <466D343C.6000501@kanarip.com> <267C4A57-E1D0-4515-9398-1BE1214210A8@dev.intechnology.co.uk> Message-ID: <20070611130533.GA6400@dudweiler.stuttgart.redhat.com> On Mon, Jun 11, 2007 at 01:18:19PM +0100, Nigel Metheringham wrote: > > On 11 Jun 2007, at 12:38, Jeroen van Meeuwen wrote: > > >Bruno Wolff III wrote: > >>You guys should buy a bus. > > > >That oughta be fun, from Europe... > > You could hire one of these... > http://www.vikingsplash.ie/gallery1.htm Hello Nigel, I've recently joined in a Boston Duck Tour and can only recommend doing one. 2 hours with lots of nice stories and lots of humor: http://www.bostonducktours.com/ Maybe they can offer a "big tour" over the big pond... regards, Florian La Roche From Matt_Domsch at dell.com Mon Jun 11 13:06:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 11 Jun 2007 08:06:45 -0500 Subject: The updates firehose In-Reply-To: <1181467847.28023.6.camel@rousalka.dyndns.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <1181467847.28023.6.camel@rousalka.dyndns.org> Message-ID: <20070611130645.GA17371@lists.us.dell.com> On Sun, Jun 10, 2007 at 11:30:47AM +0200, Nicolas Mailhot wrote: > Le samedi 09 juin 2007 ?? 20:31 -0500, Matt Domsch a ??crit : > > > You can add your local private mirror to mirrormanager, add a netblock > > that covers your address space, and all your clients will then pull > > from your local mirror rather than public mirrors, with no change on > > the clients. > > That's nice but if the infrastructure was friendlier to proxies most big > entities wouldn't have to setup any mirror but could just rely on their > existing proxy infrastructure > > - mirrormanager should return data with high expire values and/or detect > squid/mod_proxy whatever and direct it to a static mirror Mirrormanager just returns a yum mirrorlist, which is updated hourly, and is very fast to return (under 0.5s almost all the time). Not sure how caching will help this. We don't presently do what openSUSE does, which is handle all the mirror redirection on the back-end. In their case, their yum mirrorlist-like thing only ever returns one answer: download.opensuse.org/path/to/repo/, and then they take the request for download.opensuse.org/path/to/repo/file.rpm and do a temporary HTTP redirect to the actual site they want to refer that particular user to. This gives them the ability to see every RPM download request (for statistical purposes), and presumably the user-side proxies might cache the downloaded RPM (not sure how that would work with the redirect though). As it stands, user-side proxies can't really cache effectively, because they may get told to use a different mirror for every yum invocation. > - yum should generate proxy-friendly metadata It's static files from yum, yes? What's not proxy-friendly about that? I'm open to all suggestions, and patches are welcome! -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Mon Jun 11 13:08:30 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 11 Jun 2007 08:08:30 -0500 Subject: The updates firehose - automatic local mirrors In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> Message-ID: <20070611130830.GB17371@lists.us.dell.com> On Mon, Jun 11, 2007 at 08:06:39AM +0300, Pekka Savola wrote: > On Sat, 9 Jun 2007, Matt Domsch wrote: > >On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote: > >>Christopher Blizzard wrote: > >> > >>>Are people complaining? > >> > >>I don't complain when it happens with my own computer that's > >>being updated daily... but it's painful when you update a > >>dozen of desktops in the office to F7 and all them want to > >>download 500MB worth of updates the first time they boot. > >> > >>Yes, I could use a local Fedora mirror. And, in fact, > >>I do. But then I'd have to customize the yum config on > >>all clients to go look there. > > > >You can add your local private mirror to mirrormanager, add a netblock > >that covers your address space, and all your clients will then pull > >from your local mirror rather than public mirrors, with no change on > >the clients. > > > >https://admin.fedoraproject.org/mirrormanager > >http://fedoraproject.org/wiki/Infrastructure/Mirroring > > (My definition of 'local' = in the same country or region of > countries. As shown in later messages, others want to create custom > repositories for organization's internal use, but that requires > different tools.) > > Even better would be that only local mirrors would be shown > automatically. Nowadays, countries with less than 3 mirrors don't get > this optimization. > > This would require rather simple updates to the > http://mirrors.fedoraproject.org/mirrorlist script. I really don't want to trust that the only mirror in a given country is active and fully up-to-date, and send everyone from that country to that single mirror. The thresshold is 3 per country to provide some reasonable guarantee that at least one of those 3 is active and up-to-date at any given instance. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From kzak at redhat.com Mon Jun 11 13:08:35 2007 From: kzak at redhat.com (Karel Zak) Date: Mon, 11 Jun 2007 15:08:35 +0200 Subject: RFR: GIT Package VCS In-Reply-To: <20070610231859.GQ16879@petra.dvoda.cz> References: <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <20070608001130.GP16879@petra.dvoda.cz> <20070610182023.GA29512@redhat.com> <20070610231859.GQ16879@petra.dvoda.cz> Message-ID: <20070611130835.GU16879@petra.dvoda.cz> On Mon, Jun 11, 2007 at 01:18:59AM +0200, Karel Zak wrote: > On Sun, Jun 10, 2007 at 02:20:23PM -0400, Dave Jones wrote: > > > I'm almost sure that someone other (for example > > > Linus) will use GIT instead quilt for same job. > > > > I tried it during F7 after FUDCon. I thought it'd work out too. > > It didn't. As soon as rebasing broke Xen, it became a nightmare, > > as I couldn't easily drop it. It became easier to just > > What not? You need to 1/ checkout code to a temporary branch, 2/ > remove the patch (reset --hard) and 3/ rebase (--onto tmp) to the > original branch. Ah.. the step 2/ is not required. You can drop a patch in two steps. Karel -- Karel Zak From dtimms at iinet.net.au Mon Jun 11 13:12:13 2007 From: dtimms at iinet.net.au (David Timms) Date: Mon, 11 Jun 2007 23:12:13 +1000 Subject: Improving availability and guaranteeing integrity in ISO - internal sha1sums In-Reply-To: <20070610105852.GA86555@dspnet.fr.eu.org> References: <200706081441.42279.jkeating@redhat.com> <466A0E5E.50201@iinet.net.au> <200706090822.48020.jkeating@redhat.com> <466B7EB7.4000006@iinet.net.au> <20070610105852.GA86555@dspnet.fr.eu.org> Message-ID: <466D4A2D.5090802@iinet.net.au> Olivier Galibert wrote: > On Sun, Jun 10, 2007 at 02:31:51PM +1000, David Timms wrote: >> I am not sure how you do that - how can you include inside a piece of >> data a checksum that uses the data {including itself} to calculate the >> checksum ? > > Standard method is "zero the checksum area, compute the checksum, > write it". At verification time, copy the checksum area in memory, > zero it and compute the checksum. Ok, makes sense now how it actually works. An error in the checksum implanted or the data will be detected, but not the case where an attacker modifies a file, and re-embeds the matching checksum. Thats why the necessity of the external sha1sum and signing. I've read in f-l and seen myself where "tested good" cd/dvds {media check} that fail during installation when trying to read a particular rpm. Once sha1sum are on the iso, helping the user get to the definite problem {and making them believe it} would be as simple as getting them to run sha1sum -c failing....rpm or a nicer checksumming app. I also see the other side where media fails the test, but works without error for what the user is installing. The cost of inserting this info would be pretty minimal - just an extra step in the iso spin process. As Till suggests elsewhere in this thread: find -type f -print0 | xargs -0 sha1sum >../SHA1SUM ... 154cbac962cf0e04ffd3163b6526fa8190df1299 ./stylesheet-images/titlepage.png 235e0b26cdc5a41c6d9b58ee57dd665c42611d79 ./stylesheet-images/warning.png real 1m10.209s user 0m24.258s sys 0m6.452s size: -rw-r--r-- 1 root root 145080 Jun 11 21:44 SHA1SUM.txt The resultant SHA1SUM file is acceptable to "sha1sum -c ../SHA1SUM" {My iso is mounted, not the actual source files, so I cant write to the correct location - hence the ../}. Since it would probably be more useful for a media contents test script to work from multiple places: - a running Fedora system - rescue iso - dvd iso - linux rescue - {from another OS - could include dos/win ftp://ftp.gnupg.org/gcrypt/binary/sha1sum.exe} Perhaps it is best to be as simple as possible, rather than python as I first suggested -> bash script: attached. Since scrollback through 1800 files might not be possible directs the output to the users home directory, and uses the return value to state either ~good or ~bad with this files bad or missing. This could become standard practice on any iso fedora produces {ie including rescue and live}. DaveT. -------------- next part -------------- A non-text attachment was scrubbed... Name: verify_media_accessibility.sh Type: application/x-shellscript Size: 613 bytes Desc: not available URL: From vnpenguin at vnoss.org Mon Jun 11 13:12:01 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Mon, 11 Jun 2007 15:12:01 +0200 Subject: pungi : question about dependency of "devel" packages In-Reply-To: <200706110825.45160.jkeating@redhat.com> References: <200706110825.45160.jkeating@redhat.com> Message-ID: On 6/11/07, Jesse Keating wrote: > On Monday 11 June 2007 06:43:49 Vnpenguin wrote: > > So "libmetacity-private.so.0" is provided by both metacity & metacity-devel > > ???? > > That looks like a packaging bug to me. File it against metacity? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689 it's ok ? -- http://vnoss.org From limb at jcomserv.net Mon Jun 11 13:12:31 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 11 Jun 2007 08:12:31 -0500 (CDT) Subject: Unsigned package In-Reply-To: <200706081013.22723.jkeating@redhat.com> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <23087.65.192.24.190.1181242852.squirrel@mail.jcomserv.net> <13717.65.192.24.190.1181311193.squirrel@mail.jcomserv.net> <200706081013.22723.jkeating@redhat.com> Message-ID: <57943.65.192.24.190.1181567551.squirrel@mail.jcomserv.net> Still not working. > On Friday 08 June 2007 09:59:53 Jon Ciesla wrote: >> Still not working. Is it still a time question? I don't see a change >> in >> scons, PHP-Pear-Mail-Mime, or anything else. > > I've haded the signed tree off to IS to sync to the mirror masters. > Hopefully > later today we'll see the changed content filtering out to the rest of the > world mirrors. > > -- > Jesse Keating > Release Engineer: Fedora > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From rc040203 at freenet.de Mon Jun 11 13:19:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 Jun 2007 15:19:27 +0200 Subject: The updates firehose In-Reply-To: <1181531543.3840.4.camel@neutron.verbum.private> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> <1181482619.3445.9.camel@localhost.localdomain> <1181531543.3840.4.camel@neutron.verbum.private> Message-ID: <1181567967.3233.16.camel@mccallum.corsepiu.local> On Sun, 2007-06-10 at 23:12 -0400, Colin Walters wrote: > On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote: > > > The current classification we have is just > > "bugfix - enhancement - security". It would be nice add some more > > categories to this, like "cosmetic" (for minor packaging cleanups like > > directory ownership handling), and some way to differentiate by > > severity. > > Why would someone push an update for cosmetic issues? Because what to consider cosmetic is largely up to the eye of the beholder. I for one would consider changes which don't have any impact on a binary rpm to be cosmetic, and anything else to be "bugfix". That said, broken permissions/ownerships never are cosmetic, they are real bug fixes. Ralf From jakub at redhat.com Mon Jun 11 13:21:00 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 11 Jun 2007 09:21:00 -0400 Subject: The updates firehose - automatic local mirrors In-Reply-To: <20070611130830.GB17371@lists.us.dell.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <20070611130830.GB17371@lists.us.dell.com> Message-ID: <20070611132100.GC4033@devserv.devel.redhat.com> On Mon, Jun 11, 2007 at 08:08:30AM -0500, Matt Domsch wrote: > > This would require rather simple updates to the > > http://mirrors.fedoraproject.org/mirrorlist script. > > I really don't want to trust that the only mirror in a given country > is active and fully up-to-date, and send everyone from that country to > that single mirror. The thresshold is 3 per country to provide some > reasonable guarantee that at least one of those 3 is active and > up-to-date at any given instance. Isn't that reasonable guarantee already the report_mirror data or crawler acquired data? Looking at current http://mirrors.fedoraproject.org/publiclist/Fedora/7/ there are only very few countries for which non-global list is used (unlike FC6 times): Canada, Germany, Spain, France, Greece, Japan, Netherlands, Romania, USA E.g. Czech Rep. used to be listed, but supposedly two of the mirrors were kicked out for not being 100% up2date by the crawler and now we have just 2 mirrors, both stable though. Jakub From jkeating at redhat.com Mon Jun 11 13:20:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 09:20:04 -0400 Subject: Unsigned package In-Reply-To: <57943.65.192.24.190.1181567551.squirrel@mail.jcomserv.net> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706081013.22723.jkeating@redhat.com> <57943.65.192.24.190.1181567551.squirrel@mail.jcomserv.net> Message-ID: <200706110920.04931.jkeating@redhat.com> On Monday 11 June 2007 09:12:31 Jon Ciesla wrote: > Still not working. I'm looking into why my sync request has not been completed yet. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Jun 11 13:34:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 11 Jun 2007 15:34:57 +0200 (CEST) Subject: The updates firehose In-Reply-To: <20070611130645.GA17371@lists.us.dell.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <1181467847.28023.6.camel@rousalka.dyndns.org> <20070611130645.GA17371@lists.us.dell.com> Message-ID: <29185.192.54.193.51.1181568897.squirrel@rousalka.dyndns.org> Le Lun 11 juin 2007 15:06, Matt Domsch a ?crit : > Mirrormanager just returns a yum mirrorlist, which is updated hourly, > and is very fast to return (under 0.5s almost all the time). And this kills proxies as the systems behind a proxy will switch from a mirror already cached by the proxy to another one potentially every hour. Proxies want a static mirrorlist or a mirrorlist they can cache. (using a mirrorlist URL with parameters is probably sufficient to make it uncacheable, better static URLs with mod_rewrite or something similar behind to translate them in hidden requests) >> - yum should generate proxy-friendly metadata > > It's static files from yum, yes? What's not proxy-friendly about > that? The static files do not use a mimetype that allows embedding expiration period, so unless the mirror admins configure their http server to add correct expire info for those specific files in the HTTP response (no one will bother) proxies will fall back to a default retention policy. Usually that means "keep the files x hours/days, and only check later if they've been updated". Every yum behind the proxy will then use a cached metadata version that does not correspond to the actual mirror content and will trigger problems. (typically yum asks for a package which exists in the cached metadata but is no longuer on the mirror and has not been cached in the proxy when it did exist -> boom) If you are behind a non-mandatory proxy you can configure yum to ignore the proxy for metadata (lots of hassle when you have to change the default config of many systems. Also this option only exists because the current system does not work with proxies) If you're not you're out of luck. A proxy-friendly metadata would probably be an xhtml index file (with correct HTML expire metadata) pointing to xml.gz files that change name every time they're regenarated. Other people may have better suggestions. -- Nicolas Mailhot From k.georgiou at imperial.ac.uk Mon Jun 11 13:43:18 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Mon, 11 Jun 2007 14:43:18 +0100 Subject: The updates firehose - automatic local mirrors In-Reply-To: <20070611132100.GC4033@devserv.devel.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <20070611130830.GB17371@lists.us.dell.com> <20070611132100.GC4033@devserv.devel.redhat.com> Message-ID: <20070611134318.GA7194@imperial.ac.uk> On Mon, Jun 11, 2007 at 09:21:00AM -0400, Jakub Jelinek wrote: > On Mon, Jun 11, 2007 at 08:08:30AM -0500, Matt Domsch wrote: > > > This would require rather simple updates to the > > > http://mirrors.fedoraproject.org/mirrorlist script. > > > > I really don't want to trust that the only mirror in a given country > > is active and fully up-to-date, and send everyone from that country to > > that single mirror. The thresshold is 3 per country to provide some > > reasonable guarantee that at least one of those 3 is active and > > up-to-date at any given instance. > > Isn't that reasonable guarantee already the report_mirror data or > crawler acquired data? > Looking at current http://mirrors.fedoraproject.org/publiclist/Fedora/7/ > there are only very few countries for which non-global list is used > (unlike FC6 times): > Canada, Germany, Spain, France, Greece, Japan, Netherlands, Romania, USA > E.g. Czech Rep. used to be listed, but supposedly two of the mirrors > were kicked out for not being 100% up2date by the crawler and now we > have just 2 mirrors, both stable though. For my systems I use something like country=GB,FR to avoid getting the global list. How hard will it be instead of returning the global list to check if there are enough near by countries (same continent for example) to satisfy the thresshold and only return those? Kostas From mclasen at redhat.com Mon Jun 11 13:41:00 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 11 Jun 2007 09:41:00 -0400 Subject: Unwanted RPM dependencies In-Reply-To: <1181549400.3827.17.camel@workstation.unixkiste.local> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> <1181471430.7684.3.camel@bigbox.unixkiste.local> <1181481524.3445.2.camel@localhost.localdomain> <1181549400.3827.17.camel@workstation.unixkiste.local> Message-ID: <1181569260.3630.1.camel@dhcp83-186.boston.redhat.com> On Mon, 2007-06-11 at 10:10 +0200, Stefan Held wrote: > Am Sonntag, den 10.06.2007, 09:18 -0400 schrieb Matthias Clasen: > > > We are not going to remove your ability to configure grub in whatever > > way you want, in exactly the same way as you always could. > > Did i say something else? > > > > And therefore it would be > > > great to have a small fedora-logo-grub.fc8.rpm which does not depend on > > > 1000 rpms afterwards. > > > > Jeremy already stated why we can't do that. > > Come on. Somebody who set up koji, mock and other stuff for building his > own derivate of Fedora should be afraid about 3 lines in the > fedora-logos.spec file which declares a sub package should be made for > the grub grafic? > > This doesn't sound like why we "can't" do that. As i said allready all > what i am asking for is: > > generate a grub-logo-rpm which does not need half of the base rpms. > > Is that really so hard to do? > > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00519.html > > Read this mail again and decide for yourself why this is a good plan. > > Please. I ever thought this is the place for improvements of Fedora. > There is one. Take the chance to do it. Maybe we come to a minimal > install without 250Mb not needed stuff on the harddisk. > You are not listening. No matter how easy it is to split off a subpackage, legal has asked us to keep all trademarked images in a single package. Anyway, there is still an easy way out; just don't use trademarked images in grub. From buc at odusz.so-cdu.ru Mon Jun 11 13:54:15 2007 From: buc at odusz.so-cdu.ru (buc) Date: Mon, 11 Jun 2007 17:54:15 +0400 Subject: The updates firehose In-Reply-To: <1181520396.3233.10.camel@mccallum.corsepiu.local> References: <200706091605.00638.jkeating@redhat.com> <20070610084816.GC30166@ryvius.pekin.waw.pl> <200706100732.03368.jkeating@redhat.com> <1181520396.3233.10.camel@mccallum.corsepiu.local> Message-ID: <1181570055.2251.18.camel@localhost.localdomain> On Mon, 2007-06-11 at 02:06 +0200, Ralf Corsepius wrote: > On Sun, 2007-06-10 at 07:31 -0400, Jesse Keating wrote: > > On Sunday 10 June 2007 04:48:16 Dominik 'Rathann' Mierzejewski wrote: > > > I feel like you're saying that Core's "culture" (whatever you mean by that) > > > should have precedence over Extras' and that "your way" is better than > > > "our way". I assure you that Extras maintainers didn't just "fire and > > > forget" their updates. They were tested. Yes, some accidents happened, but > > > that was the price of greater freedom the maintainers used to have. So > > > please don't try to discourage those who managed to put up with all the new > > > obstacles any further. > > > > I didn't mean to say that Core's was better. Just different. > Core was worse ... Core maintainers not shipping updated packages was/is > the reason for me to locally rebuild "up-distro" packages or locally > build patched packages. > Me too. We use Fedora in some "non-typical" production environment, hence some "hidden" bugs affect us from time to time. Any attempt to bugzilla it (i.e. to share the fixes with other people) does nothing -- we are compelled to rebuild locally. :( Sometimes even the "back-porting" of the new "rawhide" package into the current used release is enough. It looks a bit strange -- there is a new upstream stable version, this version works OK, is fully compatible with the current Fedora release we use, but is present in rawhide only... We even thought in the past of creating of some "more fast updates for Core" repository... Dmitry Butskoy From Matt_Domsch at Dell.com Mon Jun 11 13:59:13 2007 From: Matt_Domsch at Dell.com (Matt Domsch) Date: Mon, 11 Jun 2007 08:59:13 -0500 Subject: The updates firehose - automatic local mirrors In-Reply-To: <20070611134318.GA7194@imperial.ac.uk> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <20070611130830.GB17371@lists.us.dell.com> <20070611132100.GC4033@devserv.devel.redhat.com> <20070611134318.GA7194@imperial.ac.uk> Message-ID: <20070611135913.GD17371@lists.us.dell.com> On Mon, Jun 11, 2007 at 02:43:18PM +0100, Kostas Georgiou wrote: > For my systems I use something like country=GB,FR to avoid getting the > global list. How hard will it be instead of returning the global list > to check if there are enough near by countries (same continent for > example) to satisfy the thresshold and only return those? See my last note I just sent - if someone helps with the python-GeoIP code, I can make mirrormanager handle the same-continent thing quite easily. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at Dell.com Mon Jun 11 13:58:09 2007 From: Matt_Domsch at Dell.com (Matt Domsch) Date: Mon, 11 Jun 2007 08:58:09 -0500 Subject: The updates firehose - automatic local mirrors In-Reply-To: <20070611132100.GC4033@devserv.devel.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <20070611130830.GB17371@lists.us.dell.com> <20070611132100.GC4033@devserv.devel.redhat.com> Message-ID: <20070611135809.GC17371@lists.us.dell.com> On Mon, Jun 11, 2007 at 09:21:00AM -0400, Jakub Jelinek wrote: > On Mon, Jun 11, 2007 at 08:08:30AM -0500, Matt Domsch wrote: > > > This would require rather simple updates to the > > > http://mirrors.fedoraproject.org/mirrorlist script. > > > > I really don't want to trust that the only mirror in a given country > > is active and fully up-to-date, and send everyone from that country to > > that single mirror. The thresshold is 3 per country to provide some > > reasonable guarantee that at least one of those 3 is active and > > up-to-date at any given instance. > > Isn't that reasonable guarantee already the report_mirror data or > crawler acquired data? > Looking at current http://mirrors.fedoraproject.org/publiclist/Fedora/7/ > there are only very few countries for which non-global list is used > (unlike FC6 times): > Canada, Germany, Spain, France, Greece, Japan, Netherlands, Romania, USA > E.g. Czech Rep. used to be listed, but supposedly two of the mirrors > were kicked out for not being 100% up2date by the crawler and now we > have just 2 mirrors, both stable though. It's a lot better, yes, but it's not guaranteed. The crawler takes nearly 12 hours to get through all the mirror hosts. Tell you what. I need three changes, and we can make this a lot better. 1) python-GeoIP needs to export the countrycode->continent mapping table, so we can list other mirrors on the same continent at least if the country has <3 hosts. The code is in GeoIP, it's just not exported via python-GeoIP, and my Python C-binding foo is weak. I'd like the countrycode->countryname (e.g. FI -> 'Finland') mapping exported as well, so I can display the country names rather than just the country codes. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243696 filed to track this. 2) mirrormanager mirrorlist algorithm adds an extra step. If there are 3 or more mirrors in a country, return all those. If not, add in mirrors on the same continent. If still <3, add in the global list. In addition, mirrormanager then returns the mirrorlist in priority order, so the country-specific mirrors appear first, then the same-continent, then global if necessary. For each geographic circle, randomize that sub-list so we get the same behavior as yum failovermethod=roundrobin, but we don't rely on yum for help. 3) Jesse releases a new fedora-release RPM that adds failovermethod=priority to each of the [repository] sections. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243698 filed to track this. So, if someone can help with 1) above, the other two should be easy. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From halfline at gmail.com Mon Jun 11 15:13:12 2007 From: halfline at gmail.com (Ray Strode) Date: Mon, 11 Jun 2007 11:13:12 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <1181539880.19531.26.camel@localhost.localdomain> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> Message-ID: <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> Hi, > The recommendation there is to have libgnomeui depend on yelp. Creating > a virtual provide of HelpBrowser or DocbookXmlViewer in yelp and having > libgnomeui require that might work even better. The virtual provides idea sounds reasonable to me. Would probably help olpc out. --Ray From mclasen at redhat.com Mon Jun 11 15:10:13 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 11 Jun 2007 11:10:13 -0400 Subject: The updates firehose In-Reply-To: <1181567967.3233.16.camel@mccallum.corsepiu.local> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> <1181482619.3445.9.camel@localhost.localdomain> <1181531543.3840.4.camel@neutron.verbum.private> <1181567967.3233.16.camel@mccallum.corsepiu.local> Message-ID: <1181574613.3630.8.camel@dhcp83-186.boston.redhat.com> On Mon, 2007-06-11 at 15:19 +0200, Ralf Corsepius wrote: > On Sun, 2007-06-10 at 23:12 -0400, Colin Walters wrote: > > On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote: > > > > > The current classification we have is just > > > "bugfix - enhancement - security". It would be nice add some more > > > categories to this, like "cosmetic" (for minor packaging cleanups like > > > directory ownership handling), and some way to differentiate by > > > severity. > > > > Why would someone push an update for cosmetic issues? > Because what to consider cosmetic is largely up to the eye of the > beholder. I for one would consider changes which don't have any impact > on a binary rpm to be cosmetic, and anything else to be "bugfix". > > That said, broken permissions/ownerships never are cosmetic, they are > real bug fixes. Here is a typical example of what I consider cosmetic: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689 From notting at redhat.com Mon Jun 11 15:18:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 11:18:02 -0400 Subject: The updates firehose In-Reply-To: <200706110831.22069.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> <20070611050840.GD18869@nostromo.devel.redhat.com> <200706110831.22069.jkeating@redhat.com> Message-ID: <20070611151802.GB3882@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > So, this is something I'd *love* to have - some sort of stats on > > how many people have installed package X; useful for doing checks > > to see what should or shouldn't be on the DVDs, and so on. I know > > the mugshot stats exist, but that's not the same. > > And how thrown off is this data by people who install Everything The number of people who do 'yum install *'.... > or all in a group but never use the data? ... or actively check every box in comps is almost certainly too small to affect things. > More important than 'how many people installed > package X' is perhaps "how many people installed package X that wasn't on the > media" Right, which is done by gathering how many people installed X, and seeing if it wasn't on the media. :) Bill From mschwendt.tmp0701.nospam at arcor.de Mon Jun 11 15:29:30 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 11 Jun 2007 17:29:30 +0200 Subject: More conflicts in Rawhide Message-ID: <20070611172930.0eab9ac6.mschwendt.tmp0701.nospam@arcor.de> html-xml-utils - 3.7-4.fc6.i386 File conflict with: csound - 5.03.0-13.fc7.i386 /usr/bin/extract File conflict with: fish - 1.21.12-1.fc6.i386 /usr/bin/count /usr/share/man/man1/count.1.gz File conflict with: libextractor - 0.5.17a-1.fc7.i386 /usr/bin/extract File conflict with: surfraw - 1.0.7-3.fc8.noarch /usr/bin/cite libtranslate - 0.99-9.fc6.i386 File conflict with: surfraw - 1.0.7-3.fc8.noarch /usr/bin/translate hunspell-he - 0.20050112-3.fc8.noarch File conflict with: hunspell-he - 1.0-7.fc8.i386 postgresql-pgpool - 3.2-1.fc7.i386 File conflict with: postgresql-pgpool-II - 1.1-1.fc8.i386 /usr/bin/pgpool postgresql-pgpool-II - 1.1-1.fc8.i386 File conflict with: postgresql-pgpool - 3.2-1.fc7.i386 /usr/bin/pgpool surfraw - 1.0.7-3.fc8.noarch File conflict with: html-xml-utils - 3.7-4.fc6.i386 /usr/bin/cite File conflict with: libtranslate - 0.99-9.fc6.i386 /usr/bin/translate From halfline at gmail.com Mon Jun 11 15:26:47 2007 From: halfline at gmail.com (Ray Strode) Date: Mon, 11 Jun 2007 11:26:47 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> Message-ID: <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> Hi, > > The recommendation there is to have libgnomeui depend on yelp. Creating > > a virtual provide of HelpBrowser or DocbookXmlViewer in yelp and having > > libgnomeui require that might work even better. > The virtual provides idea sounds reasonable to me. Would probably > help olpc out. Actually, I talked with Matthias a bit more about this, and we came to a slightly different conclusion than before. The gnome_help APIs already have a mechanism for putting up a dialog saying "help not available" or some such that apps should (and mostly do) take advantage of. We already include yelp in comps. If the user wants to explicitly remove yelp to regain some space or whatever, that seems like an okay thing to do. If we put the virtual provides/requires in then the user would have to get some stub package to be able to cleanly drop yelp. It doesn't matter a whole lot either way, but I guess if we think about help as an optional feature, then we shouldn't put the Requires in libgnomeui. --Ray From rc040203 at freenet.de Mon Jun 11 15:34:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 Jun 2007 17:34:25 +0200 Subject: The updates firehose In-Reply-To: <1181574613.3630.8.camel@dhcp83-186.boston.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> <1181482619.3445.9.camel@localhost.localdomain> <1181531543.3840.4.camel@neutron.verbum.private> <1181567967.3233.16.camel@mccallum.corsepiu.local> <1181574613.3630.8.camel@dhcp83-186.boston.redhat.com> Message-ID: <1181576066.3233.37.camel@mccallum.corsepiu.local> On Mon, 2007-06-11 at 11:10 -0400, Matthias Clasen wrote: > On Mon, 2007-06-11 at 15:19 +0200, Ralf Corsepius wrote: > > On Sun, 2007-06-10 at 23:12 -0400, Colin Walters wrote: > > > On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote: > > > > > > > The current classification we have is just > > > > "bugfix - enhancement - security". It would be nice add some more > > > > categories to this, like "cosmetic" (for minor packaging cleanups like > > > > directory ownership handling), and some way to differentiate by > > > > severity. > > > > > > Why would someone push an update for cosmetic issues? > > Because what to consider cosmetic is largely up to the eye of the > > beholder. I for one would consider changes which don't have any impact > > on a binary rpm to be cosmetic, and anything else to be "bugfix". > > > > That said, broken permissions/ownerships never are cosmetic, they are > > real bug fixes. > > Here is a typical example of what I consider cosmetic: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689 > It's an example of what I call bug. I also consider it granted that you will be going to fix this for FC-7 ASAP. Ralf From jkeating at redhat.com Mon Jun 11 15:44:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 11:44:50 -0400 Subject: More conflicts in Rawhide In-Reply-To: <20070611172930.0eab9ac6.mschwendt.tmp0701.nospam@arcor.de> References: <20070611172930.0eab9ac6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706111144.50579.jkeating@redhat.com> On Monday 11 June 2007 11:29:30 Michael Schwendt wrote: > hunspell-he - 0.20050112-3.fc8.noarch > ? File conflict with: hunspell-he - 1.0-7.fc8.i386 This one looks fishy. hunspell-he-0.20050112-3.fc8 is the latest dist-f8 build of hunspell-hg, and it only produced a srpm and noarch package. Where is this i386 hunspell-he package coming from? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 11 15:46:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 11:46:13 -0400 Subject: The updates firehose In-Reply-To: <1181576066.3233.37.camel@mccallum.corsepiu.local> References: <200706091605.00638.jkeating@redhat.com> <1181574613.3630.8.camel@dhcp83-186.boston.redhat.com> <1181576066.3233.37.camel@mccallum.corsepiu.local> Message-ID: <200706111146.13957.jkeating@redhat.com> On Monday 11 June 2007 11:34:25 Ralf Corsepius wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689 > > It's an example of what I call bug. > > I also consider it granted that you will be going to fix this for FC-7 > ASAP. I also consider this a bug. It winds up pulling metacity-devel onto a user's system when they try to install something that requires metacity. Then all the depchain of metacity-devel is pulled in as well. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Mon Jun 11 15:44:59 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 11 Jun 2007 11:44:59 -0400 Subject: The updates firehose In-Reply-To: <200706111146.13957.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <1181574613.3630.8.camel@dhcp83-186.boston.redhat.com> <1181576066.3233.37.camel@mccallum.corsepiu.local> <200706111146.13957.jkeating@redhat.com> Message-ID: <1181576699.3630.10.camel@dhcp83-186.boston.redhat.com> On Mon, 2007-06-11 at 11:46 -0400, Jesse Keating wrote: > On Monday 11 June 2007 11:34:25 Ralf Corsepius wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689 > > > > It's an example of what I call bug. > > > > I also consider it granted that you will be going to fix this for FC-7 > > ASAP. > > I also consider this a bug. It winds up pulling metacity-devel onto a user's > system when they try to install something that requires metacity. Then all > the depchain of metacity-devel is pulled in as well. Doesn't rpm's grandiose shortest-name-wins rule save us there ? From jkeating at redhat.com Mon Jun 11 15:52:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 11:52:56 -0400 Subject: The updates firehose In-Reply-To: <1181576699.3630.10.camel@dhcp83-186.boston.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <200706111146.13957.jkeating@redhat.com> <1181576699.3630.10.camel@dhcp83-186.boston.redhat.com> Message-ID: <200706111152.56896.jkeating@redhat.com> On Monday 11 June 2007 11:44:59 Matthias Clasen wrote: > Doesn't rpm's grandiose shortest-name-wins rule save us there ? Not really it would seem. Not entirely sure why. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rjones at redhat.com Mon Jun 11 15:55:03 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 11 Jun 2007 16:55:03 +0100 Subject: OCaml find-requires and find-provides In-Reply-To: References: <46571CAB.203@redhat.com> Message-ID: <466D7057.8000309@redhat.com> Panu Matilainen wrote: > On Fri, 25 May 2007, Richard W.M. Jones wrote: > >> Here are some working find-requires and find-provides scripts for >> OCaml. The produce dependencies according to what I wrote about here: >> >> https://www.redhat.com/archives/fedora-packaging/2007-May/msg00105.html >> >> (Ignore the earlier versions of the same scripts attached to that email). >> >> To use them is simply a matter of adding the following lines to a spec >> file: >> >> %define _use_internal_dependency_generator 0 >> %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh >> %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh >> >> Also attached is a patch to the ocaml.spec file to install these. >> > > Hey, if/when you think these are ready for widespread use, please drop a > note to rpm-maint at lists.rpm.org for inclusion... Panu, I tried to join the list, but my subscription request seems to have disappeared somewhere. Anyway, I'm quite happy with the latest versions of these scripts which are attached to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From caillon at redhat.com Mon Jun 11 15:56:21 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 11 Jun 2007 11:56:21 -0400 Subject: The updates firehose In-Reply-To: <1181576699.3630.10.camel@dhcp83-186.boston.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <1181574613.3630.8.camel@dhcp83-186.boston.redhat.com> <1181576066.3233.37.camel@mccallum.corsepiu.local> <200706111146.13957.jkeating@redhat.com> <1181576699.3630.10.camel@dhcp83-186.boston.redhat.com> Message-ID: <466D70A5.3020600@redhat.com> Matthias Clasen wrote: > On Mon, 2007-06-11 at 11:46 -0400, Jesse Keating wrote: >> I also consider this a bug. It winds up pulling metacity-devel onto a user's >> system when they try to install something that requires metacity. Then all >> the depchain of metacity-devel is pulled in as well. Fortunately, not many things require metacity, and chances are that the user isn't going to install it post facto since we install firstboot by default which has an explicit metacity requirement. > Doesn't rpm's grandiose shortest-name-wins rule save us there ? Not quite sure, there may be a bug. I accidentally had firefox-debuginfo providing gecko-devel (along with firefox-devel) and firefox-devel won all of the time in brew. As soon as we switched to koji, -debuginfo started to win half the time which is when I noticed the error. Could be that we switched around the time we got a new rpm that broke this behavior, I didn't investigate too far... From mschwendt.tmp0701.nospam at arcor.de Mon Jun 11 16:03:54 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 11 Jun 2007 18:03:54 +0200 Subject: More conflicts in Rawhide In-Reply-To: <200706111144.50579.jkeating@redhat.com> References: <20070611172930.0eab9ac6.mschwendt.tmp0701.nospam@arcor.de> <200706111144.50579.jkeating@redhat.com> Message-ID: <20070611180354.f70da9f5.mschwendt.tmp0701.nospam@arcor.de> On Mon, 11 Jun 2007 11:44:50 -0400, Jesse Keating wrote: > > hunspell-he - 0.20050112-3.fc8.noarch > > ? File conflict with: hunspell-he - 1.0-7.fc8.i386 > > This one looks fishy. hunspell-he-0.20050112-3.fc8 is the latest dist-f8 > build of hunspell-hg, and it only produced a srpm and noarch package. Where > is this i386 hunspell-he package coming from? http://redhat.download.fedoraproject.org/pub/fedora/linux/development/i386/os/repodata/ From jkeating at redhat.com Mon Jun 11 16:04:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 12:04:07 -0400 Subject: The updates firehose In-Reply-To: <466D70A5.3020600@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <1181576699.3630.10.camel@dhcp83-186.boston.redhat.com> <466D70A5.3020600@redhat.com> Message-ID: <200706111204.08020.jkeating@redhat.com> On Monday 11 June 2007 11:56:21 Christopher Aillon wrote: > Fortunately, not many things require metacity, and chances are that the > user isn't going to install it post facto since we install firstboot by > default which has an explicit metacity requirement. The way it came to my attention was somebody trying to use pungi to respin Fedora. Depsolving brought in all the -devel stuff. Perhaps this is also a result of how pungi is doing the depsolving as it has to do it differently than one would do at install time. (IE I can't rely on the metacity already in the transaction to satisfy a dep of something else as that user may not actually select metacity, I need to pull in all possible providers of a dep and have anaconda/yum sort it out at install time based on the packages selected then). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Mon Jun 11 16:14:44 2007 From: wwoods at redhat.com (Will Woods) Date: Mon, 11 Jun 2007 12:14:44 -0400 Subject: The updates firehose In-Reply-To: <200706110831.22069.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> <20070611050840.GD18869@nostromo.devel.redhat.com> <200706110831.22069.jkeating@redhat.com> Message-ID: <1181578484.25734.23.camel@metroid.rdu.redhat.com> On Mon, 2007-06-11 at 08:31 -0400, Jesse Keating wrote: > On Monday 11 June 2007 01:08:40 Bill Nottingham wrote: > > So, this is something I'd *love* to have - some sort of stats on > > how many people have installed package X; useful for doing checks > > to see what should or shouldn't be on the DVDs, and so on. I know > > the mugshot stats exist, but that's not the same. > > And how thrown off is this data by people who install Everything, or all in a > group but never use the data? More important than 'how many people installed > package X' is perhaps "how many people installed package X that wasn't on the > media" and even more importantly "how many people launched package X and what > was X's deps?". Debian's popcon[0] utility does almost exactly that. This would make a nice counterpart to smolt - where smolt tracks what hardware people are using, popcon tracks what *software* they're using. It's all proven, open-source stuff - adding this as a feature for F8 wouldn't be hard. On the other hand, I don't want to duplicate code. Since we're already talking about more Mugshot-y stuff in F8[1], maybe it makes sense to extend the Mugshot application info-gathering backend to work more like popcon. Perhaps it would need to be split out from Mugshot so people who don't care about Mugshot can still opt to collect and submit stats. Thoughts? -w [0] http://popcon.debian.org/ [1] http://fedoraproject.org/wiki/Releases/FeatureBigboard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Mon Jun 11 16:16:18 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 11 Jun 2007 10:16:18 -0600 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <3689.71.208.222.235.1181536031.squirrel@www.cora.nwra.com> Message-ID: <466D7552.4080903@cora.nwra.com> Simon Andrews wrote: > orion at cora.nwra.com wrote: >> >> Add the updates repo at upgrade/install time. > > Is this currently possible? I've just upgraded a load of servers from > FC6 to F7 and saw no option to add in extra repositories. This was a > text based nfs upgrade. > Support was added in FC6. Looks like from Jesse's email you need to be doing a network install. Also, there is a bug when doing nfs installs that requires *lots* of memory to do an install. I've switched to http as a result. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jon at fedoraunity.org Mon Jun 11 16:41:42 2007 From: jon at fedoraunity.org (Jonathan Steffan) Date: Mon, 11 Jun 2007 10:41:42 -0600 Subject: Fedora 8 FUDCon/Hackfest In-Reply-To: <20070611130533.GA6400@dudweiler.stuttgart.redhat.com> References: <1181330087.3903.185.camel@lt21223.campus.dmacc.edu> <200706081520.11252.jkeating@redhat.com> <1181417651.4813.19.camel@localhost.localdomain> <20070609194220.GA8740@wolff.to> <466D343C.6000501@kanarip.com> <267C4A57-E1D0-4515-9398-1BE1214210A8@dev.intechnology.co.uk> <20070611130533.GA6400@dudweiler.stuttgart.redhat.com> Message-ID: <1181580102.6880.0.camel@damaestro> Either date is fine with me. I would rather have the even earlier vs. later. Jonathan Steffan From notting at redhat.com Mon Jun 11 17:09:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 13:09:55 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> Message-ID: <20070611170955.GD3882@nostromo.devel.redhat.com> Ray Strode (halfline at gmail.com) said: > It doesn't matter a whole lot either way, but I guess if we think > about help as an optional feature, then we shouldn't put the Requires > in libgnomeui. Why should help be an optional feature? Bill From rc040203 at freenet.de Mon Jun 11 17:13:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 11 Jun 2007 19:13:11 +0200 Subject: The updates firehose In-Reply-To: <1181578484.25734.23.camel@metroid.rdu.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> <20070611050840.GD18869@nostromo.devel.redhat.com> <200706110831.22069.jkeating@redhat.com> <1181578484.25734.23.camel@metroid.rdu.redhat.com> Message-ID: <1181581992.3233.53.camel@mccallum.corsepiu.local> On Mon, 2007-06-11 at 12:14 -0400, Will Woods wrote: > On Mon, 2007-06-11 at 08:31 -0400, Jesse Keating wrote: > > On Monday 11 June 2007 01:08:40 Bill Nottingham wrote: > > > So, this is something I'd *love* to have - some sort of stats on > > > how many people have installed package X; useful for doing checks > > > to see what should or shouldn't be on the DVDs, and so on. I know > > > the mugshot stats exist, but that's not the same. > > > > And how thrown off is this data by people who install Everything, or all in a > > group but never use the data? More important than 'how many people installed > > package X' is perhaps "how many people installed package X that wasn't on the > > media" and even more importantly "how many people launched package X and what > > was X's deps?". > > Debian's popcon[0] utility does almost exactly that. This would > make a nice counterpart to smolt - where smolt tracks what hardware > people are using, popcon tracks what *software* they're using. It's all > proven, open-source stuff - adding this as a feature for F8 wouldn't be > hard. > > On the other hand, I don't want to duplicate code. Since we're already > talking about more Mugshot-y stuff in F8[1], maybe it makes sense to > extend the Mugshot application info-gathering backend to work more like > popcon. Perhaps it would need to be split out from Mugshot so people who > don't care about Mugshot can still opt to collect and submit stats. > > Thoughts? Linux is gradually approaching 1984. From a.badger at gmail.com Mon Jun 11 17:23:11 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 Jun 2007 10:23:11 -0700 Subject: To Require yelp or not to require yelp In-Reply-To: <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> Message-ID: <1181582591.19531.54.camel@localhost.localdomain> On Mon, 2007-06-11 at 11:26 -0400, Ray Strode wrote: > Hi, > > > > The recommendation there is to have libgnomeui depend on yelp. Creating > > > a virtual provide of HelpBrowser or DocbookXmlViewer in yelp and having > > > libgnomeui require that might work even better. > > The virtual provides idea sounds reasonable to me. Would probably > > help olpc out. > > Actually, I talked with Matthias a bit more about this, and we came to > a slightly different conclusion than before. > > The gnome_help APIs already have a mechanism for putting up a dialog > saying "help not available" or some such that apps should (and mostly > do) take advantage of. Great! Does the API work with gnomeuiinfo or uimanager? (I'm packaging an old app that uses gnomeuiinfo and the menu system does not give an error when yelp is not installed. I can propose a port to uimanager to upstream if there's a way to get at the error there.) > We already include yelp in comps. If the user wants to explicitly > remove yelp to regain some space or whatever, that seems like an okay > thing to do. If we put the virtual provides/requires in then the user > would have to get some stub package to be able to cleanly drop yelp. > > It doesn't matter a whole lot either way, but I guess if we think > about help as an optional feature, then we shouldn't put the Requires > in libgnomeui. I agree that the provides is less than ideal. If there's another way to find out there's a problem displaying help I'll work with that. BTW, I was wrong about the mime-type in the .desktop file being the key for selecting the application to use. gnome-help which is a symlink to yelp is referenced from a gconf key:: /desktop/gnome/url-handlers/ghelp/command -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jun 11 17:28:45 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 13:28:45 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <1181582591.19531.54.camel@localhost.localdomain> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> Message-ID: <20070611172845.GA6648@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > BTW, I was wrong about the mime-type in the .desktop file being the key > for selecting the application to use. gnome-help which is a symlink to > yelp is referenced from a gconf key:: > /desktop/gnome/url-handlers/ghelp/command So, rpm *does* need to synthesize a requires from the union of all users' gconf keys. Fun! Bill From ssorce at redhat.com Mon Jun 11 18:06:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Jun 2007 14:06:58 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <20070611172845.GA6648@nostromo.devel.redhat.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> Message-ID: <1181585218.15078.54.camel@willson> On Mon, 2007-06-11 at 13:28 -0400, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > BTW, I was wrong about the mime-type in the .desktop file being the key > > for selecting the application to use. gnome-help which is a symlink to > > yelp is referenced from a gconf key:: > > /desktop/gnome/url-handlers/ghelp/command > > So, rpm *does* need to synthesize a requires from the union of all users' > gconf keys. Fun! Exp. when you don't have access to their homes or you don't even know they exists (NSS enumeration turned off) :-) Simo. From davej at redhat.com Mon Jun 11 18:21:37 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 11 Jun 2007 14:21:37 -0400 Subject: rawhide report: 20070601 changes In-Reply-To: References: <200706020524.l525OU7X002727@porkchop.devel.redhat.com> <1180808607.4028.7.camel@pensja.lam.pl> <1180969267.9788.25.camel@erebor.boston.redhat.com> Message-ID: <20070611182137.GA18850@redhat.com> On Fri, Jun 08, 2007 at 07:14:32AM -0700, darrell pfeifer wrote: > On 6/4/07, Jeremy Katz wrote: > > On Sat, 2007-06-02 at 20:23 +0200, Leszek Matok wrote: > > > Dnia 02-06-2007, sob o godzinie 09:58 -0700, darrell pfeifer napisa?(a): > > > > 4) Java (the Sun version) segfaulted > > > On my system, QuakeForge (compiled by me 4 days ago, when development > > > was an almost-F7) segfaults in memset() (run from > > > _dl_map_object_from_fd() trying to map a shared library) when I try to > > > run it, also "ldd `which nq-glx`" is crashing, but "/lib/ld-linux.so.2 > > > `nq-glx`" runs the game. Weird. > > > > mono apps similarly based on tomboy's failure to start this morning on > > my laptop; haven't gotten to actually debugging it yet. Anyone filed it > > in bugzilla? > > > > The failures in mono and java have disappeared with the 3213 kernel yeah, MAP_FIXED wasn't. Sorry about that.. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Mon Jun 11 18:26:39 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 11 Jun 2007 14:26:39 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <466A3C95.60905@gmail.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> <466A3C95.60905@gmail.com> Message-ID: <466D93DF.6090108@redhat.com> Ken YANG wrote: > hi, > > it seems that the update about beryl still has dependence error: > > Error: Missing Dependency: emerald-themes >= 0.2.1 is needed by package > beryl-gnome > Error: Missing Dependency: heliodor >= 0.2.1 is needed by package > beryl-gnome > Error: Missing Dependency: emerald >= 0.2.1 is needed by package beryl-gnome > > i wait several days for this bug fix, but these errors still be there. > > please correct me if i'm wrong Nope, you're correct. I've not had time to deal with beryl, its rather low-priority juxtaposed to a bunch of other stuff on my plate right now. Patches welcome! ;) > by the way, how can i report this sort of update dependence errors? > is it appropriates to report errors to fedora-devel-list? That's generally fine. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tmz at pobox.com Mon Jun 11 18:55:01 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 11 Jun 2007 14:55:01 -0400 Subject: The updates firehose In-Reply-To: <1181581992.3233.53.camel@mccallum.corsepiu.local> References: <200706091605.00638.jkeating@redhat.com> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> <20070611050840.GD18869@nostromo.devel.redhat.com> <200706110831.22069.jkeating@redhat.com> <1181578484.25734.23.camel@metroid.rdu.redhat.com> <1181581992.3233.53.camel@mccallum.corsepiu.local> Message-ID: <20070611185501.GA18455@psilocybe.teonanacatl.org> Ralf Corsepius wrote: > Linux is gradually approaching 1984. *Asking* users for feedback is not at all similar to 1984's governmental abuses of liberty. No need for paranoid worries. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have an existential map; it has 'you are here' written all over it. -- Steven Wright -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From pertusus at free.fr Mon Jun 11 19:20:33 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 11 Jun 2007 21:20:33 +0200 Subject: The updates firehose In-Reply-To: <1181559951.2351.7.camel@localhost.localdomain> References: <200706091605.00638.jkeating@redhat.com> <20070610090424.faf52471.mschwendt.tmp0701.nospam@arcor.de> <466BC5A8.4000707@fedoraproject.org> <20070610101402.GA30423@eeyore.32.boerneef.vornavalley> <466BD775.5000902@fedoraproject.org> <1181559951.2351.7.camel@localhost.localdomain> Message-ID: <20070611192033.GA4394@free.fr> On Mon, Jun 11, 2007 at 01:05:51PM +0200, Sindre Pedersen Bjordal wrote: > For the record, I'm a community guy requesting a policy on updates. > > Leaving it up to the packagers is fine if the packagers feel confident > that they can themselves decide on the best updates policy for users for > each package, I'm not that confident. I'd like to see some guidelines on > when to push updates for certain types of packages, simply because I > just don't know what makes sense. Do you really want a policy or an advice? It will be quite hard to come up with a policy that matches all the use cases and all the types of packages and isn't too complex nor bureaucratic. > And I feel really guilty, I alone am responsible for 22 of the updates You shouldn't. -- Pat From walters at redhat.com Mon Jun 11 19:31:54 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 11 Jun 2007 15:31:54 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <20070611172845.GA6648@nostromo.devel.redhat.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> Message-ID: <1181590315.3840.15.camel@neutron.verbum.private> On Mon, 2007-06-11 at 13:28 -0400, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > BTW, I was wrong about the mime-type in the .desktop file being the key > > for selecting the application to use. gnome-help which is a symlink to > > yelp is referenced from a gconf key:: > > /desktop/gnome/url-handlers/ghelp/command > > So, rpm *does* need to synthesize a requires from the union of all users' > gconf keys. Fun! There's no good reason that should be a GConf key; you could just ignore it. Random aside - I wonder if anyone would notice or care if the Help menu items just disappeared from all applications. From jspaleta at gmail.com Mon Jun 11 19:37:58 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Jun 2007 11:37:58 -0800 Subject: To Require yelp or not to require yelp In-Reply-To: <1181590315.3840.15.camel@neutron.verbum.private> References: <466BA0D6.8050603@hhs.nl> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> Message-ID: <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> On 6/11/07, Colin Walters wrote: > Random aside - I wonder if anyone would notice or care if the Help menu > items just disappeared from all applications. I'd notice. I use the help a lot when I'm trying to learn how to play a new variant of solitaire in aisleriot. -jef"how the frell do you change openoffice's default date representation when using the date field in a presentation template so it doesn't use the god aweful European standard of DD/MM/YY and uses the much more reasonable US standard of MM/DD/YY."spaleta From dimi at lattica.com Mon Jun 11 19:41:17 2007 From: dimi at lattica.com (Dimi Paun) Date: Mon, 11 Jun 2007 15:41:17 -0400 (EDT) Subject: To Require yelp or not to require yelp In-Reply-To: <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> References: <466BA0D6.8050603@hhs.nl> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> Message-ID: <38362.142.205.241.254.1181590877.squirrel@lattica.com> > it doesn't use the god aweful European standard of DD/MM/YY and uses > the much more reasonable US standard of MM/DD/YY."spaleta Wow, just curious why would MM/DD/YY be "reasonable"?!? It's completely non-uniform, I guess the only thing going for it is the fact that it makes some sense in accounting, but that is rather obscure reason to prefer it... :) -- Dimi Paun Lattica, Inc. From jkeating at redhat.com Mon Jun 11 19:48:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 15:48:16 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <38362.142.205.241.254.1181590877.squirrel@lattica.com> References: <466BA0D6.8050603@hhs.nl> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> <38362.142.205.241.254.1181590877.squirrel@lattica.com> Message-ID: <200706111548.20110.jkeating@redhat.com> On Monday 11 June 2007 15:41:17 Dimi Paun wrote: > Wow, just curious why would MM/DD/YY be "reasonable"?!? > It's completely non-uniform, I guess the only thing going > for it is the fact that it makes some sense in accounting, > but that is rather obscure reason to prefer it... :) Probably because here in the states we say things like 'March 5th, 1985' when talking about a date, so having the date format flow month-day-year makes sense to us. (yes there is "5th of march, 1985" but that's less common in my experience. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Jun 11 19:49:19 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 11 Jun 2007 21:49:19 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> References: <466BA0D6.8050603@hhs.nl> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> Message-ID: <1181591359.3729.4.camel@rousalka.dyndns.org> Le lundi 11 juin 2007 ? 11:37 -0800, Jeff Spaleta a ?crit : > -jef"how the frell do you change openoffice's default date > representation when using the date field in a presentation template so > it doesn't use the god aweful European standard of DD/MM/YY and uses > the much more reasonable US standard of MM/DD/YY."spaleta The European standard is sane if in the reverse order for decent computer sorting. The US standard is not called reasonable by anyone but americans. So you should use iso 8601 dates which are sane *and* in the order computers expect: YYYY-MM-DD And no I haven't looked how to feed it to openoffice by default either (cursing there too) -- 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 jspaleta at gmail.com Mon Jun 11 19:50:52 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Jun 2007 11:50:52 -0800 Subject: To Require yelp or not to require yelp In-Reply-To: <38362.142.205.241.254.1181590877.squirrel@lattica.com> References: <466BA0D6.8050603@hhs.nl> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> <38362.142.205.241.254.1181590877.squirrel@lattica.com> Message-ID: <604aa7910706111250s30dd9d91g308c4562bdc2b1bd@mail.gmail.com> On 6/11/07, Dimi Paun wrote: > Wow, just curious why would MM/DD/YY be "reasonable"?!? > It's completely non-uniform, I guess the only thing going > for it is the fact that it makes some sense in accounting, > but that is rather obscure reason to prefer it... :) Off Topic!!!!!!!!!!!! Its reasonable.. in that... i've chosen a US English keyboard layout, and there is a cultural expectation that dates be presented in that way by default. I would have expected this sort of thing to be a locale sensitive default... but apparently it isn't. I make no claim that US culture is reasonable... just that my software conform to the syntactical expectations thereof. Now I just have to figure out how to beat the software into submission so people don't make unreasonably nitpicky comments about the date format when I'm doing a presentation. -jef"You know your science results are solid when the most contentious aspect of your presentation is the date string format"spaleta From jwilson at redhat.com Mon Jun 11 20:24:42 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 11 Jun 2007 16:24:42 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <466D93DF.6090108@redhat.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> <466A3C95.60905@gmail.com> <466D93DF.6090108@redhat.com> Message-ID: <466DAF8A.6040809@redhat.com> Jarod Wilson wrote: > Ken YANG wrote: >> hi, >> >> it seems that the update about beryl still has dependence error: >> >> Error: Missing Dependency: emerald-themes >= 0.2.1 is needed by package >> beryl-gnome >> Error: Missing Dependency: heliodor >= 0.2.1 is needed by package >> beryl-gnome >> Error: Missing Dependency: emerald >= 0.2.1 is needed by package beryl-gnome >> >> i wait several days for this bug fix, but these errors still be there. >> >> please correct me if i'm wrong > > Nope, you're correct. I've not had time to deal with beryl, its rather > low-priority juxtaposed to a bunch of other stuff on my plate right now. > Patches welcome! ;) Patch is dead-simple, found a few cycles this afternoon to work on this. New builds are slowly working their way through the build system, should be available on mirrors sometime soonish (where "soonish" might be something between "tonight" and "this upcoming weekend"... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tonynelson at georgeanelson.com Mon Jun 11 21:19:35 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 11 Jun 2007 17:19:35 -0400 Subject: The updates firehose In-Reply-To: <29185.192.54.193.51.1181568897.squirrel@rousalka.dyndns.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <1181467847.28023.6.camel@rousalka.dyndns.org> <20070611130645.GA17371@lists.us.dell.com> <29185.192.54.193.51.1181568897.squirrel@rousalka.dyndns.org> Message-ID: At 3:34 PM +0200 6/11/07, Nicolas Mailhot wrote: >Le Lun 11 juin 2007 15:06, Matt Domsch a ?crit : > >> Mirrormanager just returns a yum mirrorlist, which is updated hourly, >> and is very fast to return (under 0.5s almost all the time). > >And this kills proxies as the systems behind a proxy will switch from >a mirror already cached by the proxy to another one potentially every >hour. Proxies want a static mirrorlist or a mirrorlist they can cache. >(using a mirrorlist URL with parameters is probably sufficient to make >it uncacheable, better static URLs with mod_rewrite or something >similar behind to translate them in hidden requests) ... Would my StableMirror yum plugin help? It uses the same mirror each time as long as that mirror was offered (and it does other things too). It's main idea could certainly be added to yum. StableMirror isn't updated for F7 yet (I assume it will need an update). -- ____________________________________________________________________ TonyN.:' ' From blc at redhat.com Mon Jun 11 21:27:33 2007 From: blc at redhat.com (Brendan Conoboy) Date: Mon, 11 Jun 2007 15:27:33 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <466D0105.7090608@linux-kernel.at> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <4669AEBC.3070802@redhat.com> <466D0105.7090608@linux-kernel.at> Message-ID: <466DBE45.206@redhat.com> Oliver Falk wrote: >> Reliable? Sure. But there are problems unique to cross compiling which >> must be addressed. You don't want to pull in a host-header instead of a >> target-header. > > Issue number 1. It's a pretty rare issue these days. You have to provide an absolute pathname, which is always frowned upon. Further, if you cross-build in a chroot, it's a non-issue. >> You also can't run the resulting executables so >> post-build testsuites can't be run. > > Issue number 2. Yep- but only relevant for a small set of packages. > OK. That might be true for gcc, but how about gcj? Or other compilers? > I'm also thinking about python that emits byte-code. Is this code > machine independent? I'm not sure; Could google or read, but just want > to mention.... Gcj?! Er, no problem there... I'm sure there could be some Python issues (We have not had to tackle that one). When we start implementing a cross compile feature, we would naturally would take on the easy and critical packages first. Python could come later. > Yes, cross compilation is an interesting; At least for me and I would be > happy to be a bit involved; You never stop learning... Great! -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Mon Jun 11 21:42:31 2007 From: blc at redhat.com (Brendan Conoboy) Date: Mon, 11 Jun 2007 15:42:31 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181377214.2801.54.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> Message-ID: <466DC1C7.6070303@redhat.com> David Woodhouse wrote: > Before we get to actually cross-compiling something for release, it > would be good to get cross-compilers into Fedora. > > Making a cross-binutils package isn't hard; it's a relatively > modification to our existing binutils package to make it build for > multiple %targets. > > Making a cross-gcc package which targets linux-elf is harder, because of > the evil recursive dependencies to which you refer above. It would be > good if we could get that working though. Hi, Yep, we've been through this a few times. Having discussed this with you a number of times before, I know where you're coming from. We really should be able to build gcc without having to build parts of glibc in the process. That said, this is really only an exercise in bootstrapping which doesn't happen very often. Let us, for example, pretend we're just discussing cross compilation for existing archs. Because of the iterative nature of these builds, everything we need is already there to build the cross compiler. We have kernel headers and we have a glibc rpm for the target arch. All that we need in some machinery to pull in files from a different arch and extract them into a sys-root. As gcc matures, it's likely that the libgcc problem will go away by it being split out. At that time, the chicken/egg problem will be solved without having to resort to clever hacks. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Mon Jun 11 21:51:52 2007 From: blc at redhat.com (Brendan Conoboy) Date: Mon, 11 Jun 2007 15:51:52 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181557202.2801.74.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466A717A.1050102@hhs.nl> <1181557202.2801.74.camel@pmac.infradead.org> Message-ID: <466DC3F8.5000003@redhat.com> David Woodhouse wrote: > I see you've actually pulled in glibc sources and you're using them in > the gcc build. I was trying to avoid that. Yeah, it's nasty but necessary until you have binaries for your dependencies. Hopefully gcc will split out all its support libraries in time such that it isn't necessary. Meanwhile, it's only a problem for arches that the build system doesn't already have a glibc for. > I suppose if we can depend on having a sysroot populated with > appropriate glibc-*.$ARCH.rpm packages then the bootstrap approach isn't > _so_ bad, but that might be a lot to expect of yum/koji. It's an area of the build system that has to be extended for cross compiling to work in general. Making the cross compiler build is but a small example of the general case. There are plenty of packages which have multi-layer dependencies. The build system needs to resolve those, installing the packages into the sys-root for the cross compiler to compile and link against. This falls to the build system because it would be silly for each and every package to have to do that itself. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Mon Jun 11 22:18:02 2007 From: blc at redhat.com (Brendan Conoboy) Date: Mon, 11 Jun 2007 16:18:02 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181388161.2845.43.camel@rt.jesacco.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <1181388161.2845.43.camel@rt.jesacco.com> Message-ID: <466DCA1A.10708@redhat.com> Joseph Sacco wrote: > which is RPM based and extensible. crosstools "auto-magically" handles > the recursive dependency problems that you mention It's the doing-it-the-rpm-way that is a problem. All from-scratch gcc cross compiler-generating scripts that I have seen require glibc sources as part of the compiler build. In an rpm universe you only need headers and libraries to build a package, not sources from some other package. My scripts, Hans's scripts, and crosstool all have this limitation. This is because gcc contains both an independent compiler and libc-intertwined support libraries. > Both are RPM based and extensible. Doesn't seem like the sort of thing we could simply bolt onto the side of the existing build system and enjoy. It's possibly not even that big of a change to the build system since it's just a slight twist on something it's already doing. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From caillon at redhat.com Mon Jun 11 22:23:45 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 11 Jun 2007 18:23:45 -0400 Subject: The updates firehose In-Reply-To: <200706101910.22912.opensource@till.name> References: <200706091605.00638.jkeating@redhat.com> <200706101726.36818.opensource@till.name> <466C21E5.3050201@redhat.com> <200706101910.22912.opensource@till.name> Message-ID: <466DCB71.1090602@redhat.com> Till Maas wrote: > On So Juni 10 2007, Christopher Aillon wrote: > >> But there are always bugs. Are we going to fix every one? We need to >> fix the important ones. I don't think that pulling in every latest >> version is important enough against a release. > > When an update that fixes an not very important bug causes a lot of work, e.g. > a new python version, than imho it is worth waiting till the next release. > Also, when there are no bug reports from Fedora users, than imho it is also > ok to delay an update. What does a maintainer gain when he maintains an old > version of a package in one release and a newer one in another instead of > maintaining the same new version in both releases? Also there are cases, when > a user cannot easiely upgrade to a new release, e.g. all zope users cannot > use Fedora 7 afaik, because there is no Zope in Fedora 7 anymore. And last > but not least it is also depressing to fill bug reports, when they are > ignored. I never said ignore them. Respond timely. Fix with discretion. Users for the most part are willing to accept that not every bug is going to be fixed in the current version. From williams at redhat.com Mon Jun 11 22:53:37 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 11 Jun 2007 17:53:37 -0500 Subject: Fedora and Cross Compiling In-Reply-To: <466D085A.90001@linux-kernel.at> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <466D085A.90001@linux-kernel.at> Message-ID: <466DD271.6050602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oliver Falk wrote: > On 06/08/2007 09:56 PM, Brendan Conoboy wrote: > [ ... ] >>> The build system must be enhanced to support cross compilation. >> This is a really interesting (to me) extension of the build system >> requiring enhancements in many areas. >> >> First, there are primitives in Koji that need to be built up such that, >> for instance, x86 knows it can cross build arm tools. > > To make koji believe it can build arm on x86 should be no problem. But > how to tell koji to don't do the %test's. We need to do this on rpm level... > >> Second, the x86 host needs to be able to retrieve and install arm >> dependencies in the arm sys-root (arm's glibc, arm's libX11-devel, etc). > > Now we need to touch yum... I'm sure Seth can hack up that bit of code. > :-) Also mock needs to understand it. We use mock and yum in our current cross build environment (I'm in Brendan's group as well). Mock doesn't really care what's going on in the chroot, it just installs package dependencies and periodically runs commands in the chroot. So, if you have a repository with cross tool binary RPMs in it, mock will happily use yum to fetch them, install them into your chroot and will run them in the chroot. I did add an option to mock (the --installdeps option) that will just pull the build depdendencies from an RPM and have yum install them into a chroot, but that's the only thing that's really cross-specific in mock. Haven't really had to do anything to yum. We do have some ugly hackery in our tools that use mock/yum though. We override the RPM macros and rpmrc files, in an attempt to use the out-of-the-box specfile while overriding the compiler, linker, assembler, etc. The intent is to put together a chroot that contains cross tools, then run rpmbuild on a specfile in the chroot so that the outtput is a binary RPM targeted for the desired architecture (armv5l, mips32, etc.). Unfortunately not many specfiles work out-of-the-box. I'll see if I can put together a (somewhat) coherent description of how we build and install cross RPMS. Not sure it'll be all that useful for Fedora, but it might stimulate a discussion that gets us there. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGbdJxHyuj/+TTEp0RApRGAKDf2AN8wbLH4D1XJsLdzoyLBmdmQwCghisq vFCAIROepedxEoadk6eDT68= =Z1DR -----END PGP SIGNATURE----- From mcepl at redhat.com Mon Jun 11 23:53:18 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 Jun 2007 01:53:18 +0200 Subject: To Require yelp or not to require yelp References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> Message-ID: On 2007-06-11, 15:26 GMT, Ray Strode wrote: > We already include yelp in comps. If the user wants to > explicitly remove yelp to regain some space or whatever, Not they didn't want to remove yelp (see bug 242673 for the background story on this mess) -- just removed firefox on x86_64 so that they could install firefox.i386 and they didn't noticed what's going on (I guess the thought was something like: ?Yelp -- sounds nasty; ... what is it good for anyway, name doesn't sound familiar??). Matej From mcepl at redhat.com Mon Jun 11 23:56:14 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 Jun 2007 01:56:14 +0200 Subject: To Require yelp or not to require yelp References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <20070611170955.GD3882@nostromo.devel.redhat.com> Message-ID: On 2007-06-11, 17:09 GMT, Bill Nottingham wrote: > Ray Strode (halfline at gmail.com) said: >> It doesn't matter a whole lot either way, but I guess if we think >> about help as an optional feature, then we shouldn't put the Requires >> in libgnomeui. > > Why should help be an optional feature? +1 !!! (because geeks don't care about lusers? Wasn't Gnome meant to be for non-geeks?) Matej From mcepl at redhat.com Mon Jun 11 23:50:29 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 Jun 2007 01:50:29 +0200 Subject: To Require yelp or not to require yelp References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> Message-ID: On 2007-06-11, 19:31 GMT, Colin Walters wrote: > Random aside - I wonder if anyone would notice or care if the > Help menu items just disappeared from all applications. Reporter of bug 242673 which lies in the root of all this messes noticed. Matej From cr33dog at gmail.com Tue Jun 12 02:02:59 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Mon, 11 Jun 2007 21:02:59 -0500 Subject: A couple of glitches installing F7 from Live CD - to BZ, or not to BZ? Message-ID: Hi List! Had a few obstacles to successful install - wanting to confirm these as bugs (vs my own stupidity) before filing. I installed from the Live CD. 1. - The installer was came up in a res that my flat panel would not display. After giving a CTRL-ALT-BACKSPACE or two, should an option be given to switch display modes? (no CTRL-ALT-+ selections worked). Or is this a matter of passing the right vga= option at boot time? (seems it could be friendlier - could the live CD/installer show a table of options?). 2. - I bypassed #1 by editing xorg.conf and using the vesa driver for install. Afterward I mounted the new installation and make the same change. Without this step, firstboot fails to run (well it does, but you can't *see* it :) ). Should anaconda check to see if xorg.conf was modified? Or back to vga= at boot time? 3. I entered a static IP during install but on reboot NetworkManager picked up a DHCP address from the router. I'm pretty sure this one's a bug. If NetworkManager doesn't respect the static IP, the option should not be shown in anaconda. Apologies if these are just noise - I ran several queries in BZ with no (apparent) matches. And to tell the truth, I'm not sure #1 and #2 are really bugs. I kept step-by-step notes from the install - mainly for my own sanity: http://cr33k.com/random/f7-XPS400-install-notes.html (sorry about the formatting) Aside from the few bumps in the road, it was a pleasant trip - thanks for all the hard work! Chris From fedora at drussell.dnsalias.com Tue Jun 12 01:31:15 2007 From: fedora at drussell.dnsalias.com (Don Russell) Date: Mon, 11 Jun 2007 18:31:15 -0700 Subject: The updates firehose In-Reply-To: <200706091605.00638.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> Message-ID: <466DF763.5090608@drussell.dnsalias.com> Jesse Keating wrote: > Anybody else think we're issuing entirely /way/ too many updates? We've had > 138 "stable" updates, and 177 current "testing" updates. If all those were > to go stable, we're talking over 300 updates, in just over a week. > > Seriously. We're drowning our users in updates. Are all of them really > necessary? I feel like we've got this culture of update whatever/whenever > coming from Extras where it was just fire and forget. While that might be > fun for the maintainer, is it fun for the user? Is it fun for the user with > a slow connection? > I'm a user (of my own system, so also an administrator).... here's my 2 cents... I don't really care if there is a "flood of updates".... I interpret it as "people are busy" at making my system better. :-) or adding new things to make other systems better. :-) What I *would* like (just started thinking about it) is a procmail recipe to divide the announcement e-mails into "installed" and "not installed" packages. For example... I received an e-mail with this subject: Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7 Thats great... very consistent subject patterns, but from a programming point of view, how do I know where the program name ends (so I can use it with an rpm -q command to see if it is installed), and where the version number starts (so I can compare it with the results of rpm -q)? It would help is there was a blank between program name and version number... or even more explicit: Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7 ThenI can easily just grab everything between "Update:" and "Version:" for the program name, and everything aftet "Version:" for the version number. Ideally, I'll have procmail divide these announcements into three groups: 1 - program is installed and announcement is advising of newer version (yum should pick those up automatically when the nightly yum runs) 2 - program is installed and already at/beyond the announced version (i.e yum update beat the announcement) 3 - program is not installed, but I can look at the announcement to see if it's something I might be interested in From caillon at redhat.com Tue Jun 12 02:29:58 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 11 Jun 2007 22:29:58 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> Message-ID: <466E0526.3050807@redhat.com> Matej Cepl wrote: > On 2007-06-11, 19:31 GMT, Colin Walters wrote: >> Random aside - I wonder if anyone would notice or care if the >> Help menu items just disappeared from all applications. > > Reporter of bug 242673 which lies in the root of all this messes > noticed. No, reading the bug, the root of all this is because someone went against my will twice now and added the firefox-32 package. Now people think they can do shit like this which was one of my objections in the first place. I objected to this before it got added and it got added anyway. Then I objected after it got added again and they promised to remove it but it's apparently back now, after I verified it got removed. Clearly, my decisions matter. From seg at haxxed.com Tue Jun 12 02:35:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 11 Jun 2007 21:35:19 -0500 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: References: Message-ID: <1181615719.9159.24.camel@localhost> http://www.getright.com/seedtorrent.html Supported by Azureus, among others. We already have an extensive HTTP/FTP mirror system to leverage. I've noticed, after the initial release rush, torrents end up being quite a bit slower than just downloading from a mirror. Especially on a less popular arch. (cough ppc cough...) In the past I've just stopped the torrent, downloaded the iso from a mirror, then restarted the torrent to help seed. It would be nice to just have this happen automagically. -------------- next part -------------- A non-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 Jun 12 02:51:45 2007 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 11 Jun 2007 20:51:45 -0600 Subject: The updates firehose In-Reply-To: <20070611050545.GC18869@nostromo.devel.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070611050545.GC18869@nostromo.devel.redhat.com> Message-ID: <1181616705.4361.25.camel@mentorng.gurulabs.com> On Mon, 2007-06-11 at 01:05 -0400, Bill Nottingham wrote: > Gianluca Sforna (giallu at gmail.com) said: > > On 6/9/07, Bernardo Innocenti wrote: > > >Yes, I could use a local Fedora mirror. And, in fact, > > >I do. But then I'd have to customize the yum config on > > >all clients to go look there. > > > > > > > Guru Labs have a nice howto for solving that problem (/me bookmarking it...) > > > > http://www.gurulabs.com/goodies/YUM_automatic_local_mirror.php > > Why not just use: > > https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003654.html > > ? The Guru Labs local mirror howto method doesn't require *any* changes to the clients. That was the whole point. :) If the yum-avahi plugin ever gets installed and enabled by default, then it would address that concern too. I have my own question about the yum-avahi. What does it take it get it to work (if it can) across multiple subnets within an organization? Dax Kelson Guru Labs From fedora at drussell.dnsalias.com Tue Jun 12 03:26:27 2007 From: fedora at drussell.dnsalias.com (Don Russell) Date: Mon, 11 Jun 2007 20:26:27 -0700 Subject: The updates firehose In-Reply-To: <466DF763.5090608@drussell.dnsalias.com> References: <200706091605.00638.jkeating@redhat.com> <466DF763.5090608@drussell.dnsalias.com> Message-ID: <466E1263.6070906@drussell.dnsalias.com> Don Russell wrote: > Jesse Keating wrote: >> Anybody else think we're issuing entirely /way/ too many updates? >> We've had 138 "stable" updates, and 177 current "testing" updates. >> If all those were to go stable, we're talking over 300 updates, in >> just over a week. >> >> Seriously. We're drowning our users in updates. Are all of them >> really necessary? I feel like we've got this culture of update >> whatever/whenever coming from Extras where it was just fire and >> forget. While that might be fun for the maintainer, is it fun for >> the user? Is it fun for the user with a slow connection? >> > > I'm a user (of my own system, so also an administrator).... here's my > 2 cents... > > I don't really care if there is a "flood of updates".... I interpret > it as "people are busy" at making my system better. :-) or adding new > things to make other systems better. :-) > > What I *would* like (just started thinking about it) is a procmail > recipe to divide the announcement e-mails into "installed" and "not > installed" packages. > > For example... I received an e-mail with this subject: > Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7 > > Thats great... very consistent subject patterns, but from a > programming point of view, how do I know where the program name ends > (so I can use it with an rpm -q command to see if it is installed), > and where the version number starts (so I can compare it with the > results of rpm -q)? It would help is there was a blank between program > name and version number... or even more explicit: > Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7 > > ThenI can easily just grab everything between "Update:" and "Version:" > for the program name, and everything aftet "Version:" for the version > number. > > Ideally, I'll have procmail divide these announcements into three groups: > 1 - program is installed and announcement is advising of newer version > (yum should pick those up automatically when the nightly yum runs) > 2 - program is installed and already at/beyond the announced version > (i.e yum update beat the announcement) > 3 - program is not installed, but I can look at the announcement to > see if it's something I might be interested in As I started looking into this more, I realized the needed information (package name, version, etc) are already nicely formatted in the message body.... so, no need to add a blank in the subject line material. :-) From che666 at gmail.com Tue Jun 12 03:24:08 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 12 Jun 2007 05:24:08 +0200 Subject: The updates firehose In-Reply-To: <466DCB71.1090602@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <200706101726.36818.opensource@till.name> <466C21E5.3050201@redhat.com> <200706101910.22912.opensource@till.name> <466DCB71.1090602@redhat.com> Message-ID: 2007/6/12, Christopher Aillon : > Till Maas wrote: > > On So Juni 10 2007, Christopher Aillon wrote: > > > >> But there are always bugs. Are we going to fix every one? We need to > >> fix the important ones. I don't think that pulling in every latest > >> version is important enough against a release. > > > > When an update that fixes an not very important bug causes a lot of work, e.g. > > a new python version, than imho it is worth waiting till the next release. > > Also, when there are no bug reports from Fedora users, than imho it is also > > ok to delay an update. What does a maintainer gain when he maintains an old > > version of a package in one release and a newer one in another instead of > > maintaining the same new version in both releases? Also there are cases, when > > a user cannot easiely upgrade to a new release, e.g. all zope users cannot > > use Fedora 7 afaik, because there is no Zope in Fedora 7 anymore. And last > > but not least it is also depressing to fill bug reports, when they are > > ignored. > > I never said ignore them. Respond timely. Fix with discretion. Users > for the most part are willing to accept that not every bug is going to > be fixed in the current version. Are you really sure on that? Its atleast not true for me. Actually one of the reasons i sticked with fedora back then is to have a recent system. if it again starts to stall it will result in me replacing half the system again with my own selfbuilt packages which is basically the state i had 5 years ago. It would also open a reason to actually start a 3rd party repository again to get things fixed that are just stalled. Basically i think that fedora should really reflect the current state and that we have systems like yum-presto in place that prevent users from downloading that big amounts of updates which is relevant for low bandwidth users. Personally i still find a few things here or there that are stalled and that didnt get any updates since a while (see xchat at releasetime... see libtorrent/rtorrent etc etc). i think the amount of updates is rather unproblematic if there is a proper qa process in place to prevent too many regressions. If i wanted a more freezed state and backports of fixes instead lots of feature updates i would definitely use a different distro. regards, Rudolf Kastl > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From me at semitekie.com Tue Jun 12 03:33:29 2007 From: me at semitekie.com (J French) Date: Mon, 11 Jun 2007 23:33:29 -0400 Subject: Rebuilding RPMs results in bad update behavior Message-ID: <466E1409.2080505@semitekie.com> If I have a fully updated system and I decide I want to oh, say rebuild the nautilus rpm on my system to make it faster, I go download the latest version src.rpm (which happens to be the same version I have installed) and rebuild it on my system. This is the way you should be doing things on a server, by the way - at least for those packages you want optimized. I don't do automatic updates on my servers though, so never noticed this before. Now, when I go to rpm -Uvh the resulting rpm, I get "the installed version is NEWER than this one". How in the world is this even possible? So now, any packages I rebuild get marked as older than the binaries? Are we building our RPMs in the future now? What's determining the age of these RPMs - it's certainly not the build time. What's determining whether or not a package should be updated - it's certainly not the version number. In short, do I have to actually unpack any rpms I want to rebuild and go change the version number in the source to stop this from happening? Oh yes, one last thing: On my dual Opteron 246 running in 32-bit mode (I use 32-bit for my desktop for compatability reasons), rebuilding Metacity and Nautilus make the desktop *very* much more responsive than the binary packages. No surprise there, the only real surprise was when I logged into my newly lightning fast desktop and was informed that there were updates to these packages (of the same version number). I'm guessing this is a bug in either rpm or rpmbuild, but I'd like more input before I file one. From spng.yang at gmail.com Tue Jun 12 03:28:46 2007 From: spng.yang at gmail.com (Ken YANG) Date: Tue, 12 Jun 2007 11:28:46 +0800 Subject: new libwnck make emerald fail to start In-Reply-To: <466DAF8A.6040809@redhat.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> <466A3C95.60905@gmail.com> <466D93DF.6090108@redhat.com> <466DAF8A.6040809@redhat.com> Message-ID: <466E12EE.7080904@gmail.com> Jarod Wilson wrote: > Jarod Wilson wrote: >> Ken YANG wrote: >>> hi, >>> >>> it seems that the update about beryl still has dependence error: >>> >>> Error: Missing Dependency: emerald-themes >= 0.2.1 is needed by package >>> beryl-gnome >>> Error: Missing Dependency: heliodor >= 0.2.1 is needed by package >>> beryl-gnome >>> Error: Missing Dependency: emerald >= 0.2.1 is needed by package beryl-gnome >>> >>> i wait several days for this bug fix, but these errors still be there. >>> >>> please correct me if i'm wrong >> Nope, you're correct. I've not had time to deal with beryl, its rather >> low-priority juxtaposed to a bunch of other stuff on my plate right now. >> Patches welcome! ;) > > Patch is dead-simple, found a few cycles this afternoon to work on this. > New builds are slowly working their way through the build system, should > be available on mirrors sometime soonish (where "soonish" might be > something between "tonight" and "this upcoming weekend"... :) thanks for your work :-) by the way, the dependence error about revisor is still there: Error: Missing Dependency: nash = 6.0.9-4 is needed by package libbdevid-python can you guide me who can i report this error to. > > From kevin at scrye.com Tue Jun 12 03:46:09 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 11 Jun 2007 21:46:09 -0600 Subject: XFCE desktop needs ... tetex ? In-Reply-To: <20070607064516.GB2848@free.fr> References: <645d17210706061527k5237fe0ci7c7aeccdd8e9f5a@mail.gmail.com> <20070607064516.GB2848@free.fr> Message-ID: <20070611214609.17e3eef2@ghistelwchlohm.scrye.com> On Thu, 7 Jun 2007 08:45:16 +0200 pertusus at free.fr (Patrice Dumas) wrote: > On Wed, Jun 06, 2007 at 11:27:10PM +0100, Jonathan Underwood wrote: > > > > Hm. I wonder if xfprint could be patched to use enscript instead of > > a2ps - enscript doesn't have such dependencies. > > enscript doesn't use delegation, it is only for text files. In that > case, paps may be a better solution. a2ps allows to use many more > document types. In fact xfprint can autodetect if a2ps is installed at run time. However, there would then just be a lot less options available for people running it, and not any indication why. ;( Since we don't have anything like a "Suggests:" in rpm, I think it's best that we require a2ps so all the options are available to users. We could look at changing to paps or something, but that should probibly be done upstream. I see that there are some of the translation files that talk about a2ps, so they would all need to be retranslated if another package was used. ;( > Pat kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jun 12 04:11:05 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Jun 2007 00:11:05 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <466E1409.2080505@semitekie.com> References: <466E1409.2080505@semitekie.com> Message-ID: <20070612041105.GA4244@jadzia.bu.edu> On Mon, Jun 11, 2007 at 11:33:29PM -0400, J French wrote: > Now, when I go to rpm -Uvh the resulting rpm, I get "the installed > version is NEWER than this one". How in the world is this even possible? > So now, any packages I rebuild get marked as older than the binaries? echo '%dist .fc8.jfrench' >> ~/.rpmmacros > Oh yes, one last thing: On my dual Opteron 246 running in 32-bit mode (I > use 32-bit for my desktop for compatability reasons), rebuilding Compatibility with what, exactly? You can run, for example, 32-bit firefox on an otherwise 64-bit system for the best of both worlds.... > Metacity and Nautilus make the desktop *very* much more responsive than > the binary packages. No surprise there, the only real surprise was when I'm actually a little surprised. Can you qualtify your results? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Tue Jun 12 03:07:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 23:07:55 -0400 Subject: The updates firehose In-Reply-To: <466DF763.5090608@drussell.dnsalias.com> References: <200706091605.00638.jkeating@redhat.com> <466DF763.5090608@drussell.dnsalias.com> Message-ID: <20070612030755.GA6895@nostromo.devel.redhat.com> Don Russell (fedora at drussell.dnsalias.com) said: > What I *would* like (just started thinking about it) is a procmail > recipe to divide the announcement e-mails into "installed" and "not > installed" packages. Well, there's no guarantee that you're reading the mail on the box in question, etc. Perhaps something utilizing yum-updatesd might be better? > For example... I received an e-mail with this subject: > Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7 > > Thats great... very consistent subject patterns, but from a programming > point of view, how do I know where the program name ends (so I can use > it with an rpm -q command to see if it is installed), and where the > version number starts (so I can compare it with the results of rpm -q)? > It would help is there was a blank between program name and version > number... or even more explicit: > Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7 echo "xorg-x11-server-1.3.0.0-8.fc7" | awk -F '-' '{ print gensub("-"," ",NF-2) }' There are certainly simpler ways. Bill From bernie at codewiz.org Tue Jun 12 04:27:53 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 12 Jun 2007 00:27:53 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <20070611170955.GD3882@nostromo.devel.redhat.com> Message-ID: <466E20C9.7060707@codewiz.org> Matej Cepl wrote: > On 2007-06-11, 17:09 GMT, Bill Nottingham wrote: >> Ray Strode (halfline at gmail.com) said: >>> It doesn't matter a whole lot either way, but I guess if we think >>> about help as an optional feature, then we shouldn't put the Requires >>> in libgnomeui. >> Why should help be an optional feature? > > +1 !!! (because geeks don't care about lusers? Wasn't Gnome meant > to be for non-geeks?) -1. What desktop should the geeks be using then? Since we support people with various disabilities, then we should support geeks too :-) The serious argument is: something is "optional" when it is not strictly required by the application to provide its core functionality. Saying that help is useful for newbies or lusers is pointless. Optional stuff is always useful to somebody, otherwise it wouldn't have been done in the first place. So, online help is *clearly* an optional desktop feature. People using systems with limited disk space, like the OLPC users, will want to remove it. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From buildsys at redhat.com Tue Jun 12 05:06:29 2007 From: buildsys at redhat.com (Build System) Date: Tue, 12 Jun 2007 01:06:29 -0400 Subject: rawhide report: 20070612 changes Message-ID: <200706120506.l5C56TOw031925@porkchop.devel.redhat.com> From me at semitekie.com Tue Jun 12 05:13:09 2007 From: me at semitekie.com (J French) Date: Tue, 12 Jun 2007 01:13:09 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <20070612041105.GA4244@jadzia.bu.edu> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> Message-ID: <466E2B65.9000509@semitekie.com> Matthew Miller wrote: > On Mon, Jun 11, 2007 at 11:33:29PM -0400, J French wrote: >> Now, when I go to rpm -Uvh the resulting rpm, I get "the installed >> version is NEWER than this one". How in the world is this even possible? >> So now, any packages I rebuild get marked as older than the binaries? > > echo '%dist .fc8.jfrench' >> ~/.rpmmacros Right, why should I have to do that? > >> Oh yes, one last thing: On my dual Opteron 246 running in 32-bit mode (I >> use 32-bit for my desktop for compatability reasons), rebuilding > > Compatibility with what, exactly? You can run, for example, 32-bit firefox > on an otherwise 64-bit system for the best of both worlds.... I have the 64-bit version of 7 which I'm going to install tonight, but if the bugs I expressed I was being bitten by in Test 4 are still there, it won't be there in the morning. These bugs included Firefox crashing X when closing a tab with absolutely no indication as to why, X crashing when switching VT's and a few others - I filed bugs on all of them. If they haven't been fixed, I'll reassert that 7 should never have been released like that. I seriously couldn't get any real work done. > > >> Metacity and Nautilus make the desktop *very* much more responsive than >> the binary packages. No surprise there, the only real surprise was when > > I'm actually a little surprised. Can you qualtify your results? > Qualtify it? When I log in, my desktop is ready to use in about 2-4 seconds as opposed to around 10-15. When I'm full out working, with a plethora of applications, instances of applications and whatnot running, I don't see any window drawing lag as I do with the binaries. I rebuilt Firefox too, and I'm here to tell you it also starts WAY faster than the binary install did when no other instances are running. On top of this, OpenOffice, which I haven't yet touched (yet), now takes 4 seconds to start as opposed to 12 before - I have no idea why this is though, I didn't think OOo called on either Nautilus or Metacity *that* much. My Athlon 64 3000+ desktop with half the RAM (4GB opposed to 8GB) has about the same responsiveness as the dual Opteron 246 running with the binaries. The reason I don't find this surprising is that I suspect the single processor system is closer in architecture to the original build host and, both processors are indeed used with the binaries, the code's just more optimized for that system when it's compiled on that system. This is system optimization 101 and has sparked many debates on the web about using RPMs as opposed to compiling from source. The "correct" method when installing or updating RPMs on a production server (where optimization is key) has always been to download the source and build an RPM from that or rebuild a src.rpm, which you then install on the server. Yes, this means dealing with dependency hell a little bit (and there are some insane dependencies these days), but that's why we make the big bucks and gcc uses different optimization code for 32-bit and 64-bit processors (even though I'm running in 32-bit mode, I saw gcc say "checking for 64-bit host: yes") as well as seeing a difference in Athlon and Intel processors and quite a few other optimizations. Regardless of why I might want to build my own RPMs on system, regardless of if I'm seeing much improvement: The point I'm trying to make with this is that a binary RPM that I make on June 11th of packagename-1.1 should take precedence over an RPM of packagename-1-1 made on March 3rd - no matter who made it. People running servers in production environments who care more about those servers than to just "yum install whatever" are going to have these same issues. I know Fedora isn't exactly geared toward servers (even though it's being used on quite a few of them), but the downstream RHEL is and some consideration should be taken on the issue anyway for those of us who like to tweak the daylights out of our systems. I mean, why would you want to make customization of a Linux system harder without *very* good reason to do so? I'm off to install the 64-bit Fedora 7 on the dual Opteron system, I'll take some startup times from the fresh install, repeat the RPM rebuilds and take some times from that and post them back here when I'm done. From notting at redhat.com Tue Jun 12 05:09:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Jun 2007 01:09:08 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <466E20C9.7060707@codewiz.org> References: <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <20070611170955.GD3882@nostromo.devel.redhat.com> <466E20C9.7060707@codewiz.org> Message-ID: <20070612050908.GB14864@nostromo.devel.redhat.com> Bernardo Innocenti (bernie at codewiz.org) said: > So, online help is *clearly* an optional desktop feature. People > using systems with limited disk space, like the OLPC users, will > want to remove it. So, then, every package should package *-help separately, and if you want to actually have online help, you need to become superuser and install it? That's a horrible user experience. Frankly, it seems all the kvetching here is 'yelp is bloated because it pulls in firefox'. Which is completely orthogonal to the packaging of help - if the viewer is a pig, fix the viewer, don't remove all the apps. Bill From mkearey at redhat.com Tue Jun 12 18:28:56 2007 From: mkearey at redhat.com (Mike Kearey) Date: Wed, 13 Jun 2007 04:28:56 +1000 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <466E2B65.9000509@semitekie.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> Message-ID: <466EE5E8.5010407@redhat.com> J French wrote: > > > Matthew Miller wrote: >> On Mon, Jun 11, 2007 at 11:33:29PM -0400, J French wrote: >>> Now, when I go to rpm -Uvh the resulting rpm, I get "the installed >>> version is NEWER than this one". How in the world is this even >>> possible? So now, any packages I rebuild get marked as older than the >>> binaries? >> >> echo '%dist .fc8.jfrench' >> ~/.rpmmacros > Right, why should I have to do that? > >> >>> Oh yes, one last thing: On my dual Opteron 246 running in 32-bit mode >>> (I use 32-bit for my desktop for compatability reasons), rebuilding >> >> Compatibility with what, exactly? You can run, for example, 32-bit >> firefox >> on an otherwise 64-bit system for the best of both worlds.... > I have the 64-bit version of 7 which I'm going to install tonight, but > if the bugs I expressed I was being bitten by in Test 4 are still there, > it won't be there in the morning. These bugs included Firefox crashing X > when closing a tab with absolutely no indication as to why, X crashing > when switching VT's and a few others - I filed bugs on all of them. If > they haven't been fixed, I'll reassert that 7 should never have been > released like that. I seriously couldn't get any real work done. > >> >> >>> Metacity and Nautilus make the desktop *very* much more responsive >>> than the binary packages. No surprise there, the only real surprise >>> was when >> >> I'm actually a little surprised. Can you qualtify your results? >> > Qualtify it? I'd like to see repeatable, measurable tests not subjective 'I think it's faster' observations. I am no criticizing here, it's just that humans are actually bad at this sort of thing. Measurements are better. Also exactly what 'optimizations' are you doing? Simply rebuilding is a waste of time. Open Source development is about collaboration. So if you have found the magic sekret sauce to make your desktop apps faster, it would be nice to share it. Cheers From jspaleta at gmail.com Tue Jun 12 05:39:37 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Jun 2007 21:39:37 -0800 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <466EE5E8.5010407@redhat.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> <466EE5E8.5010407@redhat.com> Message-ID: <604aa7910706112239k60a210cal29e2ab250dd18cf3@mail.gmail.com> On 6/12/07, Mike Kearey wrote: > Also exactly what 'optimizations' are you doing? Simply rebuilding is a > waste of time. Yes, knowing what differences are there during the local rebuild process. Since the distribution builders themselves are 64bit machines its not even clear to me that there's a significant difference between the system he's rebuilding on and the actual build systems. Is he perhaps hitting some sort of oddity with prelink and or readahead memory caching and misdiagnosing some sort of slowdown due to library loading? I'm only guessing, but without a concrete procedure to attempt to reproduce and a benchmark metric to record this is just noise with no way forward. -jef From nicolas.mailhot at laposte.net Tue Jun 12 05:40:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 12 Jun 2007 07:40:01 +0200 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <1181467847.28023.6.camel@rousalka.dyndns.org> <20070611130645.GA17371@lists.us.dell.com> <29185.192.54.193.51.1181568897.squirrel@rousalka.dyndns.org> Message-ID: <1181626801.27823.6.camel@rousalka.dyndns.org> Le lundi 11 juin 2007 ? 17:19 -0400, Tony Nelson a ?crit : > Would my StableMirror yum plugin help? It uses the same mirror each time > as long as that mirror was offered (and it does other things too). It's > main idea could certainly be added to yum. StableMirror isn't updated for > F7 yet (I assume it will need an update). > Can't really say, never used it and the URL you gave is dead. However from your description it isn't going to fix the metadata problem, nor ensure every box behind the proxy uses the same mirror -- 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 oliver at linux-kernel.at Tue Jun 12 07:16:15 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 12 Jun 2007 09:16:15 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466DD271.6050602@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <466D085A.90001@linux-kernel.at> <466DD271.6050602@redhat.com> Message-ID: <466E483F.7000901@linux-kernel.at> Hi! I would suggest we create a Wiki (best under SIGs) and add our ideas there. Also the steps that must be done... What do you think? -of From caolanm at redhat.com Tue Jun 12 07:22:37 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 12 Jun 2007 08:22:37 +0100 Subject: date format in impress In-Reply-To: <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> References: <466BA0D6.8050603@hhs.nl> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> Message-ID: <1181632957.2833.16.camel@localhost.localdomain> On Mon, 2007-06-11 at 11:37 -0800, Jeff Spaleta wrote: > On 6/11/07, Colin Walters wrote: > > Random aside - I wonder if anyone would notice or care if the Help menu > > items just disappeared from all applications. > > I'd notice. I use the help a lot when I'm trying to learn how to play > a new variant of solitaire in aisleriot. > > -jef"how the frell do you change openoffice's default date > representation when using the date field in a presentation template so > it doesn't use the god aweful European standard of DD/MM/YY and uses > the much more reasonable US standard of MM/DD/YY."spaleta in a blank document... echo $LANG en_US.UTF-8 ooimpress->insert->date says 6/12/07 i.e. MM/DD/YY export LANG=en_IE.UTF-8 ooimpress->insert->date says 12/06/07 i.e. DD/MM/YY Perhaps your document/template has the language set to override the locale, check tools->options->language settings->languages C. From sundaram at fedoraproject.org Tue Jun 12 07:32:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 13:02:21 +0530 Subject: The updates firehose In-Reply-To: <1181578484.25734.23.camel@metroid.rdu.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> <20070611050840.GD18869@nostromo.devel.redhat.com> <200706110831.22069.jkeating@redhat.com> <1181578484.25734.23.camel@metroid.rdu.redhat.com> Message-ID: <466E4C05.3090304@fedoraproject.org> Will Woods wrote: > > Debian's popcon[0] utility does almost exactly that. This would > make a nice counterpart to smolt - where smolt tracks what hardware > people are using, popcon tracks what *software* they're using. It's all > proven, open-source stuff - adding this as a feature for F8 wouldn't be > hard. > I haven't looked at how popcon works. If you can port it easily that would be fine. Otherwise adding a optional package listing in Smolt (changing it from a hardware to system profiler) might also be good. > On the other hand, I don't want to duplicate code. Since we're already > talking about more Mugshot-y stuff in F8[1], maybe it makes sense to > extend the Mugshot application info-gathering backend to work more like > popcon. Perhaps it would need to be split out from Mugshot so people who > don't care about Mugshot can still opt to collect and submit stats. > > Thoughts? Mugshot folks don't seem to be interested in splitting out code when I asked in fedora-desktop list. From the description it appears that the code is not going to useful outside of mugshot. Talk to them again anyway. Rahul From sundaram at fedoraproject.org Tue Jun 12 07:36:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 13:06:01 +0530 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <200706101726.36818.opensource@till.name> <466C21E5.3050201@redhat.com> <200706101910.22912.opensource@till.name> <466DCB71.1090602@redhat.com> Message-ID: <466E4CE1.4000907@fedoraproject.org> Rudolf Kastl wrote: >> >> I never said ignore them. Respond timely. Fix with discretion. Users >> for the most part are willing to accept that not every bug is going to >> be fixed in the current version. > > Are you really sure on that? Its atleast not true for me. > The general releases can't by definition fix every bug. Some of them are always going to be too intrusive to fix in a "stable" branch. Rahul From sundaram at fedoraproject.org Tue Jun 12 07:39:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 13:09:51 +0530 Subject: Don't use trademark images in Grub In-Reply-To: <1181569260.3630.1.camel@dhcp83-186.boston.redhat.com> References: <4663C148.1040909@codewiz.org> <1180980718.15415.29.camel@rousalka.dyndns.org> <1180981031.10913.3.camel@workstation.unixkiste.local> <200706041421.51808.jkeating@redhat.com> <20070607145703.GB25221@nostromo.devel.redhat.com> <1181294808.3782.0.camel@workstation.unixkiste.local> <466B8F76.1080301@fedoraproject.org> <1181471430.7684.3.camel@bigbox.unixkiste.local> <1181481524.3445.2.camel@localhost.localdomain> <1181549400.3827.17.camel@workstation.unixkiste.local> <1181569260.3630.1.camel@dhcp83-186.boston.redhat.com> Message-ID: <466E4DC7.7040602@fedoraproject.org> Matthias Clasen wrote: > > You are not listening. No matter how easy it is to split off a > subpackage, legal has asked us to keep all trademarked images in a > single package. > > Anyway, there is still an easy way out; just don't use trademarked > images in grub. That should be pretty easy to do. CC'ing fedora-art list. The plan for Fedora 8 is to reduce the branding in the images anyway. Rahul From bernie at codewiz.org Tue Jun 12 07:56:44 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Tue, 12 Jun 2007 03:56:44 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <20070612050908.GB14864@nostromo.devel.redhat.com> References: <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <20070611170955.GD3882@nostromo.devel.redhat.com> <466E20C9.7060707@codewiz.org> <20070612050908.GB14864@nostromo.devel.redhat.com> Message-ID: <466E51BC.8070405@codewiz.org> Bill Nottingham wrote: > Bernardo Innocenti (bernie at codewiz.org) said: >> So, online help is *clearly* an optional desktop feature. People >> using systems with limited disk space, like the OLPC users, will >> want to remove it. > > So, then, every package should package *-help separately, > and if you want to actually have online help, you need to become > superuser and install it? That's a horrible user experience. I have not suggested packaging the help files separately. It's easy to avoid installing them with --excludedocs anyway. > Frankly, it seems all the kvetching here is 'yelp is bloated > because it pulls in firefox'. Which is completely orthogonal > to the packaging of help - if the viewer is a pig, fix the viewer, > don't remove all the apps. Then why not just drop the few explicit dependencies on yelp so it can be uninstalled? It could still be listed as a default install in comps. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From vnpenguin at vnoss.org Tue Jun 12 08:34:51 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Tue, 12 Jun 2007 10:34:51 +0200 Subject: mod_perl-devel is needed for Perl ? Message-ID: On my F7: yum deplist perl Finding dependencies: package: perl.i386 4:5.8.8-18.fc7 dependency: perl(Text::Tabs) provider: perl.i386 4:5.8.8-18.fc7 dependency: perl(IO) provider: perl.i386 4:5.8.8-18.fc7 dependency: perl(Exporter) provider: perl.i386 4:5.8.8-18.fc7 ... dependency: perl(warnings) provider: perl.i386 4:5.8.8-18.fc7 provider: mod_perl-devel.i386 2.0.3-7 ... Why there is such dependency ? I need (standard) Perl only; I have no intention do run mod_perl, nothing to do with httpd, why need mod_perl-devel here ? Any idea ? Feature ? Bug ? Thanks -- http://vnoss.org From vnpenguin at vnoss.org Tue Jun 12 09:04:49 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Tue, 12 Jun 2007 11:04:49 +0200 Subject: mod_perl-devel is needed for Perl ? In-Reply-To: References: Message-ID: Because of this dependency, a lot of unwanted *-devel package will be added to my build: -rw-r--r-- 2 root root 173948 2007-05-23 16:39 apr-devel-1.2.8-6.i386.rpm -rw-r--r-- 2 root root 56837 2007-05-23 16:39 apr-util-devel-1.2.8-7.i386.rpm -rw-r--r-- 2 root root 362052 2007-05-23 17:22 cyrus-sasl-devel-2.1.22-6.i386.rpm -rw-r--r-- 2 root root 2417089 2007-05-23 17:23 db4-devel-4.5.20-5.fc7.i386.rpm -rw-r--r-- 2 root root 132291 2007-05-23 17:45 expat-devel-1.95.8-9.i386.rpm -rw-r--r-- 2 root root 149554 2007-05-23 18:45 httpd-devel-2.2.4-4.i386.rpm -rw-r--r-- 2 root root 270905 2007-05-23 20:30 mod_perl-devel-2.0.3-7.i386.rpm -rw-r--r-- 2 root root 270696 2007-06-09 15:01 mod_perl-devel-2.0.3-9.1.fc7.i386.rpm -rw-r--r-- 2 root root 1653098 2007-05-23 20:58 openldap-devel-2.3.34-0.fc7.i386.rpm :(( How to fix this "buggy" dependency ? Thanks, From rc040203 at freenet.de Tue Jun 12 09:08:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 Jun 2007 11:08:42 +0200 Subject: mod_perl-devel is needed for Perl ? In-Reply-To: References: Message-ID: <1181639322.3233.163.camel@mccallum.corsepiu.local> On Tue, 2007-06-12 at 10:34 +0200, Vnpenguin wrote: > On my F7: > > yum deplist perl > > Finding dependencies: > dependency: perl(warnings) > provider: perl.i386 4:5.8.8-18.fc7 > provider: mod_perl-devel.i386 2.0.3-7 > Any idea ? Feature ? Bug ? This definitely is a packaging bug. Ralf From sundaram at fedoraproject.org Tue Jun 12 09:15:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 14:45:03 +0530 Subject: mod_perl-devel is needed for Perl ? In-Reply-To: References: Message-ID: <466E6417.1040407@fedoraproject.org> Vnpenguin wrote: > Because of this dependency, a lot of unwanted *-devel package will be > added to my build: > > -rw-r--r-- 2 root root 173948 2007-05-23 16:39 apr-devel-1.2.8-6.i386.rpm > -rw-r--r-- 2 root root 56837 2007-05-23 16:39 > apr-util-devel-1.2.8-7.i386.rpm > -rw-r--r-- 2 root root 362052 2007-05-23 17:22 > cyrus-sasl-devel-2.1.22-6.i386.rpm > -rw-r--r-- 2 root root 2417089 2007-05-23 17:23 > db4-devel-4.5.20-5.fc7.i386.rpm > -rw-r--r-- 2 root root 132291 2007-05-23 17:45 > expat-devel-1.95.8-9.i386.rpm > -rw-r--r-- 2 root root 149554 2007-05-23 18:45 > httpd-devel-2.2.4-4.i386.rpm > -rw-r--r-- 2 root root 270905 2007-05-23 20:30 > mod_perl-devel-2.0.3-7.i386.rpm > -rw-r--r-- 2 root root 270696 2007-06-09 15:01 > mod_perl-devel-2.0.3-9.1.fc7.i386.rpm > -rw-r--r-- 2 root root 1653098 2007-05-23 20:58 > openldap-devel-2.3.34-0.fc7.i386.rpm > > :(( > > How to fix this "buggy" dependency ? File a bug report. A rebuild can workaround this if you need a solution immediately. Rahul From vnpenguin at vnoss.org Tue Jun 12 09:28:22 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Tue, 12 Jun 2007 11:28:22 +0200 Subject: mod_perl-devel is needed for Perl ? In-Reply-To: <466E6417.1040407@fedoraproject.org> References: <466E6417.1040407@fedoraproject.org> Message-ID: On 6/12/07, Rahul Sundaram wrote: > > File a bug report. A rebuild can workaround this if you need a solution > immediately. > Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243832 -- http://vnoss.org From mschwendt.tmp0701.nospam at arcor.de Tue Jun 12 09:39:14 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 12 Jun 2007 11:39:14 +0200 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <466E2B65.9000509@semitekie.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> Message-ID: <20070612113914.37855a4f.mschwendt.tmp0701.nospam@arcor.de> On Tue, 12 Jun 2007 01:13:09 -0400, J French wrote: > > > Matthew Miller wrote: > > On Mon, Jun 11, 2007 at 11:33:29PM -0400, J French wrote: > >> Now, when I go to rpm -Uvh the resulting rpm, I get "the installed > >> version is NEWER than this one". How in the world is this even possible? > >> So now, any packages I rebuild get marked as older than the binaries? > > > > echo '%dist .fc8.jfrench' >> ~/.rpmmacros > Right, why should I have to do that? Because you don't have the redhat-rpm-config package installed? $ rpm --eval %dist .fc7 $ rpm -qf /usr/lib/rpm/redhat/macros redhat-rpm-config-8.0.45-15.fc7 For many packages, this %dist macro is appended to the package release tag. If undefined, the rebuilt package has a lower release tag. From mattdm at mattdm.org Tue Jun 12 10:45:24 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Jun 2007 06:45:24 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <466E2B65.9000509@semitekie.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> Message-ID: <20070612104524.GA29825@jadzia.bu.edu> On Tue, Jun 12, 2007 at 01:13:09AM -0400, J French wrote: > >echo '%dist .fc8.jfrench' >> ~/.rpmmacros > Right, why should I have to do that? You don't "have" to do anything. You want your local packages to 1) automatically be easily identifiable as such and 2) automatically beat Fedora packages, you *should* do that. I recommend also making your own "subrelease" if you've made any changes. > I have the 64-bit version of 7 which I'm going to install tonight, but > if the bugs I expressed I was being bitten by in Test 4 are still there, > it won't be there in the morning. These bugs included Firefox crashing X > when closing a tab with absolutely no indication as to why, X crashing > when switching VT's and a few others - I filed bugs on all of them. If > they haven't been fixed, I'll reassert that 7 should never have been > released like that. I seriously couldn't get any real work done. Not sure about the Firefox issue, but the rest sounds like buggy video drivers. What card? > >I'm actually a little surprised. Can you qualtify your results? > Qualtify it? When I log in, my desktop is ready to use in about 2-4 Well, I'll be happy with "quantify". > seconds as opposed to around 10-15. When I'm full out working, with a > plethora of applications, instances of applications and whatnot running, This amount of change is almost certainly due to something other than recompiling your applications for another architecture. > about using RPMs as opposed to compiling from source. The "correct" > method when installing or updating RPMs on a production server (where > optimization is key) has always been to download the source and build an > RPM from that or rebuild a src.rpm, which you then install on the > server. Yes, this means dealing with dependency hell a little bit (and No, that really, really isn't the correct method. The correct method is to use binaries that have gone through QA. > Regardless of why I might want to build my own RPMs on system, > regardless of if I'm seeing much improvement: The point I'm trying to > make with this is that a binary RPM that I make on June 11th of > packagename-1.1 should take precedence over an RPM of packagename-1-1 > made on March 3rd - no matter who made it. People running servers in Not automatically it shouldn't. The date should have nothing to do with it -- it should only do what it's explictly told. And you're telling it the wrong thing, so no surprise that it's not doing what you want. However, if you want to disagree with me, hey, it's a free world, and you can in fact define your dist tag to automatically incude the current date and time -- problem solved. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at drussell.dnsalias.com Tue Jun 12 07:38:19 2007 From: fedora at drussell.dnsalias.com (Don Russell) Date: Tue, 12 Jun 2007 00:38:19 -0700 Subject: The updates firehose In-Reply-To: <20070612030755.GA6895@nostromo.devel.redhat.com> References: <200706091605.00638.jkeating@redhat.com> <466DF763.5090608@drussell.dnsalias.com> <20070612030755.GA6895@nostromo.devel.redhat.com> Message-ID: <466E4D6B.2020400@drussell.dnsalias.com> Bill Nottingham wrote: > Don Russell (fedora at drussell.dnsalias.com) said: > >> What I *would* like (just started thinking about it) is a procmail >> recipe to divide the announcement e-mails into "installed" and "not >> installed" packages. >> > > Well, there's no guarantee that you're reading the mail on the > box in question, etc. Perhaps something utilizing yum-updatesd > might be better? > Actually I can guarantee that because sendmail/procmail runs on my Fedora box... I access my e-mail via IMAP. But, I see your point in general applications... if I have F7 on my laptop for example, that mail-sorting method won't be accurate. But, for what I want... it's perfect. :-) > >> For example... I received an e-mail with this subject: >> Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7 >> >> Thats great... very consistent subject patterns, but from a programming >> point of view, how do I know where the program name ends (so I can use >> it with an rpm -q command to see if it is installed), and where the >> version number starts (so I can compare it with the results of rpm -q)? >> It would help is there was a blank between program name and version >> number... or even more explicit: >> Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7 >> > > echo "xorg-x11-server-1.3.0.0-8.fc7" | awk -F '-' '{ print gensub("-"," ",NF-2) }' > > There are certainly simpler ways. > Thanks.... I found a way to easily extract the info from the message boy using native procmail syntax. From vpivaini at cs.helsinki.fi Tue Jun 12 12:33:45 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 12 Jun 2007 15:33:45 +0300 Subject: Questions regarding my man/info summer project Message-ID: <200706121533.50219.vpivaini@cs.helsinki.fi> Hi, (I'm CCing fedora-docs-list and Ivana Varekova who seems to maintain Fedora's man-pages package, I hope that's ok) As some of you may have noticed already, I'm working on a summer coding project that's about man/info page publication and editing with MoinMoin. There's a more detailed description here: I've hit a problem now and I'd like to get your feedback, I assume there are some people here who maintain man or info pages with their software. The problem is choosing the correct storage format for the man/info pages in MoinMoin. Publication of those pages is relatively simple, but editing them and getting the edits upstream is a completely other thing. For brevity, I'll be talking about man pages here only. It's possible to store the man pages "as such" (as described in man.7) and then display them through a Moin parser. But then users editing the pages through the wiki would have to know *roff, which probably isn't very newbie friendly. On the other hand, Moin would generate "upstream compatible" patches from the edits (almost) automatically. Another possiblity is to store the man pages in wiki markup. That would be very easy for the users to edit, as they probably already know it and it's simple. But how to get the changes upstream then? A wiki markup -> man source exporter would be possible to make, but it's probable that the man source generated automatically from the wiki markup would differ a lot from the original upstream man page source. So producing meaningful and clean patches that could be easily applied would be difficult this way. The main question here concerning this whole project is: what do we want from the project? Do we want the system to be an information source to man page maintainers ("this man page could have these points") where they could take material from and then add it to the corresponding man pages themselves? Or do we want the system to be a tool for the maintainers where they just take patches from and apply them with minimal human interaction? Of course the latter sounds better, but it's also a lot more difficult to implement. That's why I'd want some feedback from those who maintain man/info pages for their projects. If the system only produced wiki markup or plain text diffs, would you still incorporate the changes into your man pages (assuming they are reasonable content-wise)? Also, how would you maintainers describe your workflow when it comes to updating man pages? Do you usually get ideas from users and if so, how do you incorporate them into your man pages? Or are the man pages usually written by the same individual who maintains that specific piece of code? Even though it seems that the main "audience" for this system would be the users and administrators, it definitely wouldn't hurt if it helped the developers/maintainers in their work too :) Thanks in advance for your input! -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 12 12:42:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Jun 2007 08:42:09 -0400 Subject: rawhide report: 20070612 changes In-Reply-To: <200706120506.l5C56TOw031925@porkchop.devel.redhat.com> References: <200706120506.l5C56TOw031925@porkchop.devel.redhat.com> Message-ID: <200706120842.09619.jkeating@redhat.com> On Tuesday 12 June 2007 01:06:29 Build System wrote: This blew up, investigating. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mcepl at redhat.com Tue Jun 12 13:09:38 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 Jun 2007 15:09:38 +0200 Subject: To Require yelp or not to require yelp References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> Message-ID: On Mon, 11 Jun 2007 22:29:58 -0400, Christopher Aillon scripst: > No, reading the bug, the root of all this is because someone went > against my will twice now and added the firefox-32 package. Just curious, why in the world people created firefox-32 in the first place, when there is firefox.i386 on every x86_64 system? Is there firefox-32 for PPC or what? How would it work? > Clearly, my decisions matter. Oh well, that's the other (not enough discussed IMHO) side of contributors-created distribution. Matej From mcepl at redhat.com Tue Jun 12 13:03:56 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 12 Jun 2007 15:03:56 +0200 Subject: To Require yelp or not to require yelp References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <20070611170955.GD3882@nostromo.devel.redhat.com> <466E20C9.7060707@codewiz.org> Message-ID: On Tue, 12 Jun 2007 00:27:53 -0400, Bernardo Innocenti scripst: > -1. What desktop should the geeks be using then? The real ones something like ratpoison or even dwm (http:// www.suckless.org/wiki/dwm -- "Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions."; from people who brought us IRC client faithfully following Unix idea to its very end -- http://www.suckless.org/wiki/tools/irc). Those who are not real hacker, but they faking it, will probably use KDE. > The serious argument is: something is "optional" when it is not strictly > required by the application to provide its core functionality. Yes, and the bigger problem of rpm-based systems is that they don't have a good way how to distinguish between which is strictly required (because without glibc the program just won't start) and the ones which "optional" in your sense of the world (which is Recommended: in Debian-speak), or even those which would be nice to have (like apache log analyzer for apache; i.e., Suggest: in dpkg world). > So, online help is *clearly* an optional desktop feature. People using > systems with limited disk space, like the OLPC users, will want to > remove it. Will they? No, I mean, I am quite surprised that OLPC would have no help -- I thought that it is targeted towards very end users (which may not read, true). Best, Matej From mattdm at mattdm.org Tue Jun 12 13:21:40 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Jun 2007 09:21:40 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: References: <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> Message-ID: <20070612132140.GA9600@jadzia.bu.edu> On Tue, Jun 12, 2007 at 03:09:38PM +0200, Matej Cepl wrote: > Just curious, why in the world people created firefox-32 in the first > place, when there is firefox.i386 on every x86_64 system? Is there > firefox-32 for PPC or what? How would it work? Firefox-32 is just a kludgy shim which provides an icon to run the 32-bit Firefox. It isn't actually a packaging of firefox itself. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Jun 12 13:28:08 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Jun 2007 09:28:08 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <466E0526.3050807@redhat.com> References: <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> Message-ID: <20070612132808.GA9785@jadzia.bu.edu> On Mon, Jun 11, 2007 at 10:29:58PM -0400, Christopher Aillon wrote: > No, reading the bug, the root of all this is because someone went > against my will twice now and added the firefox-32 package. Now people > think they can do shit like this which was one of my objections in the > first place. I objected to this before it got added and it got added > anyway. Then I objected after it got added again and they promised to > remove it but it's apparently back now, after I verified it got removed. > Clearly, my decisions matter. Well, clearly your decisions aren't *authoritative* in a community project. But that doesn't mean they don't matter. There's just obviously other factors involved too. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ml at deadbabylon.de Tue Jun 12 13:35:04 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 12 Jun 2007 15:35:04 +0200 Subject: Fedora Extras Package Build Report 2007-06-09 In-Reply-To: <200706101924.49346.jkeating@redhat.com> References: <20070609191838.69C33152131@buildsys.fedoraproject.org> <20070610235149.1896aa84@localhost.localdomain> <200706101924.49346.jkeating@redhat.com> Message-ID: <200706121535.08235.ml@deadbabylon.de> Am Mo 11.Juni 2007 schrieb Jesse Keating: > On Sunday 10 June 2007 17:51:49 Sebastian Vahl wrote: > > > You can find that information at: > > > ? https://admin.fedoraproject.org/updates/F7 > > > > On this page only the updated packages are shown. I'm searching for the > > newly integrated packages in f7? Or am I missing something there? > > New packages for Fedora 7 are released as updates. So is there an easy way to watch for new packages? Here they are tagged as update, in the Fedora Extras Package Build Reports they are also flagged as "NEW". Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Tue Jun 12 13:57:34 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 12 Jun 2007 09:57:34 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <38362.142.205.241.254.1181590877.squirrel@lattica.com> References: <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> <38362.142.205.241.254.1181590877.squirrel@lattica.com> Message-ID: <20070612135734.GC24259@devserv.devel.redhat.com> On Mon, Jun 11, 2007 at 03:41:17PM -0400, Dimi Paun wrote: > > it doesn't use the god aweful European standard of DD/MM/YY and uses > > the much more reasonable US standard of MM/DD/YY."spaleta > > Wow, just curious why would MM/DD/YY be "reasonable"?!? > It's completely non-uniform, I guess the only thing going > for it is the fact that it makes some sense in accounting, > but that is rather obscure reason to prefer it... :) Accounting people, and indeed anyone working with data sets normally prefer YYYY-MM-DD so it sorts nicely and is unambiguous. For any kind of international consumption where the date isn't in a form processed by the local locale setting YYYY-MM-DD is also probably the safest. Alan From alan at redhat.com Tue Jun 12 13:59:17 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 12 Jun 2007 09:59:17 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <604aa7910706111250s30dd9d91g308c4562bdc2b1bd@mail.gmail.com> References: <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> <38362.142.205.241.254.1181590877.squirrel@lattica.com> <604aa7910706111250s30dd9d91g308c4562bdc2b1bd@mail.gmail.com> Message-ID: <20070612135917.GD24259@devserv.devel.redhat.com> On Mon, Jun 11, 2007 at 11:50:52AM -0800, Jeff Spaleta wrote: > Its reasonable.. in that... i've chosen a US English keyboard layout, > and there is a cultural expectation that dates be presented in that > way by default. I would have expected this sort of thing to be a Not really. US keyboards are used with many languages and systems and don't neccessarily imply the user is working in Wronglish rather than en_GB. The locale folks seperated all these things out for a reason 8) From buildsys at redhat.com Tue Jun 12 14:09:58 2007 From: buildsys at redhat.com (Build System) Date: Tue, 12 Jun 2007 10:09:58 -0400 Subject: rawhide report: 20070612 changes Message-ID: <200706121409.l5CE9wJc031277@porkchop.devel.redhat.com> From poelstra at redhat.com Tue Jun 12 14:13:49 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 12 Jun 2007 07:13:49 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 Message-ID: <466EAA1D.70409@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jun-11 Please make corrections and clarifications to the wiki page. == Buildroot contents for updates == * The buildroot used for fedora 7 updates building is not self updating. It only contains things from f7-gold, and stable released updates. This means that one update candidate cannot be built against another update candidate without rel-eng interaction. We haven't been very vocal about this yet, and it isn't documented anywhere. * Do we want to adjust things or leave them be? * See IRC log for discussion points Decision: Talk to lmacken about modifying Bodhi to do a sanity check on published buildroot contents before allowing an update be pushed. After that we will make the dist-fc7-build buildroot auto-update with -candidate builds and see what happens. == Expand Standard Operating Procedures (SOPs) == * f13 * rel-eng has more and more people helping out so we want to make sure that things are well documented * Infrastructure team started doing SOP/ pages (Standard Operating Procedure) and they are proving very useful. I'd like to start doing them for Release Engineering too * thinking of ReleaseEngineering/SOP/ as the layout, the SOP page itself could be a list of pages and info on how to add an SOP * Proposal: As a release engineer, as you do tasks for Fedora, check to see if there is an SOP/ page. If there isn't, create one and poke rel-eng folks for review. * This is more of a mandate than a vote item. == Early Torrent Release - Rahul Sundaram == * explore possibility of doing early torrent releases. * See IRC log for discussion of pros and cons and affect on mirrors Decision: Investigate with Infrastructure team ways of getting more mirrors to participate in seeding the torrent (early?). Do not release torrent to general public before the agreed upon coordinated release date/time. == Upgrade path enforcement - Rahul Sundaram == * Discussion surrounding policy that upgrade path should not break from a particular point on, for example, after Test1 or Test2--enforced by Release Engineering. * See IRC log for discussion details Decision: Recommend to FESCo policy that upgrade path never be compromised either by removing builds or NEVR regressions. File RFE in Koji to enforce rule at build time From jwilson at redhat.com Tue Jun 12 14:23:51 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 12 Jun 2007 10:23:51 -0400 Subject: new libwnck make emerald fail to start In-Reply-To: <466E12EE.7080904@gmail.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> <466A3C95.60905@gmail.com> <466D93DF.6090108@redhat.com> <466DAF8A.6040809@redhat.com> <466E12EE.7080904@gmail.com> Message-ID: <466EAC77.2020308@redhat.com> Ken YANG wrote: > Jarod Wilson wrote: >> Jarod Wilson wrote: >>> Ken YANG wrote: >>>> hi, >>>> >>>> it seems that the update about beryl still has dependence error: >>>> >>>> Error: Missing Dependency: emerald-themes >= 0.2.1 is needed by package >>>> beryl-gnome >>>> Error: Missing Dependency: heliodor >= 0.2.1 is needed by package >>>> beryl-gnome >>>> Error: Missing Dependency: emerald >= 0.2.1 is needed by package beryl-gnome >>>> >>>> i wait several days for this bug fix, but these errors still be there. >>>> >>>> please correct me if i'm wrong >>> Nope, you're correct. I've not had time to deal with beryl, its rather >>> low-priority juxtaposed to a bunch of other stuff on my plate right now. >>> Patches welcome! ;) >> Patch is dead-simple, found a few cycles this afternoon to work on this. >> New builds are slowly working their way through the build system, should >> be available on mirrors sometime soonish (where "soonish" might be >> something between "tonight" and "this upcoming weekend"... :) > > thanks for your work :-) No problem. Hopefully the last time I ever have to touch the beryl bits though... :) > by the way, the dependence error about revisor is still there: > > Error: Missing Dependency: nash = 6.0.9-4 is needed by package > libbdevid-python > > can you guide me who can i report this error to. The dependency error isn't revisor's fault, best as I can tell. Something is awry between nash and libbdevid-python there. Exactly what, I don't know, I don't work on those packages. Perhaps you should file a bug against libbdevid-python or nash. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From katzj at redhat.com Tue Jun 12 14:37:29 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 12 Jun 2007 10:37:29 -0400 Subject: A couple of glitches installing F7 from Live CD - to BZ, or not to BZ? In-Reply-To: References: Message-ID: <1181659049.31562.7.camel@erebor.boston.redhat.com> Probably not the right list, but... On Mon, 2007-06-11 at 21:02 -0500, Chris Mohler wrote: > 1. - The installer was came up in a res that my flat panel would not > display. After giving a CTRL-ALT-BACKSPACE or two, should an option > be given to switch display modes? (no CTRL-ALT-+ selections worked). > Or is this a matter of passing the right vga= option at boot time? > (seems it could be friendlier - could the live CD/installer show a > table of options?). This is a bug in your X driver -- file it against X so that it can be fixed. Forcing people to choose options here really means that we've lost. > 2. - I bypassed #1 by editing xorg.conf and using the vesa driver for > install. Afterward I mounted the new installation and make the same > change. Without this step, firstboot fails to run (well it does, but > you can't *see* it :) ). Should anaconda check to see if xorg.conf > was modified? Or back to vga= at boot time? Much better to just fix the root cause rather than piling hacks on top of workarounds. > 3. I entered a static IP during install but on reboot NetworkManager > picked up a DHCP address from the router. I'm pretty sure this one's > a bug. If NetworkManager doesn't respect the static IP, the option > should not be shown in anaconda. Yeah, this is known and due to the mismatch between what we do with the live image and a real install. Hopefully for F8, we'll be getting NetworkManager for everywhere (and it'll also hopefully handle things like static IPs). But if not, then we'll probably just end up skipping the network config for the live install case Jeremy From caillon at redhat.com Tue Jun 12 14:52:59 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 12 Jun 2007 10:52:59 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <20070612132808.GA9785@jadzia.bu.edu> References: <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> <20070612132808.GA9785@jadzia.bu.edu> Message-ID: <466EB34B.9050701@redhat.com> Matthew Miller wrote: > Well, clearly your decisions aren't *authoritative* in a community project. > > But that doesn't mean they don't matter. There's just obviously other > factors involved too. If this is not a meritocracy, then I'm leaving the project. If I can't maintain some semblance of control over things I pour my guts out on, then I'm leaving the project. If people can't take the fact seriously that "community" doesn't mean do whatever the F they want when they want, then I'm leaving the project. And most importantly, if people are going to go out of their way to make my life hell by going against mine and upstream's wishes which makes our legal situation with keeping the Firefox branding harder, then I'll remove Firefox from Fedora altogether, and you guys can have fun maintaining the iceweasel fork of it. From halfline at gmail.com Tue Jun 12 15:07:36 2007 From: halfline at gmail.com (Ray Strode) Date: Tue, 12 Jun 2007 11:07:36 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <20070611170955.GD3882@nostromo.devel.redhat.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <20070611170955.GD3882@nostromo.devel.redhat.com> Message-ID: <45abe7d80706120807q2edb60capc3d777a6ae90ac1b@mail.gmail.com> Hi, On 6/11/07, Bill Nottingham wrote: > Ray Strode (halfline at gmail.com) said: > > It doesn't matter a whole lot either way, but I guess if we think > > about help as an optional feature, then we shouldn't put the Requires > > in libgnomeui. > > Why should help be an optional feature? Might make life easier for OLPC, it's a feature not everyone uses..I don't know. I don't have a really strong opinion either way to be honest. >From the rest of this thread, it looks like the issue wasn't "trying to get rid of help" it was "trying to get flash to work on x86-64 or something", so I'm really losing interest... I'm going to add "Requires: yelp" to libgnomeui now and move on to other things. --Ray From dwmw2 at infradead.org Tue Jun 12 15:31:51 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 12 Jun 2007 16:31:51 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466DC1C7.6070303@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> Message-ID: <1181662311.25228.42.camel@pmac.infradead.org> On Mon, 2007-06-11 at 15:42 -0600, Brendan Conoboy wrote: > Yep, we've been through this a few times. Having discussed this with > you a number of times before, I know where you're coming from. We > really should be able to build gcc without having to build parts of > glibc in the process. Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses? Or do we even need to build the dynamic libgcc _with_ the compiler at all? > That said, this is really only an exercise in bootstrapping which > doesn't happen very often. Actually it happens for me every time I build a cross-compiler. But perhaps it doesn't _need_ to; you're right. > Let us, for example, pretend we're just discussing cross compilation for > existing archs. That's a very good place to start. Especially if you realise that it doesn't _really_ restrict us to 'existing architectures' -- it restricts us to those architectures for which we can cobble together 'native' packages for gcc, etc. Which is actually not much of a restriction at all. > Because of the iterative nature of these builds, > everything we need is already there to build the cross compiler. We > have kernel headers and we have a glibc rpm for the target arch. All > that we need in some machinery to pull in files from a different arch > and extract them into a sys-root. That would be an interesting answer, yes. It only solves the _build_ part of the problem though. The packaging side remains -- you'll want to end up a cross-compiler package for the host arch, but libgcc etc. for the target. RPM doesn't currently let you spit out even .noarch.rpm and $ARCH.rpm simultaneously -- to build both i686-linux-gnu-gcc-$V-$R.ppc.rpm and libgcc-$V-$R.i386.rpm you'll almost certainly need a separate rpmbuild run _anyway_. So how will we handle that? > As gcc matures, it's likely that the libgcc problem will go away by it > being split out. At that time, the chicken/egg problem will be solved > without having to resort to clever hacks. I think we need to accelerate that rather than waiting for it. Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc Even for this we have build system questions... how best to build it for each target architecture we want? Index: binutils.spec =================================================================== RCS file: /cvs/pkgs/rpms/binutils/F-7/binutils.spec,v retrieving revision 1.115 diff -u -p -r1.115 binutils.spec --- binutils.spec 14 Apr 2007 15:21:02 -0000 1.115 +++ binutils.spec 12 Jun 2007 15:30:56 -0000 @@ -1,5 +1,13 @@ +%if "%{?binutils_target}" == "" +%define binutils_target %{_target_platform} +%define isnative 1 +%else +%define cross %{binutils_target}- +%define isnative 0 +%endif + Summary: A GNU collection of binary utilities. -Name: binutils +Name: %{?cross}binutils Version: 2.17.50.0.12 Release: 4 License: GPL @@ -51,7 +59,7 @@ have a stable ABI. Developers starting to consider using libelf instead of BFD. %prep -%setup -q +%setup -q -n binutils-%{version} %patch1 -p0 -b .ltconfig-multilib~ %patch2 -p0 -b .ppc64-pie~ %patch3 -p0 -b .place-orphan~ @@ -66,7 +74,7 @@ to consider using libelf instead of BFD. %patch8 -p0 -b .osabi~ %patch9 -p0 -b .rh235747~ -# On ppc64 we might use 64K pages +# On ppc64 we might use 64KiB pages sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c # LTP sucks perl -pi -e 's/i\[3-7\]86/i[34567]86/g' */conf* @@ -78,24 +86,36 @@ sed -i -e 's/^libbfd_la_LDFLAGS = /&-Wl, sed -i -e 's/^libopcodes_la_LDFLAGS = /&-Wl,-Bsymbolic-functions /' opcodes/Makefile.{am,in} fi touch */configure +sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' */configure %build -mkdir build-%{_target_platform} -cd build-%{_target_platform} +mkdir build-%{binutils_target} +cd build-%{binutils_target} CARGS= -%ifarch sparc ppc s390 -CARGS=--enable-64-bit-bfd -%endif -%ifarch ia64 -CARGS=--enable-targets=i386-linux +case %{binutils_target} in + sparc*|ppc*|s390*) + CARGS=--enable-64-bit-bfd + ;; + ia64*) + CARGS=--enable-targets=i386-linux + ;; +esac +%if %isnative + SHAREDARGS=--enable-shared + TARGET=%{binutils_target} + SYSROOT= +%else + SHAREDARGS=--disable-shared + TARGET="--target %{binutils_target} --host %{_target_platform}" + SYSROOT="--with-sysroot=/usr/%{binutils_target}" %endif CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags}" ../configure \ - %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ + $TARGET --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} \ - --infodir=%{_infodir} --enable-shared $CARGS --disable-werror + --infodir=%{_infodir} $SHAREDARGS $CARGS --disable-werror $SYSROOT make %{_smp_mflags} tooldir=%{_prefix} all make %{_smp_mflags} tooldir=%{_prefix} info make -k check < /dev/null > check.log 2>&1 || : @@ -107,8 +127,9 @@ cd .. %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_prefix} -cd build-%{_target_platform} +cd build-%{binutils_target} %makeinstall +%if %isnative make prefix=%{buildroot}%{_prefix} infodir=%{buildroot}%{_infodir} install-info gzip -q9f %{buildroot}%{_infodir}/*.info* @@ -130,10 +151,6 @@ rm -f %{buildroot}%{_prefix}/%{_lib}/lib # Remove libtool files, which reference the .so libs rm -f %{buildroot}%{_prefix}/%{_lib}/lib{bfd,opcodes}.la -# This one comes from gcc -rm -f %{buildroot}%{_infodir}/dir -rm -rf %{buildroot}%{_prefix}/%{_target_platform} - %ifarch %{ix86} x86_64 ppc ppc64 s390 s390x sparc sparc64 sed -i -e '/^#include "ansidecl.h"/{p;s~^.*$~#include ~;}' \ %ifarch %{ix86} x86_64 @@ -151,22 +168,36 @@ sed -i -e '/^#include "ansidecl.h"/{p;s~ %endif touch -r ../bfd/bfd-in2.h %{buildroot}%{_prefix}/include/bfd.h +%else # native +# For cross-binutils we drop the documentation. +rm -rf %{buildroot}%{_infodir} +#rm -rf %{buildroot}%{_prefix}/share/locale +#rm -rf %{buildroot}%{_mandir} +rm -rf %{buildroot}%{_prefix}/%{_lib}/libiberty.a +%endif # native + +# This one comes from gcc +rm -f %{buildroot}%{_infodir}/dir +rm -rf %{buildroot}%{_prefix}/%{binutils_target} + + cd .. -%find_lang binutils -%find_lang opcodes -%find_lang bfd -%find_lang gas -%find_lang ld -%find_lang gprof -cat opcodes.lang >> binutils.lang -cat bfd.lang >> binutils.lang -cat gas.lang >> binutils.lang -cat ld.lang >> binutils.lang -cat gprof.lang >> binutils.lang +%find_lang %{?cross}binutils +%find_lang %{?cross}opcodes +%find_lang %{?cross}bfd +%find_lang %{?cross}gas +%find_lang %{?cross}ld +%find_lang %{?cross}gprof +cat %{?cross}opcodes.lang >> %{?cross}binutils.lang +cat %{?cross}bfd.lang >> %{?cross}binutils.lang +cat %{?cross}gas.lang >> %{?cross}binutils.lang +cat %{?cross}ld.lang >> %{?cross}binutils.lang +cat %{?cross}gprof.lang >> %{?cross}binutils.lang %clean rm -rf %{buildroot} +%if %isnative %post /sbin/ldconfig /sbin/install-info --info-dir=%{_infodir} %{_infodir}/as.info.gz @@ -197,12 +228,14 @@ exit 0 if [ $1 = 0 ] ;then /sbin/install-info --delete --info-dir=%{_infodir} %{_infodir}/bfd.info.gz || : fi +%endif # native -%files -f binutils.lang +%files -f %{?cross}binutils.lang %defattr(-,root,root) %doc README %{_prefix}/bin/* %{_mandir}/man1/* +%if %isnative %{_prefix}/%{_lib}/lib*.so %{_infodir}/[^b]*info* %{_infodir}/binutils*info* @@ -212,6 +245,7 @@ fi %{_prefix}/include/* %{_prefix}/%{_lib}/lib*.a %{_infodir}/bfd*info* +%endif # native %changelog * Sat Apr 14 2007 Jakub Jelinek 2.17.50.0.12-4 -- dwmw2 From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jun 12 15:45:42 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 13 Jun 2007 00:45:42 +0900 Subject: rpms/ntfs-config/F-7 ntfs-config.spec,1.6,1.7 In-Reply-To: <200706121531.l5CFV5m2025891@cvs-int.fedora.redhat.com> References: <200706121531.l5CFV5m2025891@cvs-int.fedora.redhat.com> Message-ID: <466EBFA6.2040109@ioa.s.u-tokyo.ac.jp> Xavier LAMIEN (laxathom) wrote, at 06/13/2007 12:31 AM +9:00: > Author: laxathom > > Update of /cvs/pkgs/rpms/ntfs-config/F-7 > Modified Files: > ntfs-config.spec > Log Message: > > Index: ntfs-config.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/ntfs-config/F-7/ntfs-config.spec,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- ntfs-config.spec 20 May 2007 02:21:32 -0000 1.6 > +++ ntfs-config.spec 12 Jun 2007 15:30:30 -0000 1.7 > @@ -3,13 +3,13 @@ > > Name: ntfs-config > Version: 1.0 > -Release: 0.2.beta1%{?dist} > +Release: 0.1.rc4%{?dist} > Summary: A front-end to Enable/disable NTFS write support > > Group: Applications/System This should not be. 1.0-0.2 > 1.0-0.1 Mamoru From sundaram at fedoraproject.org Tue Jun 12 15:49:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 21:19:14 +0530 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EAA1D.70409@redhat.com> References: <466EAA1D.70409@redhat.com> Message-ID: <466EC07A.2050305@fedoraproject.org> John Poelstra wrote: > > == Early Torrent Release - Rahul Sundaram == > * explore possibility of doing early torrent releases. > * See IRC log for discussion of pros and cons and affect on mirrors > Decision: Investigate with Infrastructure team ways of getting more > mirrors to participate in seeding the torrent (early?). Do not release > torrent to general public before the agreed upon coordinated release > date/time. Seeding the torrent early solves one part of the problem (ie) the torrent being initially slow but the disadvantages isn't clear to me reading the IRC conversations. 1) Mirrors allegedly have a problem: What exactly are they complaining about? 2) It only makes the torrent available 4 days earlier: I don't see how this is a disadvantage. We have the bits available ready and the first few days rush and resulting infrastructure issues will certainly be reduced by encouraging the usage of the torrent as soon as the bits are ready to be mirrored. So when you open up the ISO images to the mirrors make it available in the torrent. 3) We are "breaking" a coordinated release and users will get confused: If we make a announcement clearly saying that it is a early torrent release and other ftp/http mirrors will be available when the images are synced 4 days later then the confusion should be minimum or non-existent. > Decision: Recommend to FESCo policy that upgrade path never be > compromised either by removing builds or NEVR regressions. File RFE in > Koji to enforce rule at build time Thank you. This alone will make a big difference to providing a good upgrade path from older releases or testing in rawhide. Rahul From katzj at redhat.com Tue Jun 12 15:58:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 12 Jun 2007 11:58:48 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EC07A.2050305@fedoraproject.org> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> Message-ID: <1181663928.31562.44.camel@erebor.boston.redhat.com> On Tue, 2007-06-12 at 21:19 +0530, Rahul Sundaram wrote: > John Poelstra wrote: > > == Early Torrent Release - Rahul Sundaram == > > * explore possibility of doing early torrent releases. > > * See IRC log for discussion of pros and cons and affect on mirrors > > Decision: Investigate with Infrastructure team ways of getting more > > mirrors to participate in seeding the torrent (early?). Do not release > > torrent to general public before the agreed upon coordinated release > > date/time. > > Seeding the torrent early solves one part of the problem (ie) the > torrent being initially slow but the disadvantages isn't clear to me > reading the IRC conversations. > > 1) Mirrors allegedly have a problem: > > What exactly are they complaining about? They're complaining that it erodes the value that they provide to us. And that if we do that, then there's a lot less reason for them to mirror and help us out. And they don't like that they get it mirrored and yet people at their institutions still end up using their _external_ bandwidth to get the torrent early rather than accessing the local mirror which was explicitly set up to reduce local bandwidth consumption. > 2) It only makes the torrent available 4 days earlier: > > I don't see how > this is a disadvantage. We have the bits available ready and the first > few days rush and resulting infrastructure issues will certainly be > reduced by encouraging the usage of the torrent as soon as the bits are > ready to be mirrored. So when you open up the ISO images to the mirrors > make it available in the torrent. I don't think that any of the infrastructure issues will be changed at all. The infrastructure issues we have at release time aren't that the mirrors are falling over or anything of the sort. > 3) We are "breaking" a coordinated release and users will get confused: > > If we make a announcement clearly saying that it is a early torrent > release and other ftp/http mirrors will be available when the images are > synced 4 days later then the confusion should be minimum or non-existent. How is that clear? Why can't I download from the box that's two hops away from me on the network and I have a gigabit connection to? And no matter how clear we are, it's still going to be muddy and make things a lot more difficult from the standpoint of a launch with the press Jeremy From laxathom at fedoraproject.org Tue Jun 12 15:59:48 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 12 Jun 2007 11:59:48 -0400 Subject: rpms/ntfs-config/F-7 ntfs-config.spec,1.6,1.7 In-Reply-To: <466EBFA6.2040109@ioa.s.u-tokyo.ac.jp> References: <200706121531.l5CFV5m2025891@cvs-int.fedora.redhat.com> <466EBFA6.2040109@ioa.s.u-tokyo.ac.jp> Message-ID: <62bc09df0706120859j70d2d0f2obbf5aad039eccfbc@mail.gmail.com> 2007/6/12, Mamoru Tasaka : > > Xavier LAMIEN (laxathom) wrote, at 06/13/2007 12:31 AM +9:00: > > Author: laxathom > > > > Update of /cvs/pkgs/rpms/ntfs-config/F-7 > > Modified Files: > > ntfs-config.spec > > Log Message: > > > > Index: ntfs-config.spec > > =================================================================== > > RCS file: /cvs/pkgs/rpms/ntfs-config/F-7/ntfs-config.spec,v > > retrieving revision 1.6 > > retrieving revision 1.7 > > diff -u -r1.6 -r1.7 > > --- ntfs-config.spec 20 May 2007 02:21:32 -0000 1.6 > > +++ ntfs-config.spec 12 Jun 2007 15:30:30 -0000 1.7 > > @@ -3,13 +3,13 @@ > > > > Name: ntfs-config > > Version: 1.0 > > -Release: 0.2.beta1%{?dist} > > +Release: 0.1.rc4%{?dist} > > Summary: A front-end to Enable/disable NTFS write support > > > > Group: Applications/System > > This should not be. 1.0-0.2 > 1.0-0.1 oops, indeed, it will not update like that sorry for this typo. fixing... Mamoru > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Tue Jun 12 16:10:00 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 Jun 2007 09:10:00 -0700 Subject: To Require yelp or not to require yelp In-Reply-To: <466E51BC.8070405@codewiz.org> References: <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <20070611170955.GD3882@nostromo.devel.redhat.com> <466E20C9.7060707@codewiz.org> <20070612050908.GB14864@nostromo.devel.redhat.com> <466E51BC.8070405@codewiz.org> Message-ID: <1181664600.19531.87.camel@localhost.localdomain> On Tue, 2007-06-12 at 03:56 -0400, Bernardo Innocenti wrote: > Bill Nottingham wrote: > > Bernardo Innocenti (bernie at codewiz.org) said: > >> So, online help is *clearly* an optional desktop feature. People > >> using systems with limited disk space, like the OLPC users, will > >> want to remove it. > > > > So, then, every package should package *-help separately, > > and if you want to actually have online help, you need to become > > superuser and install it? That's a horrible user experience. > > I have not suggested packaging the help files separately. > It's easy to avoid installing them with --excludedocs anyway. > This shouldn't be true. If it is true for an app then it's a bug that needs to be filed against the app. The reason is that having online help files excluded when using --excludedocs breaks runtime functionality (ie: The help menu). Excluding man pages, README, and other files that are not part of the runtime behaviour of the app is okay. In this light, Help is not optional. yelp is optional (_if_ there's something to replace it), help is not. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Jun 12 16:14:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 21:44:43 +0530 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <1181663928.31562.44.camel@erebor.boston.redhat.com> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> Message-ID: <466EC673.9050707@fedoraproject.org> Jeremy Katz wrote: >> >> 1) Mirrors allegedly have a problem: >> >> What exactly are they complaining about? > > They're complaining that it erodes the value that they provide to us. > And that if we do that, then there's a lot less reason for them to > mirror and help us out. If other mirrors are more occupied then does it erode the value of the one mirror which is not being used as much? If I distribute the software via Free Media program, online or retail shops, magazines and books, does it erode their value? We are always going to be distributing our software in more than one way and if some ways are more faster or efficient than the rest we should do that. This seems a rather odd thing for a mirror to be complaining about. How many are complaining? And they don't like that they get it mirrored > and yet people at their institutions still end up using their _external_ > bandwidth to get the torrent early rather than accessing the local > mirror which was explicitly set up to reduce local bandwidth > consumption. Is there anything stopping them from opening their local mirror within their institution? > I don't think that any of the infrastructure issues will be changed at > all. The infrastructure issues we have at release time aren't that the > mirrors are falling over or anything of the sort. We might not be particularly worried about mirrors but they do get saturated quickly and in short the infrastructure problems are directly related to many people rushing to get the new release which can certainly mitigated by a early torrent release. > How is that clear? Why can't I download from the box that's two hops > away from me on the network and I have a gigabit connection to? .. because the mirror is waiting to sync the content that we are pushing out? If they prefer the closer mirror they can very well wait for it to open up. Right? And no > matter how clear we are, it's still going to be muddy and make things a > lot more difficult from the standpoint of a launch with the press How? Why would the press be bothered that we are doing a torrent only release 4 days earlier? Should we be more worried about the hypothetical confusion in press as opposed to getting the release to end users faster? Rahul From jspaleta at gmail.com Tue Jun 12 16:33:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 12 Jun 2007 08:33:48 -0800 Subject: To Require yelp or not to require yelp In-Reply-To: <20070612135917.GD24259@devserv.devel.redhat.com> References: <20070611050108.GB18869@nostromo.devel.redhat.com> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <604aa7910706111237wac14646kf22f196f062975f1@mail.gmail.com> <38362.142.205.241.254.1181590877.squirrel@lattica.com> <604aa7910706111250s30dd9d91g308c4562bdc2b1bd@mail.gmail.com> <20070612135917.GD24259@devserv.devel.redhat.com> Message-ID: <604aa7910706120933q347867dcr9affa7960f6b0d31@mail.gmail.com> On 6/12/07, Alan Cox wrote: > The locale folks seperated all these things out for a reason 8) All the friendly pointless banter aside concerning the superiority of default date formats. All i really want, what I really really want is the magic to manipulate the format so that I can use OO.org's variable date field and have it display the date string in whatever format I choose. I just can't find the blasted config. -jef"here's what's really funny...I get MM/DD/YY by default in rawhide oo.org now. But now everyone's convinced me that I should use YYYY/MM/DD or else I will have my membership in the International League of Rational Thinkers revoked. I just can't win"spaleta From notting at redhat.com Tue Jun 12 16:36:14 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Jun 2007 12:36:14 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EC673.9050707@fedoraproject.org> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> Message-ID: <20070612163614.GA5569@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > >They're complaining that it erodes the value that they provide to us. > >And that if we do that, then there's a lot less reason for them to > >mirror and help us out. > > If other mirrors are more occupied then does it erode the value of the > one mirror which is not being used as much? If I distribute the software > via Free Media program, online or retail shops, magazines and books, > does it erode their value? You're not doing this *before they get a chance to help*, effectively saying they're a second class delivery method for their users. What's the point of them mirroring for their users if their users are going to use their bandwidth to try and jump on a torrent earlier? > We are always going to be distributing our > software in more than one way and if some ways are more faster or > efficient than the rest we should do that. This seems a rather odd thing > for a mirror to be complaining about. How many are complaining? A large number complained when this was originally proposed. > >And they don't like that they get it mirrored > >and yet people at their institutions still end up using their _external_ > >bandwidth to get the torrent early rather than accessing the local > >mirror which was explicitly set up to reduce local bandwidth > >consumption. > > Is there anything stopping them from opening their local mirror within > their institution? What? You're expecting every mirror to reconfigure special access rules based on IP ranges or domain names just because you want to torrent ISOs early? How is that at all practical or sensible? > >And no > >matter how clear we are, it's still going to be muddy and make things a > >lot more difficult from the standpoint of a launch with the press > > How? Why would the press be bothered that we are doing a torrent only > release 4 days earlier? Because, when is the release date? Earlier or later> > Should we be more worried about the hypothetical > confusion in press as opposed to getting the release to end users faster? If the torrent is earlier, then the end users who can't use it (which is many) are going to be getting the release 4 days later. Bill From katzj at redhat.com Tue Jun 12 16:39:05 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 12 Jun 2007 12:39:05 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EC673.9050707@fedoraproject.org> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> Message-ID: <1181666345.31562.49.camel@erebor.boston.redhat.com> On Tue, 2007-06-12 at 21:44 +0530, Rahul Sundaram wrote: > Jeremy Katz wrote: > >> 1) Mirrors allegedly have a problem: > >> > >> What exactly are they complaining about? > > > > They're complaining that it erodes the value that they provide to us. > > And that if we do that, then there's a lot less reason for them to > > mirror and help us out. > > If other mirrors are more occupied then does it erode the value of the > one mirror which is not being used as much? If I distribute the software > via Free Media program, online or retail shops, magazines and books, > does it erode their value? We are always going to be distributing our > software in more than one way and if some ways are more faster or > efficient than the rest we should do that. This seems a rather odd thing > for a mirror to be complaining about. How many are complaining? No, but in all of those cases, people aren't going and using bandwidth to the world as opposed to local bandwidth. Also, they're fine with torrent being available, but making it available _EARLIER_ is the problem. > And they don't like that they get it mirrored > > and yet people at their institutions still end up using their _external_ > > bandwidth to get the torrent early rather than accessing the local > > mirror which was explicitly set up to reduce local bandwidth > > consumption. > > Is there anything stopping them from opening their local mirror within > their institution? So, they have to set up special access restriction for Fedora content for a space of a small number of days? This just isn't going to happen. Or, they'll open to the world -- "the bits are available officially anyway, why shouldn't I make my copy available". And then we look really stupid because we're just saying "no, you can't download it from us yet." > > I don't think that any of the infrastructure issues will be changed at > > all. The infrastructure issues we have at release time aren't that the > > mirrors are falling over or anything of the sort. > > We might not be particularly worried about mirrors but they do get > saturated quickly and in short the infrastructure problems are directly > related to many people rushing to get the new release which can > certainly mitigated by a early torrent release. No, it just changes when people rush. > > How is that clear? Why can't I download from the box that's two hops > > away from me on the network and I have a gigabit connection to? > > .. because the mirror is waiting to sync the content that we are pushing > out? If they prefer the closer mirror they can very well wait for it to > open up. Right? And we could very well get rid of this confusion and awfulness by not opening one mode of distribution sooner than every other one. > And no > > matter how clear we are, it's still going to be muddy and make things a > > lot more difficult from the standpoint of a launch with the press > > How? Why would the press be bothered that we are doing a torrent only > release 4 days earlier? Should we be more worried about the hypothetical > confusion in press as opposed to getting the release to end users faster? Because press wants to be able have articles published on what we claim is our release day. And having the official torrent available but not the official mirrors available is guaranteed to be a source of confusion and trouble. Jeremy From sundaram at fedoraproject.org Tue Jun 12 16:47:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 22:17:43 +0530 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <20070612163614.GA5569@nostromo.devel.redhat.com> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> Message-ID: <466ECE2F.2060100@fedoraproject.org> Bill Nottingham wrote: > You're not doing this *before they get a chance to help*, effectively > saying they're a second class delivery method for their users. What's > the point of them mirroring for their users if their users are going > to use their bandwidth to try and jump on a torrent earlier? I don't know what you mean by "their users" but if it is say a university then they can make it available in their LAN when they have the bits and not to the entire world for initial few days before the announcement. What? You're expecting every mirror to reconfigure special access rules > based on IP ranges or domain names just because you want to torrent ISOs > early? How is that at all practical or sensible? You misunderstood. See above. >>> And no >>> matter how clear we are, it's still going to be muddy and make things a >>> lot more difficult from the standpoint of a launch with the press >> How? Why would the press be bothered that we are doing a torrent only >> release 4 days earlier? > > Because, when is the release date? Earlier or later> Torrent is earlier. Rest is later. It's not like all the releases don't have leaked mirrors anyway a few days before the release anyway. > If the torrent is earlier, then the end users who can't use it (which > is many) are going to be getting the release 4 days later. Let them. Distributing the load is the whole point. If some people get it earlier and the rest later then we have achieved that goal. Rahul From notting at redhat.com Tue Jun 12 16:52:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Jun 2007 12:52:18 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466ECE2F.2060100@fedoraproject.org> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> <466ECE2F.2060100@fedoraproject.org> Message-ID: <20070612165218.GD4573@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > >You're not doing this *before they get a chance to help*, effectively > >saying they're a second class delivery method for their users. What's > >the point of them mirroring for their users if their users are going > >to use their bandwidth to try and jump on a torrent earlier? > > I don't know what you mean by "their users" but if it is say a > university then they can make it available in their LAN when they have > the bits and not to the entire world for initial few days before the > announcement. > > What? You're expecting every mirror to reconfigure special access rules > >based on IP ranges or domain names just because you want to torrent ISOs > >early? How is that at all practical or sensible? > > You misunderstood. See above. No, I didn't. That comment still applies *exactly the same*. And if you don't understand that, I'm not sure why I'm having this discussion. Bill From sundaram at fedoraproject.org Tue Jun 12 16:59:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 12 Jun 2007 22:29:28 +0530 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <20070612165218.GD4573@nostromo.devel.redhat.com> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> <466ECE2F.2060100@fedoraproject.org> <20070612165218.GD4573@nostromo.devel.redhat.com> Message-ID: <466ED0F0.4060300@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >>> You're not doing this *before they get a chance to help*, effectively >>> saying they're a second class delivery method for their users. What's >>> the point of them mirroring for their users if their users are going >>> to use their bandwidth to try and jump on a torrent earlier? >> I don't know what you mean by "their users" but if it is say a >> university then they can make it available in their LAN when they have >> the bits and not to the entire world for initial few days before the >> announcement. >> >> What? You're expecting every mirror to reconfigure special access rules >>> based on IP ranges or domain names just because you want to torrent ISOs >>> early? How is that at all practical or sensible? >> You misunderstood. See above. > > No, I didn't. That comment still applies *exactly the same*. And if you > don't understand that, I'm not sure why I'm having this discussion. I don't understand your point. Setting up local access without giving world access is pretty simple for any well configured LAN. Every major organization already has such access rules setup for stuff they don't want the world to know. We aren't forcing everyone to do that. If they want to give their users a local mirror that's a choice for them. How is that *not sensible*? Rahul From alan at redhat.com Tue Jun 12 17:12:47 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 12 Jun 2007 13:12:47 -0400 Subject: Bug: Fedora doesn't close DVD drive door In-Reply-To: References: Message-ID: <20070612171247.GA3839@devserv.devel.redhat.com> On Mon, Jun 04, 2007 at 10:07:37PM +1200, Shams wrote: > When I shutdown Fedora 7 it doesn't close the DVD drive > door automatically and the door is left open. Same problem > persisted with Fedora 6. That isn't a bug a such. We don't worry about the door on shutdown. If you think we should close the door on shutdown then file an RFE - but it would need to be specific to poweroff, having the CD door shut on a reboot would probably be counted as a pain by most people > However if I reboot then the DVD drive door does get closed > automatically. Annoying isn't it. You open the door so it won't boot off the CD and then it closes it again Your CD or BIOS probably does this during probing Alan From notting at redhat.com Tue Jun 12 17:26:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Jun 2007 13:26:02 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466ED0F0.4060300@fedoraproject.org> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> <466ECE2F.2060100@fedoraproject.org> <20070612165218.GD4573@nostromo.devel.redhat.com> <466ED0F0.4060300@fedoraproject.org> Message-ID: <20070612172602.GA5972@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > >> What? You're expecting every mirror to reconfigure special access rules > >>>based on IP ranges or domain names just because you want to torrent ISOs > >>>early? How is that at all practical or sensible? > >>You misunderstood. See above. > > > >No, I didn't. That comment still applies *exactly the same*. And if you > >don't understand that, I'm not sure why I'm having this discussion. > > I don't understand your point. You've run a public mirror for 10 years. It's simple. Now, we come along and say "oh, if you actually want to conserve your bandwidth locally, you're going to need to set up separate ACLs and filters that allow your content to be visible from your IP range but not publically". You're essentially telling our mirrors how to run their mirror for their site. And for what gain? So some people can get a release a couple of days early? Let's go back and do some quick cost-benefit analysis: Benefits: - some subset of users get the release a few days early ... which affects the project how? Do we really need 2 early days of bug filing? (For which we won't have updates that we're pushing at that point). How does that benefit the users to have it two days earlier other than they can run bragging to the people down the halls I GOTZ THE ZERO DAYS HOOK UP! Costs: - mirrors, *one of our most valuable resources*, get less utilized - mirrors are required to change their own configurations to properly handle their local bandwith - ergo, mirrors are likely to feel more disenfranchised - leading to less mirror coverage for updates. And whoops, there's no early-bt mechanism to handle that. - instead of a single release date to coordinate release, announcements, PR, etc., we have two It's *just not worth it*. And that's why the release engineering group considered this proposal, and rejected it. So, let's go back to your original problem. How do we make the torrent faster, and help lessen the load on our infrastructure? We can 1) allow mirrors who have the release to seed the torrent, giving more bandwidth to it. 2) set up a tiered mirroring system, to ensure that more mirrors can easily sync the content and be ready in time And we're planning to do both of those. Bill > Setting up local access without giving > world access is pretty simple for any well configured LAN. Every major > organization already has such access rules setup for stuff they don't > want the world to know. We aren't forcing everyone to do that. If they > want to give their users a local mirror that's a choice for them. How is > that *not sensible*? > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From j.w.r.degoede at hhs.nl Tue Jun 12 18:00:35 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 12 Jun 2007 20:00:35 +0200 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <20070612165218.GD4573@nostromo.devel.redhat.com> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> <466ECE2F.2060100@fedoraproject.org> <20070612165218.GD4573@nostromo.devel.redhat.com> Message-ID: <466EDF43.3060801@hhs.nl> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >>> You're not doing this *before they get a chance to help*, effectively >>> saying they're a second class delivery method for their users. What's >>> the point of them mirroring for their users if their users are going >>> to use their bandwidth to try and jump on a torrent earlier? >> I don't know what you mean by "their users" but if it is say a >> university then they can make it available in their LAN when they have >> the bits and not to the entire world for initial few days before the >> announcement. >> >> What? You're expecting every mirror to reconfigure special access rules >>> based on IP ranges or domain names just because you want to torrent ISOs >>> early? How is that at all practical or sensible? >> You misunderstood. See above. > > No, I didn't. That comment still applies *exactly the same*. And if you > don't understand that, I'm not sure why I'm having this discussion. > Gee, Somehow this reminds me of a discussion me and Ralf had with Rahul about a week ago. I believe I made a comment much like this one. Anyone else see a pattern here? Regards, Hans p.s. Rahul, When I saw the Fedora 7 Faq on the wiki I thought "good work!", so please don't think I do not appreciate your contributions, really I do, but ... (that has al already been said). Talking about the Fedora 7 Faq, each time I want to reference it I type "Fedora 7 Faq" in google, as I can't find it through the wiki. Maybe there should be a link on the frontpage, or atleast under the http://fedoraproject.org/wiki/FAQ page, as that is were you go if you press the FAQs link on the mainpage. From tonynelson at georgeanelson.com Tue Jun 12 18:18:45 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 12 Jun 2007 14:18:45 -0400 Subject: The updates firehose In-Reply-To: <1181626801.27823.6.camel@rousalka.dyndns.org> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <1181467847.28023.6.camel@rousalka.dyndns.org> <20070611130645.GA17371@lists.us.dell.com> <29185.192.54.193.51.1181568897.squirrel@rousalka.dyndns.org> <1181626801.27823.6.camel@rousalka.dyndns.org> Message-ID: At 7:40 AM +0200 6/12/07, Nicolas Mailhot wrote: >Le lundi 11 juin 2007 ? 17:19 -0400, Tony Nelson a ?crit : > >> Would my StableMirror yum plugin help? It uses the same mirror each time >> as long as that mirror was offered (and it does other things too). It's >> main idea could certainly be added to yum. StableMirror isn't updated for >> F7 yet (I assume it will need an update). >> > >Can't really say, never used it and the URL you gave is dead. Oops, typo. >However from your description it isn't going to fix the metadata >problem, nor ensure every box behind the proxy uses the same mirror Well, yes, it can be used to ensure that every box uses the same mirror, if it is available, by pushing the same stablemirrors file to each machine. -- ____________________________________________________________________ TonyN.:' ' From brent at brentnorris.net Tue Jun 12 18:34:05 2007 From: brent at brentnorris.net (Brent) Date: Tue, 12 Jun 2007 13:34:05 -0500 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <1181666345.31562.49.camel@erebor.boston.redhat.com> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <1181666345.31562.49.camel@erebor.boston.redhat.com> Message-ID: <466EE71D.3010400@brentnorris.net> Jeremy Katz wrote: > On Tue, 2007-06-12 at 21:44 +0530, Rahul Sundaram wrote: > >> Jeremy Katz wrote: >> >>>> 1) Mirrors allegedly have a problem: >>>> >>>> What exactly are they complaining about? >>>> >>> They're complaining that it erodes the value that they provide to us. >>> And that if we do that, then there's a lot less reason for them to >>> mirror and help us out. >>> >> If other mirrors are more occupied then does it erode the value of the >> one mirror which is not being used as much? If I distribute the software >> via Free Media program, online or retail shops, magazines and books, >> does it erode their value? We are always going to be distributing our >> software in more than one way and if some ways are more faster or >> efficient than the rest we should do that. This seems a rather odd thing >> for a mirror to be complaining about. How many are complaining? >> > > No, but in all of those cases, people aren't going and using bandwidth > to the world as opposed to local bandwidth. Also, they're fine with > torrent being available, but making it available _EARLIER_ is the > problem. > I think one really great way to help with this problem is if there was a way to have the mirrors run torrent seeds too. If that were to happen then the local network mirrors thing would pretty much automagically work itself out. If the people in the LAN know about the FTP/HTTP mirror they use it, if they don't most of the good Bittorrent software tries hard to find local nodes to connect to. So torrent users would still get it using the LAN _mostly_ and the mirrors would also be helping to seed the torrents during the slow beginning part. It does mean that mirrors might have more bandwidth being used on their external links, but if they are a mirror they are probably ok with that bandwidth being used. I don't see why they would care if it is with HTTP, FTP, or torrent. Also the more mirrors you have using it the more feasible it becomes to start looking at the possibility of maybe doing updates via the torrent network or something like that. Things like that make the mirror lists start to become obsolete. Just some thoughts. Brent From adrian at lisas.de Tue Jun 12 18:40:54 2007 From: adrian at lisas.de (Adrian Reber) Date: Tue, 12 Jun 2007 20:40:54 +0200 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EE71D.3010400@brentnorris.net> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <1181666345.31562.49.camel@erebor.boston.redhat.com> <466EE71D.3010400@brentnorris.net> Message-ID: <20070612184054.GB32469@lisas.de> On Tue, Jun 12, 2007 at 01:34:05PM -0500, Brent wrote: > I think one really great way to help with this problem is if there was a > way to have the mirrors run torrent seeds too. If that were to happen > then the local network mirrors thing would pretty much automagically > work itself out. If the people in the LAN know about the FTP/HTTP > mirror they use it, if they don't most of the good Bittorrent software > tries hard to find local nodes to connect to. So torrent users would > still get it using the LAN _mostly_ and the mirrors would also be > helping to seed the torrents during the slow beginning part. There seems to be a feature in bittorrent which does exactly this. I have heard the gentoo is experimenting with it: http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/experimental/bittorrent-http-seeding/READ-ME-FIRST.txt No idea if it actually works. Adrian From jkeating at redhat.com Tue Jun 12 18:40:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Jun 2007 14:40:34 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EE71D.3010400@brentnorris.net> References: <466EAA1D.70409@redhat.com> <1181666345.31562.49.camel@erebor.boston.redhat.com> <466EE71D.3010400@brentnorris.net> Message-ID: <200706121440.34418.jkeating@redhat.com> On Tuesday 12 June 2007 14:34:05 Brent wrote: > I think one really great way to help with this problem is if there was a > way to have the mirrors run torrent seeds too. ? That's what the rel-eng team decided to investigate, with getting support into mirrormanager hopefully so that it Just Happens. > If that were to happen > then the local network mirrors thing would pretty much automagically > work itself out. ?If the people in the LAN know about the FTP/HTTP > mirror they use it, if they don't most of the good Bittorrent software > tries hard to find local nodes to connect to. ?So torrent users would > still get it using the LAN _mostly_ and the mirrors would also be > helping to seed the torrents during the slow beginning part. Meh, most bittorrent stuff I've seen isn't that great about using "local" connections, unless it's right on the same network. Most mirrors are likely not on the same network as the client machines, your public facing network is rarely your private network too. > It does mean that mirrors might have more bandwidth being used on their > external links, but if they are a mirror they are probably ok with that > bandwidth being used. ?I don't see why they would care if it is with > HTTP, FTP, or torrent. Right, many complain that not all their bandwidth is being used due to resource contention for http or whatnot. Having more methods for them to use the bandwidth and flex their muscles are better (: > Also the more mirrors you have using it the more > feasible it becomes to start looking at the possibility of maybe doing > updates via the torrent network or something like that. ?Things like > that make the mirror lists start to become obsolete. The majority of the update files are too small for bittorrent to really be worth while. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Jun 12 18:45:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Jun 2007 00:15:29 +0530 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EDF43.3060801@hhs.nl> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> <466ECE2F.2060100@fedoraproject.org> <20070612165218.GD4573@nostromo.devel.redhat.com> <466EDF43.3060801@hhs.nl> Message-ID: <466EE9C9.2000405@fedoraproject.org> Hans de Goede wrote: > > Gee, > > Somehow this reminds me of a discussion me and Ralf had with Rahul about > a week ago. I believe I made a comment much like this one. Anyone else > see a pattern here? Are you adding anything useful to the discussion apart from a poor jibe at me? Is that really worth your effort? If you want to somehow see a pattern in two completely different things would you then expand on that and tell me exactly what you are concluding from that "pattern" if anything? Rahul > Talking about the Fedora 7 Faq, each time I want to reference it I type > "Fedora 7 Faq" in google, as I can't find it through the wiki. Maybe > there should be a link on the frontpage, or atleast under the > http://fedoraproject.org/wiki/FAQ page, as that is were you go if you > press the FAQs link on the mainpage. It has been added to docs.fedoraproject.org a while back. I have added a reference from the above FAQ now. Rahul From sundaram at fedoraproject.org Tue Jun 12 18:59:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Jun 2007 00:29:04 +0530 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <20070612172602.GA5972@nostromo.devel.redhat.com> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> <466ECE2F.2060100@fedoraproject.org> <20070612165218.GD4573@nostromo.devel.redhat.com> <466ED0F0.4060300@fedoraproject.org> <20070612172602.GA5972@nostromo.devel.redhat.com> Message-ID: <466EECF8.7030100@fedoraproject.org> Bill Nottingham wrote: > You've run a public mirror for 10 years. It's simple. Now, we come along > and say "oh, if you actually want to conserve your bandwidth locally, > you're going to need to set up separate ACLs and filters that allow your > content to be visible from your IP range but not publically". You're > essentially telling our mirrors how to run their mirror for their site. They can it run however they want. If they want to conserve their bandwidth what I am providing is a suggestion on how to handle that problem while serving their local users since this was projected as a problem. I don't know whether mirror administrators have actually complained about this or whether we assume they will. > And for what gain? So some people can get a release a couple of days early? Yes. The project benefit is that we split the load. Some folks who prefer and can use the torrent will get it early. The rest will get it 4 days later. It has nothing to do with bragging rights or filing bug reports although I don't see a problem with either of that. We have end users wondering why we are holding back on the release after the images are ready instead of making it available on the bittorrent and the answer seems to revolve around not affecting the perceptions of mirror administrators that somehow their path is treated as second class which as a end user seems rather weak to me. If I was a mirror administrator I would be very happy if the bandwidth was used less and the load shared by other folks running mirrors, torrent or anything like that. My original problem description had nothing to do with making the torrent go faster BTW. That would be useful indeed and what has been planned would work for that. No oppositions. Rahul From jkeating at redhat.com Tue Jun 12 19:07:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Jun 2007 15:07:01 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466EECF8.7030100@fedoraproject.org> References: <466EAA1D.70409@redhat.com> <20070612172602.GA5972@nostromo.devel.redhat.com> <466EECF8.7030100@fedoraproject.org> Message-ID: <200706121507.01675.jkeating@redhat.com> On Tuesday 12 June 2007 14:59:04 Rahul Sundaram wrote: > We have end users wondering why we are holding back on the release after > the images are ready instead of making it available on the bittorrent Quite simply because a release date is a release date. We set a coordinated release date for /many/ reasons. Just because one method of distribution is ready before others is _not_ a reason to fracture your release process. If it really makes you feel better, I'll delay getting the torrents ready until just before the coordinated release date. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buytenh at wantstofly.org Tue Jun 12 19:29:28 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 21:29:28 +0200 Subject: thoughts about secondary architectures In-Reply-To: <1180781106.25232.118.camel@pmac.infradead.org> References: <20070602034206.GF16918@xi.wantstofly.org> <1180781106.25232.118.camel@pmac.infradead.org> Message-ID: <20070612192928.GX11141@xi.wantstofly.org> I think we discussed most of this in IRC, but let's continue the thread in email anyway, for the sake of having the discussion archived and giving others the chance to jump in. On Sat, Jun 02, 2007 at 11:45:06AM +0100, David Woodhouse wrote: > > My view is that it's clear that most of the people hacking on Fedora > > and using Fedora care only about x86/x86_64 systems, and that I (and > > the other people who are interested in secondary architectures) > > should try as much as possible to avoid making the lives of the x86 > > people difficult, if we ever want to have a chance of getting our > > patches merged without pissing everyone else off. > > I think you do us a disservice here. Sorry. :-( > I hope that getting sensible patches merged should always be easy, > regardless of how the build system works. There aren't many of us > who'll start refusing your patches just because your build system > pissed us off, hopefully :) They might not refuse the patches, but they might delay them... :) > We're trying to make it easier for people to build Fedora for new > architectures. As you've so capably demonstrated, it's already > _possible_ to do that -- but we want to make it less painful, and in > particular we want to help you keep in sync with Fedora during the > development cycle. (At least, that's what I _think_ we're trying to > achieve -- Spot's document itself lacked any explicit rationale.) Getting hooked up into the upstream build system as early as possible is something that I would really like, and what seems like might make my life easier. But, right now, we have a mostly complete FC6 port, no F7 port, and no F8 port. At this point, it doesn't seem like an option to me to get ARM hooked up into koji, and it probably won't be until we get in sync with most of the devel effort. > Yes, we want to keep the impact on the package maintainers minimal. > But that doesn't mean it has to be entirely zero. If we want _zero_ > impact, then you might just as well keep building it for yourself > as you already are. >From personal experience, what I tend to see is that there is a lot of reluctance to merge things to benefit ARM or to accomodate ARM, as ARM is seen as a minority architecture, even if there are probably more ARM CPUs in the world running Linux than anything else. >From that point of view, I'd be inclined to say that I'll take any additional effort required for having an official Fedora ARM port upon myself, and others who work on the ARM port an are interested in the ARM port. Of course, if you don't agree with this division of labor, I'm not going to complain about it. :) > > While it is very well possible that there is some bug in a package > > that does not surface on x86, 99.9% of the Fedora developers are > > unlikely to care about that > > (Actually I think are many more than 1 in 1000 who are more > conscientious than that and actually do care about portability. We're > not _that_ lackadaisical, as a rule.) Well, I assumed that most Fedora developers probably only develop on x86/x86_64 and thus care most about those architectures, I didn't mean to say that they wouldn't care about portability in general. > > if the package builds OK on x86 and no ill effects are seen on x86. > > Nevertheless, in the case where a package _used_ to work on ARM and the > updated version suddenly doesn't build, don't you think that warrants at > least a _glance_ from the package maintainer to see if it's actually a > _generic_ issue which just happens to bite on ARM today for some > timing-related or other not 100% repeatable reason? Sure, I'd agree with you on this point, I'm just saying that there is some kind of line that should be drawn. Would you consider the fact that some package depends on being run on a 2's complement architecture a release blocker? From the "What is every sensible architecture out there doing?", I probably wouldn't... Of course, if it did build before on that 1's complement machine, it might be a different issue. > That glance is _all_ that should be required -- package maintainers > should _definitely_ have the option of just pushing a button to say they > don't care, and shipping the package anyway on all the architectures for > which it _did_ build. We don't want to make life hard for them; you're > right. But we don't necessarily want them to ignore failures which could > show up a real problem, either. > > We could see the builds on other architectures as free testing. They > often _do_ show up issues which are generic, and not just arch-specific. > Especially in the cases where the package in question _used_ to build OK > on that architecture -- which is all we'd be expecting the package > maintainers to notice in the general case. Totally agreed, no argument here. That 'ship it anyway' button is probably something that needs some more thought. Effectively, if we allow someone to press the 'ship it anyway' button, we allow them to decide that the architectures that didn't build will now be out of sync. For things like Jack's Virtual Pipe Organ for X Windows, this probably isn't a big issue, but for the more fundamental packages (gcc, python, any critical libraries), it seems that it would. >From the point that the 'ship it anyway' button is pressed, some archs will be out of sync, and we really don't want to build, say, some python module against python 2.8 on some archs and against python 2.9 on some other archs. Should we track the exact build dependencies used on the 'primary architectures' and bail out a secondary arch build if the same versions of the same packages are not available? Or is there another way to enforce these dependencies that works better? In any case, to me it seems like that this is an issue that you have to deal with in some way in any case once you provide people with a 'ship it anyway' button. > > From a purely technical point of view I would advocate that a build > > failure on any architecture fails the package build, but there will > > only have to be 3 or 4 cases where some gcc ICE causes some package > > to fail to build on some secondary architecture but build fine on > > x86 and the x86 people will hate us forever afterwards, and will > > eventually start clamoring that getting all these secondary > > architectures on board was a bad idea to begin with. (Which, of > > course, would be totally understandable at that point.) > > I don't think it would be understandable at all. It's not as if it > would take them long to glance at the failure and click the "don't > care" button. (Well, OK, we'd want a bug filed, but there can be > automated assistance with templates for that, even though it's a > bad idea to have it all done _completely_ automatically). Well, if you've never dealt with architectures where chars are unsigned by default, where unaligned accesses don't work as you would expect, where sizeof(struct { char a; char b; }) == 4, or where 'double' values are in little endian byte order but in big endian word order, I would think that it is understandable that you're not extremely interested in bug reports for architectures where that is in fact the case. I'm not saying that it is not your job as package maintainer to look at such failures, I'm just saying that such failures are not likely to draw a lot of your attention. Especially if you have 13562 other things to do. And if enough of these 'unexplainable' issues occur, you're more likely to just press the 'ship it anyway' button anyway. > If we think GCC is going to be unstable on some platforms, then perhaps > the 'complete rebuild in mock' process which Matt Domsch has been doing > should be made mandatory? That would generally help to catch such > compiler-related problems before they affect package maintainers. (Tangent: I've wondered for a while whether the 'rebuild all packages in F(C)-foo using packages in F(C)-foo' is something that is supposed to work. If it is, then I wonder why I should try to create the exact same chroot build environments (in terms of packages and package versions) on ARM as was used on primary architectures when some certain package was built?) > > There is a similar issue with build speed. While my fastest ARM box > > (800 MHz with 512K L2 cache) is quite snappy as far as ARM systems go, > > it is probably no match for even the crappiest of x86 boxes. The > > fastest ARM CPU I know of is a dual core 1.2GHz, which is still no > > match for x86. > > > > This doesn't mean, IMHO, that it makes no sense to run Fedora on ARM > > systems. > > > > But it does mean that if the building of packages on primary > > architectures is throttled at the speed of building packages on ARM, > > we're going to make a lot of (x86) Fedora developers very sad, angry, > > frustrated, or all of the above. > > Not really. The builds for the architecture they _care_ about would be > available in koji from the moment they finish, and with the > 'chain-build' option they'd be able to build subsequent dependent > packages immediately too. The only thing that would be waiting is the > push to the main repository... which also in practice waits for mirrors > to sync and other stuff like that. It's hardly a fast-path. (How is chain-build different from "BuildRequires: foo >= bar.baz.quux"? The latter is at least easily enforced.) > If there are architectures which are _really_ slow, and it really does > start to cause problems, then _perhaps_ we'd need to stop waiting for > those architectures. > > I think we should try to avoid that unless it's really necessary though. > Not only would we be pushing partially-failed packages without any > investigation, but you'd also start getting build failures and > inconsistencies on that architecture even when there wasn't actually a > real problem -- if a developer doesn't use chain-build but just submits > jobs one after the other, before the first job finished on all > architectures. The repository for that architecture wouldn't really be > in sync with Fedora at all -- you haven't gained much over the current > situation where you're entirely on your own. (The 'asking people to use chain-build' is another case (IMHO) of 'putting some burden on the arch maintainer' vs 'putting some burden on the package maintainer'.) > Perhaps one way to deal with this potential problem is to allow the > package maintainer to push the 'go ahead and push it anyway' button in > the build system even _before_ the build has run to completion on every > architecture? That seems fine to me, too, but at that point, aren't you back to 'keep your arch in sync separate from the primary archs' anyway? I.e. let's say that I track upstream koji build dependencies in my downstream arch build system. (I.e. I make sure that I only build packages with the same versions of build-dependent packages as on x86.) Aren't we back to 'my arch is supported separately' at that point? Sure, I can send $packagemaintainer an email whenever his/her package fails to build in my arch build system even though it built fine on x86, but it's not quite the same thing. > That way, the build would _normally_ wait for everyone to finish > and the repositories would remain in sync, and potential bugs would > get at least a cursory glance before the package is shipped -- but > in the fairly rare case where there's an urgent need for it in the > actual repositories, the package maintainer could speed things up. > > (Presumably they'd need to have a way to force the mirrors to sync > up immediately too, if they're in this much of a rush? Something > which has never been brought up as an issue before, AIUI.) I can't sensibly comment on that.. > > So, IMHO, ideally, the existence of secondary architectures should > > not significantly affect the typical workflow of an x86 Fedora > > developer, and secondary architectures should not negatively affect > > development on x86. > > This is true, but taken to extremes it means we may as well not bother > trying to make life easier for you at all. Well, considering what I've said above, I'm not really asking the Fedora project to make my life easier at all. If they'd merge my patches, that'd be fine with me. Even if that means extra work for me. I guess I'm mostly talking from the point of view of an architecture for which there has been a "Fedora" port available since the Red Hat 7.3 days, but has always lived out-of-tree. Any change to that situation would be welcome, really. Even if they'd only take the patches but not make arm a primary or secondary arch. > I think the whole point of the proposal is that there _are_ things we > can do, which are simple enough for us, which will help you a lot. > Should we refuse even to lift a finger to merge your patches, just > because we're too lazy? I know what my opinion is, but ultimately, it's not up to me.. :) (I.e. ideally I'd just retire to some desert island while the Fedora ARM point maintains itself.) > Despite the fact that you then have to work "two or three times as > hard" because you have to work around our recalcitrance? I don't think it's necessarily recalcitrance on the Fedora side, but more a not really seeing the point of having to spend effort on something they don't care about? > If so, then why are we bothering with this proposal at > all? You might as well just keep doing it on your own, surely? That's what we've been doing for a while. :) (RH73, RH9, FC2, FC3, FC4, FC6.) We tried to merge our patches at various points in the past, which never turned out successful. If people feel that ARM being supported separately is the best way forward for the ARM port, sure, I'll accept that. I just hope that there's another way that can be found that is both: 1/ minimal impact for the existing Fedora package maintainers; and 2/ less hassle for us. If that means that I have to work harder, I'll do that. > I think that if we're going to bother doing _anything_, the least we > should do is merge your patches and keep the build system in sync in the > _default_ case. Again, I don't disagree here at all. > Yes, package maintainers should have the option not to > care about builds which fail on ARM -- but any competent maintainer > should at least be taking a _cursory_ look at any new failure. Nor do I disagree with this. > If we _really_ have to, we could have an option not to wait for the > build to complete -- but using that should be discouraged except in very > special cases. As I said, it's not as if packages making it to the > mirrors is a fast path. ACK. cheers, Lennert From buytenh at wantstofly.org Tue Jun 12 19:42:07 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 21:42:07 +0200 Subject: fedora for ARM In-Reply-To: <4667F669.3000304@warmcat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070607110354.GC2079@xi.wantstofly.org> <4667E82B.3010503@warmcat.com> <20070607115009.GI2079@xi.wantstofly.org> <4667F669.3000304@warmcat.com> Message-ID: <20070612194207.GA14392@xi.wantstofly.org> On Thu, Jun 07, 2007 at 01:13:29PM +0100, Andy Green wrote: > > I am not forgetting that, all I said was that I just don't think we > > should pile every change to Fedora that could ever be useful on > > embedded targets together into one patch repository and then present > > that as a fait accomplis 'Fedora ARM patch set'. > > Well, clearly that wouldn't be a Fedora ARM patch set any more, so fair > enough. I agree your patches are a separate issue, it's another arch > support added for native compile same as say s390 and that is fine. Right. > This all came up on the same thread but talking about building cross > isn't saying anything about your patches at all or trying to tie them to > the issue of cross compiling. > > Fedora targeting OLPC and now ARM though, the spread of system > capability being aimed at is clearly increasing over time, not > decreasing. That does make more reasons to look not only at cross but > at more than One True Configuration for some core packages that are in > themselves quite configurable at compile time. Ideally, I'd just like to be able to say "Build me a copy of F8 without selinux and without java, but with X support." etc, but this is not necessarily something that other Fedora developers would be interested in, so not necessarily something I should be bothering other developers with, IMHO, at least not at this point. From buytenh at wantstofly.org Tue Jun 12 19:45:19 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 21:45:19 +0200 Subject: fedora for ARM In-Reply-To: <466834DA.1060009@redhat.com> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <20070607114028.GH2079@xi.wantstofly.org> <466834DA.1060009@redhat.com> Message-ID: <20070612194519.GB14392@xi.wantstofly.org> On Thu, Jun 07, 2007 at 10:39:54AM -0600, Brendan Conoboy wrote: > >I would fully agree with the sentiment that cross-compiling the entire > >distro as _the_ standard way of maintaining the arch package repository > >is not a realistic scenario and will likely never be. Preferably, I > >would like to just keep doing this entirely natively. > > I hesitate to say never, prefering to invoke the forseeable future. > Wherever native builds are a viable option, it makes sense to use them. > Wherever cross builds are a viable option, it makes sense to use them. What I said was that I don't think that cross-building packages will ever supersede natively building packages as the preferred package building method. I don't really see this changing any time soon -- even if I'd like to be able to build more packages cross. > >It appears a lot less effort to maintain a set of patches to make some > >limited subset of packages (say, 300 packages) cross-compilable, > >though. In some cases, we'll have to do this anyway. > > Indeed- if you can simply cross build the packages at the top of the > dependency tree (kernel, libc, coreutils, init, bash/sh), you are in > much better shape. ACK. > What's more, they are typically very cross friendly. My experience is somewhat different, but OK. :-) One thing I wondered about, are your (cross-) diffs available somewhere? From laroche at redhat.com Tue Jun 12 19:49:04 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 12 Jun 2007 21:49:04 +0200 Subject: R500 initial driver release Message-ID: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> http://lwn.net/Articles/237920/rss regards, Florian La Roche From buytenh at wantstofly.org Tue Jun 12 19:54:35 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 21:54:35 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46686D85.5000603@redhat.com> References: <46686D85.5000603@redhat.com> Message-ID: <20070612195435.GC14392@xi.wantstofly.org> On Thu, Jun 07, 2007 at 02:41:41PM -0600, Brendan Conoboy wrote: > I don't have fast and easy answers to all of the above, but I would > like to have a discussion about them. My group may be able to offer > expertise, patches and some man power toward this goal. What do you > think? The best way to convince people (in my experience) is to show them your patches, and let the patches do the convincing. :-) If you could show your patches, and show that they are really non-intrusive, that might convince people. Can we see your patches anywhere? From buytenh at wantstofly.org Tue Jun 12 19:56:48 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 21:56:48 +0200 Subject: Fedora and Cross Compiling In-Reply-To: References: <46686D85.5000603@redhat.com> Message-ID: <20070612195648.GD14392@xi.wantstofly.org> On Thu, Jun 07, 2007 at 11:42:42PM +0200, Gianluca Sforna wrote: > >I don't have fast and easy answers to all of the above, but I would like > >to have a discussion about them. My group may be able to offer > >expertise, patches and some man power toward this goal. What do you think? > > I think that would be wonderful to have Fedora (or a significant > subset of it) available for my Linksys NSLU2, since it's the only way > to resurrect it from the drawer I buried it after I had enough of the > unslung (debian based) firmware... The Fedora ARM port should run on the NSLU2 just fine. It's just that we don't provide HOWTOs/install images/installation help for the NSLU2 at this point, but in theory it should work... From blizzard at redhat.com Tue Jun 12 19:57:35 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 12 Jun 2007 15:57:35 -0400 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1180609829.26803.345.camel@pmac.infradead.org> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> Message-ID: <1181678255.2681.21.camel@localhost.localdomain> On Thu, 2007-05-31 at 12:10 +0100, David Woodhouse wrote: > On Wed, 2007-05-30 at 19:20 -0400, Christopher Blizzard wrote: > > I think that this is a separate topic from the larger secondary arch > > disucssion? Whether or not PowerPC is on that list or not? > > Yes, but I have a suspicion there may be some backtracking. Since it was > assured before, I'd like it in writing now so that nobody can pretend it > wasn't said. > > Especially since we're making such unnecessary and potentially > detrimental changes to the way that secondary arches are handled. > I've been talking to people on and off about this and I think you're statement elsewhere in this thread hit it right on the nose: it's good to have a nice mix of 32 and 64 bit as well as LE and BE systems. So I think it's important that PPC be a primary arch and package maintainers are responsible to make sure that it works before any builds are pushed out to the repos. PPC is the fastest canary in the cage, if you will. :) --Chris From buytenh at wantstofly.org Tue Jun 12 20:06:00 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 22:06:00 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46691FB4.1090508@warmcat.com> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <46691FB4.1090508@warmcat.com> Message-ID: <20070612200600.GF14392@xi.wantstofly.org> On Fri, Jun 08, 2007 at 10:21:56AM +0100, Andy Green wrote: > Native compilers would be built on an ARM box or emulation creating an > ARM executable compiler that emits ARM code. But in both cases, the > compiler is coming from the same gcc sources. > > In either case, if you give it some C to compile, it should emit the > same ARM object file, one happens to emit that ARM object code with a > compiler that is built from i386 instructions itself and another does it > with the same compiler built from ARM instructions itself. In this way > "real native hardware" has absolutely *nothing* to do with it. I don't think that a cross-compiler always generates the very same binary code (e.g. I've been told that you can't always pre-compute constant floating point operations on the compiling host as you would on the target), but cross-compiling _should_ produce functionally identical code. From buildsys at redhat.com Tue Jun 12 20:06:21 2007 From: buildsys at redhat.com (Build System) Date: Tue, 12 Jun 2007 16:06:21 -0400 Subject: rawhide report: 20070612 changes Message-ID: <200706122006.l5CK6LFI017729@porkchop.devel.redhat.com> New package perl-Compress-Raw-Zlib Low-Level Interface to the zlib compression library New package php-pear-PhpDocumentor The complete documentation solution for PHP New package professor-is-missing The Professor is Missing, an AGI adventure game New package repoman Tool for configuring yum settings and repositories Removed package hunspell-he Updated Packages: aquamarine-0.2.1-1.fc8 ---------------------- * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 archivemail-0.7.0-6.fc8 ----------------------- * Tue Jun 12 2007 Jon Ciesla 0.7.0-6 - Patch to fix imap handling, BZ 243846. authconfig-5.3.14-1.fc8 ----------------------- * Tue Jun 12 2007 Tomas Mraz - 5.3.14-1 - authconfig.8 synopsis fixed (patch by Eric Raymond) (#220574) - drop explicit requirement on python version as it is now generated automatically - improve writing /etc/samba/smb.conf (based on patch by Simo Sorce) - merge changes upstream autofs-1:5.0.1-16 ----------------- * Tue Jun 12 2007 Ian Kent - 5.0.1-16 - add ldaps support. - note: it's no longer possible to have multiple hosts in an ldap map spec. - note: to do this you need to rely on the ldap client config. bdock-0.2.1-1.fc8 ----------------- * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 binutils-2.17.50.0.16-1 ----------------------- * Tue Jun 12 2007 Jakub Jelinek 2.17.50.0.16-1 - update to 2.17.50.0.16 bygfoot-2.2.0-1.fc8 ------------------- * Mon Jun 11 2007 Micha?? Bentkowski - 2.2.0-1 - 2.2.0 * Fri May 18 2007 Micha?? Bentkowski - 2.1.1-1 - 2.1.1 coolkey-1.1.0-3.fc8 ------------------- * Tue Jun 05 2007 Bob Relyea - 1.1.0-3 - add build requires, bump version number for make tag. * Thu May 31 2007 Bob Relyea - 1.1.0-2 - Back out RHEL-4 version of spec from CVS, add pcsc-lite-lib requires. cpuspeed-1:1.2.1-1.59.fc8 ------------------------- * Mon Jun 11 2007 Jarod Wilson - Add e_powersaver (new Via C3 cpufreq driver) to list of those which should use ondemand governor by default * Thu Apr 26 2007 Jarod Wilson - Add a bit to the config file documentation - Use variable for program name - Fix up exit codes (#237942) dhcdbd-2.8-2.fc8 ---------------- * Mon Jun 11 2007 David Cantrell - 2.8-2 - Merge review (#225690) dhcpv6-0.10-43.fc8 ------------------ * Mon Jun 11 2007 David Cantrell - 0.10-43 - Merge review (#225692) djvulibre-3.5.19-2.fc8 ---------------------- * Mon Jun 11 2007 Matthias Saou 3.5.19-2 - Include patch to remove LC_CTYPE for ja man pages, fixes sed 100% CPU issue. * Fri Jun 08 2007 Matthias Saou 3.5.19-1 - Update to 3.5.19. - Disable rpath on 64bit... not. - Convert ja man pages to UTF-8. * Tue Feb 13 2007 Matthias Saou 3.5.18-2 - Include man page patch to have man pages be identical across archs (#228359). dovecot-1.0.0-11.7.fc8 ---------------------- * Fri Jun 08 2007 Tomas Janousek - 1.0.0-11.7 - specfile merge from 145241 branch - new sql split patch - support for not building all sql modules - split sql libraries to separate packages * Sat Apr 14 2007 Tomas Janousek - 1.0.0-11.1 - dovecot-1.0.beta2-pam-tty.patch is no longer needed emerald-0.2.1-2.fc8 ------------------- * Mon Jun 11 2007 Jarod Wilson 0.2.1-2 - Fix up build against latest libwnck * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 emerald-themes-0.2.1-1.fc8 -------------------------- * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 esound-1:0.2.38-2.fc8 --------------------- * Mon Jun 11 2007 - Bastien Nocera - 1:0.2.38-2 - Patch from Martin Stransky to work around a race condition in snd_pcm_drain (#238680) evince-0.9.0-3.fc8 ------------------ * Mon Jun 11 2007 - Bastien Nocera - 0.9.0-3 - Add comics-related build fixes * Mon Jun 11 2007 - Bastien Nocera - 0.9.0-2 - Enable comics support (#186865) findutils-1:4.2.31-1.fc8 ------------------------ * Tue Jun 12 2007 Vitezslav Crhonek - 1:4.2.31-1 - Update to findutils-4.2.31 Resolves: #243732 firstboot-1.4.35-3.fc8 ---------------------- * Mon Jun 11 2007 Chris Lumens - 1.4.35-3 - More fixes for package review (#225756). * Mon Jun 11 2007 Chris Lumens - 1.4.35-2 - Fixes for package review (#225756). gimmie-0.2.7-1.fc8 ------------------ * Mon Jun 11 2007 Deji Akingunola - 0.2.7-1 - New release glunarclock-0.32.4-9.fc8 ------------------------ * Mon Jun 11 2007 Jon Ciesla - 0.32.4-9 - Backed out yelp Requires. gparted-0.3.3-11.fc8 -------------------- * Mon Jun 11 2007 Deji Akingunola - 0.3.3-11 - Apply patch to only detect real devices, useful for correcting gparted slow startup in situations when floppy drives don't exist but are enabled in bios (BZ #208821). gstreamer-plugins-farsight-0.12.1-3.fc8 --------------------------------------- * Mon Jun 11 2007 Brian Pepple - 0.12.1-3 - Correct URL. (#242407) gwenhywfar-2.6.0-1.fc8 ---------------------- * Mon Jun 11 2007 Bill Nottingham - 2.6.0-1 - update to 2.6.0 gzip-1.3.12-2.fc8 ----------------- * Mon Jun 11 2007 Ivana Varekova - 1.3.12-2 - remove useless patches heliodor-0.2.1-2.fc8 -------------------- * Mon Jun 11 2007 Jarod Wilson 0.2.1-2 - Fix build against latest libwnck * Mon Jun 04 2007 Jarod Wilson 0.2.1-1 - beryl 0.2.1 * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 hunspell-pl-0.20070611-1.fc8 ---------------------------- * Mon Jun 11 2007 Caolan McNamara - 0.20070611-1 - latest version, are they updating this thing every day * Sat Jun 09 2007 Caolan McNamara - 0.20070609-1 - latest version * Wed Jun 06 2007 Caolan McNamara - 0.20070606-1 - next version jabberd-2.0-0.s11.13.fc8 ------------------------ * Tue Jun 12 2007 Thorsten Leemhuis - 2.0-0.s11.13 - rebuilt on behalf of Adrian jd-1.9.5-0.4.beta070611.fc8 --------------------------- * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.4.beta070611 - 1.9.5 beta 070611 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta 070528 * Tue May 22 2007 Mamoru Tasaka - 1.9.5-0.2.beta070516 - Support C/Migemo search kernel-xen-2.6-2.6.20-2925.10.fc8 --------------------------------- * Mon Jun 11 2007 Eduardo Habkost - Added fix to bug #215201: linux-2.6-xen-fix-nosegneg-detection.patch - Disabled CONFIG_PROVE_LOCKING, as the xen code doesn't support it. See bug #239601 kmenu-gnome-0.6.5-2.fc8 ----------------------- * Tue Jun 12 2007 Chitlesh Goorah - 0.6.5-2 - new upstream release * Mon Jun 11 2007 Ariszlo - 0.6.5-1 - release 0.6.5 * Tue May 22 2007 Chitlesh Goorah - 0.6.4-1 - new upstream release kshutdown-1.0-3.fc8 ------------------- * Fri Apr 27 2007 Chitlesh Goorah 1.0-3 - bug fixing #241019 for gnome libselinux-2.0.21-1.fc8 ----------------------- * Mon Jun 11 2007 Dan Walsh - 2.0.21-1 - Upgrade to upstream * Class and permission mapping support patches from Eamon Walsh. * Object class discovery support patches from Chris PeBenito. * Refactoring and errno support in string representation code. * Fri Jun 01 2007 Dan Walsh - 2.0.18-1 - Upgrade to upstream * Merged patch to reduce size of libselinux and remove need for libsepol for embedded systems from Yuichi Nakamura. This patch also turns the link-time dependency on libsepol into a runtime (dlopen) dependency even in the non-embedded case. 2.0.17 2007-05-31 * Updated Lindent script and reindented two header files. * Fri May 04 2007 Dan Walsh - 2.0.16-1 - Upgrade to upstream * Merged additional swig python bindings from Dan Walsh. * Merged helpful message when selinuxfs mount fails patch from Dax Kelson. man-pages-2.55-1.fc8 -------------------- * Mon Jun 11 2007 Ivana Varekova - 2.55-1 - update to 2.55 * Mon Jun 04 2007 Stepan Kasal - 2.51-4 - Simplified the build and installed phases; pages are now recoded during the install. - Moved the "rm" commands from build to prep. - Added epoll_pwait.patch to fix a circular link. * Mon Jun 04 2007 Stepan Kasal - 2.51-3 - Add man-pages-2.51-nscd-conf.patch, fixes #204596 - Fix typos, man-pages-2.51-typos.patch mkinitrd-6.0.9-7 ---------------- * Mon Jun 11 2007 Peter Jones - 6.0.9-7 - Undo the change from -6, it is wrong. * Thu Jun 07 2007 Peter Jones - 6.0.9-6 - Use stat(2) not lstat(2) when probing subdirs in /sys/block . Needed before gregkh-driver-block-device.patch in 2.6.22-rc4-mm1 makes it upstream. (reported by Kay Sievers) * Mon May 21 2007 Jeremy Katz - 6.0.9-5 - update mdadm patch to install binaries in the right place (#221696) mutt-5:1.5.16-1.fc8 ------------------- * Mon Jun 11 2007 Miroslav Lichvar 5:1.5.16-1 - update to 1.5.16 perl-Locale-Maketext-Lexicon-0.64-1.fc8 --------------------------------------- * Mon Jun 11 2007 Ralf Cors??pius - 0.64-1 - Upgrade to 0.64. - Reflect source-url having changed. php-pear-PHP-CodeSniffer-0.6.0-1.fc8 ------------------------------------ * Mon Jun 11 2007 Konstantin Ryabitsev - 0.6.0-1 - Upstream 0.6.0 - Fix owner on phpcs policycoreutils-2.0.20-1.fc8 ---------------------------- * Mon Jun 11 2007 Dan Walsh 2.0.20-1 - Update to match NSA * Merged genhomedircon fixes from Dan Walsh. * Merged setfiles -c usage fix from Dan Walsh. * Merged restorecon fix from Yuichi Nakamura. * Dropped -lsepol where no longer needed. * Mon Jun 11 2007 Dan Walsh 2.0.19-5 - Fix translations code, Add more filters to gui powertop-1.6-1.fc8 ------------------ * Mon Jun 11 2007 Adam Jackson 1.6-1 - powertop 1.6. python-kiwi-1.9.15-1.fc8 ------------------------ * Mon Jun 11 2007 Konstantin Ryabitsev - 1.9.15-1 - Upstream 1.9.15 ruby-cairo-1.5.0-1.fc8 ---------------------- spamassassin-3.2.1-1.fc8 ------------------------ * Mon Jun 11 2007 Warren Togami 3.2.1-1 - 3.2.1 CVE-2007-2873 spandsp-0.0.4-0.1.pre3.fc8 -------------------------- * Mon Jun 11 2007 Jeffrey C. Ollie - 0.0.4-0.1.pre3 - Update to 0.0.4pre3 squid-7:2.6.STABLE13-1.fc7 -------------------------- * Mon Jun 04 2007 Martin Bacovsky - 7:2.6.STABLE13-1 - update to latest upstream 2.6.STABLE13 - resolves: #242423: Squid Version Violation sysklogd-1.4.2-9.fc8 -------------------- * Mon Jun 11 2007 Peter Vrabec 1.4.2-9 - fix reload option in initscript (#243507) system-config-kickstart-2.7.7-2.fc8 ----------------------------------- * Mon Jun 11 2007 Chris Lumens 2.7.7-2 - Fixes for package review (#226459). usermode-1.92-1 --------------- * Mon Jun 11 2007 Miloslav Trma?? - 1.92-1 - Fix userhelper hangs in non-UTF8 locales Resolves: #242420 - Clean up menu categories in desktop files * Sat Jun 09 2007 Miloslav Trma?? - 1.91.2-1 - Show the user we're authenticating as in an i18n-safe way. Resolves: #233210 - Remove BuildRequires: libattr-devel vdr-1.4.7-2.fc8 --------------- * Mon Jun 11 2007 Ville Skytt?? - 1.4.7-2 - Apply Reinhard Ni??l's "sync early" patch for smoother channel changes. * Sat May 12 2007 Ville Skytt?? - 1.4.7-1 - 1.4.7. * Tue May 01 2007 Ville Skytt?? - 1.4.6-3 - Upstream 1.4.6-1, refresh other patches. xen-3.1.0-2.fc8 --------------- * Tue Jun 12 2007 Daniel P. Berrange - 3.1.0-2.fc8 - Remove patch which kills VNC monitor - Fix HVM save/restore file path to be /var/lib/xen instead of /tmp - Don't spawn a bogus xen-vncfb daemon for HVM guests - Add persistent logging of hypervisor & guest consoles - Add /etc/sysconfig/xen to allow admin choice of logging options - Re-write Xen startup to use standard init script functions - Add logrotate configuration for all xen related logs * Fri May 25 2007 Daniel P. Berrange - 3.1.0-1.fc8 - Updated to official 3.1.0 tar.gz - Fixed data corruption from VNC client disconnect (bz 241303) * Thu May 17 2007 Daniel P. Berrange - 3.1.0-0.rc7.2.fc7 - Ensure xen-vncfb processes are cleanedup if guest quits (bz 240406) - Tear down guest if device hotplug fails xorg-x11-server-1.3.0.0-9.fc8 ----------------------------- * Mon Jun 11 2007 Adam Jackson 1.3.0.0-9 - xserver-1.3.0-reput-video.patch: Don't crash when minimizing an Xv window. (#241214) xournal-0.3.3-5.fc8 ------------------- * Mon Jun 11 2007 Rick L Vinyard Jr 0.3.3-5 - Added Requires for poppler-utils (#243750) - Added Requires for ghostscript xtide-2.9.3-3.fc8 ----------------- * Mon Jun 11 2007 Mamoru Tasaka - 2.9.3-3 - Require needed fonts (bug reported from upstream) yumex-1.9.9-1.0.fc8 ------------------- * Tue Jun 12 2007 Tim Lauridsen - 1.9.9-1.0 - Development Release 1.9.9-1.0 Broken deps for i386 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 k3b - 1.0.1-2.fc8.x86_64 requires libmpcdec.so.3()(64bit) k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.x86_64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 k3b - 1.0.1-2.fc8.ppc requires libmpcdec.so.3 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 From buytenh at wantstofly.org Tue Jun 12 20:12:27 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 22:12:27 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <4669AEBC.3070802@redhat.com> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <4669AEBC.3070802@redhat.com> Message-ID: <20070612201227.GG14392@xi.wantstofly.org> On Fri, Jun 08, 2007 at 01:32:12PM -0600, Brendan Conoboy wrote: > > I think for Alpha we will have enough fast machines that can get > > the job done. I don't know about the other arches.... > > That's handy- how will you bootstrap? That's a bit of a false argument. How are you ever going to get your x86 distro bootstrapped? I.e. how are you ever going to produce a chicken without eggs? From buytenh at wantstofly.org Tue Jun 12 20:38:42 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 22:38:42 +0200 Subject: fedora for ARM In-Reply-To: References: <20070602032955.GC16918@xi.wantstofly.org> <20070602183828.GI7445@redhat.com> <20070607103441.GB2079@xi.wantstofly.org> Message-ID: <20070612203842.GH14392@xi.wantstofly.org> On Sat, Jun 09, 2007 at 12:09:19PM +0000, Kevin Kofler wrote: > > > # CONFIG_UTRACE is not set > > > > > > note that this will also disable ptrace too afaik. > > > > Hmm. Hmm? > > > > [root iop ~]# uname -a > > Linux iop.wantstofly.org 2.6.21 #13 Sun May 13 23:39:28 CEST 2007 armv5tel > > armv5tel armv5tel GNU/Linux > > That's not a Fedora kernel. Disabling utrace only disables ptrace > if the kernel actually has the utrace patch. :-) Ah, OK. That makes sense. Sorry for the noise. From walters at redhat.com Tue Jun 12 20:47:19 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 12 Jun 2007 16:47:19 -0400 Subject: The updates firehose In-Reply-To: <466E4C05.3090304@fedoraproject.org> References: <200706091605.00638.jkeating@redhat.com> <604aa7910706092034m390c83a7p7c06d7131056256c@mail.gmail.com> <20070611050840.GD18869@nostromo.devel.redhat.com> <200706110831.22069.jkeating@redhat.com> <1181578484.25734.23.camel@metroid.rdu.redhat.com> <466E4C05.3090304@fedoraproject.org> Message-ID: <1181681239.6681.10.camel@neutron.verbum.private> On Tue, 2007-06-12 at 13:02 +0530, Rahul Sundaram wrote: > Mugshot folks don't seem to be interested in splitting out code when I > asked in fedora-desktop list. From the description it appears that the > code is not going to useful outside of mugshot. Talk to them again anyway. I can't think of much from the Mugshot code that would be directly reusable for package installation stats. Desktop applications people are interested in (what Mugshot tracks) and RPM packages installed on a computer are only distantly related. At least on the client side I'm not sure how much more complicated it would get than a POST of the output of rpm -qa to a fedora server (i.e. a few lines of Python) in /etc/cron.whatever. On the server side I'd just reuse the smolt code. From jkeating at redhat.com Tue Jun 12 20:47:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Jun 2007 16:47:57 -0400 Subject: The updates firehose In-Reply-To: <1181681239.6681.10.camel@neutron.verbum.private> References: <200706091605.00638.jkeating@redhat.com> <466E4C05.3090304@fedoraproject.org> <1181681239.6681.10.camel@neutron.verbum.private> Message-ID: <200706121648.01703.jkeating@redhat.com> On Tuesday 12 June 2007 16:47:19 Colin Walters wrote: > I can't think of much from the Mugshot code that would be directly > reusable for package installation stats. ?Desktop applications people > are interested in (what Mugshot tracks) and RPM packages installed on a > computer are only distantly related. > > At least on the client side I'm not sure how much more complicated it > would get than a POST of the output of rpm -qa to a fedora server (i.e. > a few lines of Python) in /etc/cron.whatever. It's not about what is installed, but rather what is used. So just getting a list of packages installed is not helpful (much). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Tue Jun 12 20:54:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 12 Jun 2007 15:54:39 -0500 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <466ECE2F.2060100@fedoraproject.org> References: <466EAA1D.70409@redhat.com> <466EC07A.2050305@fedoraproject.org> <1181663928.31562.44.camel@erebor.boston.redhat.com> <466EC673.9050707@fedoraproject.org> <20070612163614.GA5569@nostromo.devel.redhat.com> <466ECE2F.2060100@fedoraproject.org> Message-ID: <1181681679.28872.9.camel@localhost> On Tue, 2007-06-12 at 22:17 +0530, Rahul Sundaram wrote: > Torrent is earlier. Rest is later. It's not like all the releases don't > have leaked mirrors anyway a few days before the release anyway. For reference, here's how the FC6 and F7 releases went for me: 1) The day before release, a leaky mirror is discovered. 2) An enterprising user downloads the iso and creates a torrent. 3) The torrent spreads like wildfire through forums and IRC. 4) I download the torrent, and verify the signature on the checksums. 5) On release day, I download the official torrent and help seed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Tue Jun 12 21:07:26 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 12 Jun 2007 17:07:26 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <466E0526.3050807@redhat.com> References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> Message-ID: <466F0B0E.4030903@redhat.com> Christopher Aillon wrote: > Matej Cepl wrote: >> On 2007-06-11, 19:31 GMT, Colin Walters wrote: >>> Random aside - I wonder if anyone would notice or care if the Help >>> menu items just disappeared from all applications. >> >> Reporter of bug 242673 which lies in the root of all this messes noticed. > > No, reading the bug, the root of all this is because someone went > against my will twice now and added the firefox-32 package. Now people > think they can do shit like this which was one of my objections in the > first place. I objected to this before it got added and it got added > anyway. Then I objected after it got added again and they promised to > remove it but it's apparently back now, after I verified it got removed. > > Clearly, my decisions matter. > This is FUD with a few outright lies sprinkled within. - I created firefox-32 as an alternative way to explicitly launch the 32bit firefox on x86_64 because you rejected multiple REASONABLE requests to allow it to be launched somehow without modifying /usr/bin/firefox manually. - I added it to Extras because I wanted a convenient shell script to launch the 32bit browser without removing x86_64. - You objected to it. I refused to remove it until nspluginwrapper was viable. - You threatened to add Conflicts out of spite. - I escalated this issue to engineering management because I felt you were acting unprofessional and spiteful. agreed with me. - I heard nothing about it for a while. - It never was removed from the distro or re-added at any point. The current version in F7 was built back in November 2006. Someone screwing themselves by removing firefox.x86_64 is completely independent of firefox-32. Furthermore, if you remove firefox.x86_64 you don't need the firefox-32 script at all. I completely fail to see how firefox-32 is the cause of this flamewar. Removing firefox.x86_64 itself is what breaks yelp, and firefox-32 has NOTHING to do with this. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236521 It seems that nspluginwrapper is now close to being suitable for Fedora... although there seems to be a separate drama going on in this review ticket. Let's see how stable and reliable nspluginwrapper can be before removing firefox-32. Warren Togami wtogami at redhat.com From walters at redhat.com Tue Jun 12 21:08:31 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 12 Jun 2007 17:08:31 -0400 Subject: The updates firehose In-Reply-To: <200706121648.01703.jkeating@redhat.com> References: <200706091605.00638.jkeating@redhat.com> <466E4C05.3090304@fedoraproject.org> <1181681239.6681.10.camel@neutron.verbum.private> <200706121648.01703.jkeating@redhat.com> Message-ID: <1181682511.6681.24.camel@neutron.verbum.private> On Tue, 2007-06-12 at 16:47 -0400, Jesse Keating wrote: > It's not about what is installed, but rather what is used. So just getting a > list of packages installed is not helpful (much). I see 3 fairly distinct classes of RPM packages (as I mentioned in earlier messages with thoughts about how these could be viewed differently for installation). * Desktop apps - Mugshot covers this, though of course it is tied in with the rest of the Mugshot system (getting stacker notifications, etc) that we could separate out a bit more. * Developer tools - popcon's measure of atime is probably good enough * Server software - used == running (service foo status), obviously How to distinguish whether an RPM package is in one of these 3 cases would require some heuristics right now I believe. From vnpenguin at vnoss.org Tue Jun 12 21:09:56 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Tue, 12 Jun 2007 23:09:56 +0200 Subject: pungi : double rpm packages in ISO image Message-ID: Hi, I make a customized iso with pungi. In my config file for yum, I defined both release & update repos. Logically, pungi will fetch only latest version (update in this case) and build iso from only updated packages. But it's not. By mounting my iso, I found both old & updated packages !!! -rw-r--r-- 2 root root 1478279 May 23 16:46 audacious-plugins-1.3.3-1.fc7.i386.rpm -rw-r--r-- 2 root root 1482290 Jun 11 21:09 audacious-plugins-1.3.4-2.fc7.i386.rpm -rw-r--r-- 2 root root 896385 May 23 16:54 bind-libs-9.4.0-6.fc7.i386.rpm -rw-r--r-- 2 root root 935866 Jun 8 17:34 bind-libs-9.4.1-4.fc7.i386.rpm -rw-r--r-- 2 root root 135001 May 23 17:20 ctapi-cyberjack-2.0.14-1.fc7.i386.rpm -rw-r--r-- 2 root root 134997 Jun 8 08:34 ctapi-cyberjack-2.0.14-2.fc7.i386.rpm -rw-r--r-- 2 root root 3262934 Jun 11 21:11 gdb-6.6-15.fc7.i386.rpm -rw-r--r-- 2 root root 3255434 May 23 18:07 gdb-6.6-8.fc7.i386.rpm -rw-r--r-- 2 root root 172994 May 23 18:21 gnome-menus-2.18.0-1.fc7.i386.rpm -rw-r--r-- 2 root root 177552 Jun 9 14:59 gnome-menus-2.18.2-1.fc7.i386.rpm -rw-r--r-- 2 root root 55527 May 23 18:23 gnome-python2-libegg-2.14.3-2.fc7.i386.rpm -rw-r--r-- 2 root root 55331 Jun 8 17:36 gnome-python2-libegg-2.14.3-3.fc7.i386.rpm -rw-r--r-- 2 root root 189479 May 23 18:29 gpm-1.20.1-83.fc7.i386.rpm -rw-r--r-- 2 root root 189405 Jun 5 11:17 gpm-1.20.1-84.fc7.i386.rpm ... We need _only_ updated packages here please ! Anyone knows how to fix this please ? Thanks, -- http://vnoss.org From jwboyer at jdub.homelinux.org Tue Jun 12 21:16:47 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 12 Jun 2007 16:16:47 -0500 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181678255.2681.21.camel@localhost.localdomain> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> Message-ID: <1181683007.17463.41.camel@vader.jdub.homelinux.org> On Tue, 2007-06-12 at 15:57 -0400, Christopher Blizzard wrote: > On Thu, 2007-05-31 at 12:10 +0100, David Woodhouse wrote: > > On Wed, 2007-05-30 at 19:20 -0400, Christopher Blizzard wrote: > > > I think that this is a separate topic from the larger secondary arch > > > disucssion? Whether or not PowerPC is on that list or not? > > > > Yes, but I have a suspicion there may be some backtracking. Since it was > > assured before, I'd like it in writing now so that nobody can pretend it > > wasn't said. > > > > Especially since we're making such unnecessary and potentially > > detrimental changes to the way that secondary arches are handled. > > > > I've been talking to people on and off about this and I think you're > statement elsewhere in this thread hit it right on the nose: it's good > to have a nice mix of 32 and 64 bit as well as LE and BE systems. So I > think it's important that PPC be a primary arch and package maintainers > are responsible to make sure that it works before any builds are pushed > out to the repos. > > PPC is the fastest canary in the cage, if you will. :) I'm surprised. Pleasantly, because I agree with you, but surprised none the less. josh From mike at miketc.com Tue Jun 12 21:33:42 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 12 Jun 2007 16:33:42 -0500 Subject: R500 initial driver release In-Reply-To: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> Message-ID: <1181684022.2680.4.camel@scrappy.miketc.com> On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: > http://lwn.net/Articles/237920/rss So will someone be including this driver (this is in the kernel or xorg packages) in fc7 or I assume fc8? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From buildsys at fedoraproject.org Tue Jun 12 21:34:48 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 12 Jun 2007 17:34:48 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-12 Message-ID: <20070612213448.20059152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 24 NEW digitemp-3.5.0-1.fc6 : Dallas Semiconductor 1-wire device reading console application dirac-0.7.0-1.fc6 empathy-0.7-1.fc6 NEW glump-0.9.11-3.fc6 : A small web application to glue files from multiple sources glunarclock-0.32.4-9.fc6 jd-1.9.5-0.4.beta070611.fc6 kmenu-gnome-0.6.5-2.fc6 kshutdown-1.0-3.fc6 mecab-0.96-1.fc6 mecab-ipadic-2.7.0.20070610-1.fc6 NEW muParser-1.27-4.fc6 : A fast math parser library ntfs-config-1.0-0.3.rc4.fc6 perl-mecab-0.96-1.fc6 php-pear-PHP-CodeSniffer-0.6.0-1.fc6 NEW professor-is-missing-0.1-3.fc6 : The Professor is Missing, an AGI adventure game NEW python-genshi-0.4.1-1.fc6 : Toolkit for stream-based generation of output for the web python-mecab-0.96-1.fc6 NEW python-pgsql-0.9.5-2.fc6 : Enhanced python interface to PostgreSQL python-setuptools-0.6c6-1.fc6 ruby-mecab-0.96-1.fc6 sipp-2.0.1-2.fc6 VLGothic-fonts-20070507-1.fc6 weechat-0.2.5-1.fc6 xtide-2.9.3-3.fc6 Packages built and released for Fedora Extras 5: 13 em8300-kmod-0.16.1-0.2.6.20_1.2319.fc5.2 glunarclock-0.32.4-9.fc5 jd-1.9.5-0.4.beta070611.fc5 kmenu-gnome-0.6.5-2.fc5 kshutdown-1.0-3.fc5 mecab-0.96-1.fc5 mecab-ipadic-2.7.0.20070610-1.fc5 NEW muParser-1.27-4.fc5 : A fast math parser library perl-mecab-0.96-1.fc5 NEW professor-is-missing-0.1-3.fc5 : The Professor is Missing, an AGI adventure game python-mecab-0.96-1.fc5 ruby-mecab-0.96-1.fc5 xtide-2.9.3-3.fc5 Changes in Fedora Extras 6: digitemp-3.5.0-1.fc6 -------------------- * Sun Jan 07 2007 Robert Scheck 3.5.0-1 - Upgrade to 3.5.0 - Initial spec file for Fedora and Red Hat Enterprise Linux dirac-0.7.0-1.fc6 ----------------- * Fri Jun 15 2007 kwizart < kwizart at gmail.com > - 0.7.0-1 - Update to 0.7.0 empathy-0.7-1.fc6 ----------------- * Sat Jun 09 2007 David Nielsen - 0.7-1 - bump to 0.7 glump-0.9.11-3.fc6 ------------------ * Sat Jun 09 2007 Jeffrey C. Ollie - 0.9.11-3 - Clean up tab/space confusion - Remove the buildroot at the beginning of the install glunarclock-0.32.4-9.fc6 ------------------------ * Mon Jun 11 2007 Jon Ciesla - 0.32.4-9 - Backed out yelp Requires. jd-1.9.5-0.4.beta070611.fc6 --------------------------- * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.4.beta070611 - 1.9.5 beta 070611 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta 070528 kmenu-gnome-0.6.5-2.fc6 ----------------------- * Tue Jun 12 2007 Chitlesh Goorah - 0.6.5-2 - new upstream release * Mon Jun 11 2007 Ariszlo - 0.6.5-1 - release 0.6.5 * Tue May 22 2007 Chitlesh Goorah - 0.6.4-1 - new upstream release * Mon May 21 2007 Ariszlo - 0.6.4-0.1 - release 0.6.4 - Removed redhat-artwork dependency kshutdown-1.0-3.fc6 ------------------- * Fri Apr 27 2007 Chitlesh Goorah 1.0-3 - bug fixing #241019 for gnome mecab-0.96-1.fc6 ---------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release * Fri May 04 2007 Mamoru Tasaka - 0.95-2.dist.2 - rebuild mecab-ipadic-2.7.0.20070610-1.fc6 --------------------------------- * Mon Jun 11 2007 Mamoru Tasaka - 2.7.0.20070610 - New release 2.7.0-20070610 muParser-1.27-4.fc6 ------------------- * Fri Jun 08 2007 Frank B?ttner - 1.27-4.fc6 - fix depend on pkgconfig * Wed Jun 06 2007 Frank B?ttner - 1.27-3.fc6 - clean build root before run install part - fix missing pkconfig file * Thu May 17 2007 Frank B?ttner - 1.27-2.fc6 - fix missing post -p /sbin/ldconfig - fix the double doc files - fix missing compiler flags - fix wrong file encoding of the doc files * Wed May 16 2007 Frank B?ttner - 1.27-1.fc6 - start ntfs-config-1.0-0.3.rc4.fc6 --------------------------- * Tue Jun 12 2007 Xavier Lamien - 1.0-0.3.rc4 - Updated Release. perl-mecab-0.96-1.fc6 --------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release php-pear-PHP-CodeSniffer-0.6.0-1.fc6 ------------------------------------ * Mon Jun 11 2007 Konstantin Ryabitsev - 0.6.0-1 - Upstream 0.6.0 - Fix owner on phpcs professor-is-missing-0.1-3.fc6 ------------------------------ * Wed Jun 06 2007 Jon Ciesla 0.1-3 - Corrected tarball modification handling. * Wed May 30 2007 Jon Ciesla 0.1-2 - Fixed .desktop typo. * Wed May 30 2007 Jon Ciesla 0.1-1 - Initial packaging. python-genshi-0.4.1-1.fc6 ------------------------- * Sat Jun 09 2007 Jeffrey C. Ollie - 0.4.1-1 - Update to 0.4.1 python-mecab-0.96-1.fc6 ----------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release python-pgsql-0.9.5-2.fc6 ------------------------ * Thu Jun 07 2007 Konstantin Ryabitsev - 0.9.5-2 - Set license according to what rpmlint wants python-setuptools-0.6c6-1.fc6 ----------------------------- * Sun Jun 10 2007 Konstantin Ryabitsev - 0.6c6-1 - Upstream 0.6c6 - Require python-devel (#240707) ruby-mecab-0.96-1.fc6 --------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release sipp-2.0.1-2.fc6 ---------------- * Sun Jun 10 2007 Peter Lemenkov 2.0.1-2 - rebuild * Wed Jun 06 2007 Peter Lemenkov 2.0.1-1 - Version 2.0.1 VLGothic-fonts-20070507-1.fc6 ----------------------------- * Sat Jun 02 2007 Ryo Dairiki - 20070507-1 - Update to 20070507 weechat-0.2.5-1.fc6 ------------------- * Fri Jun 08 2007 Paul P. Komkoff Jr - 0.2.5-1 - new upstream version xtide-2.9.3-3.fc6 ----------------- * Mon Jun 11 2007 Mamoru Tasaka - 2.9.3-3 - Require needed fonts (bug reported from upstream) Changes in Fedora Extras 5: em8300-kmod-0.16.1-0.2.6.20_1.2319.fc5.2 ---------------------------------------- * Tue Jun 12 2007 Ville Skytt? - Rebuild for kernel 2.6.20-1.2319.fc5. * Tue May 01 2007 Ville Skytt? - Rebuild for kernel 2.6.20-1.2316.fc5. glunarclock-0.32.4-9.fc5 ------------------------ * Mon Jun 11 2007 Jon Ciesla - 0.32.4-9 - Backed out yelp Requires. jd-1.9.5-0.4.beta070611.fc5 --------------------------- * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.4.beta070611 - 1.9.5 beta 070611 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta 070528 kmenu-gnome-0.6.5-2.fc5 ----------------------- * Tue Jun 12 2007 Chitlesh Goorah - 0.6.5-2 - new upstream release * Mon Jun 11 2007 Ariszlo - 0.6.5-1 - release 0.6.5 kshutdown-1.0-3.fc5 ------------------- * Fri Apr 27 2007 Chitlesh Goorah 1.0-3 - bug fixing #241019 for gnome mecab-0.96-1.fc5 ---------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release * Fri May 04 2007 Mamoru Tasaka - 0.95-2.dist.2 - rebuild mecab-ipadic-2.7.0.20070610-1.fc5 --------------------------------- * Mon Jun 11 2007 Mamoru Tasaka - 2.7.0.20070610 - New release 2.7.0-20070610 muParser-1.27-4.fc5 ------------------- * Fri Jun 08 2007 Frank B?ttner - 1.27-4.fc5 - fix depend on pkgconfig * Wed Jun 06 2007 Frank B?ttner - 1.27-3.fc5 - clean build root before run install part - fix missing pkconfig file * Thu May 17 2007 Frank B?ttner - 1.27-2.fc5 - fix missing post -p /sbin/ldconfig - fix the double doc files - fix missing compiler flags - fix wrong file encoding of the doc files * Wed May 16 2007 Frank B?ttner - 1.27-1.fc5 - start perl-mecab-0.96-1.fc5 --------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release professor-is-missing-0.1-3.fc5 ------------------------------ * Wed Jun 06 2007 Jon Ciesla 0.1-3 - Corrected tarball modification handling. * Wed May 30 2007 Jon Ciesla 0.1-2 - Fixed .desktop typo. * Wed May 30 2007 Jon Ciesla 0.1-1 - Initial packaging. python-mecab-0.96-1.fc5 ----------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release ruby-mecab-0.96-1.fc5 --------------------- * Mon Jun 11 2007 Mamoru Tasaka - 0.96-1 - 0.96 release xtide-2.9.3-3.fc5 ----------------- * Mon Jun 11 2007 Mamoru Tasaka - 2.9.3-3 - Require needed fonts (bug reported from upstream) For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jspaleta at gmail.com Tue Jun 12 21:35:34 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 12 Jun 2007 13:35:34 -0800 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181678255.2681.21.camel@localhost.localdomain> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> Message-ID: <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> On 6/12/07, Christopher Blizzard wrote: > PPC is the fastest canary in the cage, if you will. :) no its not... the builders are sooooo damn slow. I hate it... ppc builders are such a tease. You see your package burn through x86 and x86_64 and then boom it falls over and dies on ppc after everything else has gone swimmingly. -jef"its all in favor of crippling the other builders to make ppc fail faster than the other builders succeed"spaleta From buytenh at wantstofly.org Tue Jun 12 21:39:04 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 12 Jun 2007 23:39:04 +0200 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> Message-ID: <20070612213904.GI14392@xi.wantstofly.org> On Tue, Jun 12, 2007 at 01:35:34PM -0800, Jeff Spaleta wrote: > > PPC is the fastest canary in the cage, if you will. :) > > no its not... the builders are sooooo damn slow. I hate it... ppc > builders are such a tease. You see your package burn through x86 and > x86_64 and then boom it falls over and dies on ppc after everything > else has gone swimmingly. > > -jef"its all in favor of crippling the other builders to make ppc fail > faster than the other builders succeed"spaleta You're just going to _love_ those ARM boxes.. From dwmw2 at infradead.org Tue Jun 12 21:51:06 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 12 Jun 2007 22:51:06 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181678255.2681.21.camel@localhost.localdomain> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> Message-ID: <1181685066.25228.77.camel@pmac.infradead.org> On Tue, 2007-06-12 at 15:57 -0400, Christopher Blizzard wrote: > I've been talking to people on and off about this and I think you're > statement elsewhere in this thread hit it right on the nose: it's good > to have a nice mix of 32 and 64 bit as well as LE and BE systems. So I > think it's important that PPC be a primary arch and package maintainers > are responsible to make sure that it works before any builds are pushed > out to the repos. Yes, it certainly makes a lot of sense. Including something with signed-char and something with unsigned-char is good, too. > PPC is the fastest canary in the cage, if you will. :) Having looked over the FE-ExcludeArch-ppc tracker, I think 'canary' is a good word. When it falls over, you really don't want to ignore it. If you ignore the trivial 'Needs Porting' bugs and the 'IBM made us break it' bugs (caused by stuff like 128-bit long double and 64KiB pages on PPC64), and look at the remaining cases where the package _used_ to build and then suddenly failed.... you find that a _significant_ proportion of them are actually _generic_ problems where PPC just happened to fall over first, rather than really being a PPC-specific problem. In fact, it may even be the majority. Examples... Bug 201739: Macaulay2: ppc build hangs, never finishes - showed up a generic 32-on-64 kernel bug affecting x86_64 too (220892) Bug 193727: Build on ppc fails some tests during the %check phase - timing-related differences causing 'make check' to fail - a harder failure caused by aliasing, not arch-specific. Bug 189160: internal compiler error: in get_callee_fndecl, at tree.c:5846 - compiler bug not arch-specific, I believe. GCC PR #27134? When a package _used_ to build but no longer does, that is _often_ an indication of a generic problem rather than an arch-specific problem -- which is why I think 'canary' was such a good choice of word on your part. It really shouldn't go uninvestigated. In particular, if a package builds on some architectures but unexpectedly fails on others, I think it would be very unwise to automatically ship it on the architectures for which it happened to build. Have a 'ship it anyway' button for the maintainer to use after they've at least _looked_ at the failure and found it to be harmless, by all means. But don't just let a partially-failed package get shipped automatically. Really. -- dwmw2 From veillard at redhat.com Tue Jun 12 21:56:52 2007 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 12 Jun 2007 17:56:52 -0400 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> Message-ID: <20070612215652.GD5561@redhat.com> On Tue, Jun 12, 2007 at 01:35:34PM -0800, Jeff Spaleta wrote: > On 6/12/07, Christopher Blizzard wrote: > >PPC is the fastest canary in the cage, if you will. :) > > no its not... the builders are sooooo damn slow. I hate it... ppc > builders are such a tease. You see your package burn through x86 and > x86_64 and then boom it falls over and dies on ppc after everything > else has gone swimmingly. Ahum, consider yourself lucky, as a reminder we used to also build Core on ia64 and s390(x) :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From buildsys at fedoraproject.org Tue Jun 12 21:58:21 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 12 Jun 2007 21:58:21 -0000 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-12 Message-ID: <20070612215821.4051.12287@extras64.linux.duke.edu> Summary of broken packages (by owner): bdpepple AT ameritech.net gstreamer-plugins-farsight - 0.12.0-1.fc7.i386 gstreamer-plugins-farsight - 0.12.0-1.fc7.ppc gstreamer-plugins-farsight - 0.12.0-1.fc7.ppc64 gstreamer-plugins-farsight - 0.12.0-1.fc7.x86_64 cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (10 days) dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (10 days) fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 (10 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (10 days) glest-data - 2.0.0-2.fc7.noarch (10 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (10 days) icon AT fedoraproject.org phpdoc - 1.3.2-1.fc7.noarch phpdoc - 1.3.2-1.fc7.noarch phpdoc - 1.3.2-1.fc7.noarch phpdoc - 1.3.2-1.fc7.noarch jonathansteffan AT gmail.com revisor - 2.0.3.9-1.fc7.noarch revisor - 2.0.3.9-1.fc7.noarch jwilson AT redhat.com beryl-gnome - 0.2.1-1.fc7.ppc64 (6 days) beryl-kde - 0.2.1-1.fc7.ppc64 (6 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (10 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (10 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (10 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (10 days) mdehaan AT redhat.com koan - 0.4.0-1.fc7.noarch (10 days) orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 (10 days) rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 (10 days) rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (10 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (10 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (10 days) tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 (10 days) Democracy - 0.9.5.1-8.fc7.ppc (10 days) Democracy - 0.9.5.1-8.fc7.ppc64 (10 days) Democracy - 0.9.5.1-8.fc7.x86_64 (10 days) ====================================================================== Broken packages in fedora-7-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 gstreamer-plugins-farsight-0.12.0-1.fc7.i386 requires libjrtp-3.7.0.so gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-7-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gstreamer-plugins-farsight-0.12.0-1.fc7.ppc64 requires libjrtp-3.7.0.so()(64bit) gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in fedora-7-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gstreamer-plugins-farsight-0.12.0-1.fc7.ppc requires libjrtp-3.7.0.so gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-7-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 gstreamer-plugins-farsight-0.12.0-1.fc7.x86_64 requires libjrtp-3.7.0.so()(64bit) gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-updates-7-i386: phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 ====================================================================== Broken packages in fedora-updates-7-ppc64: phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 ====================================================================== Broken packages in fedora-updates-7-ppc: phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 ====================================================================== Broken packages in fedora-updates-7-x86_64: phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 ====================================================================== Broken packages in fedora-updates-testing-7-ppc64: beryl-gnome-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 beryl-kde-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 koan-0.4.0-1.fc7.noarch requires syslinux revisor-2.0.3.9-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-testing-7-ppc: revisor-2.0.3.9-1.fc7.noarch requires livecd-tools From dwmw2 at infradead.org Tue Jun 12 22:00:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 12 Jun 2007 23:00:37 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> Message-ID: <1181685637.25228.85.camel@pmac.infradead.org> On Tue, 2007-06-12 at 13:35 -0800, Jeff Spaleta wrote: > On 6/12/07, Christopher Blizzard wrote: > > PPC is the fastest canary in the cage, if you will. :) > > no its not... the builders are sooooo damn slow. I hate it... ppc > builders are such a tease. I've never quite understood why they seem so slow. When I build stuff locally on a quad G5 @2.5GHz with 7GiB of RAM, it goes a lot quicker than _all_ our build machines do. > You see your package burn through x86 and x86_64 and then boom it > falls over and dies on ppc after everything else has gone swimmingly. Well, if it _fails_ that's likely to be generic problem which you need to deal with anyway. If it _succeeds_ then can't you get the builds from koji as soon as they're finished on each architecture? They take another day or so to hit the mirrors _anyway_, so presumably it's not _that_ delay you care about. -- dwmw2 From dominik at greysector.net Tue Jun 12 21:04:18 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 12 Jun 2007 23:04:18 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <20070610212349.GE2371@neu.nirvana> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610212349.GE2371@neu.nirvana> Message-ID: <20070612210418.GA20619@ryvius.pekin.waw.pl> On Sunday, 10 June 2007 at 23:23, Axel Thimm wrote: > On Sun, Jun 10, 2007 at 02:10:10PM +0200, Matej Cepl wrote: > > @Christopher: I have this scenario (taken out of bug > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242673) -- > > user removes firefox from his system (for example, because he > > wants to install firefox.i386 instead of firefox.x86_64). Yum > > dutifuly notes, that depending package yelp will be also removed. > > Doesn't this remind a bit like the ten year old "Windows needs > Explorer" issues, only now "Fedora needs Firefox"? > > Maybe firefox should be split into libs and non-libs? yelp only needs > libgtkembedmoz.so, libxpcom.so, libxpcom_core.so and gecko-libs, not > firefox itself. AFAIK there's a standalone package of gecko coming sometime in the future. Then firefox and thunderbird and whatnot could be built against it instead of each using its own copy. > Requiring yelp only because an app ships a yelp file is like requiring > evince for shipping pdf docu or firefox for shipping html docu. How true. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From notting at redhat.com Tue Jun 12 22:24:30 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Jun 2007 18:24:30 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <466F0B0E.4030903@redhat.com> References: <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> <466F0B0E.4030903@redhat.com> Message-ID: <20070612222430.GA4120@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > This is FUD with a few outright lies sprinkled within. He said people are going out of their way to make his life as firefox maintainer and liason with upstream harder. You say: > - I created firefox-32 as an alternative way to explicitly launch the > 32bit firefox on x86_64 because you rejected multiple REASONABLE > requests to allow it to be launched somehow without modifying > /usr/bin/firefox manually. > - I added it to Extras because I wanted a convenient shell script to > launch the 32bit browser without removing x86_64. > - You objected to it. I refused to remove it until nspluginwrapper was > viable. Refusing to remove something the maintainer of firefox believes is a bad idea that exists *solely as a crutch for proprietary software* seems to be *exactly* what he was saying about ignoring his technical input and making his life as maintainer and liason harder. Bill From jspaleta at gmail.com Tue Jun 12 22:32:12 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 12 Jun 2007 14:32:12 -0800 Subject: To Require yelp or not to require yelp In-Reply-To: <20070612210418.GA20619@ryvius.pekin.waw.pl> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610212349.GE2371@neu.nirvana> <20070612210418.GA20619@ryvius.pekin.waw.pl> Message-ID: <604aa7910706121532m554c38e5idc4d40aad2c0eda7@mail.gmail.com> On 6/12/07, Dominik 'Rathann' Mierzejewski wrote: > AFAIK there's a standalone package of gecko coming sometime in the future. > Then firefox and thunderbird and whatnot could be built against it instead > of each using its own copy. I can't wait for the future to hurry up and get here. Having a set of stablish libs which conform to most common soname rules and library location which are separate from the firefox application itself will do wonders. -jef"whose kneecaps do I need to whack or whose coffee cup do I need to re-fill to help speed this development along?"spaleta From dwmw2 at infradead.org Tue Jun 12 22:45:52 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 12 Jun 2007 23:45:52 +0100 Subject: To Require yelp or not to require yelp In-Reply-To: References: <466BA0D6.8050603@hhs.nl> <20070610092225.db9050e8.mschwendt.tmp0701.nospam@arcor.de> <466BA617.9070408@redhat.com> <200706101224.09692.ville.skytta@iki.fi> <20070611050108.GB18869@nostromo.devel.redhat.com> <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> Message-ID: <1181688352.25228.90.camel@pmac.infradead.org> On Tue, 2007-06-12 at 15:09 +0200, Matej Cepl wrote: > Just curious, why in the world people created firefox-32 in the first > place, when there is firefox.i386 on every x86_64 system? Is there > firefox-32 for PPC or what? How would it work? On PowerPC we have mostly 32-bit userspace by default. Firefox defaults to 32-bit too. The problem is that we ship both libraries and executable 'firefox' browser together in the same package. What we _should_ do is split them into separate 'firefox-libs' and 'firefox' packages. So you can have both versions of the libraries installed, but choose only the one 'firefox'. Xulrunner will let us do it like that. -- dwmw2 From jspaleta at gmail.com Tue Jun 12 22:58:34 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 12 Jun 2007 14:58:34 -0800 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181685637.25228.85.camel@pmac.infradead.org> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <1181685637.25228.85.camel@pmac.infradead.org> Message-ID: <604aa7910706121558y995e09fpbbf2cdf90ffe8513@mail.gmail.com> On 6/12/07, David Woodhouse wrote: > Well, if it _fails_ that's likely to be generic problem which you need > to deal with anyway. If it _succeeds_ then can't you get the builds from > koji as soon as they're finished on each architecture? They take another > day or so to hit the mirrors _anyway_, so presumably it's not _that_ > delay you care about. it just an irking waste of resources really, its not a serious complaint. I haven't had a ppc failure for my package since koji was handed to me to play with so I can't really comment on whether or not koji will make me feel better about the situation. I've no dog in the architecture class warfare battle (though I'm happy to take some ppc hardware donations to get me off the fence.) I'm content to watch ppc failures on my packages and then come to you with hat in hand and big puppydog eyes so that I can be humbled for my lack of expertise solving obvious problems. -jef"too bad we can't squeeze fedora onto a lego mindstorm brick... i'm sure the fedora infrastructure team would love to have some legos to play with as build hosts"spaleta From jonathan.underwood at gmail.com Tue Jun 12 23:28:27 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 13 Jun 2007 00:28:27 +0100 Subject: Ralink binary firmwares Message-ID: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> Hi, What is the reasoning behind not bundling the binary firmware for Ralink wireless devices with Fedora 7. AFAIK (and I could be wrong), these are redistributable firmwares, and are not considered "non-free" as they are uploaded to the device itself. Jonathan From rdieter at math.unl.edu Wed Jun 13 00:31:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 12 Jun 2007 19:31:29 -0500 Subject: Ralink binary firmwares In-Reply-To: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> Message-ID: <466F3AE1.9060508@math.unl.edu> Jonathan Underwood wrote: > What is the reasoning behind not bundling the binary firmware for > Ralink wireless devices with Fedora 7. AFAIK (and I could be wrong), > these are redistributable firmwares If that's the case, it's likely only a case of no-one yet working at packaging it for review and inclusion in Fedora. -- Rex From kevin.kofler at chello.at Wed Jun 13 00:28:19 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 Jun 2007 00:28:19 +0000 (UTC) Subject: Ralink binary firmwares References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> Message-ID: Jonathan Underwood gmail.com> writes: > What is the reasoning behind not bundling the binary firmware for > Ralink wireless devices with Fedora 7. AFAIK (and I could be wrong), > these are redistributable firmwares, and are not considered "non-free" > as they are uploaded to the device itself. The problem is that they don't come with any license attached, so there's no proof that they really are redistributable. Kevin Kofler From davej at redhat.com Wed Jun 13 00:43:39 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 12 Jun 2007 20:43:39 -0400 Subject: Ralink binary firmwares In-Reply-To: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> Message-ID: <20070613004339.GA31917@redhat.com> On Wed, Jun 13, 2007 at 12:28:27AM +0100, Jonathan Underwood wrote: > Hi, > > What is the reasoning behind not bundling the binary firmware for > Ralink wireless devices with Fedora 7. AFAIK (and I could be wrong), > these are redistributable firmwares, and are not considered "non-free" > as they are uploaded to the device itself. Do you have a pointer to a license for those firmwares suggesting they're redistributable ? Because there's nothing on the download page, or in the zip file that I can see. Dave -- http://www.codemonkey.org.uk From spng.yang at gmail.com Wed Jun 13 00:58:52 2007 From: spng.yang at gmail.com (Ken YANG) Date: Wed, 13 Jun 2007 08:58:52 +0800 Subject: new libwnck make emerald fail to start In-Reply-To: <466EAC77.2020308@redhat.com> References: <466615E8.4070101@gmail.com> <466617ED.7030404@redhat.com> <1181095857.3620.0.camel@localhost.localdomain> <46664CFB.7050606@gmail.com> <4666F434.4010508@redhat.com> <1181154316.3454.21.camel@dhcp83-186.boston.redhat.com> <46671453.6010908@redhat.com> <466759DD.1030302@gmail.com> <76e72f800706061844s755a9bctc07e98b5d7d3fc74@mail.gmail.com> <466A3C95.60905@gmail.com> <466D93DF.6090108@redhat.com> <466DAF8A.6040809@redhat.com> <466E12EE.7080904@gmail.com> <466EAC77.2020308@redhat.com> Message-ID: <466F414C.9010005@gmail.com> Jarod Wilson wrote: > Ken YANG wrote: >> Jarod Wilson wrote: >>> Jarod Wilson wrote: >>>> Ken YANG wrote: >>>>> hi, >>>>> >>>>> it seems that the update about beryl still has dependence error: >>>>> >>>>> Error: Missing Dependency: emerald-themes >= 0.2.1 is needed by package >>>>> beryl-gnome >>>>> Error: Missing Dependency: heliodor >= 0.2.1 is needed by package >>>>> beryl-gnome >>>>> Error: Missing Dependency: emerald >= 0.2.1 is needed by package beryl-gnome >>>>> >>>>> i wait several days for this bug fix, but these errors still be there. >>>>> >>>>> please correct me if i'm wrong >>>> Nope, you're correct. I've not had time to deal with beryl, its rather >>>> low-priority juxtaposed to a bunch of other stuff on my plate right now. >>>> Patches welcome! ;) >>> Patch is dead-simple, found a few cycles this afternoon to work on this. >>> New builds are slowly working their way through the build system, should >>> be available on mirrors sometime soonish (where "soonish" might be >>> something between "tonight" and "this upcoming weekend"... :) >> thanks for your work :-) > > No problem. Hopefully the last time I ever have to touch the beryl bits > though... :) :-) now i can update beryl through "yum update" without dependence error thanks > >> by the way, the dependence error about revisor is still there: >> >> Error: Missing Dependency: nash = 6.0.9-4 is needed by package >> libbdevid-python >> >> can you guide me who can i report this error to. > > The dependency error isn't revisor's fault, best as I can tell. > Something is awry between nash and libbdevid-python there. Exactly what, > I don't know, I don't work on those packages. Perhaps you should file a > bug against libbdevid-python or nash. thanks today, the dependence errors about revisor also disappears thanks "someone" who fix this bug :-) > > From mattdm at mattdm.org Wed Jun 13 01:34:24 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 12 Jun 2007 21:34:24 -0400 Subject: To Require yelp or not to require yelp In-Reply-To: <20070612222430.GA4120@nostromo.devel.redhat.com> References: <1181539880.19531.26.camel@localhost.localdomain> <45abe7d80706110813k5619c1a1h6c7c16f98c7faf86@mail.gmail.com> <45abe7d80706110826wf412e6alcbde13b647b4aac@mail.gmail.com> <1181582591.19531.54.camel@localhost.localdomain> <20070611172845.GA6648@nostromo.devel.redhat.com> <1181590315.3840.15.camel@neutron.verbum.private> <466E0526.3050807@redhat.com> <466F0B0E.4030903@redhat.com> <20070612222430.GA4120@nostromo.devel.redhat.com> Message-ID: <20070613013424.GA5572@jadzia.bu.edu> On Tue, Jun 12, 2007 at 06:24:30PM -0400, Bill Nottingham wrote: > > This is FUD with a few outright lies sprinkled within. > He said people are going out of their way to make his life as firefox > maintainer and liason with upstream harder. Well, clearly that's not Warren's *intent*. > Refusing to remove something the maintainer of firefox believes is > a bad idea that exists *solely as a crutch for proprietary software* But can't that be said for the entire idea of multilib? :) > seems to be *exactly* what he was saying about ignoring his technical > input and making his life as maintainer and liason harder. Ins seriousness: this is hard to argue with, mostly because Christopher is right, especially when it comes to respecting his work and area of expertise. On the other hand, Warren also has a lot of valuable expertise in making a collection of software that many people actually want to use and are excited about, and that needs to be respected too. I guess what I'm saying is: can't we all just get along? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From stickster at gmail.com Wed Jun 13 02:34:32 2007 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 12 Jun 2007 22:34:32 -0400 Subject: The updates firehose In-Reply-To: <20070610025254.GF26897@lists.us.dell.com> References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <466B1068.7030002@codewiz.org> <20070610013123.GE26897@lists.us.dell.com> <466B6107.7090904@fedoraproject.org> <20070610025254.GF26897@lists.us.dell.com> Message-ID: <1181702072.3682.9.camel@localhost.localdomain> On Sat, 2007-06-09 at 21:52 -0500, Matt Domsch wrote: > On Sun, Jun 10, 2007 at 07:55:11AM +0530, Rahul Sundaram wrote: > > Matt Domsch wrote: > > >On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote: > > >>Christopher Blizzard wrote: > > >> > > >>>Are people complaining? > > >>I don't complain when it happens with my own computer that's > > >>being updated daily... but it's painful when you update a > > >>dozen of desktops in the office to F7 and all them want to > > >>download 500MB worth of updates the first time they boot. > > >> > > >>Yes, I could use a local Fedora mirror. And, in fact, > > >>I do. But then I'd have to customize the yum config on > > >>all clients to go look there. > > > > > >You can add your local private mirror to mirrormanager, add a netblock > > >that covers your address space, and all your clients will then pull > > >from your local mirror rather than public mirrors, with no change on > > >the clients. > > > > > >https://admin.fedoraproject.org/mirrormanager > > >http://fedoraproject.org/wiki/Infrastructure/Mirroring > > > > Matt, would you be interested in writing a updated mirror guide? The one > > at http://docs.fedoraproject.org is pretty outdated and we need to cover > > all the new configurations and features in the new mirror manager. > > Yeah, somehow I found that link the other day, and thought it needed > to be reworked somewhat. That doc is nice in that works regardless of > any new features Fedora Infrastructure provides (like mirrormanager), > and is good for anyone anywhere that has a copy of the packages, > either from media or downloaded. But it could certainly be enhanced > to describe using the publicly available mirrors to keep your own tree > up-to-date, as well as pointers to perhaps another doc describing how > to use MirrorManager. I'd love to see some changes to this document. I wrote that *way* back in the FC2 time frame and the Docs Project was still testing out its wings back then, so much so that it took until FC3 got out for the document to be published. Wasn't long before it was behind, as my time got eaten up by toolchain and other work. ;-) Matt, if you're interested in updating it, I'm happy to help by giving you any needed info on the tools and other niceties for FDP, as well as helping edit of course. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Jun 13 02:41:58 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 12 Jun 2007 21:41:58 -0500 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <466EE5E8.5010407@redhat.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> <466EE5E8.5010407@redhat.com> Message-ID: <1181702518.28872.28.camel@localhost> On Wed, 2007-06-13 at 04:28 +1000, Mike Kearey wrote: > I'd like to see repeatable, measurable tests not subjective 'I think > it's faster' observations. I am no criticizing here, it's just that > humans are actually bad at this sort of thing. Measurements are better. I've been doing rather extensive performance profiling on OpenJPEG, using Fedora 6/7's gcc 4.1, and I've discovered a few things: Compiling for pentium3 rather than "generic" measurably improves performance on both my i386 test platforms, mobile Celeron 1.3 (PIII based), Celeron 2.1 (P4 based). This is at least partly due to optimizing signed integer math with cmovs. Compiling for pentium4 is slower than pentium3, even on the pentium4! Deriving gain from vectorization is tricky. It's not a Cray, if you're doing just a few calculations on a data set that doesn't fit in cache, you're bound by memory bandwidth and vectorization will likely just slow you down due to the additional alignment requirements. And, there's no signed integer math in SSE2... I need to do some more testing with generic i686 and pentium2 as well, but the primary gain seems to come from compiling for a minimum of i686. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Wed Jun 13 03:41:04 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 12 Jun 2007 23:41:04 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <1181702518.28872.28.camel@localhost> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> <466EE5E8.5010407@redhat.com> <1181702518.28872.28.camel@localhost> Message-ID: <20070613034103.GA11946@redhat.com> On Tue, Jun 12, 2007 at 09:41:58PM -0500, Callum Lerwick wrote: > On Wed, 2007-06-13 at 04:28 +1000, Mike Kearey wrote: > > I'd like to see repeatable, measurable tests not subjective 'I think > > it's faster' observations. I am no criticizing here, it's just that > > humans are actually bad at this sort of thing. Measurements are better. > > I've been doing rather extensive performance profiling on OpenJPEG, > using Fedora 6/7's gcc 4.1, and I've discovered a few things: > > Compiling for pentium3 rather than "generic" measurably improves > performance on both my i386 test platforms, mobile Celeron 1.3 (PIII > based), Celeron 2.1 (P4 based). This is at least partly due to > optimizing signed integer math with cmovs. No surprise really. generic isn't targetting either of the processors you mention. The idea behind generic is 'optimise for _todays_ CPUs', which right now typically means Intel Core, and AMD Opteron/Athlon64. On these platforms, cmov isn't a win (and is even a loss in some cases). For stuff that's really performance sensitive, runtime selection of optimised routines is a far better solution than n different packages for each flavour of CPU. Dave -- http://www.codemonkey.org.uk From vnpenguin at vnoss.org Wed Jun 13 04:01:10 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 13 Jun 2007 06:01:10 +0200 Subject: pungi : double rpm packages in ISO image In-Reply-To: References: Message-ID: @ Jesse Keating & pungi team: Any help to fix this problem please !!! Thanks, From blc at redhat.com Wed Jun 13 04:13:59 2007 From: blc at redhat.com (Brendan Conoboy) Date: Tue, 12 Jun 2007 22:13:59 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <20070612201227.GG14392@xi.wantstofly.org> References: <46686D85.5000603@redhat.com> <4669171D.90906@linux-kernel.at> <4669AEBC.3070802@redhat.com> <20070612201227.GG14392@xi.wantstofly.org> Message-ID: <466F6F07.7020302@redhat.com> Lennert Buytenhek wrote: > That's a bit of a false argument. How are you ever going to get > your x86 distro bootstrapped? I.e. how are you ever going to produce > a chicken without eggs? Toggle switches, man. Cross compiling, it's all about artificial insemination. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From seg at haxxed.com Wed Jun 13 04:20:45 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 12 Jun 2007 23:20:45 -0500 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <20070613034103.GA11946@redhat.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> <466EE5E8.5010407@redhat.com> <1181702518.28872.28.camel@localhost> <20070613034103.GA11946@redhat.com> Message-ID: <1181708445.28872.47.camel@localhost> On Tue, 2007-06-12 at 23:41 -0400, Dave Jones wrote: > No surprise really. > generic isn't targetting either of the processors you mention. > The idea behind generic is 'optimise for _todays_ CPUs', which > right now typically means Intel Core, and AMD Opteron/Athlon64. > On these platforms, cmov isn't a win (and is even a loss in > some cases). I thought Core is a revival of the PIII core. At any rate, "generic" is an -mtune option only, so alone it will not use cmovs anyway because they're not supported earlier that i686. I just tried it, gcc compiling for i386 uses cmov for a signed divide by 128 with march = i686, pentiumpro, pentium2, pentium3, pentium4, core2 and k8. Compiling for x86_64, it uses cmov on march = generic, k8 and core2. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From andy at smile.org.ua Wed Jun 13 05:20:23 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Wed, 13 Jun 2007 08:20:23 +0300 Subject: Bug: Fedora doesn't close DVD drive door In-Reply-To: <20070612171247.GA3839@devserv.devel.redhat.com> References: <20070612171247.GA3839@devserv.devel.redhat.com> Message-ID: <20070613052023.GD14773@serv.smile.org.ua> Hi Alan Cox! On Tue, Jun 12, 2007 at 01:12:47PM -0400, Alan Cox wrote next: > On Mon, Jun 04, 2007 at 10:07:37PM +1200, Shams wrote: > > When I shutdown Fedora 7 it doesn't close the DVD drive > > door automatically and the door is left open. Same problem > > persisted with Fedora 6. > > That isn't a bug a such. We don't worry about the door on shutdown. If you > think we should close the door on shutdown then file an RFE - but it would > need to be specific to poweroff, having the CD door shut on a reboot would > probably be counted as a pain by most people Sorry, Alan, I've deleted original letter. I think this hook may be added via /etc/acpi/{actions,events} by simple script. Thus no recompiletion nor patching is needed. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From blc at redhat.com Wed Jun 13 05:21:10 2007 From: blc at redhat.com (Brendan Conoboy) Date: Tue, 12 Jun 2007 23:21:10 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <20070612195435.GC14392@xi.wantstofly.org> References: <46686D85.5000603@redhat.com> <20070612195435.GC14392@xi.wantstofly.org> Message-ID: <466F7EC6.7030005@redhat.com> Lennert Buytenhek wrote: > The best way to convince people (in my experience) is to show > them your patches, and let the patches do the convincing. :-) Definitely. > If you could show your patches, and show that they are really > non-intrusive, that might convince people. Can we see your > patches anywhere? Not quite yet- The patches to packages are half of the equation. The other half is the changes to the build system that make the patches work. Let me see what I can share sooner than later. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From j.w.r.degoede at hhs.nl Wed Jun 13 06:12:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 08:12:32 +0200 Subject: Ralink binary firmwares In-Reply-To: <20070613004339.GA31917@redhat.com> References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> <20070613004339.GA31917@redhat.com> Message-ID: <466F8AD0.60902@hhs.nl> Dave Jones wrote: > On Wed, Jun 13, 2007 at 12:28:27AM +0100, Jonathan Underwood wrote: > > Hi, > > > > What is the reasoning behind not bundling the binary firmware for > > Ralink wireless devices with Fedora 7. AFAIK (and I could be wrong), > > these are redistributable firmwares, and are not considered "non-free" > > as they are uploaded to the device itself. > > Do you have a pointer to a license for those firmwares suggesting > they're redistributable ? Because there's nothing on the download > page, or in the zip file that I can see. > Has anybody actually asked ralink under which conditions they can be distributed? I think it would be a good idea to create a standard letter for this and then mail (maybe even snail mail) it to ralink and to others listed on this page: http://fedoraproject.org/wiki/SIGs/FirmWare Regards, Hans From blc at redhat.com Wed Jun 13 06:25:58 2007 From: blc at redhat.com (Brendan Conoboy) Date: Wed, 13 Jun 2007 00:25:58 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181662311.25228.42.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> Message-ID: <466F8DF6.7000805@redhat.com> David Woodhouse wrote: > Do we _actually_ need to build parts of glibc? Could we not get away > with a fake DSO which just provides the few symbols libgcc uses? [snip] Will follow up on this part tomorrow. I disfavor faking it, as it were. > Binutils at least should be relatively easy. Here's a patch against > binutils/F-7 which lets me: > make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc > > Even for this we have build system questions... how best to build it for > each target architecture we want? Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options: 1. One srpm to rule them all. This seems like a bad idea as it doesn't scale. 2. One srpm which generates multiple crosses. This might be in the form of one package for the Fedora mesh, another for all mips targets, and so forth. The realm of when somebody wants to be a cross-arch-czar or there is some technical reason to bunch them together. 3. One srpm which generates packages for a single cross, like Hans's arm-gp2x-linux-package effort I favor a combination of #2 and #3. I'll see about adapting your binutils patch to accommodate multiple targets, unless people think this is a really bad idea. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From rc040203 at freenet.de Wed Jun 13 06:48:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Jun 2007 08:48:38 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466F8DF6.7000805@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> Message-ID: <1181717318.2121.67.camel@mccallum.corsepiu.local> On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote: > David Woodhouse wrote: > > Do we _actually_ need to build parts of glibc? Could we not get away > > with a fake DSO which just provides the few symbols libgcc uses? > > [snip] > > Will follow up on this part tomorrow. I disfavor faking it, as it were. > > > Binutils at least should be relatively easy. Here's a patch against > > binutils/F-7 which lets me: > > make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc > > > > Even for this we have build system questions... how best to build it for > > each target architecture we want? > > Generally, I think Hans and the rest at > http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. > Prefixing the target name to the package is a good plan for most > crosses. More fully, I see 3 options: > > 1. One srpm to rule them all. This seems like a bad idea as it doesn't > scale. Right, it doesn't. You'd end up with a monsterous spec cluttered with cases and many (unused) patches, because different vendors apply different patch sets. > 2. One srpm which generates multiple crosses. This might be in the > form of one package for the Fedora mesh, another for all mips targets, > and so forth. The realm of when somebody wants to be a cross-arch-czar > or there is some technical reason to bunch them together. I am having doubts this can work, either, because different architectures/target OS aren't necessarily in a shape to be using the same sources. It definitely don't apply to embedded targets, which tend to require different versions on different architectures. > 3. One srpm which generates packages for a single cross, like Hans's > arm-gp2x-linux-package effort IMO, this is the only viable approach. It bloats the repos and requires some effort to assure packaging consistency when targeting several architectures/OSes, but it's basically what I am doing. > I favor a combination of #2 and #3. FWI: What I am doing for my cross-toolchain rpms is to generate the specs from a other, shared spec templates/fragments. > I'll see about adapting your > binutils patch to accommodate multiple targets, unless people think this > is a really bad idea. This idea probably can be made functional for targets addressing different archs of the same OS, but it doesn't work across OSes nor for embedded targets, because vendors often have different patches applied, even to binutils. Also, there occasionally are problems stemming from certain host/target combinations which render one of binutils/gcc/gdb components unbuildable for one host/target pair. A combined binutils is not unlikely to suffer from the same issues, which would mean "one broken" host/target pair is likely to block out all (E.g. I recently found binutils-2.17 for target sparc-rtems* to bomb out on x86_64, which they build flawlessly on i386). Ralf From andy at warmcat.com Wed Jun 13 07:14:14 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 13 Jun 2007 08:14:14 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <1181717318.2121.67.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> Message-ID: <466F9946.9050900@warmcat.com> Ralf Corsepius wrote: > On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote: >> David Woodhouse wrote: >>> Do we _actually_ need to build parts of glibc? Could we not get away >>> with a fake DSO which just provides the few symbols libgcc uses? >> [snip] >> >> Will follow up on this part tomorrow. I disfavor faking it, as it were. >> >>> Binutils at least should be relatively easy. Here's a patch against >>> binutils/F-7 which lets me: >>> make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc >>> >>> Even for this we have build system questions... how best to build it for >>> each target architecture we want? >> Generally, I think Hans and the rest at >> http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. >> Prefixing the target name to the package is a good plan for most >> crosses. More fully, I see 3 options: >> >> 1. One srpm to rule them all. This seems like a bad idea as it doesn't >> scale. > Right, it doesn't. You'd end up with a monsterous spec cluttered with > cases and many (unused) patches, because different vendors apply > different patch sets. Yet if you can put the clutter issue aside, this is definitely the Holy Grail. The spec file is the single point at which the uncontrolled variance of the raw tarballs are smoothed into a normalized Fedora package. Having multiple specs is going to lead to duplication of information and loss of coherence when changes are made. How about... a single Holy Spec, exactly what Fedora has right now, but which gets dynamically pre-patched if there is stuff needed for cross on a particular package that can't be hidden in the rpmmacros? The set of arch spec patches lives in the SRPM like the other patches. This: - keeps a single Fedora basic spec - allows non-cross folks to totally ignore the existence of cross if they like - allows maintainability - visibility of what is done for per-arch cross -Andy From j.w.r.degoede at hhs.nl Wed Jun 13 07:11:15 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 09:11:15 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466F8DF6.7000805@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> Message-ID: <466F9893.80809@hhs.nl> Brendan Conoboy wrote: > Generally, I think Hans and the rest at > http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. > Prefixing the target name to the package is a good plan for most > crosses. More fully, I see 3 options: > > 3. One srpm which generates packages for a single cross, like Hans's > arm-gp2x-linux-package effort > I keep seeing my name mentioned here, but unfortunately I'm receiving little feedback on my arm-gp2x-linux review tickets. Which is a bit of a shame as I spend a lot of time on getting gcc for linux+glibc to build and install inside a buildroot and getting this right, as is needed for proper rpm / mock building. Luckily I eventually found that Mandrake is already doing cross building of most of the distro, and their gcc comes with a patch to make --with-build-sysroot work for this. So does the lack of feedback mean that my SPECS are good? Or do people just not have the time to look at / review them? Regards, Hans From j.w.r.degoede at hhs.nl Wed Jun 13 07:13:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 09:13:33 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466F9946.9050900@warmcat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> Message-ID: <466F991D.6030407@hhs.nl> Andy Green wrote: > Ralf Corsepius wrote: >> On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote: >>> David Woodhouse wrote: >>>> Do we _actually_ need to build parts of glibc? Could we not get away >>>> with a fake DSO which just provides the few symbols libgcc uses? >>> [snip] >>> >>> Will follow up on this part tomorrow. I disfavor faking it, as it were. >>> >>>> Binutils at least should be relatively easy. Here's a patch against >>>> binutils/F-7 which lets me: >>>> make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc >>>> >>>> Even for this we have build system questions... how best to build it for >>>> each target architecture we want? >>> Generally, I think Hans and the rest at >>> http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. >>> Prefixing the target name to the package is a good plan for most >>> crosses. More fully, I see 3 options: >>> >>> 1. One srpm to rule them all. This seems like a bad idea as it doesn't >>> scale. >> Right, it doesn't. You'd end up with a monsterous spec cluttered with >> cases and many (unused) patches, because different vendors apply >> different patch sets. > > Yet if you can put the clutter issue aside, this is definitely the Holy > Grail. The spec file is the single point at which the uncontrolled > variance of the raw tarballs are smoothed into a normalized Fedora package. > > Having multiple specs is going to lead to duplication of information and > loss of coherence when changes are made. > > How about... a single Holy Spec, exactly what Fedora has right now, but > which gets dynamically pre-patched if there is stuff needed for cross on > a particular package that can't be hidden in the rpmmacros? The set of > arch spec patches lives in the SRPM like the other patches. This: > > - keeps a single Fedora basic spec > - allows non-cross folks to totally ignore the existence of cross if > they like > - allows maintainability > - visibility of what is done for per-arch cross > One single spec might be an idea for Fedora-Fedora cross packages, but it is not the answer for Fedora-Other (Embedded) OS target. For example the gp2x sdk uses binutils 2.16.1 and glibc 2.3.5, so I don't think stuffing this into the main Fedora binutils and glibc specs is a good idea. Regards, Hans From dwmw2 at infradead.org Wed Jun 13 07:25:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 13 Jun 2007 08:25:02 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <1181717318.2121.67.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> Message-ID: <1181719502.25228.127.camel@pmac.infradead.org> On Wed, 2007-06-13 at 08:48 +0200, Ralf Corsepius wrote: > On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote: > > David Woodhouse wrote: > > > Do we _actually_ need to build parts of glibc? Could we not get away > > > with a fake DSO which just provides the few symbols libgcc uses? > > > > [snip] > > > > Will follow up on this part tomorrow. I disfavor faking it, as it were. > > > > > Binutils at least should be relatively easy. Here's a patch against > > > binutils/F-7 which lets me: > > > make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc > > > > > > Even for this we have build system questions... how best to build it for > > > each target architecture we want? > > > > Generally, I think Hans and the rest at > > http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. > > Prefixing the target name to the package is a good plan for most > > crosses. More fully, I see 3 options: > > > > 1. One srpm to rule them all. This seems like a bad idea as it doesn't > > scale. > Right, it doesn't. You'd end up with a monsterous spec cluttered with > cases and many (unused) patches, because different vendors apply > different patch sets. The same was true of the kernel until we started slapping people and making them push their code upstream rather than dumping it in the RPM, and banning the use of %ifarch in the specfile (at least for applying patches). Having applied that discipline, this approach _does_ seem to work for the kernel. (So far, at least). I think Jakub does a good job of keeping patches to a minimum for the toolchain, just as we do for the kernel. Why should we expect less from those involved in cross-compilers? When I build an i386-fedora-linux-gnu cross-compiler package, I want that to be exactly the same compiler as the 'native' i386 compiler. The approach I've taken with binutils allows that. Perhaps we wouldn't get away with the same for gcc, but it would be nice if we could. > > 2. One srpm which generates multiple crosses. This might be in the > > form of one package for the Fedora mesh, another for all mips targets, > > and so forth. The realm of when somebody wants to be a cross-arch-czar > > or there is some technical reason to bunch them together. > I am having doubts this can work, either, because different > architectures/target OS aren't necessarily in a shape to be using the > same sources. > > It definitely don't apply to embedded targets, which tend to require > different versions on different architectures. We really don't want to pander to this. If an architecture cannot work with a current toolchain, then we should just ignore it until the toolchain is fixed. They can get it working upstream, or they can sod off. Otherwise, they'll be asking us to ship their vendor-hacked 2.6.9 kernel next... and then we'll have to hurt them. > > 3. One srpm which generates packages for a single cross, like Hans's > > arm-gp2x-linux-package effort > IMO, this is the only viable approach. It bloats the repos and requires > some effort to assure packaging consistency when targeting several > architectures/OSes, but it's basically what I am doing. This would be a little nicer once we move to git and can just pull changes from Jakub's 'master' Fedora toolchain packages. -- dwmw2 From andy at warmcat.com Wed Jun 13 07:25:57 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 13 Jun 2007 08:25:57 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466F991D.6030407@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> <466F991D.6030407@hhs.nl> Message-ID: <466F9C05.2070202@warmcat.com> Hans de Goede wrote: > Andy Green wrote: >> Ralf Corsepius wrote: >>> On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote: >>>> David Woodhouse wrote: >>>>> Do we _actually_ need to build parts of glibc? Could we not get away >>>>> with a fake DSO which just provides the few symbols libgcc uses? >>>> [snip] >>>> >>>> Will follow up on this part tomorrow. I disfavor faking it, as it >>>> were. >>>> >>>>> Binutils at least should be relatively easy. Here's a patch against >>>>> binutils/F-7 which lets me: >>>>> make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc >>>>> >>>>> Even for this we have build system questions... how best to build >>>>> it for >>>>> each target architecture we want? >>>> Generally, I think Hans and the rest at >>>> http://fedoraproject.org/wiki/SIGs/Embedded have the right idea >>>> here. Prefixing the target name to the package is a good plan for >>>> most crosses. More fully, I see 3 options: >>>> >>>> 1. One srpm to rule them all. This seems like a bad idea as it >>>> doesn't scale. >>> Right, it doesn't. You'd end up with a monsterous spec cluttered with >>> cases and many (unused) patches, because different vendors apply >>> different patch sets. >> >> Yet if you can put the clutter issue aside, this is definitely the Holy >> Grail. The spec file is the single point at which the uncontrolled >> variance of the raw tarballs are smoothed into a normalized Fedora >> package. >> >> Having multiple specs is going to lead to duplication of information and >> loss of coherence when changes are made. >> >> How about... a single Holy Spec, exactly what Fedora has right now, but >> which gets dynamically pre-patched if there is stuff needed for cross on >> a particular package that can't be hidden in the rpmmacros? The set of >> arch spec patches lives in the SRPM like the other patches. This: >> >> - keeps a single Fedora basic spec >> - allows non-cross folks to totally ignore the existence of cross if >> they like >> - allows maintainability >> - visibility of what is done for per-arch cross >> > > One single spec might be an idea for Fedora-Fedora cross packages, but > it is not the answer for Fedora-Other (Embedded) OS target. > > For example the gp2x sdk uses binutils 2.16.1 and glibc 2.3.5, so I > don't think stuffing this into the main Fedora binutils and glibc specs > is a good idea. Maybe I didn't make my actual point clear in that (or maybe I don't get your objection)... the idea is you maintain a patch against the existing Fedora spec file for any package and arch that needs meddling with. So there is one spec file same as right now - unchanged - but you have additional per-arch pre-patches in the SRPM as well for cross cases that need them. Non-cross people who don't go look at the patches aren't even aware anything has changed let alone see things "stuffed" or "cluttered". -Andy From j.w.r.degoede at hhs.nl Wed Jun 13 07:38:03 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 09:38:03 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466F9C05.2070202@warmcat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> <466F991D.6030407@hhs.nl> <466F9C05.2070202@warmcat.com> Message-ID: <466F9EDB.3080507@hhs.nl> Andy Green wrote: > Hans de Goede wrote: >> Andy Green wrote: >>> Ralf Corsepius wrote: >>>> On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote: >>>>> David Woodhouse wrote: >>>>>> Do we _actually_ need to build parts of glibc? Could we not get away >>>>>> with a fake DSO which just provides the few symbols libgcc uses? >>>>> [snip] >>>>> >>>>> Will follow up on this part tomorrow. I disfavor faking it, as it >>>>> were. >>>>> >>>>>> Binutils at least should be relatively easy. Here's a patch against >>>>>> binutils/F-7 which lets me: >>>>>> make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc >>>>>> >>>>>> Even for this we have build system questions... how best to build >>>>>> it for >>>>>> each target architecture we want? >>>>> Generally, I think Hans and the rest at >>>>> http://fedoraproject.org/wiki/SIGs/Embedded have the right idea >>>>> here. Prefixing the target name to the package is a good plan for >>>>> most crosses. More fully, I see 3 options: >>>>> >>>>> 1. One srpm to rule them all. This seems like a bad idea as it >>>>> doesn't scale. >>>> Right, it doesn't. You'd end up with a monsterous spec cluttered with >>>> cases and many (unused) patches, because different vendors apply >>>> different patch sets. >>> Yet if you can put the clutter issue aside, this is definitely the Holy >>> Grail. The spec file is the single point at which the uncontrolled >>> variance of the raw tarballs are smoothed into a normalized Fedora >>> package. >>> >>> Having multiple specs is going to lead to duplication of information and >>> loss of coherence when changes are made. >>> >>> How about... a single Holy Spec, exactly what Fedora has right now, but >>> which gets dynamically pre-patched if there is stuff needed for cross on >>> a particular package that can't be hidden in the rpmmacros? The set of >>> arch spec patches lives in the SRPM like the other patches. This: >>> >>> - keeps a single Fedora basic spec >>> - allows non-cross folks to totally ignore the existence of cross if >>> they like >>> - allows maintainability >>> - visibility of what is done for per-arch cross >>> >> One single spec might be an idea for Fedora-Fedora cross packages, but >> it is not the answer for Fedora-Other (Embedded) OS target. >> >> For example the gp2x sdk uses binutils 2.16.1 and glibc 2.3.5, so I >> don't think stuffing this into the main Fedora binutils and glibc specs >> is a good idea. > > Maybe I didn't make my actual point clear in that (or maybe I don't get > your objection)... the idea is you maintain a patch against the existing > Fedora spec file for any package and arch that needs meddling with. So > there is one spec file same as right now - unchanged - but you have > additional per-arch pre-patches in the SRPM as well for cross cases that > need them. Non-cross people who don't go look at the patches aren't > even aware anything has changed let alone see things "stuffed" or > "cluttered". > You don't get my objectino, I'm crossing from Fedora but not too Fedora, therefore what is in Fedora's specfile is completely irrelevant. Extreme example, the sdcc cross-compiler already in Fedora. This crosses from Fedora to 8051 (and other) microcontrollers. It uses its own assembler and is its own C-compiler, binutils and gcc are not used at all (except for building the asm / compiler themselves, duh). Should the sdcc specfile be a pathc on top of gcc's specfile, a patch effectively replacing 100% of it, just because its a c-compiler too? Also see my reaction to David Woodhouse last mail. Regards, Hans > -Andy > From j.w.r.degoede at hhs.nl Wed Jun 13 07:38:05 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 09:38:05 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1181719502.25228.127.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <1181719502.25228.127.camel@pmac.infradead.org> Message-ID: <466F9EDD.4000703@hhs.nl> David Woodhouse wrote: >>> 2. One srpm which generates multiple crosses. This might be in the >>> form of one package for the Fedora mesh, another for all mips targets, >>> and so forth. The realm of when somebody wants to be a cross-arch-czar >>> or there is some technical reason to bunch them together. >> I am having doubts this can work, either, because different >> architectures/target OS aren't necessarily in a shape to be using the >> same sources. >> >> It definitely don't apply to embedded targets, which tend to require >> different versions on different architectures. > > We really don't want to pander to this. If an architecture cannot work > with a current toolchain, then we should just ignore it until the > toolchain is fixed. They can get it working upstream, or they can sod > off. > I think you on the one side and I and Ralf on the other side are talking about different things, let me try to clarify. I believe you are talking about cross building the Fedora distro to run as a replacement distro on embedded devices, in which case I agree with what you say above. However I (and Ralf to some extend to AFAIK) am talking about building executables to run on an embedded platform using the manufacturer provided distro for that platform. For example with the gp2x (a handheld game device / video player) there is a distro in onboard FLASH and you can insert an sd-card with your own applications. In this case completely different rules apply. > Otherwise, they'll be asking us to ship their vendor-hacked 2.6.9 kernel > next... and then we'll have to hurt them. > No we won't (be shipping their hacked kernel) as that is already in the device, we are "merely" shipping a toolchain (+ headers / libs needed to compile / link) to build applications to install into an already existing OS/platform. >>> 3. One srpm which generates packages for a single cross, like Hans's >>> arm-gp2x-linux-package effort >> IMO, this is the only viable approach. It bloats the repos and requires >> some effort to assure packaging consistency when targeting several >> architectures/OSes, but it's basically what I am doing. > > This would be a little nicer once we move to git and can just pull > changes from Jakub's 'master' Fedora toolchain packages. > Again this is not Fedora-Fedora cross this is Fedora-XXXX cross, where XXXX migh not even be Linux (it isn't in Ralf's scenario), so Jukub's Fedora packages are about as much "master" packages as mandrake's, suse's or debians. For starters a completely different version of some of the major toolchain components may be used, in which case its madness todo this a a patch on top of Jakub's specfile, because 90% of jakubs specfile would get replaced. Regards, Hans From dwmw2 at infradead.org Wed Jun 13 07:55:08 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 13 Jun 2007 08:55:08 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466F9EDD.4000703@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <1181719502.25228.127.camel@pmac.infradead.org> <466F9EDD.4000703@hhs.nl> Message-ID: <1181721308.25228.139.camel@pmac.infradead.org> On Wed, 2007-06-13 at 09:38 +0200, Hans de Goede wrote: > I think you on the one side and I and Ralf on the other side are talking about > different things, let me try to clarify. I believe you are talking about cross > building the Fedora distro to run as a replacement distro on embedded devices, > in which case I agree with what you say above. Yes. To start with, I have been thinking about Fedora->Fedora (or at least Fedora->Linux) cross-compilation. > However I (and Ralf to some extend to AFAIK) am talking about building > executables to run on an embedded platform using the manufacturer provided > distro for that platform. For example with the gp2x (a handheld game device / > video player) there is a distro in onboard FLASH and you can insert an sd-card > with your own applications. > > In this case completely different rules apply. Yes, this is true. Where there are ABI differences, it makes sense to have a toolchain version which matches your target environment. -- dwmw2 From giallu at gmail.com Wed Jun 13 07:56:40 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 13 Jun 2007 09:56:40 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <20070612195648.GD14392@xi.wantstofly.org> References: <46686D85.5000603@redhat.com> <20070612195648.GD14392@xi.wantstofly.org> Message-ID: On 6/12/07, Lennert Buytenhek wrote: > The Fedora ARM port should run on the NSLU2 just fine. > > It's just that we don't provide HOWTOs/install images/installation > help for the NSLU2 at this point, but in theory it should work... mmm this starts to be interesting. So, where should I start? Any wiki, mailing list, forum I could join for discussing this stuff? From andy at warmcat.com Wed Jun 13 08:06:01 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 13 Jun 2007 09:06:01 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466F9EDB.3080507@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> <466F991D.6030407@hhs.nl> <466F9C05.2070202@warmcat.com> <466F9EDB.3080507@hhs.nl> Message-ID: <466FA569.8050003@warmcat.com> Hans de Goede wrote: > You don't get my objectino, I'm crossing from Fedora but not too Fedora, > therefore what is in Fedora's specfile is completely irrelevant. Extreme > example, the sdcc cross-compiler already in Fedora. This crosses from > Fedora to 8051 (and other) microcontrollers. It uses its own assembler > and is its own C-compiler, binutils and gcc are not used at all (except > for building the asm / compiler themselves, duh). Should the sdcc > specfile be a pathc on top of gcc's specfile, a patch effectively > replacing 100% of it, just because its a c-compiler too? Should Fedora packages have to deal with it at all "just because its a c-compiler too?" I think the scenario of striving to be able to build glibc for 8051 on sdcc needs to be triaged into a different discussion. What seems to be in the world of the possible is to retrofit the Fedora - Fedora cross case into what exists already. The benefits that fall out of that in terms of regularizing upstreams for cross and making definitive cross recipes (for gcc anyway!) will only help everyone else. -Andy From j.w.r.degoede at hhs.nl Wed Jun 13 08:08:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 10:08:39 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466FA569.8050003@warmcat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> <466F991D.6030407@hhs.nl> <466F9C05.2070202@warmcat.com> <466F9EDB.3080507@hhs.nl> <466FA569.8050003@warmcat.com> Message-ID: <466FA607.5090508@hhs.nl> Andy Green wrote: > Hans de Goede wrote: > >> You don't get my objectino, I'm crossing from Fedora but not too Fedora, >> therefore what is in Fedora's specfile is completely irrelevant. Extreme >> example, the sdcc cross-compiler already in Fedora. This crosses from >> Fedora to 8051 (and other) microcontrollers. It uses its own assembler >> and is its own C-compiler, binutils and gcc are not used at all (except >> for building the asm / compiler themselves, duh). Should the sdcc >> specfile be a pathc on top of gcc's specfile, a patch effectively >> replacing 100% of it, just because its a c-compiler too? > > Should Fedora packages have to deal with it at all "just because its a > c-compiler too?" I think the scenario of striving to be able to build > glibc for 8051 on sdcc needs to be triaged into a different discussion. > I'm not talking about building glibc for 8051 (that would be kinda hard as an average 8051 comes with 256 bytes of ram, and no I didn't forget an K or M there). What I'm saying that using the same spec for sdcc and gcc makes no sense, iow that when crossing to something not fedora using Fedora's specs as a base makes no sense, because for example we might be dealing with a different compiler (version). Please read my reply to David Woodhouse. > What seems to be in the world of the possible is to retrofit the Fedora > - Fedora cross case into what exists already. The benefits that fall > out of that in terms of regularizing upstreams for cross and making > definitive cross recipes (for gcc anyway!) will only help everyone else. > Agreed, all that I'm saying is that the one spec file (with or without overlays) might be a good idea for Fedora-Fedora crosses, but is not for Fedora-Foo crosses. Regards, Hans From andy at warmcat.com Wed Jun 13 08:30:36 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 13 Jun 2007 09:30:36 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466FA607.5090508@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> <466F991D.6030407@hhs.nl> <466F9C05.2070202@warmcat.com> <466F9EDB.3080507@hhs.nl> <466FA569.8050003@warmcat.com> <466FA607.5090508@hhs.nl> Message-ID: <466FAB2C.3050205@warmcat.com> Hans de Goede wrote: > What I'm saying that using the same spec for sdcc and gcc makes no > sense, iow that when crossing to something not fedora using Fedora's > specs as a base makes no sense, because for example we might be dealing > with a different compiler (version). We agree on it, but I think accepting that it makes no sense then it is out of scope and just confusing the issue with a need that can't be met. > Please read my reply to David Woodhouse. Yep I understood it. I also build for 8051 derivatives and so on, but I don't expect Fedora packaging to give me any help for what to build down there: it doesn't seem reasonable. ARM9 that can handle the kernel and so on -- and gcc -- is a different matter. >> What seems to be in the world of the possible is to retrofit the Fedora >> - Fedora cross case into what exists already. The benefits that fall >> out of that in terms of regularizing upstreams for cross and making >> definitive cross recipes (for gcc anyway!) will only help everyone else. >> > > Agreed, all that I'm saying is that the one spec file (with or without > overlays) might be a good idea for Fedora-Fedora crosses, but is not for > Fedora-Foo crosses. Sure. But nothing Fedora can do can help with Fedora-Foo crosses where Foo is a wildcard and your plan is to replace their spec file anyway. What it can do something about is the Fedora-Fedora cross case, and specfile patching would be a neat solution. -Andy From rc040203 at freenet.de Wed Jun 13 08:55:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Jun 2007 10:55:54 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1181721308.25228.139.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <1181719502.25228.127.camel@pmac.infradead.org> <466F9EDD.4000703@hhs.nl> <1181721308.25228.139.camel@pmac.infradead.org> Message-ID: <1181724954.2121.92.camel@mccallum.corsepiu.local> On Wed, 2007-06-13 at 08:55 +0100, David Woodhouse wrote: > On Wed, 2007-06-13 at 09:38 +0200, Hans de Goede wrote: > > I think you on the one side and I and Ralf on the other side are talking about > > different things, let me try to clarify. I believe you are talking about cross > > building the Fedora distro to run as a replacement distro on embedded devices, > > in which case I agree with what you say above. > > Yes. To start with, I have been thinking about Fedora->Fedora (or at > least Fedora->Linux) cross-compilation. Let me try to clarify. I am referring to general Fedora-> cross toolchains, not necessarily restricted to Fedora targets. My primary focus is on ->*rtems* cross toolchains (rtems: A free rt-OS for embedded targets) for which I am co-maintaining/co-leading OS- and toolchain-development and also am providing toolchain rpms. Peculiar about such targets is them often addressing "2nd class architectures", which have little attention in upstream binutils/GCC/gdb and therefore often require custom patches, or particular hand-selected "known to work" source versions. My secondary focus is on sys-rooted Fedora-> toolchains, reusing target binaries, in first place aiming at Canadian cross building ->*rtems* toolchains on Fedora, in second place serving as "test beds" for portability issues in packages. > > However I (and Ralf to some extend to AFAIK) am talking about building > > executables to run on an embedded platform using the manufacturer provided > > distro for that platform. For example with the gp2x (a handheld game device / > > video player) there is a distro in onboard FLASH and you can insert an sd-card > > with your own applications. > > > > In this case completely different rules apply. > > Yes, this is true. Where there are ABI differences, it makes sense to > have a toolchain version which matches your target environment. ABI is one thing. But there are other things, not necessarily in binutils, but more in GCC and gdb. E.g. consider Fedora->FreeBSD, Fedora->SuSE, Fedora->MinGW toolchains. Though they share the same basis, they are substantially different in many details. One lesson I've learned through all these years, I am building cross-toolchains: Use upstream binaries whenever possible, only they are 100% compatible to native toolchains/run-time, use upstream source whenever possible to minimize the risk of producing incompatible toolchains. Ralf From rc040203 at freenet.de Wed Jun 13 09:01:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Jun 2007 11:01:53 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <466F9893.80809@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> Message-ID: <1181725313.2121.100.camel@mccallum.corsepiu.local> On Wed, 2007-06-13 at 09:11 +0200, Hans de Goede wrote: > I keep seeing my name mentioned here, but unfortunately I'm receiving little > feedback on my arm-gp2x-linux review tickets. Which is a bit of a shame as I > spend a lot of time on getting gcc for linux+glibc to build and install inside > a buildroot and getting this right, as is needed for proper rpm / mock > building. Luckily I eventually found that Mandrake is already doing cross > building of most of the distro, and their gcc comes with a patch to make > --with-build-sysroot work for this. > > So does the lack of feedback mean that my SPECS are good? Or do people just not > have the time to look at / review them? Wrt. me it's more the latter. More precisely, unlike with your avr-toolchain (which I reviewed/am reviewing), which resemble very much to my toolchains (i.e. I knew about potential issues in advance), I am not familiar with glibc's details. A detail inside of your specs causing me head-ache is the "bootstrap" stuff. I am not yet convinced this to be "the right thing(tm)". Ralf From j.w.r.degoede at hhs.nl Wed Jun 13 09:00:19 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 11:00:19 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1181725313.2121.100.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> Message-ID: <466FB223.5020602@hhs.nl> Ralf Corsepius wrote: > On Wed, 2007-06-13 at 09:11 +0200, Hans de Goede wrote: > >> I keep seeing my name mentioned here, but unfortunately I'm receiving little >> feedback on my arm-gp2x-linux review tickets. Which is a bit of a shame as I >> spend a lot of time on getting gcc for linux+glibc to build and install inside >> a buildroot and getting this right, as is needed for proper rpm / mock >> building. Luckily I eventually found that Mandrake is already doing cross >> building of most of the distro, and their gcc comes with a patch to make >> --with-build-sysroot work for this. >> >> So does the lack of feedback mean that my SPECS are good? Or do people just not >> have the time to look at / review them? > Wrt. me it's more the latter. > > More precisely, unlike with your avr-toolchain (which I reviewed/am > reviewing), which resemble very much to my toolchains (i.e. I knew about > potential issues in advance), I am not familiar with glibc's details. > I understand, thanks for the clarification. > A detail inside of your specs causing me head-ache is the "bootstrap" > stuff. I am not yet convinced this to be "the right thing(tm)". > Afaik when it comes to linux-glibc details its the only way, notice that bootstrap=1 will be needed only once, but I though it would be good to have configurable in the spec, becaue maybe oneday with a new binutils /glibc it might be a good idea to redo from start. Regards, Hans From aph at redhat.com Wed Jun 13 09:12:10 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2007 10:12:10 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <466FA607.5090508@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> <466F991D.6030407@hhs.nl> <466F9C05.2070202@warmcat.com> <466F9EDB.3080507@hhs.nl> <466FA569.8050003@warmcat.com> <466FA607.5090508@hhs.nl> Message-ID: <18031.46314.604724.445022@zebedee.pink> Hans de Goede writes: > Andy Green wrote: > > Hans de Goede wrote: > > > >> You don't get my objectino, I'm crossing from Fedora but not too Fedora, > >> therefore what is in Fedora's specfile is completely irrelevant. Extreme > >> example, the sdcc cross-compiler already in Fedora. This crosses from > >> Fedora to 8051 (and other) microcontrollers. It uses its own assembler > >> and is its own C-compiler, binutils and gcc are not used at all (except > >> for building the asm / compiler themselves, duh). Should the sdcc > >> specfile be a pathc on top of gcc's specfile, a patch effectively > >> replacing 100% of it, just because its a c-compiler too? > > > > Should Fedora packages have to deal with it at all "just because its a > > c-compiler too?" I think the scenario of striving to be able to build > > glibc for 8051 on sdcc needs to be triaged into a different discussion. > > > > I'm not talking about building glibc for 8051 (that would be kinda hard as an > average 8051 comes with 256 bytes of ram, and no I didn't forget an K or M there). No, that's the 8052, the de luxe version. The 8051 has 128 bytes of RAM... :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From kwizart at gmail.com Wed Jun 13 09:16:26 2007 From: kwizart at gmail.com (KH KH) Date: Wed, 13 Jun 2007 11:16:26 +0200 Subject: Ralink binary firmwares In-Reply-To: <466F8AD0.60902@hhs.nl> References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> <20070613004339.GA31917@redhat.com> <466F8AD0.60902@hhs.nl> Message-ID: 2007/6/13, Hans de Goede : > Dave Jones wrote: > > On Wed, Jun 13, 2007 at 12:28:27AM +0100, Jonathan Underwood wrote: > > > Hi, > > > > > > What is the reasoning behind not bundling the binary firmware for > > > Ralink wireless devices with Fedora 7. AFAIK (and I could be wrong), > > > these are redistributable firmwares, and are not considered "non-free" > > > as they are uploaded to the device itself. > > > > Do you have a pointer to a license for those firmwares suggesting > > they're redistributable ? Because there's nothing on the download > > page, or in the zip file that I can see. > > > > Has anybody actually asked ralink under which conditions they can be distributed? I don't know if notting was taking care of this? I proposed to intiate contact, but i'm not well aware about what to ask in such cases... If someone wants to contact them, here is the link! http://www.ralinktech.com/ralink/Home/Contact.html They claims to support the linux community - they should answears ! quote : "Ralink is very active in the Linux community," from http://www.ralinktech.com/ralink/Home/Support/Linux.html Nicolas (kwizart) > I think it would be a good idea to create a standard letter for this and then > mail (maybe even snail mail) it to ralink and to others listed on this page: > http://fedoraproject.org/wiki/SIGs/FirmWare > > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From buildsys at redhat.com Wed Jun 13 09:18:18 2007 From: buildsys at redhat.com (Build System) Date: Wed, 13 Jun 2007 05:18:18 -0400 Subject: rawhide report: 20070613 changes Message-ID: <200706130918.l5D9IID3027370@porkchop.devel.redhat.com> New package corkscrew Tool for tunneling SSH through HTTP proxies New package perl-IO-Compress-Base Base Class for IO::Compress modules New package perl-IO-Compress-Bzip2 Perl interface to allow reading and writing of bzip2 data New package xfce4-volstatus-icon System tray icon to easily eject removable devices Updated Packages: MySQL-python-1.2.2-2.fc8 ------------------------ * Tue Jun 12 2007 Tom Lane 1.2.2-2 - Fix quoting bug in use of older setup.py: need to quote version_info now Resolves: #243877 * Fri Apr 20 2007 Tom Lane 1.2.2-1 - Update to 1.2.2, but not 1.2.2 setup.py (since we don't ship setuptools yet) anaconda-11.3.0.0-1 ------------------- * Tue Jun 12 2007 Chris Lumens - 11.3.0.0-1 - Require libdhcp6client-static. - Remove loopback mounted split ISO install method. - Allow locking root and user accounts from kickstart (#240059). - Don't delete NFS mounts from /etc/fstab on upgrade (#242073). - Add support for Areca RAID controllers (#238014). - Use "disc" instead of "CD" in loader dialogs (#242830). - Don't show the X hatch pattern anymore (#195919). - Set a default clearpart type. - Permanently skip task and group selection on livecd (katzj, #242083). - Sync up repo representation with yum (dlehman). - Enable building on arm (Lennert Buytenhek). - Fix iscsi configuration traceback (#242379). - Enable all ZFCP LUNs (dcantrell, #207097). - Don't traceback on blank lines in modprobe.conf (#241991). - Fall back to English release notes (#241975). - Fix static network configuration (dcantrell, #221660). - Mount /dev/pts in rescue mode (dlehman, #228714). - Include dmidecode on ia64 (dlehman, #232947). - Correctly count SCSI disks (dlehman, #230526). - Don't traceback if we can't remove a ks script (#241878). - Preserve authconfig formatting (#241657). - Fix RAID superblock issues (katzj, #151653). - Bump early swap RAM limit (katzj, #232862). - Network configuration fixes (katzj, #240804). - Define Error to fix a livecd traceback (katzj, #241754). - Remove extra windows in text network config (notting, #241556). - Remove telnet mode (dcantrell). - Fix traceback on kickstart upgrades (#241395, #243159). - Make sure nics are brought up with DHCP config info (dcantrell). - Error out on invalid RAID superblocks (pjones, #151653). - loader UI flow fixes (dcantrell, #239958). - Fix various tracebacks in the partitioning code (dcantrell). - Fix network segfault (dcantrell, #240804). - Log real LVM errors instead of hiding them (katzj). * Mon May 21 2007 Jeremy Katz - 11.2.0.61-1 - add esound to upgrade handling - fix selected group display when adding repos with the same groups (#237708) - check for Xvnc being executable (dcantrell) - add keyutils-libs (#240629) * Wed May 16 2007 Chris Lumens - 11.2.0.60-1 - Add yum logger (katzj, #240226). - Fix up Bulgarian keyboard support (#240087). - Fix text mode language selection tracebacks. antlr-0:2.7.7-1jpp.4.fc8 ------------------------ * Tue Jun 12 2007 Deepak Bhole 2.7.7-1jpp.4.fc8 - Added a PIC compiled archive (bz# 242305) aoetools-16-1.fc8 ----------------- * Tue Jun 12 2007 Patrick "Jima" Laughton 16-1 - New upstream release (bugfix) bcfg2-0.9.4-0.1.pre2.fc8 ------------------------ * Tue Jun 12 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre2 - Update to 0.9.4pre2 gnu-efi-3.0c-2.fc8 ------------------ * Tue Jun 12 2007 Chris Lumens - 3.0c-2 - Fixes for package review (#225846). libdhcp-1.25-1.fc8 ------------------ * Tue Jun 12 2007 David Cantrell - 1.25-1 - Add root-path to the list of DHCP options request (needed for stateless) libgnomeui-2.18.1-3.fc8 ----------------------- * Tue Jun 12 2007 Ray Strode - 2.18.1-3 - Require yelp * Tue Apr 10 2007 Matthias Clasen - 2.18.1-2 - Add user-dirs support to the gnome-vfs filechooser backend * Tue Mar 13 2007 Matthias Clasen - 2.18.1-1 - Update to 2.18.1 libxml2-2.6.29-1 ---------------- * Tue Jun 12 2007 Daniel Veillard 2.6.29-1 - upstream release 2.6.29 see http://xmlsoft.org/news.html - many bug fixed upstream libxslt-1.1.21-1.fc8 -------------------- * Tue Jun 12 2007 Daniel Veillard 1.1.21-1 - upstream release 1.1.21 see http://xmlsoft.org/XSLT/news.html luma-2.3-12.fc8 --------------- * Tue Jun 12 2007 Jochen Schmitt 2.3-12 - Requires python-ldap-2.3 when using python-2.5 (#2211167) mc-1:4.6.1a-46.20070604cvs.fc8 ------------------------------ * Thu Jul 12 2007 Jindrich Novy 4.6.1a-46 - update to new upstream CVS snapshot (2007-06-04-22) - don't print prompts multiple times when switching between mc and subshell mock-0.7.0-1.fc8 ---------------- * Mon Jun 11 2007 Clark Williams - 0.7-1 - fixed bind mount problems - added code to allow multiple users to use --no-clean - merged mock-0-6-branch to head and changed version * Thu Jun 07 2007 Clark Williams - 0.6.17-1 - added F-7 config files (BZ#242276) - modified epel configs for changed mirrorlist location (BZ#239981) - added bind mount of /dev (BZ#236428) - added copy of /etc/resolv.conf to chroot (BZ#237663 and BZ#238101) * Tue May 01 2007 Clark Williams - 0.6.16-1 - timeout code adds new cmdline option that will kill build process after specified timeout. Useful for automated builds of things that may hang during build and you just want it to fail. ntfs-config-1.0-0.3.rc4.fc8 --------------------------- * Tue Jun 12 2007 Xavier Lamien - 1.0-0.3.rc4 - Updated Release. perl-MIME-Types-1.20-1.fc8 -------------------------- * Wed Jun 13 2007 Ville Skytt?? - 1.20-1 - 1.20. - Convert docs to UTF-8. php-pear-PhpDocumentor-1.3.2-2.fc8 ---------------------------------- * Tue Jun 12 2007 Konstantin Ryabitsev - 1.3.2-2 - Require parent n-v-r instead of php-pear(pear-name) in phpdoc for simplicity setroubleshoot-1.9.7-1.fc8 -------------------------- * Tue Jun 12 2007 John Dennis - 1.9.7-1 - Resolves Bug# 241739, this bug is the lead bug for several bug reports, all consequences of the same problem, setroubleshootd/sealert when run in a non latin language environment because of incompatibilities in i18n encoding between components. * Wed May 30 2007 John Dennis - 1.9.6-1 - add avc_auparse.py, now has option to use audit parsing library instead of built-in audit parsing. - fix bug in log file scanning and detail display update - Resolves Bug# 238516, python pkg directory not owned * Wed Apr 25 2007 Dan Walsh - 1.9.5-1 - Update translations - Fix mislabeled file xchat-1:2.8.2-9.fc8 ------------------- * Tue Jun 12 2007 Kevin Kofler - 1:2.8.2-9 - build against system libsexy instead of static sexy-spell-entry now that this is possible (Core-Extras merge) Broken deps for i386 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 k3b - 1.0.1-2.fc8.x86_64 requires libmpcdec.so.3()(64bit) k3b - 1.0.1-2.fc8.i386 requires libmpcdec.so.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.x86_64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 k3b - 1.0.1-2.fc8.ppc requires libmpcdec.so.3 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 k3b - 1.0.1-2.fc8.ppc64 requires libmpcdec.so.3()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 From j.w.r.degoede at hhs.nl Wed Jun 13 09:19:08 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 11:19:08 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <18031.46314.604724.445022@zebedee.pink> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <1181717318.2121.67.camel@mccallum.corsepiu.local> <466F9946.9050900@warmcat.com> <466F991D.6030407@hhs.nl> <466F9C05.2070202@warmcat.com> <466F9EDB.3080507@hhs.nl> <466FA569.8050003@warmcat.com> <466FA607.5090508@hhs.nl> <18031.46314.604724.445022@zebedee.pink> Message-ID: <466FB68C.3020806@hhs.nl> Andrew Haley wrote: > Hans de Goede writes: > > Andy Green wrote: > > > Hans de Goede wrote: > > > > > >> You don't get my objectino, I'm crossing from Fedora but not too Fedora, > > >> therefore what is in Fedora's specfile is completely irrelevant. Extreme > > >> example, the sdcc cross-compiler already in Fedora. This crosses from > > >> Fedora to 8051 (and other) microcontrollers. It uses its own assembler > > >> and is its own C-compiler, binutils and gcc are not used at all (except > > >> for building the asm / compiler themselves, duh). Should the sdcc > > >> specfile be a pathc on top of gcc's specfile, a patch effectively > > >> replacing 100% of it, just because its a c-compiler too? > > > > > > Should Fedora packages have to deal with it at all "just because its a > > > c-compiler too?" I think the scenario of striving to be able to build > > > glibc for 8051 on sdcc needs to be triaged into a different discussion. > > > > > > > I'm not talking about building glibc for 8051 (that would be kinda hard as an > > average 8051 comes with 256 bytes of ram, and no I didn't forget an K or M there). > > No, that's the 8052, the de luxe version. The 8051 has 128 bytes of RAM... > I know, but actually most 8051 deratives are 8052's hence I wrote "average" Regards, Hans From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jun 13 09:28:07 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 13 Jun 2007 11:28:07 +0200 Subject: Ralink binary firmwares In-Reply-To: References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> <20070613004339.GA31917@redhat.com> <466F8AD0.60902@hhs.nl> Message-ID: <20070613112807.101fc839@python3.es.egwn.lan> KH KH wrote : > They claims to support the linux community - they should answears ! > quote : "Ralink is very active in the Linux community," > from http://www.ralinktech.com/ralink/Home/Support/Linux.html I just clicked on the "Terms & Conditions" link. There's as much info as inside the firmware zip files ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.83 0.80 0.64 From david.craigon at griffin.com Wed Jun 13 10:00:45 2007 From: david.craigon at griffin.com (David Craigon) Date: Wed, 13 Jun 2007 11:00:45 +0100 Subject: Could I give bug 180579 a prod? Message-ID: <39C2B4777DC0364FBBF4D8233402E6C70113ABC4@dpp-exch01-a.network.griffin.net.uk> It's a bug about allowing an option for the postfix RPM to built using postgresql. It's been stuck on NEEDINFO for ages, but I've given the INFO NEEDED :-). I appreciate that this bug has a minute audience, but I'm one of them- all that is needed is to merge a patch supplied. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.craigon at griffin.com Wed Jun 13 10:03:07 2007 From: david.craigon at griffin.com (David Craigon) Date: Wed, 13 Jun 2007 11:03:07 +0100 Subject: Could I give bug 180579 a prod? References: <39C2B4777DC0364FBBF4D8233402E6C70115DE0C@dpp-exch01-a.network.griffin.net.uk> Message-ID: <39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> Really sorry about the HTML mail- many apologies. Here's what I said for those who don't use HTML mail readers. It's a bug about allowing an option for the postfix RPM to built using postgresql. It's been stuck on NEEDINFO for ages, but I've given the INFO NEEDED :-). I appreciate that this bug has a minute audience, but I'm one of them- all that is needed is to merge a patch supplied. Thanks, David From jonathan.underwood at gmail.com Wed Jun 13 10:34:03 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 13 Jun 2007 11:34:03 +0100 Subject: Ralink binary firmwares In-Reply-To: <20070613112807.101fc839@python3.es.egwn.lan> References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> <20070613004339.GA31917@redhat.com> <466F8AD0.60902@hhs.nl> <20070613112807.101fc839@python3.es.egwn.lan> Message-ID: <645d17210706130334s473bb13bg1f69abeff720c24f@mail.gmail.com> On 13/06/07, Matthias Saou wrote: > KH KH wrote : > > > They claims to support the linux community - they should answears ! > > quote : "Ralink is very active in the Linux community," > > from http://www.ralinktech.com/ralink/Home/Support/Linux.html > > I just clicked on the "Terms & Conditions" link. There's as much info > as inside the firmware zip files ;-) Yes - I failed to find anythign about the redistribution details. Since the serialmonkey project redistribute firmware, I had naively assumed this was a resolved issue, but that seems not to be the case. I'll write an email to Ralink and ask. Jonathan. From ssorce at redhat.com Wed Jun 13 11:58:18 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Jun 2007 07:58:18 -0400 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <20070612215652.GD5561@redhat.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> Message-ID: <1181735898.11346.48.camel@willson> On Tue, 2007-06-12 at 17:56 -0400, Daniel Veillard wrote: > On Tue, Jun 12, 2007 at 01:35:34PM -0800, Jeff Spaleta wrote: > > On 6/12/07, Christopher Blizzard wrote: > > >PPC is the fastest canary in the cage, if you will. :) > > > > no its not... the builders are sooooo damn slow. I hate it... ppc > > builders are such a tease. You see your package burn through x86 and > > x86_64 and then boom it falls over and dies on ppc after everything > > else has gone swimmingly. > > Ahum, consider yourself lucky, as a reminder we used to also build > Core on ia64 and s390(x) :-) And that was good, IA64 caught some bugs for me as well that went completely undetected for some mysterious reason on other architectures but were fatal for them all. (Botched shared libraries) Simo. From alan at redhat.com Wed Jun 13 12:01:01 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 13 Jun 2007 08:01:01 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <1181708445.28872.47.camel@localhost> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> <466EE5E8.5010407@redhat.com> <1181702518.28872.28.camel@localhost> <20070613034103.GA11946@redhat.com> <1181708445.28872.47.camel@localhost> Message-ID: <20070613120101.GA18901@devserv.devel.redhat.com> On Tue, Jun 12, 2007 at 11:20:45PM -0500, Callum Lerwick wrote: > I thought Core is a revival of the PIII core. At any rate, "generic" is > an -mtune option only, so alone it will not use cmovs anyway because > they're not supported earlier that i686. Jakub posted a recpie some time ago to get everything 686 but without the cmov instruction gcc otherwise erroneously issues. IMHO it would be nice to switch Fedora to using "i686 without cmov" for all the .686 packages and kernel and get rid of the extra cases if we can From baris at teamforce.name.tr Wed Jun 13 12:30:34 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Wed, 13 Jun 2007 15:30:34 +0300 Subject: Anaconda crash for Turkish installation Message-ID: <1181737834.3673.24.camel@localhost.localdomain> Hi all; I'm not quite sure if this bug mentioned before in the list, but since I could not find bug filed about it in anaconda bugs, I wanted to increase awareness. Turkish installation (probably some other languages also affected) has a problem with Fedora 7. Anaconda crashes with some unicode problem. Since I'm python ignorant I did not dare to dig into problem, but I'm affraid this important problem is due to minor translation issue. It's not possible to install fedora 7 unless you choose other language, and if you prefer to use Turkish, change the language post-install. That's not acceptable for regular user. I'm affraid most Turkish users think that Fedora has a problem and they choose other distributions. That problem existed in Fedora Core 6 as well. I should have tested the images for Fedora 7 but I thought that was fixed already. I hope there's a chance to fix this bug, and roll new ISOs as Fedora 7 is eary in its release time. Here's the bug report about the problem, anaconda traceback is also included. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244016 Regards, Baris. From dtimms at iinet.net.au Wed Jun 13 12:53:02 2007 From: dtimms at iinet.net.au (David Timms) Date: Wed, 13 Jun 2007 22:53:02 +1000 Subject: f7 images for mass production In-Reply-To: <200706090002.43553.opensource@till.name> References: <200706081522.54072.jkeating@redhat.com> <200706090002.43553.opensource@till.name> Message-ID: <466FE8AE.8040708@iinet.net.au> Till Maas wrote: > On Fr Juni 8 2007, Jesse Keating wrote: > >> I am extremely uncomfortable publishing anything that has only this level >> of QA. > > How about adding a copy of the updates repository in a new directory to the > DVD? This will not affect anything else but allows to install the security > updates without having internet access. Hmm, great minds think alike ;) We could also include an fedora-updates-local.repo that points to this folder (this should work for loop mounted dvd iso as well}. You wouldn't be able to run createrepo on the root of the dvd to make the repodata because it would find the updates folder. This way you would have the original as released {or only slightly modified as others have suggested - to suppress install bugs} iso content, and all main {ex-core} updates until make media time are included so that people with slow or no internet connections can get the normal install then update {once} experience. That would make it easier for others to make an updated {sort off} dvd media for distribution. You would get a version made like this, add any new updates {gftp |compare |retrieve} to the updates/packages folder, run createrepo on updates folder {or grab the repodata from the mirror}, and make disc. Sure there would be redundant info {the original version of updated packages}, but it would have to save a heap of QA. DaveT. From jkeating at redhat.com Wed Jun 13 13:18:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 09:18:36 -0400 Subject: pungi : double rpm packages in ISO image In-Reply-To: References: Message-ID: <200706130918.36709.jkeating@redhat.com> On Tuesday 12 June 2007 17:09:56 Vnpenguin wrote: > Hi, > I make a customized iso with pungi. In my config file for yum, I > defined both release & update repos. Logically, pungi will fetch only > latest version (update in this case) and build iso from only updated > packages. Hrm, this may be a case I haven't seen yet. Perhaps some changes to how we get the right multilib packages made it pull in doubles if it finds them. I will have to investigate today. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vnpenguin at vnoss.org Wed Jun 13 13:56:17 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 13 Jun 2007 15:56:17 +0200 Subject: pungi : double rpm packages in ISO image In-Reply-To: <200706130918.36709.jkeating@redhat.com> References: <200706130918.36709.jkeating@redhat.com> Message-ID: On 6/13/07, Jesse Keating wrote: > On Tuesday 12 June 2007 17:09:56 Vnpenguin wrote: > > Hi, > > I make a customized iso with pungi. In my config file for yum, I > > defined both release & update repos. Logically, pungi will fetch only > > latest version (update in this case) and build iso from only updated > > packages. > > Hrm, this may be a case I haven't seen yet. Perhaps some changes to how we > get the right multilib packages made it pull in doubles if it finds them. I > will have to investigate today. > Thanks Jesse :) I'm waiting for your solution. From veillard at redhat.com Wed Jun 13 14:11:56 2007 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 13 Jun 2007 10:11:56 -0400 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181735898.11346.48.camel@willson> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> Message-ID: <20070613141156.GC23140@redhat.com> On Wed, Jun 13, 2007 at 07:58:18AM -0400, Simo Sorce wrote: > On Tue, 2007-06-12 at 17:56 -0400, Daniel Veillard wrote: > > On Tue, Jun 12, 2007 at 01:35:34PM -0800, Jeff Spaleta wrote: > > > On 6/12/07, Christopher Blizzard wrote: > > > >PPC is the fastest canary in the cage, if you will. :) > > > > > > no its not... the builders are sooooo damn slow. I hate it... ppc > > > builders are such a tease. You see your package burn through x86 and > > > x86_64 and then boom it falls over and dies on ppc after everything > > > else has gone swimmingly. > > > > Ahum, consider yourself lucky, as a reminder we used to also build > > Core on ia64 and s390(x) :-) > > And that was good, IA64 caught some bugs for me as well that went > completely undetected for some mysterious reason on other architectures > but were fatal for them all. (Botched shared libraries) yeah yeah, and s390x pointed out a bug in libxml2 about some obscure aliasing problem. But in general going though that wasn't very fun. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From dwmw2 at infradead.org Wed Jun 13 14:20:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 13 Jun 2007 15:20:33 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <20070613141156.GC23140@redhat.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> <20070613141156.GC23140@redhat.com> Message-ID: <1181744433.25228.162.camel@pmac.infradead.org> On Wed, 2007-06-13 at 10:11 -0400, Daniel Veillard wrote: > yeah yeah, and s390x pointed out a bug in libxml2 about some obscure > aliasing problem. But in general going though that wasn't very fun. Yeah, finding bugs isn't fun. Let's never increase our test coverage. -- dwmw2 From halfline at gmail.com Wed Jun 13 15:12:08 2007 From: halfline at gmail.com (Ray Strode) Date: Wed, 13 Jun 2007 11:12:08 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <466E1409.2080505@semitekie.com> References: <466E1409.2080505@semitekie.com> Message-ID: <45abe7d80706130812i78b5291bnde065e6adc0a26e2@mail.gmail.com> Hi, > Now, when I go to rpm -Uvh the resulting rpm, I get "the installed > version is NEWER than this one". How in the world is this even possible? > So now, any packages I rebuild get marked as older than the binaries? I've filed a bug here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244057 to address this issue. I've put a little explanation on why it happens in the bug report, if your interested. For now, you can work around the probably by installing with --oldpackage (or --force) or by doing the ~/.rpmmacros trick mentioned else where in the thread. --Ray From blc at redhat.com Wed Jun 13 15:16:05 2007 From: blc at redhat.com (Brendan Conoboy) Date: Wed, 13 Jun 2007 09:16:05 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <466FB223.5020602@hhs.nl> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> Message-ID: <46700A35.5010902@redhat.com> Hans de Goede wrote: > Afaik when it comes to linux-glibc details its the only way, notice that > bootstrap=1 will be needed only once, but I though it would be good to > have configurable in the spec, becaue maybe oneday with a new binutils > /glibc it might be a good idea to redo from start. Without some gcc surgery, it is indeed the only way. This is what dwmw2 is trying to talk about and I am trying to artfully avoid :-) -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From kevin at scrye.com Wed Jun 13 16:06:53 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 13 Jun 2007 10:06:53 -0600 Subject: Could I give bug 180579 a prod? In-Reply-To: <39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> References: <39C2B4777DC0364FBBF4D8233402E6C70115DE0C@dpp-exch01-a.network.griffin.net.uk> <39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> Message-ID: <20070613100653.688acb2e@ghistelwchlohm.scrye.com> On Wed, 13 Jun 2007 11:03:07 +0100 david.craigon at griffin.com ("David Craigon") wrote: > > Really sorry about the HTML mail- many apologies. Here's what I said > for those who don't use HTML mail readers. > > > It's a bug about allowing an option for the postfix RPM to > built using postgresql. It's been stuck on NEEDINFO for ages, but > I've given the INFO NEEDED :-). I appreciate that this bug has a > minute audience, but I'm one of them- all that is needed is to merge > a patch supplied. See also the merge review I did for postfix: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226307 Where I also suggested we have a postfix-pgsql subpackage. It's also in NEEDINFO... for the maintainer. > Thanks, > David kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dhollis at davehollis.com Wed Jun 13 16:14:31 2007 From: dhollis at davehollis.com (David Hollis) Date: Wed, 13 Jun 2007 16:14:31 +0000 Subject: Could I give bug 180579 a prod? In-Reply-To: <39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> References: <39C2B4777DC0364FBBF4D8233402E6C70115DE0C@dpp-exch01-a.network.griffin.net.uk> <39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> Message-ID: <1181751271.3136.8.camel@dhollis-lnx.sunera.com> On Wed, 2007-06-13 at 11:03 +0100, David Craigon wrote: > Really sorry about the HTML mail- many apologies. Here's what I said for > those who don't use HTML mail readers. > > > It's a bug about allowing an option for the postfix RPM to built > using postgresql. It's been stuck on NEEDINFO for ages, but I've given > the INFO NEEDED :-). I appreciate that this bug has a minute audience, > but I'm one of them- all that is needed is to merge a patch supplied. > You may want to do as suggested in the bug and update the target version from 'fc4' to 'f7' so that it's a more 'current' bug. Looks like the patch to the spec to enable Postgres support still applies so there shouldn't be any big issues. -- David Hollis From rc040203 at freenet.de Wed Jun 13 16:21:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Jun 2007 18:21:46 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46700A35.5010902@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> Message-ID: <1181751707.2121.190.camel@mccallum.corsepiu.local> On Wed, 2007-06-13 at 09:16 -0600, Brendan Conoboy wrote: > Hans de Goede wrote: > > Afaik when it comes to linux-glibc details its the only way, notice that > > bootstrap=1 will be needed only once, but I though it would be good to > > have configurable in the spec, becaue maybe oneday with a new binutils > > /glibc it might be a good idea to redo from start. > > Without some gcc surgery, it is indeed the only way. This is what dwmw2 > is trying to talk about and I am trying to artfully avoid :-) Nah, wrt. to cross linux toolchains there are other ways. 1. If a native target distro exists, one can repackage the target's glibc binaries into a -sys-root rpm, and then build gcc against this glibc. It's what I do in my toolchain packages. Some people hate it because "I don't build everything from scratch", but it has tremendous advantages. 2. The approach dwmw2 seems to hate is the nominal way to build gcc (build a --with-newlib c-only gcc, use this to build glibc, then rebuild a full fledged gcc) 3. Build incrementally. All you need to is to once insert a glibc sys-root binary into the buildsystem (by "bootstrap" or 1. or 2.), then subsequently build gcc and glibc from source. Some people also hate this, but it's essentally the same approach as glibc and gcc are being built on Fedora. Ralf From devrim at CommandPrompt.com Wed Jun 13 16:28:32 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Wed, 13 Jun 2007 19:28:32 +0300 Subject: Anaconda crash for Turkish installation In-Reply-To: <1181737834.3673.24.camel@localhost.localdomain> References: <1181737834.3673.24.camel@localhost.localdomain> Message-ID: <1181752112.2878.9.camel@laptop.gunduz.org> Hi, On Wed, 2007-06-13 at 15:30 +0300, Baris Cicek wrote: > That problem existed in Fedora Core 6 as well. That bug was existed in F6, (I cannot remember the bug number now), which was fixed after FC-6 was released -- I am surprised that it still exists :( Regards, -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david.craigon at griffin.com Wed Jun 13 16:32:57 2007 From: david.craigon at griffin.com (David Craigon) Date: Wed, 13 Jun 2007 17:32:57 +0100 Subject: Could I give bug 180579 a prod? References: <39C2B4777DC0364FBBF4D8233402E6C70115DE0C@dpp-exch01-a.network.griffin.net.uk><39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> <1181751271.3136.8.camel@dhollis-lnx.sunera.com> Message-ID: <39C2B4777DC0364FBBF4D8233402E6C70113AC35@dpp-exch01-a.network.griffin.net.uk> As far as I can tell, I can't update the target version- only the submitter can do that. Or maybe I can't work Bugzilla? As for the other comment, I don't think it's possible to compile postfix in such a way that a postfix-mysql or postfix-pgsql package is possible- I think it is either compiled in or not, rather than having separate modules you could separate out. David > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of > David Hollis > Sent: 13 June 2007 17:15 > To: Development discussions related to Fedora Core > Subject: RE: Could I give bug 180579 a prod? > > On Wed, 2007-06-13 at 11:03 +0100, David Craigon wrote: > > Really sorry about the HTML mail- many apologies. Here's > what I said > > for those who don't use HTML mail readers. > > > > > > It's a bug about allowing an option for the postfix RPM > to built > > using postgresql. It's been stuck on NEEDINFO for ages, but > I've given > > the INFO NEEDED :-). I appreciate that this bug has a > minute audience, > > but I'm one of them- all that is needed is to merge a patch > supplied. > > > > You may want to do as suggested in the bug and update the > target version from 'fc4' to 'f7' so that it's a more > 'current' bug. Looks like the patch to the spec to enable > Postgres support still applies so there shouldn't be any big issues. > > -- > David Hollis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at theholbrooks.org Wed Jun 13 16:42:29 2007 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Wed, 13 Jun 2007 11:42:29 -0500 Subject: Unsigned package In-Reply-To: <200706110920.04931.jkeating@redhat.com> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706081013.22723.jkeating@redhat.com> <57943.65.192.24.190.1181567551.squirrel@mail.jcomserv.net> <200706110920.04931.jkeating@redhat.com> Message-ID: <46701E75.6040605@theholbrooks.org> Jesse Keating wrote: > On Monday 11 June 2007 09:12:31 Jon Ciesla wrote: > >> Still not working. >> > > I'm looking into why my sync request has not been completed yet. > > Any updates on this? I see scons and php-pear-Mail-Mime are still both unsigned on download.f.r.c. And just to clarify, as the Mail-Mime maintainer, this build was my first experiment with koji. Was there some error on my part? If a mirror sync is too troublesome, I don't mind bumping the release and rebuilding :) From ken at bitsko.slc.ut.us Wed Jun 13 15:55:49 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Wed, 13 Jun 2007 10:55:49 -0500 Subject: yum+mock patches for cross-compile and intro In-Reply-To: <645d17210706130334s473bb13bg1f69abeff720c24f@mail.gmail.com> (Jonathan Underwood's message of "Wed\, 13 Jun 2007 11\:34\:03 +0100") References: <645d17210706121628i3f50aaaclc325a9a15b4ec64@mail.gmail.com> <20070613004339.GA31917@redhat.com> <466F8AD0.60902@hhs.nl> <20070613112807.101fc839@python3.es.egwn.lan> <645d17210706130334s473bb13bg1f69abeff720c24f@mail.gmail.com> Message-ID: I've been working on adding support for cross-compiling to yum, mock, and up until now, plague. I only recently saw the new discussion on fedora-devel. I'm in the Fedora->XXXX group for now, I want to use Fedora infrastructure with other's cross-compilers and RPMs, then add our own. Upstream spec files would remain unchanged, I think we've only ever changed one outside of "taking over the kernel". Our internal coding guidelines require GNU auto-tools so our spec files are simple and shared for all cross tools and targets. Our primary cross targets are using Wind River and MontaVista Linux, ppc and x86, over multiple releases. We also use TimeSys as an up-to-date reference target (ie. TimeSys is our "Fedora") and native RHEL3, 4, and 5 targets (both our x86 Fedora->blades and internal systems). I'd like to use Koji/Bodhi/mash/pungi as our internal build system where we submit one of our packages and have it build for all targets and target releases, and we build release ISOs from all of those. I've posted my most recent snapshot patches to yum-devel and fedora-buildsys for reference but the yum patch is against CentOS4 yum 2.4.3 for our current RHEL4 build system and I haven't had a chance to update the mock patch to current CVS. It looks like we'll need to go to F7 to use the whole suite of tools, so look for updates to be against current revs. The mock patches include configs for and were tested with DENX ELDK so folks could use them without registering or needing evaluation licenses. https://lists.dulug.duke.edu/pipermail/yum-devel/2007-June/003849.html https://www.redhat.com/archives/fedora-buildsys-list/2007-June/msg00041.html I'm still re-reading the recent discussion before I add anything there. It looks like a key point was identifying the split between Fedora->Fedora and Fedora->XXXX. -- Ken From jkeating at redhat.com Wed Jun 13 17:11:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 13:11:07 -0400 Subject: Unsigned package In-Reply-To: <46701E75.6040605@theholbrooks.org> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706110920.04931.jkeating@redhat.com> <46701E75.6040605@theholbrooks.org> Message-ID: <200706131311.13201.jkeating@redhat.com> On Wednesday 13 June 2007 12:42:29 Brandon Holbrook wrote: > Any updates on this? ?I see scons and php-pear-Mail-Mime are still both > unsigned on download.f.r.c. ?And just to clarify, as the Mail-Mime > maintainer, this build was my first experiment with koji. ?Was there > some error on my part? ?If a mirror sync is too troublesome, I don't > mind bumping the release and rebuilding :) It wasn't your fault, just a tools and oversight issue on our part. The tree was supposed to be synced last night, looking into why it didn't happen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dhollis at davehollis.com Wed Jun 13 17:39:10 2007 From: dhollis at davehollis.com (David Hollis) Date: Wed, 13 Jun 2007 17:39:10 +0000 Subject: Could I give bug 180579 a prod? In-Reply-To: <39C2B4777DC0364FBBF4D8233402E6C70113AC35@dpp-exch01-a.network.griffin.net.uk> References: <39C2B4777DC0364FBBF4D8233402E6C70115DE0C@dpp-exch01-a.network.griffin.net.uk> <39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> <1181751271.3136.8.camel@dhollis-lnx.sunera.com> <39C2B4777DC0364FBBF4D8233402E6C70113AC35@dpp-exch01-a.network.griffin.net.uk> Message-ID: <1181756350.3136.12.camel@dhollis-lnx.sunera.com> On Wed, 2007-06-13 at 17:32 +0100, David Craigon wrote: > As far as I can tell, I can't update the target version- only the > submitter can do that. Or maybe I can't work Bugzilla? > > As for the other comment, I don't think it's possible to compile postfix > in such a way that a postfix-mysql or postfix-pgsql package is possible- > I think it is either compiled in or not, rather than having separate > modules you could separate out. > I agree. I think the only way you could do something like that would be to do what the snort/snort-mysql/snort-postgresql packages do and make use of alternatives to swap the various postfix binaries in & out for which one you want. It would really be a pain, and I doubt it would be worth much to do it. I'm personally OK with the package not being built by default with MySQL or PostgreSQL support, but having it easily built-in locally. Otherwise, it does bring in a lot of dependencies that folks probably wouldn't want. > David > > > -----Original Message----- > > From: fedora-devel-list-bounces at redhat.com > > [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of > > David Hollis > > Sent: 13 June 2007 17:15 > > To: Development discussions related to Fedora Core > > Subject: RE: Could I give bug 180579 a prod? > > > > On Wed, 2007-06-13 at 11:03 +0100, David Craigon wrote: > > > Really sorry about the HTML mail- many apologies. Here's > > what I said > > > for those who don't use HTML mail readers. > > > > > > > > > It's a bug about allowing an option for the postfix RPM > > to built > > > using postgresql. It's been stuck on NEEDINFO for ages, but > > I've given > > > the INFO NEEDED :-). I appreciate that this bug has a > > minute audience, > > > but I'm one of them- all that is needed is to merge a patch > > supplied. > > > > > > > You may want to do as suggested in the bug and update the > > target version from 'fc4' to 'f7' so that it's a more > > 'current' bug. Looks like the patch to the spec to enable > > Postgres support still applies so there shouldn't be any big issues. > > > > -- > > David Hollis > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- David Hollis From kevin.kofler at chello.at Wed Jun 13 18:42:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 Jun 2007 18:42:07 +0000 (UTC) Subject: Could I give bug 180579 a prod? References: <39C2B4777DC0364FBBF4D8233402E6C70115DE0C@dpp-exch01-a.network.griffin.net.uk><39C2B4777DC0364FBBF4D8233402E6C70113ABC6@dpp-exch01-a.network.griffin.net.uk> <1181751271.3136.8.camel@dhollis-lnx.sunera.com> <39C2B4777DC0364FBBF4D8233402E6C70113AC35@dpp-exch01-a.network.griffin.net.uk> Message-ID: David Craigon griffin.com> writes: > As far as I can tell, I can't update the target version- only the > submitter can do that. Or maybe I can't work Bugzilla? Any Fedora contributor can, too. I just did it for you. Kevin Kofler From bpepple at fedoraproject.org Wed Jun 13 18:48:10 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 13 Jun 2007 14:48:10 -0400 Subject: Plan for tomorrows (20070614) FESCO meeting Message-ID: <1181760490.2802.3.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- Upgrade path enforcement https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01603.html - f13 /topic FESCO-Meeting -- MISC -- Secondary Arches - spot /topic FESCO-Meeting -- MISC -- Owner to write up some docs of our brave new world. - jeremy /topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Wed Jun 13 19:18:42 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 13 Jun 2007 15:18:42 -0400 Subject: Fedora-Devel-Announce is Now Open Message-ID: <46704312.7080705@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-devel-announce fedora-devel-announce list is now open. The goal of this list is to make it easy for Fedora contributors to follow changes in that may be pertinent to developers within the Fedora Project. This is intended to be a LOW TRAFFIC announce-only list of development topics, so we hope subscribers wont feel the need to filter it away from their Inbox. Acceptable Types of Announcements ================================= * Policy or process changes that affect developers. * Infrastructure changes that affect developers. * Tools changes that affect developers. * Schedule changes * Freeze reminders Unacceptable Types of Announcements =================================== * Periodic automated reports (violates the INFREQUENT rule) * Discussion * Anything else not mentioned above Some List Details ================= * fedora-devel-announce is OPTIONAL for project contributors, although highly recommended. * In the future we will auto-subscribe new members who achieve sponsored packager status to this list. They may choose to unsubscribe themselves thereafter. * All announcements here will also be delivered to fedora-devel-list. So if you follow fedora-devel-list religiously you don't need to subscribe to fedora-devel-announce. * Replies on fedora-devel-announce go to fedora-devel-list. fedora-devel-list allows posting only to subscribed members. If you want to post but are not subscribed, you must subscribe then turn off mail delivery in the list's web interface. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dgboles at gmail.com Wed Jun 13 20:08:53 2007 From: dgboles at gmail.com (David Boles) Date: Wed, 13 Jun 2007 13:08:53 -0700 Subject: system-config-selinux Message-ID: <46704ED5.5000809@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 /usr/bin/system-config-selinux crashes in development (Rawhide) and is not listed in Bugzilla. To what package should I report this? - -- David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGcE7VAO0wNI1X4QERAjs4AJwJN6p/3MS0xsAThaD7E727J4EwsgCeJbO/ pnM0KUw9ZYRGlGaBN9vbFfc= =A717 -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Wed Jun 13 20:11:46 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 13 Jun 2007 16:11:46 -0400 Subject: system-config-selinux In-Reply-To: <46704ED5.5000809@gmail.com> References: <46704ED5.5000809@gmail.com> Message-ID: <1181765506.17547.522.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2007-06-13 at 13:08 -0700, David Boles wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > /usr/bin/system-config-selinux crashes in development (Rawhide) and is not > listed in Bugzilla. > > To what package should I report this? policycoreutils rpm -q /usr/bin/system-config-selinux -- Stephen Smalley National Security Agency From mschwendt.tmp0701.nospam at arcor.de Wed Jun 13 20:14:07 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 13 Jun 2007 22:14:07 +0200 Subject: system-config-selinux In-Reply-To: <46704ED5.5000809@gmail.com> References: <46704ED5.5000809@gmail.com> Message-ID: <20070613221407.f1d3c111.mschwendt.tmp0701.nospam@arcor.de> On Wed, 13 Jun 2007 13:08:53 -0700, David Boles wrote: > /usr/bin/system-config-selinux crashes in development (Rawhide) and is not > listed in Bugzilla. > > To what package should I report this? Its source rpm => policycoreutils $ rpm -qf /usr/bin/system-config-selinux policycoreutils-gui-2.0.16-2.fc7 $ rpm -qi policycoreutils-gui|grep Sourc Group : System Environment/Base Source RPM: policycoreutils-2.0.16-2.fc7.src.rpm From dwalsh at redhat.com Wed Jun 13 20:25:02 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 13 Jun 2007 16:25:02 -0400 Subject: system-config-selinux In-Reply-To: <1181765506.17547.522.camel@moss-spartans.epoch.ncsc.mil> References: <46704ED5.5000809@gmail.com> <1181765506.17547.522.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4670529E.10102@redhat.com> Stephen Smalley wrote: > On Wed, 2007-06-13 at 13:08 -0700, David Boles wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> /usr/bin/system-config-selinux crashes in development (Rawhide) and is not >> listed in Bugzilla. >> >> To what package should I report this? >> > > policycoreutils > > rpm -q /usr/bin/system-config-selinux > > rpm -qf /usr/bin/system-config-selinux policycoreutils-gui-2.0.20-1.fc8 I am working on it now. From dgboles at gmail.com Wed Jun 13 20:34:24 2007 From: dgboles at gmail.com (David Boles) Date: Wed, 13 Jun 2007 13:34:24 -0700 Subject: system-config-selinux In-Reply-To: <1181765506.17547.522.camel@moss-spartans.epoch.ncsc.mil> References: <46704ED5.5000809@gmail.com> <1181765506.17547.522.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <467054D0.9060808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Wed, 2007-06-13 at 13:08 -0700, David Boles wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> /usr/bin/system-config-selinux crashes in development (Rawhide) and is not >> listed in Bugzilla. >> >> To what package should I report this? > > policycoreutils > > rpm -q /usr/bin/system-config-selinux > Thank you. Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244107 - -- David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGcFTPAO0wNI1X4QERArnFAKCoV5vH2Ya1NqWA60qoP8bEHZxUKQCfS/Fr KDE3u03D1gj3PMDcU+uR+G8= =0u6f -----END PGP SIGNATURE----- From dtimms at iinet.net.au Wed Jun 13 20:58:48 2007 From: dtimms at iinet.net.au (David Timms) Date: Thu, 14 Jun 2007 06:58:48 +1000 Subject: F8devel - UI "responsiveness" improvements Message-ID: <46705A88.9000207@iinet.net.au> I'd like to suggest a goal for future Fedora of ensuring every application / task performed with Fedora actually provides user feedback at a minimum 1 {one} second interval. Culprits: - anaconda between go-ahead with install and first package installing {especially noticeable because the {boring} X screen saver kicks in. You then move the mouse to get the screen back - but there is no update to the screen for maybe one minute or more. - pup during an update run with about 30-40 packages. It took nearly an hour. Each time an app covered its windows they may not have been redrawn for some minutes. I have no idea what causes these. DaveT. From dtimms at iinet.net.au Wed Jun 13 21:10:39 2007 From: dtimms at iinet.net.au (David Timms) Date: Thu, 14 Jun 2007 07:10:39 +1000 Subject: F8devel - user configuration storage locations Message-ID: <46705D4F.10307@iinet.net.au> A potential goal for Fedora: Cleanup user settings configuration For a long time applications creates a {hidden} .mysetting file in the user's home directory, if multiple config/settings under a .myapp/.various files. I think this should be tidied up by creating a single directory at the users home folder to store all setting/configs that apps make. - The folder should not be hidden. - It should have a default text file indicating that it contains hidden files that store settings for installed applications. - It should be well named: configuration | config | application_config ? - All packages to use this folder I see some problems: - breaks FHStandard ? - every app would need to have a one time adjustment and package rebuilt ? Some advantages: - not mixing user data folders and application config in the same top level {user home} folder. - less files to read / show / search when apps ask for the home dir file list - easily move/copy all user configs to backup or a different machine DaveT. From kevin.kofler at chello.at Wed Jun 13 21:23:01 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 13 Jun 2007 21:23:01 +0000 (UTC) Subject: F8devel - user configuration storage locations References: <46705D4F.10307@iinet.net.au> Message-ID: David Timms iinet.net.au> writes: > I think this should be tidied up by creating a single directory at the > users home folder to store all setting/configs that apps make. You mean like .kde? :-) KDE apps already store their settings in a common ~/.kde/share/config directory. But unfortunately I think hell will freeze over before GNOME apps start saving their settings there. ;-) Kevin Kofler From blc at redhat.com Wed Jun 13 21:46:10 2007 From: blc at redhat.com (Brendan Conoboy) Date: Wed, 13 Jun 2007 15:46:10 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181751707.2121.190.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> Message-ID: <467065A2.9020305@redhat.com> Ralf Corsepius wrote: > Nah, wrt. to cross linux toolchains there are other ways. Well, if you want to be pedantic, sure. To be more precise, it is, at present, the only way to get from nothing but sources to having fully functional binaries. If you already have binaries that's another matter. > 1. If a native target distro exists, one can repackage the target's > glibc binaries into a -sys-root rpm, and then build gcc against > this glibc. It's what I do in my toolchain packages. Some people hate it > because "I don't build everything from scratch", but it has tremendous > advantages. You can, but you end up with binaries for one arch inside an rpm designated for another. I'm hoping to take this to the point where you can bring in rpms from one arch to cross build another another. This makes a mismatched target-sys-root rpm very undesirable as it's going in the wrong direction. The target sys-root should be provided by the build system for use by the the cross compiler. > 3. Build incrementally. All you need to is to once insert a glibc > sys-root binary into the buildsystem (by "bootstrap" or 1. or 2.), then > subsequently build gcc and glibc from source. > Some people also hate this, but it's essentally the same approach as > glibc and gcc are being built on Fedora. I think of this as The Fedora Way (tm). After discussing with dwmw2 some more, there are still some drawbacks wrt gcc for my own goals: We actually want to produce gcc support libraries for the target in an rpm for the target arch. If there is indeed a strong resistance to having rpm emit multiple arches from a single build, two builds are required (One to make the cross compiler, another to make the target libraries perhaps in the form a cross compiled cross compiler:-). Though not insurmountable, it does mean duplicate copies of the target libraries- one for the host to use, one for the native. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Wed Jun 13 21:59:47 2007 From: blc at redhat.com (Brendan Conoboy) Date: Wed, 13 Jun 2007 15:59:47 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181662311.25228.42.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> Message-ID: <467068D3.2060808@redhat.com> David Woodhouse wrote: > Do we _actually_ need to build parts of glibc? Could we not get away > with a fake DSO which just provides the few symbols libgcc uses? You can do that, but it's a bad idea. Since glibc is a moving target, libgcc's configurey might not turn on something that is valid because it can't detect the support for it. That's why we have the two stage process to begin with. > Or do we even need to build the dynamic libgcc _with_ the compiler at > all? Need? Depends on what you're willing to put into it... > Actually it happens for me every time I build a cross-compiler. > But perhaps it doesn't _need_ to; you're right. What if you're not building from scratch- instead building iteratively? What if it's in Fedora so you aren't building one in the first place? > That's a very good place to start. Especially if you realise that it > doesn't _really_ restrict us to 'existing architectures' -- it restricts > us to those architectures for which we can cobble together 'native' > packages for gcc, etc. Which is actually not much of a restriction at > all. Yep, seems like an excellent starting point. Especially while gcc is being disentangled. > That would be an interesting answer, yes. It only solves the _build_ > part of the problem though. The packaging side remains -- you'll want to > end up a cross-compiler package for the host arch, but libgcc etc. for > the target. > > RPM doesn't currently let you spit out even .noarch.rpm and $ARCH.rpm > simultaneously -- to build both i686-linux-gnu-gcc-$V-$R.ppc.rpm and > libgcc-$V-$R.i386.rpm you'll almost certainly need a separate rpmbuild > run _anyway_. So how will we handle that? Cross compile the native compiler. You need one anyway. All the resulting packages are target arch. Your cross compiler can then depend on the native compiler's libgcc rpm for the next iteration. > I think we need to accelerate [splitting gcc libs] rather than waiting for it. The wait might be so long. Libgcc is a subdiectory of gcc in upstream development (to be 4.3). -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From davej at redhat.com Wed Jun 13 22:20:52 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Jun 2007 18:20:52 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <20070613120101.GA18901@devserv.devel.redhat.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> <466EE5E8.5010407@redhat.com> <1181702518.28872.28.camel@localhost> <20070613034103.GA11946@redhat.com> <1181708445.28872.47.camel@localhost> <20070613120101.GA18901@devserv.devel.redhat.com> Message-ID: <20070613222052.GA21176@redhat.com> On Wed, Jun 13, 2007 at 08:01:01AM -0400, Alan Cox wrote: > On Tue, Jun 12, 2007 at 11:20:45PM -0500, Callum Lerwick wrote: > > I thought Core is a revival of the PIII core. At any rate, "generic" is > > an -mtune option only, so alone it will not use cmovs anyway because > > they're not supported earlier that i686. > > Jakub posted a recpie some time ago to get everything 686 but without the > cmov instruction gcc otherwise erroneously issues. IMHO it would be nice > to switch Fedora to using "i686 without cmov" for all the .686 packages > and kernel and get rid of the extra cases if we can For the kernel, that is the plan for F8. Then we can stop shipping a 586 kernel completely. Only thing holding me back right now is finding enough ancient bits to put my old 586's back together :-) Dave -- http://www.codemonkey.org.uk From alan at redhat.com Wed Jun 13 22:34:24 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 13 Jun 2007 18:34:24 -0400 Subject: Rebuilding RPMs results in bad update behavior In-Reply-To: <20070613222052.GA21176@redhat.com> References: <466E1409.2080505@semitekie.com> <20070612041105.GA4244@jadzia.bu.edu> <466E2B65.9000509@semitekie.com> <466EE5E8.5010407@redhat.com> <1181702518.28872.28.camel@localhost> <20070613034103.GA11946@redhat.com> <1181708445.28872.47.camel@localhost> <20070613120101.GA18901@devserv.devel.redhat.com> <20070613222052.GA21176@redhat.com> Message-ID: <20070613223424.GA24590@devserv.devel.redhat.com> On Wed, Jun 13, 2007 at 06:20:52PM -0400, Dave Jones wrote: > For the kernel, that is the plan for F8. Then we can stop shipping > a 586 kernel completely. Only thing holding me back right now is > finding enough ancient bits to put my old 586's back together :-) Tssh. My mailhost is a C3 (well its an S/390 emulator running as a chrooted nobody user on a C3), firewall a C3, and some test bits here so I can run tests for VIA compatibility for you without any messing around needed From dwmw2 at infradead.org Wed Jun 13 22:42:15 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 13 Jun 2007 23:42:15 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <467068D3.2060808@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <467068D3.2060808@redhat.com> Message-ID: <1181774536.5211.21.camel@shinybook.infradead.org> On Wed, 2007-06-13 at 15:59 -0600, Brendan Conoboy wrote: > David Woodhouse wrote: > > Do we _actually_ need to build parts of glibc? Could we not get away > > with a fake DSO which just provides the few symbols libgcc uses? > > You can do that, but it's a bad idea. Since glibc is a moving target, > libgcc's configurey might not turn on something that is valid because it > can't detect the support for it. That's why we have the two stage > process to begin with. You're speaking of the things which libgcc requires from glibc. That really is a _minimal_ set of functions. Is there _anything_ it actually tries to automatically detect -- _anything_ which might be turned off in libgcc because autocrap thinks glibc won't support it? > > Or do we even need to build the dynamic libgcc _with_ the compiler at > > all? > > Need? Depends on what you're willing to put into it... Que? > > Actually it happens for me every time I build a cross-compiler. > > But perhaps it doesn't _need_ to; you're right. > > What if you're not building from scratch- instead building iteratively? > What if it's in Fedora so you aren't building one in the first place? Heh, the latter would be nice :) > Cross compile the native compiler. You need one anyway. All the > resulting packages are target arch. Your cross compiler can then depend > on the native compiler's libgcc rpm for the next iteration. That works, if we can get the build system issues sorted out. RPM doesn't currently even handle arch-specific dependencies, let alone "I need foo.i386 and I need it in a /usr/i386-linux-gnu chroot" :) And since you're using the native packages in the sysroot, your cross-compiler package doesn't even need to bother building the shared libraries. -- dwmw2 From andy at warmcat.com Wed Jun 13 22:53:53 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 13 Jun 2007 23:53:53 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <1181774536.5211.21.camel@shinybook.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <467068D3.2060808@redhat.com> <1181774536.5211.21.camel@shinybook.infradead.org> Message-ID: <46707581.3010003@warmcat.com> David Woodhouse wrote: > That works, if we can get the build system issues sorted out. RPM > doesn't currently even handle arch-specific dependencies, let alone > "I need foo.i386 and I need it in a /usr/i386-linux-gnu chroot" :) Well it does "work" to do rpm --root=/usr/i386-linux-gnu --ignorearch -i foo (although last time I looked I didn't yet find a way to set dbpath on Fedora rpm that worked). If "handling it" in separate chroot worlds is good enough it shows a way forward though, presumably if yum can eat --root= it too will play along nicely in each chroot world. -Andy From dgboles at gmail.com Wed Jun 13 21:28:09 2007 From: dgboles at gmail.com (David Boles) Date: Wed, 13 Jun 2007 14:28:09 -0700 Subject: F8devel - user configuration storage locations In-Reply-To: References: <46705D4F.10307@iinet.net.au> Message-ID: <46706169.1030902@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Kofler wrote: > David Timms iinet.net.au> writes: >> I think this should be tidied up by creating a single directory at the >> users home folder to store all setting/configs that apps make. > > You mean like .kde? :-) KDE apps already store their settings in a common > ~/.kde/share/config directory. But unfortunately I think hell will freeze over > before GNOME apps start saving their settings there. ;-) > > Kevin Kofler Why in the world would GNOME apps save their settings in .kde? Or want to do that? - -- David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGcGFprItTyWRhT1YRAg9YAJ9lyjYMWbJ9ritVPnw4rU9BB2pB5QCgq9BP lLmmZmqKswAIVodpoTyihOU= =mSVi -----END PGP SIGNATURE----- From pemboa at gmail.com Wed Jun 13 23:46:51 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 13 Jun 2007 18:46:51 -0500 Subject: F8devel - user configuration storage locations In-Reply-To: <46705D4F.10307@iinet.net.au> References: <46705D4F.10307@iinet.net.au> Message-ID: <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> On 6/13/07, David Timms wrote: > A potential goal for Fedora: > Cleanup user settings configuration > > For a long time applications creates a {hidden} .mysetting file in the > user's home directory, if multiple config/settings under a > .myapp/.various files. I would hate this > I think this should be tidied up by creating a single directory at the > users home folder to store all setting/configs that apps make. > - The folder should not be hidden. I would hate this even more > - It should have a default text file indicating that it contains hidden > files that store settings for installed applications. why? > - It should be well named: configuration | config | application_config ? seems unnecessary > - All packages to use this folder good luck with that > I see some problems: > - breaks FHStandard ? > - every app would need to have a one time adjustment and package rebuilt ? You make that sound trivial > Some advantages: > - not mixing user data folders and application config in the same top > level {user home} folder. I guess that's based on your point of view. These are user specific configurations, which I consider to be part of my user data > - less files to read / show / search when apps ask for the home dir file > list I'm sorry if Gnome's dialog shows you everything by default, but some of us use KDE, and it doesn't do that, so that's a non-issue > - easily move/copy all user configs to backup or a different machine cp -a ~/.* > DaveT. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Fedora Core 6 and proud From sberry at northlc.com Wed Jun 13 23:53:16 2007 From: sberry at northlc.com (Scott Berry) Date: Wed, 13 Jun 2007 18:53:16 -0500 Subject: F8devel - UI "responsiveness" improvements In-Reply-To: <46705A88.9000207@iinet.net.au> References: <46705A88.9000207@iinet.net.au> Message-ID: <01ec01c7ae16$07b27d40$6701a8c0@yellobow> I would also like to ask for a progress bar so when the packages begin to install that it shows the percentage of each package being done. This way if you're a newbie or oldie you will know for almost certain that the packages are not the culprit of stopping the install. My instance on Fc7 was this: I had installed Office Productivity, Software Development, Web Server when it got to package 817 which was Open Office it just hung but we didn't know what it was doing so I just let it sit for a couple of hours when it didn't go any further I did a reinstall took out Office Productivity and it worked like a champ and I just did a yum install for the packages I was missing. Scott -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of David Timms Sent: Wednesday, June 13, 2007 3:59 PM To: fedora-devel-list at redhat.com Subject: F8devel - UI "responsiveness" improvements I'd like to suggest a goal for future Fedora of ensuring every application / task performed with Fedora actually provides user feedback at a minimum 1 {one} second interval. Culprits: - anaconda between go-ahead with install and first package installing {especially noticeable because the {boring} X screen saver kicks in. You then move the mouse to get the screen back - but there is no update to the screen for maybe one minute or more. - pup during an update run with about 30-40 packages. It took nearly an hour. Each time an app covered its windows they may not have been redrawn for some minutes. I have no idea what causes these. DaveT. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.15/847 - Release Date: 6/12/2007 9:42 PM From sean.stangl at gmail.com Thu Jun 14 00:03:50 2007 From: sean.stangl at gmail.com (Sean Stangl) Date: Wed, 13 Jun 2007 20:03:50 -0400 Subject: F8devel - user configuration storage locations In-Reply-To: <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> Message-ID: <1181779430.3696.7.camel@moogle> On Wed, 2007-06-13 at 18:46 -0500, Arthur Pemberton wrote: > I'm sorry if Gnome's dialog shows you everything by default, but some > of us use KDE, and it doesn't do that, so that's a non-issue Nautilus does not show hidden files by default. Unknowledgeable users are therefore not bothered by the existence of hidden files and folders, as the files' existence is never made known unless explicitly requested. There is nothing gained by following the OP's suggestion and patching all packages to use a different configuration root. We would wind up: 1) wasting a tremendous amount of time patching every package, 2) breaking compatibility with other Linux distributions, thereby increasing the amount of support we'd have to provide to migrating users, 3) making the presence of hidden configuration files shown by default, which actually ends up... 4) creating even more clutter than we have now. If it ain't broke, don't go fixin' it. Our time can be better spent. -Sean From bernie at codewiz.org Thu Jun 14 00:47:59 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Wed, 13 Jun 2007 20:47:59 -0400 Subject: Reply-To header munging for fedora-devel-list@ In-Reply-To: <1181279317.9479.3.camel@pensja.lam.pl> References: <46689424.5030009@codewiz.org> <1181259247.20322.20.camel@shinybook.infradead.org> <200706071931.36736.jkeating@redhat.com> <1181274265.24214.3.camel@scrappy.miketc.com> <4668DC91.6060403@codewiz.org> <1181279317.9479.3.camel@pensja.lam.pl> Message-ID: <4670903F.1000304@codewiz.org> Leszek Matok wrote: > Dnia 08-06-2007, pi? o godzinie 00:35 -0400, Bernardo Innocenti > napisa?(a): >> Mike Chambers wrote: >>> On Thu, 2007-06-07 at 19:31 -0400, Jesse Keating wrote: >>>> On Thursday 07 June 2007 19:34:07 David Woodhouse wrote: >>>>> Yes, reply-to munging is a very bad idea. It would be nice to turn it >>>>> off. >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> I think Warren is listed as the Admin if that helps get it done, or >>> mentioned anyway. >> Added to Cc. > The same, done better. Ping? -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From pemboa at gmail.com Thu Jun 14 01:49:47 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 13 Jun 2007 20:49:47 -0500 Subject: F8devel - user configuration storage locations In-Reply-To: <1181779430.3696.7.camel@moogle> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <1181779430.3696.7.camel@moogle> Message-ID: <16de708d0706131849r3dd55877wf1c66bd65bbdabf0@mail.gmail.com> On 6/13/07, Sean Stangl wrote: > On Wed, 2007-06-13 at 18:46 -0500, Arthur Pemberton wrote: > > I'm sorry if Gnome's dialog shows you everything by default, but some > > of us use KDE, and it doesn't do that, so that's a non-issue > > Nautilus does not show hidden files by default. Unknowledgeable users > are therefore not bothered by the existence of hidden files and folders, > as the files' existence is never made known unless explicitly requested. Firefox shows hidden files by default as far as I've noticed. -- Fedora Core 6 and proud From rc040203 at freenet.de Thu Jun 14 03:05:48 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 Jun 2007 05:05:48 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <467065A2.9020305@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> Message-ID: <1181790349.2121.210.camel@mccallum.corsepiu.local> On Wed, 2007-06-13 at 15:46 -0600, Brendan Conoboy wrote: > Ralf Corsepius wrote: > > Nah, wrt. to cross linux toolchains there are other ways. > > Well, if you want to be pedantic, sure. To be more precise, it is, at > present, the only way to get from nothing but sources to having fully > functional binaries. If you already have binaries that's another matter. > > > 1. If a native target distro exists, one can repackage the target's > > glibc binaries into a -sys-root rpm, and then build gcc against > > this glibc. It's what I do in my toolchain packages. Some people hate it > > because "I don't build everything from scratch", but it has tremendous > > advantages. > > You can, but you end up with binaries for one arch inside an rpm > designated for another. Not quite. You end up with the target's sys-root's files ("target binaries", blobs of arbitrary binary data) inside of a "noarch" rpm. > I'm hoping to take this to the point where you > can bring in rpms from one arch to cross build another another. You can. sys-root packages aiming at cross-compilers are "noarch" rpms to the host. > > 3. Build incrementally. All you need to is to once insert a glibc > > sys-root binary into the buildsystem (by "bootstrap" or 1. or 2.), then > > subsequently build gcc and glibc from source. > > Some people also hate this, but it's essentally the same approach as > > glibc and gcc are being built on Fedora. > > I think of this as The Fedora Way (tm). Right, this way should be applicable for Fedora->Fedora toolchains. However, it is more generally applicable. > After discussing with dwmw2 > some more, there are still some drawbacks wrt gcc for my own goals: We > actually want to produce gcc support libraries for the target in an rpm > for the target arch. Well, IMO this plan is not useful and doesn't fit into the working principles of rpm, because it confuses host architecture with target architecture. What I could envision to be made functional is a wrapper around rpm, using another "per-cross-target" rpmdb to add native target rpms into sys-roots. Ralf From andy at smile.org.ua Thu Jun 14 04:56:07 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Thu, 14 Jun 2007 07:56:07 +0300 Subject: F8devel - user configuration storage locations In-Reply-To: <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> Message-ID: <20070614045607.GA17173@serv.smile.org.ua> Hi Arthur Pemberton! On Wed, Jun 13, 2007 at 06:46:51PM -0500, Arthur Pemberton wrote next: > > I think this should be tidied up by creating a single directory at the > > users home folder to store all setting/configs that apps make. > > - The folder should not be hidden. > > I would hate this even more +1 > > - easily move/copy all user configs to backup or a different machine > cp -a ~/.* Not simple. If you do that you'll try to copy over the parent tree due to '..' (that is satisfy your code) represents parent and '.' represents current folder. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From mcepl at redhat.com Thu Jun 14 08:12:00 2007 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 14 Jun 2007 10:12:00 +0200 Subject: F8devel - user configuration storage locations References: <46705D4F.10307@iinet.net.au> Message-ID: On Thu, 14 Jun 2007 07:10:39 +1000, David Timms scripst: > I think this should be tidied up by creating a single directory at the > users home folder to store all setting/configs that apps make. - The > folder should not be hidden. > - It should have a default text file indicating that it contains hidden > files that store settings for installed applications. - It should be > well named: configuration | config | application_config ? - All packages > to use this folder > > I see some problems: > - breaks FHStandard ? > - every app would need to have a one time adjustment and package rebuilt > ? > > Some advantages: > - not mixing user data folders and application config in the same top > level {user home} folder. > - less files to read / show / search when apps ask for the home dir file > list > - easily move/copy all user configs to backup or a different machine Ehm, before suggesting something, it would be wise to make a little research. Maybe you would find http://standards.freedesktop.org/basedir- spec/latest/ and related other standards on http://www.freedesktop.org/ wiki/Specifications/ . Matej From dwmw2 at infradead.org Thu Jun 14 08:40:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 14 Jun 2007 09:40:38 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <46707581.3010003@warmcat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <467068D3.2060808@redhat.com> <1181774536.5211.21.camel@shinybook.infradead.org> <46707581.3010003@warmcat.com> Message-ID: <1181810438.25228.204.camel@pmac.infradead.org> On Wed, 2007-06-13 at 23:53 +0100, Andy Green wrote: > > Well it does "work" to do rpm --root=/usr/i386-linux-gnu --ignorearch -i > foo (although last time I looked I didn't yet find a way to set dbpath > on Fedora rpm that worked). If "handling it" in separate chroot worlds > is good enough it shows a way forward though, presumably if yum can eat > --root= it too will play along nicely in each chroot world. Yeah, it's not impossible. Then we just need to let koji/mock know that it must do this when building a cross-compiler... -- dwmw2 From z.kota at gmx.net Thu Jun 14 08:48:34 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Thu, 14 Jun 2007 10:48:34 +0200 (CEST) Subject: rawhide install Message-ID: Hi, How can I install rawhide? Only by enabling development repo in yum after installing F(stable)? I tried to use boot.iso from development but I couldn't manage. Zoltan From sundaram at fedoraproject.org Thu Jun 14 09:02:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 Jun 2007 14:32:58 +0530 Subject: rawhide install In-Reply-To: References: Message-ID: <46710442.8040708@fedoraproject.org> Zoltan Kota wrote: > Hi, > > How can I install rawhide? Only by enabling development repo in yum after > installing F(stable)? I tried to use boot.iso from development but I > couldn't manage. > Not enough details in here to help. Where did you download the boot.iso image from? What exactly happened? Rahul From debarshi.ray at gmail.com Thu Jun 14 09:06:59 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 14 Jun 2007 14:36:59 +0530 Subject: rawhide install In-Reply-To: References: Message-ID: <3170f42f0706140206q9e91bb9gfd7010c7bf9ac68a@mail.gmail.com> > How can I install rawhide? Only by enabling development repo in yum after > installing F(stable)? And then do a: # yum update ... Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From atkac at redhat.com Thu Jun 14 09:20:06 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 14 Jun 2007 11:20:06 +0200 Subject: rawhide install In-Reply-To: References: Message-ID: <46710846.2030902@redhat.com> Zoltan Kota napsal(a): > Hi, > > How can I install rawhide? Only by enabling development repo in yum after > installing F(stable)? I tried to use boot.iso from development but I > couldn't manage. > > Zoltan > > Rawhide anaconda is sometimes broken so I prefer this method: 1. remove fedora-release and fedora-release-notes 2. install rawhide's fedora-release and fedora-release-notes 3. yum update A From z.kota at gmx.net Thu Jun 14 09:41:10 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Thu, 14 Jun 2007 11:41:10 +0200 (CEST) Subject: rawhide install In-Reply-To: <46710442.8040708@fedoraproject.org> References: <46710442.8040708@fedoraproject.org> Message-ID: On Thu, 14 Jun 2007, Rahul Sundaram wrote: > > How can I install rawhide? Only by enabling development repo in yum after > > installing F(stable)? I tried to use boot.iso from development but I > > couldn't manage. > > > > Not enough details in here to help. Where did you download the boot.iso > image from? What exactly happened? boot.iso was downloaded from ftp://sunsite.mff.cuni.cz/MIRRORS/fedora.redhat.com/linux/development/i386/os/images After setting ftp site and directory for the installation it says: Unable to retrieve .../images/stage2.img Zoltan From buildsys at redhat.com Thu Jun 14 10:03:28 2007 From: buildsys at redhat.com (Build System) Date: Thu, 14 Jun 2007 06:03:28 -0400 Subject: rawhide report: 20070614 changes Message-ID: <200706141003.l5EA3Sl1004129@porkchop.devel.redhat.com> New package freetds Implementation of the TDS (Tabular DataStream) protocol New package gengetopt Tool to write command line option parsing code for C programs New package python-gammu Python bindings for Gammu Updated Packages: arpwatch-14:2.1a15-5.fc8 ------------------------ * Wed Jun 13 2007 Miroslav Lichvar 14:2.1a15-5 - update ethercodes.dat coreutils-6.9-3.fc8 ------------------- * Wed Jun 13 2007 Tim Waugh 6.9-3 - Fixed 'ls -x' output (bug #240298). - Disambiguate futimens() from the glibc implementation (bug #242321). cryptsetup-luks-1.0.5-1.fc8 --------------------------- * Wed Jun 13 2007 Jeremy Katz - 1.0.5-1 - update to 1.0.5 crystal-1.0.4-1.fc8 ------------------- * Wed Apr 25 2007 Chitlesh Goorah - 1.0.4-1 - New upstream release 1.0.4 cups-1:1.2.11-1.fc8 ------------------- * Wed Jun 13 2007 Tim Waugh 1:1.2.11-1 - 1.2.11. * Tue Jun 12 2007 Tim Waugh - Make the initscript use start priority 56 (bug #213828). - Better paper-out detection patch (bug #241589). * Wed May 09 2007 Tim Waugh 1:1.2.10-10 * Revert paper-out detection for the moment. curry-0.9.11-2.fc8 ------------------ * Wed Jun 13 2007 Gerard Milmeister - 0.9.11-2 - exclude arch ppc64 (#239713) * Tue Jun 12 2007 Gerard Milmeister - 0.9.11-1 - new version 0.9.11 fwbackups-1.43.0-0.2.rc2.fc7 ---------------------------- * Fri Jun 08 2007 Stewart Adam 1.43.0-0.2.rc2 - Bump sp that FC-6 > F-7 works * Fri May 25 2007 Stewart Adam 1.43.0-0.1.rc2 - Update to 1.43.0 rc2 (see CHANGELOG file for details on version changes) * Wed Mar 21 2007 Stewart Adam 1.42.3a-1 - Fix startup traceback on some systems gimp-2:2.2.15-2.fc8 ------------------- * Wed Jun 13 2007 Nils Philippsen - 2:2.2.15-2 - require gutenprint-plugin (#243593) gprolog-1.3.0-9.fc8 ------------------- * Wed Jun 13 2007 Jochen Schmitt 1.3.0-9 - Rebuild to solve a koji issue. hplip-1.7.4a-1.fc8 ------------------ * Wed Jun 13 2007 Tim Waugh 1.7.4a-1 - Don't put the version in the desktop file; let desktop-file-install do it. - 1.7.4a. No longer need marker-supply or faxing-with-low-supplies patches. Cheetah and cherrypy directories no longer shipped in source tarball. * Mon Jun 11 2007 Tim Waugh - Don't ship hp-check (bug #243273). - Moved hp-setup back to the base package, and put code in utils.checkPyQtImport() to check for the gui sub-package as well as PyQt (bug #243273). * Fri Jun 08 2007 Tim Waugh - Moved hp-setup to the ui package (bug #243273). - Prevent SELinux audit message from the CUPS backends (bug #241776) hunspell-pl-0.20070613-1.fc8 ---------------------------- * Wed Jun 13 2007 Caolan McNamara - 0.20070613-1 - latest version hwbrowser-0.33-1.fc8 -------------------- * Wed Jun 13 2007 Nils Philippsen - 0.33-1 - use "false" instead of "true" instead of "0" (#243862) * Tue Apr 24 2007 Nils Philippsen - 0.32-1 - merge review (#225892): - desktop file: use "true" instead of "0", don't use obsolete Application category - don't use macros in %changelog - remove hashbang from DeviceList.py * Fri Mar 30 2007 Nils Philippsen - 0.31 - fix summary, don't hash-bang python modules, mark config files (#225892) - remove kontrol-panel icon - pick up updated translations icu-3.6-20.fc8 -------------- * Wed Jun 13 2007 Caolan McNamara - 3.6-20 - Resolves: rhbz#243984 change the icu group as it is libicu which is "System Environment/Libraries" not icu * Mon Apr 30 2007 Caolan McNamara - 3.6-19 - Resolves: rhbz#220867 Malayalam rendering * Tue Feb 13 2007 Caolan McNamara - 3.6-18 - Resolves: rhbz#228457 icu.icu5594.gujarati.patch jd-1.9.5-0.4.svn1134.fc8 ------------------------ * Thu Jun 14 2007 Mamoru Tasaka - 1.9.5-0.4.svn1134 - svn 1134 k3b-0:1.0.1-3.fc8 ----------------- * Wed Jun 13 2007 Rex Dieter - 0:1.0.1-3 - --without-cdrecord-suid-root kasumi-2.2-4.fc8 ---------------- * Thu Jun 14 2007 Akira TAGOH - 2.2-3 - kasumi-2.2-fix-dict-breakage.patch: patch from Debian to fix the dictionary breakage when adding words to the personal dictionary against the bugfix version of anthy that the version contains non-numeric characters. kdesvn-0.12.1-1.fc8 ------------------- * Wed Jun 13 2007 - Orion Poplawski - 0.12.1-1 - Update to 0.12.1 - Remove index.cache hacks fixed upstream kernel-2.6.21-1.3221.fc8 ------------------------ * Wed Jun 13 2007 John W. Linville - Refresh wireless-dev patch - Drop iwlwifi patch (0.0.25 now in wireless-dev!) * Tue Jun 12 2007 Dave Jones - Disable libusual. * Tue Jun 12 2007 Dave Jones - 2.6.22-rc4-git4 kvm-28-1.fc8 ------------ * Wed Jun 13 2007 Jeremy Katz - 28-1 - update to kvm-28 libexif-0.6.15-2.fc8 -------------------- * Wed Jun 13 2007 Matthias Clasen - 0.6.15-2 - Add patch for CVE-2007-4168. Fix bug #243892 libtelepathy-0.0.55-1.fc8 ------------------------- * Wed Jun 13 2007 Brian Pepple - 0.0.55-1 - Update to 0.0.55. mcpp-2.6.4-1.fc8 ---------------- * Sat May 19 2007 Kiyoshi Matsui 2.6.4-1 - Upstream new release. ncurses-5.6-7.20070612.fc8 -------------------------- * Wed Jun 13 2007 Miroslav Lichvar 5.6-7.20070612 - update to patch 20070612 openbox-3.4.2-1.fc8 ------------------- * Wed Jun 13 2007 Miroslav Lichvar - 3.4.2-1 - Update to 3.4.2 policycoreutils-2.0.21-2.fc8 ---------------------------- * Wed Jun 13 2007 Dan Walsh 2.0.21-2 - Add filter to all system-config-selinux lists * Wed Jun 13 2007 Dan Walsh 2.0.21-1 - Update to match NSA * Fixed setsebool (falling through to error path on success). repoman-0.9-3.fc8 ----------------- * Wed Jun 13 2007 Chris Lumens - 0.9-3 - Don't use vendor macro in desktop-file-install. Also, put the .desktop file in the same directory as all the others (#244044). rhpxl-0.47-2.fc8 ---------------- * Wed Jun 13 2007 Chris Lumens - 0.47-2 - Fixes from package review (#226373). setools-3.2-2 ------------- * Wed Jun 13 2007 Dan Walsh 3.2-2 - Bump for rebuild * Mon Apr 30 2007 Dan Walsh 3.2-1 - Start shipping the rest of the setools command line apps * Tue Feb 20 2007 Dan Walsh 3.1-3 - Fix conflict with tcl/init.tcl stellarium-0.9.0-1.fc8 ---------------------- * Tue Jun 12 2007 Jochen Schmitt 0.9.0-1 - New upstream release uw-imap-2006i-1.fc8 ------------------- * Wed Jun 13 2007 Rex Dieter 2006i-1 - imap-2006i Broken deps for i386 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 obconf - 1.6-3.fc6.i386 requires libobrender.so.0 obconf - 1.6-3.fc6.i386 requires libobparser.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.i386 requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.x86_64 requires libmpcdec.so.3()(64bit) obconf - 1.6-3.fc6.x86_64 requires libobrender.so.0()(64bit) obconf - 1.6-3.fc6.x86_64 requires libobparser.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3194.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3194.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc requires libmpcdec.so.3 libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) obconf - 1.6-3.fc6.ppc requires libobrender.so.0 obconf - 1.6-3.fc6.ppc requires libobparser.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3194.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3194.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libtunepimp - 0.5.3-4.fc8.ppc64 requires libmpcdec.so.3()(64bit) obconf - 1.6-3.fc6.ppc64 requires libobrender.so.0()(64bit) obconf - 1.6-3.fc6.ppc64 requires libobparser.so.0()(64bit) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 From veillard at redhat.com Thu Jun 14 10:06:49 2007 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 14 Jun 2007 06:06:49 -0400 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181744433.25228.162.camel@pmac.infradead.org> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> <20070613141156.GC23140@redhat.com> <1181744433.25228.162.camel@pmac.infradead.org> Message-ID: <20070614100649.GB12330@redhat.com> On Wed, Jun 13, 2007 at 03:20:33PM +0100, David Woodhouse wrote: > On Wed, 2007-06-13 at 10:11 -0400, Daniel Veillard wrote: > > yeah yeah, and s390x pointed out a bug in libxml2 about some obscure > > aliasing problem. But in general going though that wasn't very fun. > > Yeah, finding bugs isn't fun. Let's never increase our test coverage. haha, nice rethoric. The problem is *when* do you test ? Compiling after release time on the weird platforms is nearly the worst time possible to run those checks. That means the code is already upstream, you're usually under tight timing constraints for pushing, and blocking your build because say Ekiga doesn't built on s390 puts the packager in the most awkward position possible. He gets to try to fix a bug raised on an architecture he has no knowledge of, without help from the upstream community, blocking everything else and then forcing him alone to come with a "quick fix". A sure recipe for disasters ... Suggesting I'm against testing software portability is a good joke, thank you, I'm sure the whole libxml2 community will have a laugh if you forward it in the proper place :-) Now to get back to serious stuff, yes we cleaned up most of the packages which constituted Core, but we are gonna regress now because compilation on the 'odd' platforms will now occur even more asynchronously when the Red Hat employees will start to recompile for RHEL release, possibly one year after the software has been pushed out. The later you catch stuff the more expensive it is, I doubt anybody will disagree, right ? We don't want to have those weird platform in the way of Fedora apparently (I don't know the exact reasons). Can we have them in parallel ? I'm thinking of asynchronous builds of what constitutes Fedora done on those box and error reports being raised to the packager or as bugzilla entries if they fail. That would be one start. But blocking the packager synchronously at build time is really not proper IMHO. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From atkac at redhat.com Thu Jun 14 10:27:04 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 14 Jun 2007 12:27:04 +0200 Subject: End of caching-nameserver package Message-ID: <467117F8.9070201@redhat.com> Hi all, caching-nameserver package will be removed and configfiles will be moved into main bind package. I did this decision because people often tell me something like "Where is default /etc/named.conf?" and I tell them "Please install caching-nameserver". So if you install bind package you have also default configuration which is usable for caching-nameserver. Regards, Adam From laurent.rineau__fedora_extras at normalesup.org Thu Jun 14 10:25:55 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 14 Jun 2007 12:25:55 +0200 Subject: What is wrong with my job on plague? Message-ID: <200706141225.57943@rineau.tsetse> My job 34168 on plague seems stalled. http://buildsys.fedoraproject.org/build-status/job.psp?uid=34168 I cannot even kill it with 'plague-client kill 34168'. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From dwmw2 at infradead.org Thu Jun 14 10:31:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 14 Jun 2007 11:31:19 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <20070614100649.GB12330@redhat.com> References: <1180473516.6254.454.camel@localhost.localdomain> <1180474889.13650.7.camel@shinybook.infradead.org> <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> <20070613141156.GC23140@redhat.com> <1181744433.25228.162.camel@pmac.infradead.org> <20070614100649.GB12330@redhat.com> Message-ID: <1181817079.25228.245.camel@pmac.infradead.org> On Thu, 2007-06-14 at 06:06 -0400, Daniel Veillard wrote: > Can we have them in parallel ? I'm thinking of asynchronous builds of > what constitutes Fedora done on those box and error reports being > raised to the packager or as bugzilla entries if they fail. That would > be one start. Daniel, I have a feeling you've managed to miss the _entirety_ of the discussion that's gone before. You've presented a whole lot of rhetoric about stuff which bears no relation to what's being proposed, and then make a 'new' proposal which is very close to what Spot _did_ actually suggest. > But blocking the packager synchronously at build time is really not > proper IMHO. Why on earth not? Much of the time that a package _used_ to build and now fails, it turns out to be a generic bug rather than really an arch-specific bug. It would be very wrong to just automatically ship such a partially-failed build, without any intervention from the packager to make sure it's OK. All I'm suggesting is that the packager should _look_ at the failure and make an educated decision about whether it's an arch-specific bug or a generic bug. If it's arch-specific and they don't care about the arch in question, it would be trivial for them to file the necessary ExcludeArch bug and push a button to ship the packages which already built, for the architectures on which they _did_ build. You wouldn't even need to rebuild with the ExcludeArch: in the specfile. The only down-side of this is that it would take slightly longer for the build to complete on all architectures. But the packages would be available from koji immediately after the the build completes on each architecture, and the actual push to the mirrors has huge amounts of delay for other reasons _anyway_, so it really shouldn't be an issue. -- dwmw2 From jkeating at redhat.com Thu Jun 14 11:10:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 07:10:41 -0400 Subject: rawhide install In-Reply-To: References: Message-ID: <200706140710.41969.jkeating@redhat.com> On Thursday 14 June 2007 04:48:34 Zoltan Kota wrote: > How can I install rawhide? Only by enabling development repo in yum after > installing F(stable)? I tried to use boot.iso from development but I > couldn't manage. Rawhide blew up yesterday when creating the stage images so it is not self installable. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From veillard at redhat.com Thu Jun 14 11:37:00 2007 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 14 Jun 2007 07:37:00 -0400 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181817079.25228.245.camel@pmac.infradead.org> References: <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> <20070613141156.GC23140@redhat.com> <1181744433.25228.162.camel@pmac.infradead.org> <20070614100649.GB12330@redhat.com> <1181817079.25228.245.camel@pmac.infradead.org> Message-ID: <20070614113700.GC12330@redhat.com> On Thu, Jun 14, 2007 at 11:31:19AM +0100, David Woodhouse wrote: > On Thu, 2007-06-14 at 06:06 -0400, Daniel Veillard wrote: > > Can we have them in parallel ? I'm thinking of asynchronous builds of > > what constitutes Fedora done on those box and error reports being > > raised to the packager or as bugzilla entries if they fail. That would > > be one start. > > Daniel, I have a feeling you've managed to miss the _entirety_ of the > discussion that's gone before. You've presented a whole lot of rhetoric > about stuff which bears no relation to what's being proposed, and then > make a 'new' proposal which is very close to what Spot _did_ actually > suggest. Right, sorry. I will go down in my hole to avoid this in any possible future. I still think what you are suggesting in the remaining of your mail does not match what I suggested, bahh, no big deal. Sorry for interrupting your discussion, you can come back to a normal work speed. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From dwmw2 at infradead.org Thu Jun 14 11:48:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 14 Jun 2007 12:48:46 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <20070614113700.GC12330@redhat.com> References: <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> <20070613141156.GC23140@redhat.com> <1181744433.25228.162.camel@pmac.infradead.org> <20070614100649.GB12330@redhat.com> <1181817079.25228.245.camel@pmac.infradead.org> <20070614113700.GC12330@redhat.com> Message-ID: <1181821726.25228.259.camel@pmac.infradead.org> On Thu, 2007-06-14 at 07:37 -0400, Daniel Veillard wrote: > Right, sorry. I will go down in my hole to avoid this in any possible future. > I still think what you are suggesting in the remaining of your mail does not > match what I suggested, bahh, no big deal. You're right; it doesn't. Your suggestion (mostly) matches Spot's original proposal, which is at http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures My proposal is slightly different -- I believe that Spot's original proposal is flawed, because if we make it so easy for the secondary architectures to end up with old or missing packages, we might as well not bother helping them at all. People have showed that they're _already_ capable of running entirely asynchronously and building Fedora for SPARC/Alpha/etc without any help from us at all. It's horrible, and you're constantly fighting to keep stuff in sync with 'Fedora', but it can be done. What Spot proposes really wouldn't be much better for them. I think that people are overestimating the 'burden' on package maintainers if we do synchronous builds. Note that I'm not talking about how beehive used to do it, where you have to resubmit the build if it fails. If the build fails on S390, you'd have the _option_ of declaring that it's really an arch-specific problem, and you'd be able to ship the already-completed packages anyway for the other architectures. You wouldn't even have to wait for it to rebuild. But you _would_ be expected to at least _glance_ at the failure and make a proper decision about the failure, rather than shipping the partially-failed build automatically. And while we wouldn't be _forcing_ package maintainers to do a proper job of maintaining portability, it would at least help to indicate expectations. I also believe that people are underestimating the amount of time that a build failure on one arch actually shows up a _generic_ problem which just happens to bite in some situations but not others. Sudden build failures on an arch which _used_ to build are something which the package maintainer really _should_ be looking at. -- dwmw2 From laroche at redhat.com Thu Jun 14 11:53:13 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 14 Jun 2007 13:53:13 +0200 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181817079.25228.245.camel@pmac.infradead.org> References: <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> <20070613141156.GC23140@redhat.com> <1181744433.25228.162.camel@pmac.infradead.org> <20070614100649.GB12330@redhat.com> <1181817079.25228.245.camel@pmac.infradead.org> Message-ID: <20070614115313.GA5591@dudweiler.stuttgart.redhat.com> On Thu, Jun 14, 2007 at 11:31:19AM +0100, David Woodhouse wrote: > On Thu, 2007-06-14 at 06:06 -0400, Daniel Veillard wrote: > > Can we have them in parallel ? I'm thinking of asynchronous builds of > > what constitutes Fedora done on those box and error reports being > > raised to the packager or as bugzilla entries if they fail. That would > > be one start. > > Daniel, I have a feeling you've managed to miss the _entirety_ of the > discussion that's gone before. You've presented a whole lot of rhetoric > about stuff which bears no relation to what's being proposed, and then > make a 'new' proposal which is very close to what Spot _did_ actually > suggest. > > > But blocking the packager synchronously at build time is really not > > proper IMHO. > > Why on earth not? Much of the time that a package _used_ to build and > now fails, it turns out to be a generic bug rather than really an > arch-specific bug. It would be very wrong to just automatically ship > such a partially-failed build, without any intervention from the > packager to make sure it's OK. > > All I'm suggesting is that the packager should _look_ at the failure and > make an educated decision about whether it's an arch-specific bug or a > generic bug. If it's arch-specific and they don't care about the arch in > question, it would be trivial for them to file the necessary ExcludeArch > bug and push a button to ship the packages which already built, for the > architectures on which they _did_ build. You wouldn't even need to > rebuild with the ExcludeArch: in the specfile. > > The only down-side of this is that it would take slightly longer for the > build to complete on all architectures. But the packages would be > available from koji immediately after the the build completes on each > architecture, and the actual push to the mirrors has huge amounts of > delay for other reasons _anyway_, so it really shouldn't be an issue. Hello David, this should be combined with "arch-maintainers" who can checkin patches across all packages if the changes do fix arch-specific code. Keeping Fedora running on all arches is really a plus. regards, Florian La Roche From dwmw2 at infradead.org Thu Jun 14 12:12:48 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 14 Jun 2007 13:12:48 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <20070614115313.GA5591@dudweiler.stuttgart.redhat.com> References: <1180567203.23218.46.camel@localhost.localdomain> <1180609829.26803.345.camel@pmac.infradead.org> <1181678255.2681.21.camel@localhost.localdomain> <604aa7910706121435m79a3d479g4a1326d2a3fda7b2@mail.gmail.com> <20070612215652.GD5561@redhat.com> <1181735898.11346.48.camel@willson> <20070613141156.GC23140@redhat.com> <1181744433.25228.162.camel@pmac.infradead.org> <20070614100649.GB12330@redhat.com> <1181817079.25228.245.camel@pmac.infradead.org> <20070614115313.GA5591@dudweiler.stuttgart.redhat.com> Message-ID: <1181823168.25228.266.camel@pmac.infradead.org> On Thu, 2007-06-14 at 13:53 +0200, Florian La Roche wrote: > this should be combined with "arch-maintainers" who can checkin > patches across all packages if the changes do fix arch-specific code. Yes, it should. I think that's already part of Spot's proposal. I've effectively been doing that job for PowerPC for a while already?. Which is why I know that half the 'suddenly failed to build' bugs are actually generic problems which the package owner should care about, and not really arch-specific at all. And that's just the ones which got as far as an ExcludeArch -- the trivial ones which the maintainer fixed for herself aren't included, and I suspect those are even _more_ likely to be generic bugs rather than arch-specific. -- dwmw2 ? although the recent restriction on commit access to Fedora packages has been _very_ unhelpful. From sundaram at fedoraproject.org Thu Jun 14 12:19:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 Jun 2007 17:49:58 +0530 Subject: F8devel - user configuration storage locations In-Reply-To: <16de708d0706131849r3dd55877wf1c66bd65bbdabf0@mail.gmail.com> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <1181779430.3696.7.camel@moogle> <16de708d0706131849r3dd55877wf1c66bd65bbdabf0@mail.gmail.com> Message-ID: <4671326E.6090607@fedoraproject.org> Arthur Pemberton wrote: > On 6/13/07, Sean Stangl wrote: >> On Wed, 2007-06-13 at 18:46 -0500, Arthur Pemberton wrote: >> > I'm sorry if Gnome's dialog shows you everything by default, but some >> > of us use KDE, and it doesn't do that, so that's a non-issue >> >> Nautilus does not show hidden files by default. Unknowledgeable users >> are therefore not bothered by the existence of hidden files and folders, >> as the files' existence is never made known unless explicitly requested. > > > Firefox shows hidden files by default as far as I've noticed. That doesn't have anything to do with GNOME but it should filed as a bug nevertheless. Rahul From dtimms at iinet.net.au Thu Jun 14 12:22:35 2007 From: dtimms at iinet.net.au (David Timms) Date: Thu, 14 Jun 2007 22:22:35 +1000 Subject: F8devel - user configuration storage locations In-Reply-To: References: <46705D4F.10307@iinet.net.au> Message-ID: <4671330B.9010004@iinet.net.au> Matej Cepl wrote: > On Thu, 14 Jun 2007 07:10:39 +1000, David Timms scripst: >> I think this should be tidied up by creating a single directory at the >> users home folder to store all setting/configs that apps make. - The >> folder should not be hidden. >> - It should have a default text file indicating that it contains hidden >> files that store settings for installed applications. - It should be >> well named: configuration | config | application_config ? - All packages >> to use this folder >> >> I see some problems: >> - breaks FHStandard ? >> - every app would need to have a one time adjustment and package rebuilt >> ? >> >> Some advantages: >> - not mixing user data folders and application config in the same top >> level {user home} folder. >> - less files to read / show / search when apps ask for the home dir file >> list >> - easily move/copy all user configs to backup or a different machine > > Ehm, before suggesting something, it would be wise to make a little > research. Maybe you would find http://standards.freedesktop.org/basedir- > spec/latest/ and related other standards on http://www.freedesktop.org/ > wiki/Specifications/ . Thanks, Matej, I'm sure to take a look on the weekend, I am probably missing something obvious. DaveT. From kevin.kofler at chello.at Thu Jun 14 12:38:41 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 14 Jun 2007 12:38:41 +0000 (UTC) Subject: F8devel - user configuration storage locations References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <1181779430.3696.7.camel@moogle> <16de708d0706131849r3dd55877wf1c66bd65bbdabf0@mail.gmail.com> Message-ID: Arthur Pemberton gmail.com> writes: > Firefox shows hidden files by default as far as I've noticed. Are folks using Firefox as a file manager now?! Kevin Kofler From buc at odusz.so-cdu.ru Thu Jun 14 12:55:28 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 14 Jun 2007 16:55:28 +0400 Subject: FreeTDS In-Reply-To: <20070531082107.2e47582d.jklowden@freetds.org> References: <20070531082107.2e47582d.jklowden@freetds.org> Message-ID: <46713AC0.4090404@odu.neva.ru> James K. Lowden wrote: > FreeTDS is, simply, free > software. I wish the Fedora project would accept and treat it > accordingly. > Thanks again for your clarrifications. Freetds are in "updates-testing" for Fedora 7 now (and will appear soon for Fedora Extras 6 as well). It would be nice if you check it a bit, see: ftp://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/freetds-0.64-5.fc7.i386.rpm ftp://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/freetds-devel-0.64-5.fc7.i386.rpm Regards, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From frosario777 at gmail.com Thu Jun 14 12:57:53 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Thu, 14 Jun 2007 05:57:53 -0700 Subject: F8devel - user configuration storage locations In-Reply-To: References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <1181779430.3696.7.camel@moogle> <16de708d0706131849r3dd55877wf1c66bd65bbdabf0@mail.gmail.com> Message-ID: I wouldn't go that far. Often I store webpages locally on my harddrive for offline viewing. I access them by typing "file:///home/me/..." in the url box. I have noticed the hidden files as well. I also would not go as far as calling this a bug. It may be a feature that the firefox team intended. On 6/14/07, Kevin Kofler wrote: > > Arthur Pemberton gmail.com> writes: > > Firefox shows hidden files by default as far as I've noticed. > > Are folks using Firefox as a file manager now?! > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- --Freddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From billcrawford1970 at gmail.com Thu Jun 14 13:00:54 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 14 Jun 2007 14:00:54 +0100 Subject: F8devel - user configuration storage locations In-Reply-To: <20070614045607.GA17173@serv.smile.org.ua> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <20070614045607.GA17173@serv.smile.org.ua> Message-ID: <544eb990706140600r1ccbcc4u9e22d315df15b2b1@mail.gmail.com> GLOBIGNORE='.:./:..:../' :) On 14/06/07, Andy Shevchenko wrote: > > Hi Arthur Pemberton! > > On Wed, Jun 13, 2007 at 06:46:51PM -0500, Arthur Pemberton wrote next: > > > > I think this should be tidied up by creating a single directory at the > > > users home folder to store all setting/configs that apps make. > > > - The folder should not be hidden. > > > > I would hate this even more > +1 > > > > - easily move/copy all user configs to backup or a different machine > > cp -a ~/.* > Not simple. If you do that you'll try to copy over the parent tree due to > '..' (that is satisfy your code) represents parent and '.' represents > current folder. > > -- > With best regards, > Andy Shevchenko. mailto: andy at smile.org.ua > > > -- > 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 bernie at codewiz.org Thu Jun 14 13:05:20 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 14 Jun 2007 09:05:20 -0400 Subject: End of caching-nameserver package In-Reply-To: <467117F8.9070201@redhat.com> References: <467117F8.9070201@redhat.com> Message-ID: <46713D10.7080204@codewiz.org> Adam Tkac wrote: > Hi all, > > caching-nameserver package will be removed and configfiles will be moved > into main bind package. I did this decision because people often tell me > something like "Where is default /etc/named.conf?" and I tell them > "Please install caching-nameserver". So if you install bind package you > have also default configuration which is usable for caching-nameserver. By the way, I always wanted to ask... we use caching-nameserver because the libc resolver can only do per-process caching versus system-wide caching, right? If so, wouldn't nscd be a lighter weight daemon for this purpose? I found that enabling nscd often imoproves performance on servers. It certainly does when using LDAP, even if the LDAP deamon runs locally and is accessed through the ldapi socket. The downside of nscd was not detecting when it needs to flush dirty cache entries, which leads to all sorts of glitches like adding a user with useradd and not being able to chown a file to her for 600 seconds. A simple inotify on the cached files would have sufficed. Ah, and things got even worse when nscd started making the cache persistent on disk. Then, not even restarting it would fix the problem! If we could fix or mitigate these problems, I'd like to see nscd enabled by default in Fedora. I need to enable it on all LDAP enabled clients to get acceptable performance (like "ls /home" taking less than 3 seconds the second time). -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From halfline at gmail.com Thu Jun 14 13:27:49 2007 From: halfline at gmail.com (Ray Strode) Date: Thu, 14 Jun 2007 09:27:49 -0400 Subject: F8devel - UI "responsiveness" improvements In-Reply-To: <46705A88.9000207@iinet.net.au> References: <46705A88.9000207@iinet.net.au> Message-ID: <45abe7d80706140627o2b60a7eevd234de991fddda67@mail.gmail.com> Hi, On 6/13/07, David Timms wrote: > I'd like to suggest a goal for future Fedora of ensuring every > application / task performed with Fedora actually provides user feedback > at a minimum 1 {one} second interval. > > Culprits: > - anaconda between go-ahead with install and first package installing > {especially noticeable because the {boring} X screen saver kicks in. You > then move the mouse to get the screen back - but there is no update to > the screen for maybe one minute or more. > > - pup during an update run with about 30-40 packages. It took nearly an > hour. Each time an app covered its windows they may not have been > redrawn for some minutes. > > I have no idea what causes these. The problem is librpm only offers blocking apis. This means that these functions can potentially take a long time to run. While they're running, the functions for redrawing the window can't run. So we have a few possible ways to fix this: 1) add new apis to librpm that don't block (I was told this would be very hard) 2) do all librpm work in separate threads (note librpm isn't thread safe either, so some care has to be taken with this approach) 3) do all work in a separate process from the UI It turns out we already have a separate process (yum-updatesd) and it already has code for doing installs/updates, so 3 seems like the best way forward to me. There's a bug here about it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213820 I don't know what Jeremy/Seth/Paul's opinions are though. --Ray From atkac at redhat.com Thu Jun 14 13:53:41 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 14 Jun 2007 15:53:41 +0200 Subject: End of caching-nameserver package In-Reply-To: <46713D10.7080204@codewiz.org> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> Message-ID: <46714865.1030907@redhat.com> Bernardo Innocenti napsal(a): > By the way, I always wanted to ask... we use caching-nameserver > because the libc resolver can only do per-process caching versus > system-wide caching, right? > > If so, wouldn't nscd be a lighter weight daemon for this purpose? Of course. nscd caching all "traffic" which is related to nsswitch (host, passwd, services etc). Main difference between nscd and named is that named is heavy-weight reference DNS server and nscd is here only for nss caching purposes. Adam From ajackson at redhat.com Thu Jun 14 13:57:02 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 14 Jun 2007 09:57:02 -0400 Subject: R500 initial driver release In-Reply-To: <1181684022.2680.4.camel@scrappy.miketc.com> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> Message-ID: <1181829422.30663.72.camel@localhost.localdomain> On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: > On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: > > http://lwn.net/Articles/237920/rss > > So will someone be including this driver (this is in the kernel or xorg > packages) in fc7 or I assume fc8? I need to test that it actually works on at least one piece of hardware first. - ajax From ajackson at redhat.com Thu Jun 14 13:59:25 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 14 Jun 2007 09:59:25 -0400 Subject: F8devel - UI "responsiveness" improvements In-Reply-To: <46705A88.9000207@iinet.net.au> References: <46705A88.9000207@iinet.net.au> Message-ID: <1181829565.30663.75.camel@localhost.localdomain> On Thu, 2007-06-14 at 06:58 +1000, David Timms wrote: > I'd like to suggest a goal for future Fedora of ensuring every > application / task performed with Fedora actually provides user feedback > at a minimum 1 {one} second interval. > > Culprits: > - anaconda between go-ahead with install and first package installing > {especially noticeable because the {boring} X screen saver kicks in. You > then move the mouse to get the screen back - but there is no update to > the screen for maybe one minute or more. > > - pup during an update run with about 30-40 packages. It took nearly an > hour. Each time an app covered its windows they may not have been > redrawn for some minutes. Just to clarify, it's not that you want continuous screen updates, it's that you don't want to see apps in the middle of redraw. We could solve this trivially by turning on automatic compositing by default but I don't think that's ready yet. - ajax From dwalsh at redhat.com Thu Jun 14 14:07:13 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Jun 2007 10:07:13 -0400 Subject: system-config-selinux In-Reply-To: <46704ED5.5000809@gmail.com> References: <46704ED5.5000809@gmail.com> Message-ID: <46714B91.4080100@redhat.com> David Boles wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > /usr/bin/system-config-selinux crashes in development (Rawhide) and is not > listed in Bugzilla. > > To what package should I report this? > Anytime you find an app that crashes, figure out which rpm package delivered it. rpm -qf /usr/bin/system-config-selinux policycoreutils-gui-2.0.21-2.fc8 Then use that package. BTW policycoreutils-gui-2.0.21-2.fc8 fixes the problem > - -- > > David > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > > iD8DBQFGcE7VAO0wNI1X4QERAjs4AJwJN6p/3MS0xsAThaD7E727J4EwsgCeJbO/ > pnM0KUw9ZYRGlGaBN9vbFfc= > =A717 > -----END PGP SIGNATURE----- > > From dwalsh at redhat.com Thu Jun 14 14:08:12 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 14 Jun 2007 10:08:12 -0400 Subject: system-config-selinux In-Reply-To: <46714B91.4080100@redhat.com> References: <46704ED5.5000809@gmail.com> <46714B91.4080100@redhat.com> Message-ID: <46714BCC.7070505@redhat.com> Daniel J Walsh wrote: > David Boles wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> /usr/bin/system-config-selinux crashes in development (Rawhide) and >> is not >> listed in Bugzilla. >> >> To what package should I report this? >> > Anytime you find an app that crashes, figure out which rpm package > delivered it. > > rpm -qf /usr/bin/system-config-selinux > policycoreutils-gui-2.0.21-2.fc8 > > Then use that package. > > BTW policycoreutils-gui-2.0.21-2.fc8 fixes the problem >> - -- >> >> David >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.7 (MingW32) >> >> iD8DBQFGcE7VAO0wNI1X4QERAjs4AJwJN6p/3MS0xsAThaD7E727J4EwsgCeJbO/ >> pnM0KUw9ZYRGlGaBN9vbFfc= >> =A717 >> -----END PGP SIGNATURE----- >> >> > Sorry responded to this email twice. (Now three times). From mike at miketc.com Thu Jun 14 14:32:47 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 14 Jun 2007 09:32:47 -0500 Subject: R500 initial driver release In-Reply-To: <1181829422.30663.72.camel@localhost.localdomain> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> Message-ID: <1181831567.6083.0.camel@scrappy.miketc.com> On Thu, 2007-06-14 at 09:57 -0400, Adam Jackson wrote: > On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: > > On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: > > > http://lwn.net/Articles/237920/rss > > > > So will someone be including this driver (this is in the kernel or xorg > > packages) in fc7 or I assume fc8? > > I need to test that it actually works on at least one piece of hardware > first. I've also got an X1300 Card if you need help testing, and want to post a private package unofficially or something. Anyway, just let me know. -- Mike Chambers Madisonville, KY "Best little town on Earth!" From atkac at redhat.com Thu Jun 14 14:41:35 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 14 Jun 2007 16:41:35 +0200 Subject: R500 initial driver release In-Reply-To: <1181831567.6083.0.camel@scrappy.miketc.com> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> <1181831567.6083.0.camel@scrappy.miketc.com> Message-ID: <4671539F.4030409@redhat.com> Mike Chambers napsal(a): > On Thu, 2007-06-14 at 09:57 -0400, Adam Jackson wrote: > >> On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: >> >>> On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: >>> >>>> http://lwn.net/Articles/237920/rss >>>> >>> So will someone be including this driver (this is in the kernel or xorg >>> packages) in fc7 or I assume fc8? >>> >> I need to test that it actually works on at least one piece of hardware >> first. >> > > I've also got an X1300 Card if you need help testing, and want to post a > private package unofficially or something. > > Anyway, just let me know. > > Yeah, my X1300 Pro will be enjoyed with testing driver too. A From buildsys at fedoraproject.org Thu Jun 14 14:57:31 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 14 Jun 2007 14:57:31 -0000 Subject: Summary - Broken dependencies in Fedora 7 - 2007-06-14 Message-ID: <20070614145731.26491.92001@extras64.linux.duke.edu> Summary of broken packages (by owner): cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (12 days) davej AT redhat.com kernel - 2.6.21-1.3228.fc7.i586 kernel - 2.6.21-1.3228.fc7.i686 kernel - 2.6.21-1.3228.fc7.ppc kernel - 2.6.21-1.3228.fc7.ppc64 kernel - 2.6.21-1.3228.fc7.x86_64 kernel-PAE - 2.6.21-1.3228.fc7.i686 kernel-PAE-debug - 2.6.21-1.3228.fc7.i686 kernel-debug - 2.6.21-1.3228.fc7.i686 kernel-debug - 2.6.21-1.3228.fc7.x86_64 kernel-kdump - 2.6.21-1.3228.fc7.ppc64 kernel-kdump - 2.6.21-1.3228.fc7.x86_64 kernel-smp - 2.6.21-1.3228.fc7.ppc dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (12 days) fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 (12 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (12 days) glest-data - 2.0.0-2.fc7.noarch (12 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i586 (12 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.i686 (12 days) kmod-sysprof - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (12 days) kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3116.fc7.i686 (12 days) kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 (12 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (12 days) icon AT fedoraproject.org phpdoc - 1.3.2-1.fc7.noarch (2 days) phpdoc - 1.3.2-1.fc7.noarch (2 days) phpdoc - 1.3.2-1.fc7.noarch (2 days) phpdoc - 1.3.2-1.fc7.noarch (2 days) jeff AT ocjtech.us trac - 0.10.3.1-2.fc7.noarch (12 days) jonathansteffan AT gmail.com revisor - 2.0.3.9-1.fc7.noarch (2 days) revisor - 2.0.3.9-1.fc7.noarch (2 days) jwilson AT redhat.com emerald-themes - 0.2.0-1.fc7.noarch (12 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (12 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (12 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (12 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (12 days) mdehaan AT redhat.com koan - 0.3.1-2.fc7.noarch oliver AT linux-kernel.at syck-php - 0.55-14.fc7.i386 (12 days) syck-php - 0.55-14.fc7.ppc (12 days) syck-php - 0.55-14.fc7.ppc64 (12 days) syck-php - 0.55-14.fc7.x86_64 (12 days) orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 (12 days) rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 (12 days) rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (12 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (12 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (12 days) tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 (12 days) Democracy - 0.9.5.1-8.fc7.ppc (12 days) Democracy - 0.9.5.1-8.fc7.ppc64 (12 days) Democracy - 0.9.5.1-8.fc7.x86_64 (12 days) ====================================================================== Broken packages in fedora-7-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3116.fc7 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.21_1.3116.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3116.fc7PAE syck-php-0.55-14.fc7.i386 requires php = 0:5.2.1 ====================================================================== Broken packages in fedora-7-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) emerald-themes-0.2.0-1.fc7.noarch requires emerald >= 0:0.2.0 emerald-themes-0.2.0-1.fc7.noarch requires beryl-core >= 0:0.2.0 geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics koan-0.3.1-2.fc7.noarch requires syslinux oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) syck-php-0.55-14.fc7.ppc64 requires php = 0:5.2.1 trac-0.10.3.1-2.fc7.noarch requires python-clearsilver >= 0:0.9.3 wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in fedora-7-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 syck-php-0.55-14.fc7.ppc requires php = 0:5.2.1 ====================================================================== Broken packages in fedora-7-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-sysprof-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump syck-php-0.55-14.fc7.x86_64 requires php = 0:5.2.1 ====================================================================== Broken packages in fedora-updates-7-i386: kernel-2.6.21-1.3228.fc7.i586 requires mkinitrd >= 0:6.0.9-7.1 kernel-2.6.21-1.3228.fc7.i686 requires mkinitrd >= 0:6.0.9-7.1 kernel-PAE-2.6.21-1.3228.fc7.i686 requires mkinitrd >= 0:6.0.9-7.1 kernel-PAE-debug-2.6.21-1.3228.fc7.i686 requires mkinitrd >= 0:6.0.9-7.1 kernel-debug-2.6.21-1.3228.fc7.i686 requires mkinitrd >= 0:6.0.9-7.1 phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 ====================================================================== Broken packages in fedora-updates-7-ppc64: kernel-2.6.21-1.3228.fc7.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kernel-kdump-2.6.21-1.3228.fc7.ppc64 requires mkinitrd >= 0:6.0.9-7.1 phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 revisor-2.0.3.9-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-7-ppc: kernel-2.6.21-1.3228.fc7.ppc requires mkinitrd >= 0:6.0.9-7.1 kernel-smp-2.6.21-1.3228.fc7.ppc requires mkinitrd >= 0:6.0.9-7.1 phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 revisor-2.0.3.9-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-7-x86_64: kernel-2.6.21-1.3228.fc7.x86_64 requires mkinitrd >= 0:6.0.9-7.1 kernel-debug-2.6.21-1.3228.fc7.x86_64 requires mkinitrd >= 0:6.0.9-7.1 kernel-kdump-2.6.21-1.3228.fc7.x86_64 requires mkinitrd >= 0:6.0.9-7.1 phpdoc-1.3.2-1.fc7.noarch requires php-pear(PhpDocumentor) = 0:1.3.2-1.fc7 From jkeating at redhat.com Thu Jun 14 14:59:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 10:59:23 -0400 Subject: Summary - Broken dependencies in Fedora 7 - 2007-06-14 In-Reply-To: <20070614145731.26491.92001@extras64.linux.duke.edu> References: <20070614145731.26491.92001@extras64.linux.duke.edu> Message-ID: <200706141059.23712.jkeating@redhat.com> On Thursday 14 June 2007 10:57:31 Fedora Extras repoclosure wrote: > Broken packages in fedora-7-i386: Is this just looking at the Everything/7 tree? That tree isn't going to change so continuing to check it doesn't make sense. Checking that tree + updates and that tree + updates-testing does however, and I see that later in the report (well updates, not updates-testing). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tonynelson at georgeanelson.com Thu Jun 14 15:03:20 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Thu, 14 Jun 2007 11:03:20 -0400 Subject: F8devel - user configuration storage locations In-Reply-To: <20070614045607.GA17173@serv.smile.org.ua> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <20070614045607.GA17173@serv.smile.org.ua> Message-ID: At 7:56 AM +0300 6/14/07, Andy Shevchenko wrote: >Hi Arthur Pemberton! > > On Wed, Jun 13, 2007 at 06:46:51PM -0500, Arthur Pemberton wrote next: > >> > I think this should be tidied up by creating a single directory at the >> > users home folder to store all setting/configs that apps make. >> > - The folder should not be hidden. >> >> I would hate this even more >+1 > >> > - easily move/copy all user configs to backup or a different machine >> cp -a ~/.* >Not simple. If you do that you'll try to copy over the parent tree due to >'..' (that is satisfy your code) represents parent and '.' represents >current folder. Not simple, but how about: cp -a ~/.[!.]* . -- ____________________________________________________________________ TonyN.:' ' From mschwendt.tmp0701.nospam at arcor.de Thu Jun 14 15:16:30 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 14 Jun 2007 17:16:30 +0200 Subject: Summary - Broken dependencies in Fedora 7 - 2007-06-14 In-Reply-To: <200706141059.23712.jkeating@redhat.com> References: <20070614145731.26491.92001@extras64.linux.duke.edu> <200706141059.23712.jkeating@redhat.com> Message-ID: <20070614171630.b8bc366b.mschwendt.tmp0701.nospam@arcor.de> On Thu, 14 Jun 2007 10:59:23 -0400, Jesse Keating wrote: > On Thursday 14 June 2007 10:57:31 Fedora Extras repoclosure wrote: > > Broken packages in fedora-7-i386: > > Is this just looking at the Everything/7 tree? That would be stupid. ;) > That tree isn't going to > change so continuing to check it doesn't make sense. Checking that tree + > updates and that tree + updates-testing does however, and I see that later in > the report (well updates, not updates-testing). This report is about F7 + Released Updates. The next report will be about F7 + Released Updates + Test Updates (like the one sent on 2007-06-12). From buildsys at fedoraproject.org Thu Jun 14 15:20:25 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 14 Jun 2007 15:20:25 -0000 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 Message-ID: <20070614152025.27947.93929@extras64.linux.duke.edu> Summary of broken packages (by owner): cgoorah AT yahoo.com.au geda-examples - 20070216-2.fc7.noarch (12 days) dennis AT ausil.us oooqs2 - 1.0-3.fc6.ppc64 (12 days) fedora AT leemhuis.info gsynaptics - 0.9.11-1.fc7.ppc64 (12 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (12 days) glest-data - 2.0.0-2.fc7.noarch (12 days) green AT redhat.com ardour - 0.99.3-8.fc7.ppc64 (12 days) jonathansteffan AT gmail.com revisor - 2.0.3.9-1.fc7.noarch (2 days) revisor - 2.0.3.9-1.fc7.noarch (2 days) jwilson AT redhat.com beryl-gnome - 0.2.1-1.fc7.ppc64 (8 days) beryl-kde - 0.2.1-1.fc7.ppc64 (8 days) karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (12 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 (12 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc (12 days) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 (12 days) mdehaan AT redhat.com koan - 0.4.0-1.fc7.noarch (12 days) orion AT cora.nwra.com python-basemap - 0.9.5-1.fc7.ppc64 (12 days) rdieter AT math.unl.edu wxMaxima - 0.7.2-1.fc7.ppc64 (12 days) rvokal AT redhat.com resapplet - 0.1.1-5.fc7.ppc64 (12 days) seg AT haxxed.com rosegarden4 - 1.4.0-1.fc7.ppc64 (12 days) tmraz AT redhat.com openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 (12 days) tscherf AT redhat.com Democracy - 0.9.5.1-8.fc7.i386 (12 days) Democracy - 0.9.5.1-8.fc7.ppc (12 days) Democracy - 0.9.5.1-8.fc7.ppc64 (12 days) Democracy - 0.9.5.1-8.fc7.x86_64 (12 days) ====================================================================== Broken packages in fedora-7-i386: Democracy-0.9.5.1-8.fc7.i386 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-7-ppc64: Democracy-0.9.5.1-8.fc7.ppc64 requires firefox = 0:2.0.0.3 ardour-0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples-20070216-2.fc7.noarch requires geda-gschem glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gsynaptics-0.9.11-1.fc7.ppc64 requires synaptics oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-draw oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2-1.0-3.fc6.ppc64 requires openoffice.org-impress openoffice.org-dict-cs_CZ-20060303-5.fc7.ppc64 requires openoffice.org-core python-basemap-0.9.5-1.fc7.ppc64 requires python-matplotlib >= 0:0.81 resapplet-0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4-1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 ====================================================================== Broken packages in fedora-7-ppc: Democracy-0.9.5.1-8.fc7.ppc requires firefox = 0:2.0.0.3 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-7-x86_64: Democracy-0.9.5.1-8.fc7.x86_64 requires firefox = 0:2.0.0.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm-1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 ====================================================================== Broken packages in fedora-updates-7-ppc64: revisor-2.0.3.9-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-7-ppc: revisor-2.0.3.9-1.fc7.noarch requires livecd-tools ====================================================================== Broken packages in fedora-updates-testing-7-ppc64: beryl-gnome-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 beryl-kde-0.2.1-1.fc7.ppc64 requires beryl-manager >= 0:0.2.1 koan-0.4.0-1.fc7.noarch requires syslinux From jkeating at redhat.com Thu Jun 14 15:22:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 11:22:46 -0400 Subject: Summary - Broken dependencies in Fedora 7 - 2007-06-14 In-Reply-To: <20070614171630.b8bc366b.mschwendt.tmp0701.nospam@arcor.de> References: <20070614145731.26491.92001@extras64.linux.duke.edu> <200706141059.23712.jkeating@redhat.com> <20070614171630.b8bc366b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706141122.46666.jkeating@redhat.com> On Thursday 14 June 2007 11:16:30 Michael Schwendt wrote: > This report is about F7 + Released Updates. Then I'm confused as to why there are two groups of listings. Broken packages in Fedora 7 and broken packages in Fedora 7 updates. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blc at redhat.com Thu Jun 14 15:46:01 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 14 Jun 2007 09:46:01 -0600 Subject: fedora for ARM In-Reply-To: <20070612194519.GB14392@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <4663FAEB.8070807@hhs.nl> <1181047155.27239.100.camel@mccallum.corsepiu.local> <46670F30.8080102@redhat.com> <20070607114028.GH2079@xi.wantstofly.org> <466834DA.1060009@redhat.com> <20070612194519.GB14392@xi.wantstofly.org> Message-ID: <467162B9.3010909@redhat.com> Lennert Buytenhek wrote: > My experience is somewhat different, but OK. :-) > > One thing I wondered about, are your (cross-) diffs available > somewhere? We'll be putting something together in the next few days that can be shared. Some of our tree is against F7. Other parts were only used with FC3-vintage sources (And a lot in between!), so it's a bit of a mishmash. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From rdieter at math.unl.edu Thu Jun 14 15:54:45 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Jun 2007 10:54:45 -0500 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 References: <20070614152025.27947.93929@extras64.linux.duke.edu> Message-ID: Fedora Extras repoclosure wrote: > rdieter AT math.unl.edu > wxMaxima - 0.7.2-1.fc7.ppc64 ? ?(12 days) This simply shouldn't be in the ppc64 repo. I've built a subsequent wxMaxima-0.7.2-2.fc7 that doesn't include ppc64. What's the best way to get wxMaxima-0.7.2-1.fc7.ppc64 removed/omitted? -- Rex From jkeating at redhat.com Thu Jun 14 16:05:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 12:05:49 -0400 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 In-Reply-To: References: <20070614152025.27947.93929@extras64.linux.duke.edu> Message-ID: <200706141205.50034.jkeating@redhat.com> On Thursday 14 June 2007 11:54:45 Rex Dieter wrote: > This simply shouldn't be in the ppc64 repo. ?I've built a subsequent > wxMaxima-0.7.2-2.fc7 that doesn't include ppc64. Release it as an update. Update generation pulls the latest builds, and only the arches available in the latest builds. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at scrye.com Thu Jun 14 16:08:16 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 14 Jun 2007 10:08:16 -0600 Subject: What is wrong with my job on plague? In-Reply-To: <200706141225.57943@rineau.tsetse> References: <200706141225.57943@rineau.tsetse> Message-ID: <20070614100816.1db1a71d@ghistelwchlohm.scrye.com> On Thu, 14 Jun 2007 12:25:55 +0200 laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) wrote: > My job 34168 on plague seems stalled. > http://buildsys.fedoraproject.org/build-status/job.psp?uid=34168 > > I cannot even kill it with 'plague-client kill 34168'. > It looks like it finished fine and is in the needsign repo? What about it is telling you it's stalled? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laurent.rineau__fedora_extras at normalesup.org Thu Jun 14 16:32:06 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 14 Jun 2007 18:32:06 +0200 Subject: What is wrong with my job on plague? In-Reply-To: <20070614100816.1db1a71d@ghistelwchlohm.scrye.com> References: <200706141225.57943@rineau.tsetse> <20070614100816.1db1a71d@ghistelwchlohm.scrye.com> Message-ID: <200706141832.06223@rineau.tsetse> On Thursday 14 June 2007 06:08:16 pm Kevin Fenzi wrote: > On Thu, 14 Jun 2007 12:25:55 +0200 > > laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) wrote: > > My job 34168 on plague seems stalled. > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=34168 > > > > I cannot even kill it with 'plague-client kill 34168'. > > It looks like it finished fine and is in the needsign repo? > What about it is telling you it's stalled? I?launched it hours ago (almost 24h). It was blocked in a strange "checkout" mode, if I remember well, and I was not able to kill it. However, my job send me a "success" several hours ago. I do not know what to say. There was a problem, that disappear without letting us any way to understand. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From rdieter at math.unl.edu Thu Jun 14 16:52:18 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Jun 2007 11:52:18 -0500 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 References: <20070614152025.27947.93929@extras64.linux.duke.edu> <200706141205.50034.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Thursday 14 June 2007 11:54:45 Rex Dieter wrote: >> This simply shouldn't be in the ppc64 repo. ?I've built a subsequent >> wxMaxima-0.7.2-2.fc7 that doesn't include ppc64. > > Release it as an update. Update generation pulls the latest builds, and > only the arches available in the latest builds. I did release an update: https://admin.fedoraproject.org/updates/F7/wxMaxima-0.7.2-2.fc7 which is what prompted my question, but maybe the repoclosure didn't see it (yet). ? -- Rex From mschwendt.tmp0701.nospam at arcor.de Thu Jun 14 17:08:24 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 14 Jun 2007 19:08:24 +0200 Subject: Summary - Broken dependencies in Fedora 7 - 2007-06-14 In-Reply-To: <200706141122.46666.jkeating@redhat.com> References: <20070614145731.26491.92001@extras64.linux.duke.edu> <200706141059.23712.jkeating@redhat.com> <20070614171630.b8bc366b.mschwendt.tmp0701.nospam@arcor.de> <200706141122.46666.jkeating@redhat.com> Message-ID: <20070614190824.74d27a70.mschwendt.tmp0701.nospam@arcor.de> On Thu, 14 Jun 2007 11:22:46 -0400, Jesse Keating wrote: > On Thursday 14 June 2007 11:16:30 Michael Schwendt wrote: > > This report is about F7 + Released Updates. > > Then I'm confused as to why there are two groups of listings. Broken packages > in Fedora 7 and broken packages in Fedora 7 updates. It's just the repoids of the repository a broken package is found in. It's interesting to see whether a packager breakes something in "Everything" that hasn't been updated yet or whether released updates are broken again. One could filter out the repoids and call everything just "fedora-7-$basearch", but a) that isn't useful for the updates-testing case [where a test-update can break other test-updates => a rather harmless scenario], and b) it had not been useful for Extras. :) From limb at jcomserv.net Thu Jun 14 17:07:20 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 14 Jun 2007 12:07:20 -0500 (CDT) Subject: Unsigned package In-Reply-To: <200706131311.13201.jkeating@redhat.com> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706110920.04931.jkeating@redhat.com> <46701E75.6040605@theholbrooks.org> <200706131311.13201.jkeating@redhat.com> Message-ID: <27855.65.192.24.164.1181840840.squirrel@mail.jcomserv.net> > On Wednesday 13 June 2007 12:42:29 Brandon Holbrook wrote: >> Any updates on this? I see scons and php-pear-Mail-Mime are still both >> unsigned on download.f.r.c. And just to clarify, as the Mail-Mime >> maintainer, this build was my first experiment with koji. Was there >> some error on my part? If a mirror sync is too troublesome, I don't >> mind bumping the release and rebuilding :) > > It wasn't your fault, just a tools and oversight issue on our part. The > tree > was supposed to be synced last night, looking into why it didn't happen. (Daily sync check) :) > -- > Jesse Keating > Release Engineer: Fedora > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From mschwendt.tmp0701.nospam at arcor.de Thu Jun 14 17:14:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 14 Jun 2007 19:14:02 +0200 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 In-Reply-To: References: <20070614152025.27947.93929@extras64.linux.duke.edu> <200706141205.50034.jkeating@redhat.com> Message-ID: <20070614191402.e3956c78.mschwendt.tmp0701.nospam@arcor.de> On Thu, 14 Jun 2007 11:52:18 -0500, Rex Dieter wrote: > Jesse Keating wrote: > > > On Thursday 14 June 2007 11:54:45 Rex Dieter wrote: > >> This simply shouldn't be in the ppc64 repo. ?I've built a subsequent > >> wxMaxima-0.7.2-2.fc7 that doesn't include ppc64. > > > > Release it as an update. Update generation pulls the latest builds, and > > only the arches available in the latest builds. > > I did release an update: > https://admin.fedoraproject.org/updates/F7/wxMaxima-0.7.2-2.fc7 > which is what prompted my question, but maybe the repoclosure didn't see it > (yet). ? That's one of the reasons why you see a repoid in the report and in the private mails. : Broken packages in fedora-7-ppc64: : : wxMaxima-0.7.2-1.fc7.ppc64 requires maxima >= 0:5.11 Jesse's advice doesn't apply, since your ppc64 build is included in the "Everything" repository. You cannot take it away with an update. It stays in that repo and in the metadata unless rel-eng modify the repo and drop the package. From jkeating at redhat.com Thu Jun 14 17:13:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 13:13:40 -0400 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 In-Reply-To: <20070614191402.e3956c78.mschwendt.tmp0701.nospam@arcor.de> References: <20070614152025.27947.93929@extras64.linux.duke.edu> <20070614191402.e3956c78.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706141313.46898.jkeating@redhat.com> On Thursday 14 June 2007 13:14:02 Michael Schwendt wrote: > Jesse's advice doesn't apply, since your ppc64 build is included in the > "Everything" repository. You cannot take it away with an update. It stays > in that repo and in the metadata unless rel-eng modify the repo and > drop the package. Which we're not likely to do. Making changes to the release tree is unnecessarily difficult right now, as evidenced by trying to get signed packages in place. Provided we don't have a release of "ppc64" but rather a ppc release that is multilib with ppc64 I don't think this is a huge issue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at redhat.com Thu Jun 14 17:40:26 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 14 Jun 2007 13:40:26 -0400 Subject: random comments about secondary arch proposal Message-ID: <1181842826.3635.14.camel@localhost.localdomain> Primary arch definition: need to make sure that part of the responsibility is that individual maintainers are required to make sure their stuff builds on all those arches. Three team members seems arbitrary (and it is, based on discussions.) Need to allow bootstrapping with one guy if that's at all possible and then measure if there's growth. Would rather allow trial and failure for these secondary arches instead of not letting things even get off the ground. (Old adage: the hardest part is just getting started.) Hold meetings on IRC but also report to fesco and the board on some kind of a regular basis. Have to have a place to host downloads (for now) as well as machines to host build env. Mostly a resource problem. SEND MORE NETAPPS. "Secondary architectures will need to provide their own file storage. Mirrors can choose whether they wish to mirror secondary architectures on an arch-by-arch basis." - that's not clear given my previous statement? That's about it. --Chris From blc at redhat.com Thu Jun 14 17:53:41 2007 From: blc at redhat.com (Brendan Conoboy) Date: Thu, 14 Jun 2007 11:53:41 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181790349.2121.210.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> Message-ID: <467180A5.5030305@redhat.com> Ralf Corsepius wrote: > Not quite. You end up with the target's sys-root's files ("target > binaries", blobs of arbitrary binary data) inside of a "noarch" rpm. Er, if you're building an arm-linux toolchain and store the sysroot in a noarch rpm, that's still wrong arch :-) Not *as* wrong as having it in an RPM for the build host's arch, but not as right as having it for the target arch. > Well, IMO this plan is not useful and doesn't fit into the working > principles of rpm, because it confuses host architecture with target > architecture. Eh? > What I could envision to be made functional is a wrapper around rpm, > using another "per-cross-target" rpmdb to add native target rpms into > sys-roots. If I understand you correctly, that sounds about right. When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From seg at haxxed.com Thu Jun 14 18:26:25 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 14 Jun 2007 13:26:25 -0500 Subject: End of caching-nameserver package In-Reply-To: <46713D10.7080204@codewiz.org> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> Message-ID: <1181845585.15983.4.camel@localhost> On Thu, 2007-06-14 at 09:05 -0400, Bernardo Innocenti wrote: > By the way, I always wanted to ask... we use caching-nameserver > because the libc resolver can only do per-process caching versus > system-wide caching, right? > > If so, wouldn't nscd be a lighter weight daemon for this purpose? dnsmasq is specifically designed for this purpose, and in fact upstream has added dbus support to it specifically so it can integrate nicely with NetworkManager. Why we're not using it, I don't know. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Jun 14 18:43:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 14 Jun 2007 14:43:01 -0400 Subject: End of caching-nameserver package In-Reply-To: <1181845585.15983.4.camel@localhost> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> <1181845585.15983.4.camel@localhost> Message-ID: <20070614184301.GG3522@nostromo.devel.redhat.com> Callum Lerwick (seg at haxxed.com) said: > On Thu, 2007-06-14 at 09:05 -0400, Bernardo Innocenti wrote: > > By the way, I always wanted to ask... we use caching-nameserver > > because the libc resolver can only do per-process caching versus > > system-wide caching, right? > > > > If so, wouldn't nscd be a lighter weight daemon for this purpose? > > dnsmasq is specifically designed for this purpose, and in fact upstream > has added dbus support to it specifically so it can integrate nicely > with NetworkManager. Why we're not using it, I don't know. NM doesn't actually use caching-nameserver at the moment. Bill From dgboles at gmail.com Thu Jun 14 18:55:44 2007 From: dgboles at gmail.com (David Boles) Date: Thu, 14 Jun 2007 11:55:44 -0700 Subject: system-config-selinux In-Reply-To: <46714BCC.7070505@redhat.com> References: <46704ED5.5000809@gmail.com> <46714B91.4080100@redhat.com> <46714BCC.7070505@redhat.com> Message-ID: <46718F30.8030207@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel J Walsh wrote: > Daniel J Walsh wrote: >> David Boles wrote: > /usr/bin/system-config-selinux crashes in development (Rawhide) and > is not > listed in Bugzilla. > > To what package should I report this? > > >> Anytime you find an app that crashes, figure out which rpm > package delivered it. > >> > >> rpm -qf /usr/bin/system-config-selinux > >> policycoreutils-gui-2.0.21-2.fc8 > >> > >> Then use that package. > >> > >> BTW policycoreutils-gui-2.0.21-2.fc8 fixes the problem >>> >> > Sorry responded to this email twice. (Now three times). I noticed that. ;-) Thanks for the info. I will remember that the next time. I would imagine that there might be a next time. ;-) I am one of those 'lucky users' I guess. You all do such a great job that I very seldom find any problems. - -- David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGcY8wrItTyWRhT1YRAmS3AKC3XbZGViFFPhW8g7CeQgI0PA7kBACgv1xf qsrrMCbyto0aaBAw8sqerUc= =XcYy -----END PGP SIGNATURE----- From dwmw2 at infradead.org Thu Jun 14 19:44:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 14 Jun 2007 20:44:33 +0100 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1180473516.6254.454.camel@localhost.localdomain> References: <1180473516.6254.454.camel@localhost.localdomain> Message-ID: <1181850273.25228.301.camel@pmac.infradead.org> On Tue, 2007-05-29 at 16:18 -0500, Tom "spot" Callaway wrote: > This is a very early draft of what I am planning on presenting to FESCo > in the near future: > > http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures > > I am very interested in comments and suggested changes. I know it's a wiki, but I didn't want to make changes you might not agree with -- so I've added a 'Dissent' section at the bottom, outlining the reasons why I strongly believe package builds should remain synchronous even on new architectures. -- dwmw2 From buildsys at fedoraproject.org Thu Jun 14 19:50:38 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 14 Jun 2007 15:50:38 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-14 Message-ID: <20070614195039.05A22152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 12 archivemail-0.7.0-6.fc6 balsa-2.3.16-2.fc6 CGAL-3.3-4.fc6 crystal-1.0.4-1.fc6 curry-0.9.11-1.fc6 NEW freetds-0.64-5.fc6 : Implementation of the TDS (Tabular DataStream) protocol NEW mdsplib-0.11-3.fc6 : METAR Decoder Software Package Library NEW php-pear-PhpDocumentor-1.3.2-2.fc6 : The complete documentation solution for PHP qt4-4.3.0-2.fc6 NEW wammu-0.19-2.fc6 : Mobile Phone Manager - Gammu GUI xemacs-21.5.28-2.fc6 xmlrpc-c-1.06.14-1.fc6 Packages built and released for Fedora Extras 5: 10 archivemail-0.7.0-6.fc5 balsa-2.3.16-3.fc5 CGAL-3.3-4.fc5 crystal-1.0.4-1.fc5 libtasn1-0.3.10-1.fc5 NEW mdsplib-0.11-3.fc5 : METAR Decoder Software Package Library mimetic-0.9.3-1.fc5 util-vserver-0.30.213-1.fc5 NEW wammu-0.19-2.fc5 : Mobile Phone Manager - Gammu GUI xmlrpc-c-1.06.14-1.fc5 Changes in Fedora Extras 6: archivemail-0.7.0-6.fc6 ----------------------- * Tue Jun 12 2007 Jon Ciesla 0.7.0-6 - Patch to fix imap handling, BZ 243846. balsa-2.3.16-2.fc6 ------------------ * Tue Jun 12 2007 Pawel Salek - 2.3.16-2 - Add libnotify buildreq. * Mon Jun 11 2007 Pawel Salek - 2.3.16-1 - Update to upstream 2.3.16. CGAL-3.3-4.fc6 -------------- * Thu Jun 07 2007 Laurent Rineau - 3.3-4.fc6 - Move the makefile back to %{_datadir}/CGAL, and rename it cgal.mk (sync with Debian package). That file is not a config file, but just an example .mk file that can be copied and adapted by users. - Fix the %{_sysconfdir}/profile.d/cgal.* files (the csh one was buggy). - CGAL-devel now requires all its dependancies. * Sat Jun 02 2007 Laurent Rineau - 3.3-2.fc6 - Officiel CGAL-3.3 release - Skip file named "skip_vcproj_auto_generation" * Wed May 30 2007 Laurent Rineau - 3.3-0.1.RC1.fc6 - New upstream version: 3.3-RC1 - Obsolete patches CGAL-3.2.1-build-libCGALQt-shared.patch, CGAL-3.2.1-build-no-static-lib.patch, CGAL-3.2.1-config.h-endianness_detection.patch. These patchs have been merged and adapted by upstream. - New option --disable-static - Shipped OpenNL and CORE have been renamed by upstream: - %{_includedir}/OpenNL is now /usr/include/CGAL/OpenNL - %{_includedir}/CORE is now /usr/include/CGAL/CORE - libCORE has been rename libCGALcore++ Reasons: - CGAL/OpenNL is a special version of OpenNL, rewritten for CGAL in C++ by the OpenNL author, - CGAL/CORE is a fork of CORE-1.7. CORE-1.7 is no longer maintained by its authors, and CORE-2.0 is awaited since 2004. In previous releases of this package, CORE was excluded from the package, because %{_includedir}/CORE/ was a name too generic (see comment #8 of %{_includedir}/CGAL/CORE, CORE is now shipped with CGAL. - move %{_datadir}/CGAL/make/makefile to %{_sysconfdir}/CGAL/makefile (because it is a config file). crystal-1.0.4-1.fc6 ------------------- * Wed Apr 25 2007 Chitlesh Goorah - 1.0.4-1 - New upstream release 1.0.4 curry-0.9.11-1.fc6 ------------------ * Tue Jun 12 2007 Gerard Milmeister - 0.9.11-1 - new version 0.9.11 freetds-0.64-5.fc6 ------------------ * Wed Jun 13 2007 Dmitry Butskoy - 0.64-5 - spec file cleanups - allowed for Fedora (no patent issues exist), clarification by James K. Lowden - approved for Fedora (review by Hans de Goede ) mdsplib-0.11-3.fc6 ------------------ * Fri Jun 08 2007 Matthias Saou 0.11-3 - Include patch from Hans de Goede to build the lib as shared. php-pear-PhpDocumentor-1.3.2-2.fc6 ---------------------------------- * Tue Jun 12 2007 Konstantin Ryabitsev - 1.3.2-2 - Require parent n-v-r instead of php-pear(pear-name) in phpdoc for simplicity * Sun Jun 10 2007 Konstantin Ryabitsev - 1.3.2-1 - Upstream 1.3.2 - Update the spec to the latest php-pear spec standards - Drop obsoleted patch qt4-4.3.0-2.fc6 --------------- * Wed May 30 2007 Rex Dieter 4.3.0-2 - ExclusiveArch: %ix86 -> i386 (for koji) * Wed May 30 2007 Rex Dieter 4.3.0-1 - qt-4.3.0(final) * Fri May 04 2007 Kevin Kofler 4.3.0-0.5.rc1 - update to 4.3.0 RC1 - drop LD_RUN_PATH hack * Fri May 04 2007 Kevin Kofler 4.3.0-0.3.snapshot20070423 - update to qt-4.3.0-snapshot-20070423 - build with SSL support (BR openssl-devel) - drop upstreamed mysql_config.patch * Wed May 02 2007 Rex Dieter 4.3.0-0.2.beta - qt-4.3.0beta - -system-libtiff, BR: libtiff-devel wammu-0.19-2.fc6 ---------------- * Wed Jun 06 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.19-2 - Fixed mixed-use-of-spaces warning. xemacs-21.5.28-2.fc6 -------------------- * Wed Jun 06 2007 Ville Skytt? - 21.5.28-2 - Set more dirs explicitly until upstream configure honors them better. - Borrow DESTDIR install patch from openSUSE. - Add pkgconfig file to -devel. * Mon May 21 2007 Ville Skytt? - 21.5.28-1 - 21.5.28, module path fix applied upstream. - Patch to retain courier as the default font. - Fix some corrupt characters in docs. * Fri May 18 2007 Ville Skytt? - 21.5.27-9 - Require one of the actual editor variants in -common. - Require -common in -el, drop duplicate dir ownerships. xmlrpc-c-1.06.14-1.fc6 ---------------------- * Thu Jun 14 2007 Enrico Scholz - 1.06.14-1 - updated to 1.06.14 Changes in Fedora Extras 5: archivemail-0.7.0-6.fc5 ----------------------- * Tue Jun 12 2007 Jon Ciesla 0.7.0-6 - Patch to fix imap handling, BZ 243846. balsa-2.3.16-3.fc5 ------------------ * Wed Jun 13 2007 Pawel Salek - 2.3.16-3 - s,disable-libnotify,without-libnotify, * Tue Jun 12 2007 Pawel Salek - 2.3.16-2 - Disable libnotify. * Tue Jun 12 2007 Pawel Salek - 2.3.16-1 - Update to upstream 2.3.16. CGAL-3.3-4.fc5 -------------- * Thu Jun 07 2007 Laurent Rineau - 3.3-4.fc5 - Move the makefile back to %{_datadir}/CGAL, and rename it cgal.mk (sync with Debian package). That file is not a config file, but just an example .mk file that can be copied and adapted by users. - Fix the %{_sysconfdir}/profile.d/cgal.* files (the csh one was buggy). - CGAL-devel now requires all its dependancies. * Sat Jun 02 2007 Laurent Rineau - 3.3-2.fc5 - Officiel CGAL-3.3 release - Skip file named "skip_vcproj_auto_generation" * Wed May 30 2007 Laurent Rineau - 3.3-0.1.RC1.fc5 - New upstream version: 3.3-RC1 - Obsolete patches CGAL-3.2.1-build-libCGALQt-shared.patch, CGAL-3.2.1-build-no-static-lib.patch, CGAL-3.2.1-config.h-endianness_detection.patch. These patchs have been merged and adapted by upstream. - New option --disable-static - Shipped OpenNL and CORE have been renamed by upstream: - %{_includedir}/OpenNL is now /usr/include/CGAL/OpenNL - %{_includedir}/CORE is now /usr/include/CGAL/CORE - libCORE has been rename libCGALcore++ Reasons: - CGAL/OpenNL is a special version of OpenNL, rewritten for CGAL in C++ by the OpenNL author, - CGAL/CORE is a fork of CORE-1.7. CORE-1.7 is no longer maintained by its authors, and CORE-2.0 is awaited since 2004. In previous releases of this package, CORE was excluded from the package, because %{_includedir}/CORE/ was a name too generic (see comment #8 of %{_includedir}/CGAL/CORE, CORE is now shipped with CGAL. - move %{_datadir}/CGAL/make/makefile to %{_sysconfdir}/CGAL/makefile (because it is a config file). crystal-1.0.4-1.fc5 ------------------- * Wed Apr 25 2007 Chitlesh Goorah - 1.0.4-1 - New upstream release 1.0.4 libtasn1-0.3.10-1.fc5 --------------------- * Thu Jun 14 2007 Enrico Scholz - 0.3.10-1 - updated to 0.3.10 mdsplib-0.11-3.fc5 ------------------ * Fri Jun 08 2007 Matthias Saou 0.11-3 - Include patch from Hans de Goede to build the lib as shared. mimetic-0.9.3-1.fc5 ------------------- * Thu Jun 14 2007 Enrico Scholz - 0.9.3-1 - updated to 0.9.3 util-vserver-0.30.213-1.fc5 --------------------------- * Thu May 31 2007 Enrico Scholz - 0.30.213-1 - updated to 0.30.213 - BR some tools tested by ./configure - enabled support for 'util-vserver' initscript wammu-0.19-2.fc5 ---------------- * Wed Jun 06 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.19-2 - Fixed mixed-use-of-spaces warning. xmlrpc-c-1.06.14-1.fc5 ---------------------- * Thu Jun 14 2007 Enrico Scholz - 1.06.14-1 - updated to 1.06.14 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From oliver at linux-kernel.at Thu Jun 14 20:13:34 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jun 2007 22:13:34 +0200 Subject: For your consideration: Secondary Architectures in Fedora In-Reply-To: <1181850273.25228.301.camel@pmac.infradead.org> References: <1180473516.6254.454.camel@localhost.localdomain> <1181850273.25228.301.camel@pmac.infradead.org> Message-ID: <4671A16E.1060800@linux-kernel.at> David Woodhouse schrieb: > On Tue, 2007-05-29 at 16:18 -0500, Tom "spot" Callaway wrote: >> This is a very early draft of what I am planning on presenting to FESCo >> in the near future: >> >> http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures >> >> I am very interested in comments and suggested changes. > > I know it's a wiki, but I didn't want to make changes you might not > agree with -- so I've added a 'Dissent' section at the bottom, outlining > the reasons why I strongly believe package builds should remain > synchronous even on new architectures. Yes, it is a Wiki: :-P https://fedoraproject.org/wiki/ArchTeam How do you like this? If you don't like it, just edit! -of From rdieter at math.unl.edu Thu Jun 14 20:27:49 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Jun 2007 15:27:49 -0500 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 References: <20070614152025.27947.93929@extras64.linux.duke.edu> <20070614191402.e3956c78.mschwendt.tmp0701.nospam@arcor.de> <200706141313.46898.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Thursday 14 June 2007 13:14:02 Michael Schwendt wrote: >> Jesse's advice doesn't apply, since your ppc64 build is included in the >> "Everything" repository. You cannot take it away with an update. It stays >> in that repo and in the metadata unless rel-eng modify the repo and >> drop the package. > > Which we're not likely to do. Making changes to the release tree is > unnecessarily difficult right now, as evidenced by trying to get signed > packages in place. > > Provided we don't have a release of "ppc64" but rather a ppc release that > is multilib with ppc64 I don't think this is a huge issue. I figured, but I thought it was worth asking. I'll (temporarily) chalk-it-up as one of those safely-ok-to-ignore items. -- Rex From mspevack at redhat.com Thu Jun 14 20:15:03 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 14 Jun 2007 16:15:03 -0400 (EDT) Subject: FC5 EOL on 2007-06-29 Message-ID: So I posted a general announcement to fedora-announce-list, but it's worth using our new fedora-devel-announce list to remind everyone that FC5 is EOL'd on June 29th. Jesse Keating is the guy to go to with any questions about how this will happen from the dev perspective. thanks, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From ajackson at redhat.com Thu Jun 14 20:25:57 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 14 Jun 2007 16:25:57 -0400 Subject: R500 initial driver release In-Reply-To: <1181829422.30663.72.camel@localhost.localdomain> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> Message-ID: <1181852757.30663.99.camel@localhost.localdomain> On Thu, 2007-06-14 at 09:57 -0400, Adam Jackson wrote: > On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: > > On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: > > > http://lwn.net/Articles/237920/rss > > > > So will someone be including this driver (this is in the kernel or xorg > > packages) in fc7 or I assume fc8? > > I need to test that it actually works on at least one piece of hardware > first. Well, it doesn't work on my T60p, for lack of PCI ID if nothing else. Test build: http://people.redhat.com/ajackson/avivo/ Requires libpciaccess, which thus far is only in rawhide, but should be in F-7 updates in the next push. Eats babies, etc. Once we actually have this working on at least one piece of kit out of the box I'll get it imported. - ajax From dyoung at mesd.k12.or.us Thu Jun 14 20:41:23 2007 From: dyoung at mesd.k12.or.us (Dan Young) Date: Thu, 14 Jun 2007 13:41:23 -0700 Subject: R500 initial driver release In-Reply-To: <1181852757.30663.99.camel@localhost.localdomain> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> <1181852757.30663.99.camel@localhost.localdomain> Message-ID: <994441ae0706141341occ72cdbh8e2925282fd443ba@mail.gmail.com> On 6/14/07, Adam Jackson wrote: > On Thu, 2007-06-14 at 09:57 -0400, Adam Jackson wrote: > > On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: > > > On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: > > > > http://lwn.net/Articles/237920/rss > > > > > > So will someone be including this driver (this is in the kernel or xorg > > > packages) in fc7 or I assume fc8? > > > > I need to test that it actually works on at least one piece of hardware > > first. > > Well, it doesn't work on my T60p, for lack of PCI ID if nothing else. Isn't that expected? The announcement said PCI IDs aren't included: http://article.gmane.org/gmane.comp.freedesktop.xorg/18856 "...it actually needs you to add your graphic card pci id in order for it to work." -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From nathanael at gnat.ca Thu Jun 14 20:42:19 2007 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Thu, 14 Jun 2007 14:42:19 -0600 Subject: R500 initial driver release In-Reply-To: <1181829422.30663.72.camel@localhost.localdomain> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> Message-ID: <4671A82B.3020503@gnat.ca> Adam Jackson wrote: > On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: >> On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: >>> http://lwn.net/Articles/237920/rss >> So will someone be including this driver (this is in the kernel or xorg >> packages) in fc7 or I assume fc8? > > I need to test that it actually works on at least one piece of hardware > first. > I tried it with my X1650 with no luck. Working with the developer to see if we can get it working. It seems fglrx needs to load and unload first... so maybe not such a good idea to supply it yet. It is also waiting on a patch to improve performance... -- Nathanael D. Noblet From ajackson at redhat.com Thu Jun 14 20:37:44 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 14 Jun 2007 16:37:44 -0400 Subject: R500 initial driver release In-Reply-To: <994441ae0706141341occ72cdbh8e2925282fd443ba@mail.gmail.com> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> <1181852757.30663.99.camel@localhost.localdomain> <994441ae0706141341occ72cdbh8e2925282fd443ba@mail.gmail.com> Message-ID: <1181853464.30663.101.camel@localhost.localdomain> On Thu, 2007-06-14 at 13:41 -0700, Dan Young wrote: > On 6/14/07, Adam Jackson wrote: > > On Thu, 2007-06-14 at 09:57 -0400, Adam Jackson wrote: > > > On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: > > > > On Tue, 2007-06-12 at 21:49 +0200, Florian La Roche wrote: > > > > > http://lwn.net/Articles/237920/rss > > > > > > > > So will someone be including this driver (this is in the kernel or xorg > > > > packages) in fc7 or I assume fc8? > > > > > > I need to test that it actually works on at least one piece of hardware > > > first. > > > > Well, it doesn't work on my T60p, for lack of PCI ID if nothing else. > > Isn't that expected? The announcement said PCI IDs aren't included: > http://article.gmane.org/gmane.comp.freedesktop.xorg/18856 > > "...it actually needs you to add your graphic card pci id in order for > it to work." It has some PCI IDs, just not all: static SymTabRec avivo_chips[] = { { PCI_CHIP_RV515_7142, "RV515 (Radeon X1300)" }, { PCI_CHIP_RV530_71C2, "RV530 (Radeon X1600)" }, { PCI_CHIP_RV530_71C5, "RV530 (Radeon X1600)" }, { PCI_CHIP_R580_724B, "R580 (Radeon X1900 GT)" }, { -1, NULL } }; If yours isn't in the list, well, there's the srpm for that... - ajax From giallu at gmail.com Thu Jun 14 21:11:27 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 14 Jun 2007 23:11:27 +0200 Subject: End of caching-nameserver package In-Reply-To: <46713D10.7080204@codewiz.org> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> Message-ID: On 6/14/07, Bernardo Innocenti wrote: > Adam Tkac wrote: > > Hi all, > > > > caching-nameserver package will be removed and configfiles will be moved > > into main bind package. I did this decision because people often tell me > > something like "Where is default /etc/named.conf?" and I tell them > > "Please install caching-nameserver". So if you install bind package you > > have also default configuration which is usable for caching-nameserver. > > By the way, I always wanted to ask... we use caching-nameserver > because the libc resolver can only do per-process caching versus > system-wide caching, right? > > If so, wouldn't nscd be a lighter weight daemon for this purpose? +1 /me just loves dnsmasq.... From david at fubar.dk Thu Jun 14 22:31:10 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 14 Jun 2007 18:31:10 -0400 Subject: R500 initial driver release In-Reply-To: <1181852757.30663.99.camel@localhost.localdomain> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> <1181852757.30663.99.camel@localhost.localdomain> Message-ID: <1181860270.3555.14.camel@zelda.fubar.dk> On Thu, 2007-06-14 at 16:25 -0400, Adam Jackson wrote: > Once we actually have this working on at least one piece of kit out of > the box I'll get it imported. Tried this on my MacbookPro1,1 (about a year old) with X1600/M56P using Bootcamp. The vesa driver works fine on this box although not in the native resolution - Using 'system-config-display --reconfig --noui --set-driver avivo --set-depth 24 --set-resolution=1440x900' - Had to reboot to get it to work; it consistently locked-up if I tried it after using fglrx - X.org output here; in hope it's useful http://people.freedesktop.org/~david/avivo-xorg.log - Performance is bad; I didn't try alexl's ShadowFB patch though. - VT switching either causes X server restart or locks up the box - The screen is flickering; it's especially visible with dark colors; some timing / modeline issue? - On the positive side, apart from the driver actually working, it seems that the artifacts in fglrx (and, fwiw, the ATI Windows drivers as well - I have Win XP and OS X on the box too) have been fixed. The artifact, in a nutshell, is that even though you have a solid color in your framebuffer it comes out on the LCD with an overlay of noise in the luminance channel (brings back memories from the Amiga's half-brite mode). Compare yourself flgrx: http://flickr.com/photos/davidz/549360382/ avivo: http://flickr.com/photos/davidz/549360762/ Thanks, David From mike at miketc.com Fri Jun 15 02:46:52 2007 From: mike at miketc.com (Mike Chambers) Date: Thu, 14 Jun 2007 21:46:52 -0500 Subject: R500 initial driver release In-Reply-To: <1181852757.30663.99.camel@localhost.localdomain> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> <1181852757.30663.99.camel@localhost.localdomain> Message-ID: <1181875613.2370.2.camel@scrappy.miketc.com> On Thu, 2007-06-14 at 16:25 -0400, Adam Jackson wrote: > Well, it doesn't work on my T60p, for lack of PCI ID if nothing else. > > Test build: > > http://people.redhat.com/ajackson/avivo/ Didn't work on my x1300 neither. Lack of PCI ID I guess as well. Is any of this stuff getting reported upstream already, and/or do we need to open a bug # to help keep track here to help keep up with the progress or anything? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From kevin.kofler at chello.at Fri Jun 15 04:50:54 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 04:50:54 +0000 (UTC) Subject: XFCE desktop needs ... tetex ? References: <645d17210706061527k5237fe0ci7c7aeccdd8e9f5a@mail.gmail.com> Message-ID: Jonathan Underwood gmail.com> writes: > > I trimmed down the output from yum to show the dependency chain. > > xfprint requires a2ps which requires tetex. > > Hm. I wonder if xfprint could be patched to use enscript instead of > a2ps - enscript doesn't have such dependencies. What's wrong with using LaTeX for printing? It's one of the best Free Software PostScript generators out there. Kevin Kofler From kevin.kofler at chello.at Fri Jun 15 04:58:37 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 04:58:37 +0000 (UTC) Subject: RFR: GIT Package VCS References: <1181152249.22157.44.camel@localhost.localdomain> <1181233295.4070.81.camel@localhost.localdomain> <1181237674.17222.8.camel@rousalka.dyndns.org> <1181239570.4070.109.camel@localhost.localdomain> <1181241459.18723.13.camel@rousalka.dyndns.org> <1181246416.4070.201.camel@localhost.localdomain> <1181247902.18723.44.camel@rousalka.dyndns.org> <1181250296.3472.23.camel@rousalka.dyndns.org> <20070608001130.GP16879@petra.dvoda.cz> <20070610182023.GA29512@redhat.com> <20070610231859.GQ16879@petra.dvoda.cz> Message-ID: Karel Zak redhat.com> writes: > The problem is that the method we use today doesn't support anything > like rediffing. The "rediff 1-2" is nightmare with rpmbuild + > gendiff. I don't even use gendiff, the way I rediff patches is that I just untar the upstream tarball, make a second copy of the directory, apply the patches, fix the rejects, then run diff -Nur. :-) However, that'd be a pain for something like the kernel where I'd first have to apply the hundreds of previous patches to make sure I rediff against the source the patch actually has to apply to. Luckily, I don't have to deal with a package with that many patches. If I did, I'd probably pick the "one big patchset" approach I'm using for TIGCC's heavily-patched GCC, which is ideal when working this way. Kevin Kofler From rc040203 at freenet.de Fri Jun 15 05:09:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 Jun 2007 07:09:24 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <467180A5.5030305@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> Message-ID: <1181884164.13412.45.camel@mccallum.corsepiu.local> On Thu, 2007-06-14 at 11:53 -0600, Brendan Conoboy wrote: > Ralf Corsepius wrote: > > Not quite. You end up with the target's sys-root's files ("target > > binaries", blobs of arbitrary binary data) inside of a "noarch" rpm. > > Er, if you're building an arm-linux toolchain and store the sysroot in a > noarch rpm, that's still wrong arch :-) Why? To the host, a target's binaries are non-executable, host-independent blobs of binary data (==arch). > Not *as* wrong as having it in > an RPM for the build host's arch, but not as right as having it for the > target arch. That's right. But consider: a cross-toolchain is an ordinary (host) native application, accessing target-files as ordinary data files when its is executed. I.e. a -gcc running on accessing the target's libc basically does the same as a GUI application loading a *.png. > > Well, IMO this plan is not useful and doesn't fit into the working > > principles of rpm, because it confuses host architecture with target > > architecture. > > Eh? Let me try to elaborate: You want to mix different archs inside of the host's rpmdb. This doesn't harmonize with current rpm/rpmdb's concepts, because rpm/rpmdb doesn't have a concept of "targets". All it has is "host-independent" (==noarch) and "host-dependent" (==) > > What I could envision to be made functional is a wrapper around rpm, > > using another "per-cross-target" rpmdb to add native target rpms into > > sys-roots. > > If I understand you correctly, that sounds about right. I noticed some mails outlining similar thoughts had crossed when writing the sentence above :) What I had in mind was to "installing foreign rpms" onto a secondary "target rpmdb" and to reuse them for cross-compilers: Very oversimplified, this would mean to install target-rpms into a separate rpm-based "root" with it's own rpmdb, similar to this: /usr/bin/-gcc /var/lib/rpm/ <--- "host rpmdb" ... /usr/share//sys-root/var/lib/rpm <--- "target rpmdb". In this example, target files administered inside of the "target rpmdb" would be used for applications administered inside of the "host rpmdb". rpm-wise the working principle probably would be very similar to that of how mock and mach setup their chroots. > When cross > building you need to pull in a mixture of native (host-arch) and cross > (target arch) packages to meet the build dependencies. This is part of > where the "fun" is. Well, I question the "need", but consider this kind of implementation to be "an option". Ralf From kevin.kofler at chello.at Fri Jun 15 05:36:27 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 05:36:27 +0000 (UTC) Subject: Reply-To header munging for fedora-devel-list References: <46689424.5030009@codewiz.org> <20070608100217.GA30585@neu.nirvana> <4669D4B6.5070209@codewiz.org> <20070609070226.GA4852@neu.nirvana> Message-ID: Benny Amorsen amorsen.dk> writes: > You can participate just fine without subscribing. That's what gmane > is for. Right, this message is being posted through the GMane web interface. Actually, all my messages on this list are. :-) > Requiring subscriptions breaks posting from gmane for no reason. Subscriptions are required, but the GMane gateway is explicitly exempted from that, which is a good thing. :-) Kevin Kofler From andy at warmcat.com Fri Jun 15 06:01:08 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 15 Jun 2007 07:01:08 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <1181884164.13412.45.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> Message-ID: <46722B24.9000606@warmcat.com> Ralf Corsepius wrote: > On Thu, 2007-06-14 at 11:53 -0600, Brendan Conoboy wrote: >> Ralf Corsepius wrote: >>> Not quite. You end up with the target's sys-root's files ("target >>> binaries", blobs of arbitrary binary data) inside of a "noarch" rpm. >> Er, if you're building an arm-linux toolchain and store the sysroot in a >> noarch rpm, that's still wrong arch :-) > Why? To the host, a target's binaries are non-executable, > host-independent blobs of binary data (==arch). > >> Not *as* wrong as having it in >> an RPM for the build host's arch, but not as right as having it for the >> target arch. > That's right. > > But consider: a cross-toolchain is an ordinary (host) native > application, accessing target-files as ordinary data files when its is > executed. Yep clearly a cross compiler that runs on an i386 host and emits ARM or any other target code is an i386 app destined for installation on i386 boxes, it would be something like gcc-arm5-linux-4.2-123.i386.rpm. >>> What I could envision to be made functional is a wrapper around rpm, >>> using another "per-cross-target" rpmdb to add native target rpms into >>> sys-roots. >> If I understand you correctly, that sounds about right. > I noticed some mails outlining similar thoughts had crossed when writing > the sentence above :) Agreement is usually a good sign :-) >> When cross >> building you need to pull in a mixture of native (host-arch) and cross >> (target arch) packages to meet the build dependencies. This is part of >> where the "fun" is. > Well, I question the "need", but consider this kind of implementation to > be "an option". It can be necessary though, for example if the package build wants yacc or bison or whatever to build, with cross building they are going to be host yacc and bison despite you are building for a different target arch -- it should go look in the host rpmdb to confirm they are available. But if it wants libsomething-devel to build, because it knows it will be compiling against it, it is talking about the target arch libsomething-devel that it wants to see installed in the arch chroot rpmdb. The only full answer I can think of is to improve rpmbuild and the BuildRequires syntax to allow, eg, yacc.host to be specified and to have it check in the right rpmdb, the cheap dirty answer is to ignore the build requires for cross and wait for the build error. Another idea, I think fakeroot would be super good for accessing the target arch chroots. For example that way your build user can automate refresh of the libs and -devel stuff in the chroot, ie, you rebuild libblah for a traget arch, and after a successful build libblah.arch and libblah-devel.arch are rpm -Uvf'd into the arch chroot using fakeroot as part of a cross build script, without needing true root. -Andy From rc040203 at freenet.de Fri Jun 15 07:06:47 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 Jun 2007 09:06:47 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46722B24.9000606@warmcat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> Message-ID: <1181891208.13412.80.camel@mccallum.corsepiu.local> On Fri, 2007-06-15 at 07:01 +0100, Andy Green wrote: > Ralf Corsepius wrote: > > On Thu, 2007-06-14 at 11:53 -0600, Brendan Conoboy wrote: > >> Ralf Corsepius wrote: > >>> Not quite. You end up with the target's sys-root's files ("target > >>> binaries", blobs of arbitrary binary data) inside of a "noarch" rpm. > >> Er, if you're building an arm-linux toolchain and store the sysroot in a > >> noarch rpm, that's still wrong arch :-) > > Why? To the host, a target's binaries are non-executable, > > host-independent blobs of binary data (==arch). Typo: s/arch/noarch/ > >> Not *as* wrong as having it in > >> an RPM for the build host's arch, but not as right as having it for the > >> target arch. > > That's right. > > > > But consider: a cross-toolchain is an ordinary (host) native > > application, accessing target-files as ordinary data files when its is > > executed. > > Yep clearly a cross compiler that runs on an i386 host and emits ARM or > any other target code is an i386 app destined for installation on i386 > boxes, it would be something like gcc-arm5-linux-4.2-123.i386.rpm. I prefer using -gcc-*.i386.rpm If sys-rooting such a toolchain, it's toolchain's target-libs could be packaged into a -sys-root-*.noarch.rpm Due to rpm's limitations, this isn't easy to implement with "one-tree style builts" (building GCC and libc in one build run) of a toolchain, but it is pretty straight forward, when repackaging target-library binaries or building a toolchain incrementally. > >> When cross > >> building you need to pull in a mixture of native (host-arch) and cross > >> (target arch) packages to meet the build dependencies. This is part of > >> where the "fun" is. > > Well, I question the "need", but consider this kind of implementation to > > be "an option". > > It can be necessary though, for example if the package build wants yacc > or bison or whatever to build, with cross building they are going to be > host yacc and bison despite you are building for a different target arch If I understand you correctly the problem you are referring to is separating "tools being used at build-time on the host" from "tools being used at run-time on the target". (Classic situation: building inserts hard-coded directories/paths referring to files on the build-host into target-files) Yes, this is a problem. I am not aware about a general solution nor do I have solution, either. > -- it should go look in the host rpmdb to confirm they are available. > But if it wants libsomething-devel to build, because it knows it will be > compiling against it, it is talking about the target arch > libsomething-devel that it wants to see installed in the arch chroot > rpmdb. The only full answer I can think of is to improve rpmbuild and > the BuildRequires syntax to allow, eg, yacc.host to be specified and to > have it check in the right rpmdb, the cheap dirty answer is to ignore > the build requires for cross and wait for the build error. This is a different problem, it's cross-"rpmbuild-ing" target-native-rpms. The result would be a *..rpm. What I am doing is aiming at cross-building target-binaries, not target packages/rpms. > Another idea, I think fakeroot would be super good for accessing the > target arch chroots. For example that way your build user can automate > refresh of the libs and -devel stuff in the chroot, ie, you rebuild > libblah for a traget arch, and after a successful build libblah.arch and > libblah-devel.arch are rpm -Uvf'd into the arch chroot using fakeroot as > part of a cross build script, without needing true root. Ralf From oliver at linux-kernel.at Fri Jun 15 07:13:40 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 15 Jun 2007 09:13:40 +0200 Subject: ArchTeam Wiki page(s) (WAS: Re: For your consideration: Secondary Architectures in Fedora) In-Reply-To: <4671A16E.1060800@linux-kernel.at> References: <1180473516.6254.454.camel@localhost.localdomain> <1181850273.25228.301.camel@pmac.infradead.org> <4671A16E.1060800@linux-kernel.at> Message-ID: <46723C24.1010906@linux-kernel.at> On 06/14/2007 10:13 PM, Oliver Falk wrote: > David Woodhouse schrieb: >> On Tue, 2007-05-29 at 16:18 -0500, Tom "spot" Callaway wrote: >>> This is a very early draft of what I am planning on presenting to FESCo >>> in the near future: >>> >>> http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures >>> >>> I am very interested in comments and suggested changes. >> >> I know it's a wiki, but I didn't want to make changes you might not >> agree with -- so I've added a 'Dissent' section at the bottom, outlining >> the reasons why I strongly believe package builds should remain >> synchronous even on new architectures. > > Yes, it is a Wiki: :-P > https://fedoraproject.org/wiki/ArchTeam > > How do you like this? If you don't like it, just edit! Hmmm. No feedback, but spot added his stuff. Great. I would like to invite s390, PowerPC and others to also add their team/resources. Thomas, can you add some words about this in your next Fedora Weekly News? Best, Oliver From andy at warmcat.com Fri Jun 15 07:25:16 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 15 Jun 2007 08:25:16 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <1181891208.13412.80.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> Message-ID: <46723EDC.8060004@warmcat.com> Ralf Corsepius wrote: >> Yep clearly a cross compiler that runs on an i386 host and emits ARM or >> any other target code is an i386 app destined for installation on i386 >> boxes, it would be something like gcc-arm5-linux-4.2-123.i386.rpm. > I prefer using -gcc-*.i386.rpm Well it's not important to me either way sounds good. > Due to rpm's limitations, this isn't easy to implement with "one-tree > style builts" (building GCC and libc in one build run) of a toolchain, > but it is pretty straight forward, when repackaging target-library > binaries or building a toolchain incrementally. > >>>> When cross >>>> building you need to pull in a mixture of native (host-arch) and cross >>>> (target arch) packages to meet the build dependencies. This is part of >>>> where the "fun" is. >>> Well, I question the "need", but consider this kind of implementation to >>> be "an option". >> It can be necessary though, for example if the package build wants yacc >> or bison or whatever to build, with cross building they are going to be >> host yacc and bison despite you are building for a different target arch > If I understand you correctly the problem you are referring to is > separating "tools being used at build-time on the host" from > "tools being used at run-time on the target". > (Classic situation: building inserts hard-coded directories/paths > referring to files on the build-host into target-files) No the issue I (and Brendan I believe) am talking about is, "BuildRequires... required where?". Consider BuildRequires: yacc libblah-devel rpmbuild should go and confirm that the packages mentioned here are installed before doing the build. The issue is that for cross, it has to go and check that yacc is installed in the *host* rpmdb, and that libblah-devel is installed in the *arch chroot* rpmdb. The reason is that yacc is going to get executed on the host as part of the build action, but libblah-devel is going to get linked against in the target arch chroot world. It's therefore not useful if you have a host version of libblah-devel installed or you have a target arch version of yacc installed in the arch chroot. At the moment there is no way to differentiate between these two kind of Build requirements, I propose a full solution is BuildRequires: yacc.host libblah-devel and rpmbuild is enhanced to check in the right rpmdb accordingly. A cheap and dirty solution is to ignore BuildRequires completely when the target arch != host arch and you will find out if there is a problem from build errors... hm I guess ./configure might be too smart if there are missing libs though and just turn stuff off without errors... hm... > Yes, this is a problem. I am not aware about a general solution nor do I > have solution, either. > >> -- it should go look in the host rpmdb to confirm they are available. >> But if it wants libsomething-devel to build, because it knows it will be >> compiling against it, it is talking about the target arch >> libsomething-devel that it wants to see installed in the arch chroot >> rpmdb. The only full answer I can think of is to improve rpmbuild and >> the BuildRequires syntax to allow, eg, yacc.host to be specified and to >> have it check in the right rpmdb, the cheap dirty answer is to ignore >> the build requires for cross and wait for the build error. > This is a different problem, it's cross-"rpmbuild-ing" > target-native-rpms. The result would be a *..rpm. > > What I am doing is aiming at cross-building target-binaries, not target > packages/rpms. I assume this was a misunderstanding of what I was describing above (or perhaps I can say the fruit of my not explaining it well enough). -Andy From sb at monkey-mind.net Fri Jun 15 07:44:41 2007 From: sb at monkey-mind.net (Steven Bakker) Date: Fri, 15 Jun 2007 09:44:41 +0200 Subject: F8devel - user configuration storage locations In-Reply-To: References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <20070614045607.GA17173@serv.smile.org.ua> Message-ID: <20070615094441.1482e8aa@cluestix.noc.ams-ix.net> On Thu, 14 Jun 2007 11:03:20 -0400 Tony Nelson wrote: > >> cp -a ~/.* > >Not simple. If you do that you'll try to copy over the parent tree due to > >'..' (that is satisfy your code) represents parent and '.' represents > >current folder. > > Not simple, but how about: > > cp -a ~/.[!.]* . chsh -s /bin/zsh cp -a ~/.* ;-) From rc040203 at freenet.de Fri Jun 15 08:09:56 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 Jun 2007 10:09:56 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46723EDC.8060004@warmcat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> Message-ID: <1181894996.13412.116.camel@mccallum.corsepiu.local> On Fri, 2007-06-15 at 08:25 +0100, Andy Green wrote: > Ralf Corsepius wrote: > >>>> When cross > >>>> building you need to pull in a mixture of native (host-arch) and cross > >>>> (target arch) packages to meet the build dependencies. This is part of > >>>> where the "fun" is. > >>> Well, I question the "need", but consider this kind of implementation to > >>> be "an option". > >> It can be necessary though, for example if the package build wants yacc > >> or bison or whatever to build, with cross building they are going to be > >> host yacc and bison despite you are building for a different target arch > > > If I understand you correctly the problem you are referring to is > > separating "tools being used at build-time on the host" from > > "tools being used at run-time on the target". > > (Classic situation: building inserts hard-coded directories/paths > > referring to files on the build-host into target-files) > > No the issue I (and Brendan I believe) am talking about is, > "BuildRequires... required where?". Consider > > BuildRequires: yacc libblah-devel Understood. > rpmbuild should go and confirm that the packages mentioned here are > installed before doing the build. Hmm, difficult. One would have find a way to map "native BuildRequires" into * build-requires on "build-tools" on the host (e.g. to translate BR: gcc => -gcc) * cross-host's target-link-library build-requires (E.g. to translate BR: libncurses-devel => -libncurses-devel). > The issue is that for cross, it has to go and check that yacc is > installed in the *host* rpmdb, and that libblah-devel is installed in > the *arch chroot* rpmdb. The reason is that yacc is going to get > executed on the host as part of the build action, but libblah-devel is > going to get linked against in the target arch chroot world. > > It's therefore not useful if you have a host version of libblah-devel > installed or you have a target arch version of yacc installed in the > arch chroot. Right. > At the moment there is no way to differentiate between these two kind of > Build requirements, I propose a full solution is > > BuildRequires: yacc.host libblah-devel > > and rpmbuild is enhanced to check in the right rpmdb accordingly. Hmm, ... > A cheap and dirty solution is to ignore BuildRequires completely when > the target arch != host arch and you will find out if there is a problem > from build errors... Wrt. Fedora->Fedora there probably is simpler "hack": Treat BuildRequires as identical on target and on host => install them both. > hm I guess ./configure might be too smart if there > are missing libs though and just turn stuff off without errors... hm... Yes, such cases exist. One classical case is configure --build= --host= and not having a ->-gcc installed. The standard autoconf checks will then fall back to using the native tools. Depending on a package's details the result will either be building for the wrong architecture, or a package bombing out somewhere midst building. > > What I am doing is aiming at cross-building target-binaries, not target > > packages/rpms. > > I assume this was a misunderstanding of what I was describing above (or > perhaps I can say the fruit of my not explaining it well enough). Seems so :) Ralf From atkac at redhat.com Fri Jun 15 08:21:08 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 15 Jun 2007 10:21:08 +0200 Subject: R500 initial driver release In-Reply-To: <1181852757.30663.99.camel@localhost.localdomain> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> <1181852757.30663.99.camel@localhost.localdomain> Message-ID: <46724BF4.1090303@redhat.com> Adam Jackson napsal(a): > > Well, it doesn't work on my T60p, for lack of PCI ID if nothing else. > Same problems :( -A- From ml at deadbabylon.de Fri Jun 15 08:45:10 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Fri, 15 Jun 2007 10:45:10 +0200 Subject: Bugzillas for yum-plugins? Message-ID: <200706151045.15294.ml@deadbabylon.de> Hi. Just a short question: The plugins for yum aren't existing as components in bugzilla. Against which package should I fill a bug? In my case it would be yum-merge-conf which is missing vim-enhanced as a require. So the diff would fail. Sebastian BTW: Some plugins have koji as vendor and packager. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Jun 15 08:57:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 Jun 2007 10:57:23 +0200 Subject: bodhi server error Message-ID: <1181897843.13412.126.camel@mccallum.corsepiu.local> Bodhi bombs out with the error when accessing this URL: https://admin.fedoraproject.org/updates/testing/F7/mock-0.7.1-1.fc7 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. Powered by CherryPy 2.2.1 From opensource at till.name Fri Jun 15 09:17:10 2007 From: opensource at till.name (Till Maas) Date: Fri, 15 Jun 2007 11:17:10 +0200 Subject: Bugzillas for yum-plugins? In-Reply-To: <200706151045.15294.ml@deadbabylon.de> References: <200706151045.15294.ml@deadbabylon.de> Message-ID: <200706151117.12591.opensource@till.name> On Fr Juni 15 2007, Sebastian Vahl wrote: > Just a short question: The plugins for yum aren't existing as components in > bugzilla. Against which package should I fill a bug? It should be yum-utils, at least the changelog plugin is build from the yum-utils src.rpm, you can see this in the output of "rpm -qi". Regards, Till From hk at circlestorm.org Fri Jun 15 09:23:58 2007 From: hk at circlestorm.org (Hans K. Rosbach) Date: Fri, 15 Jun 2007 11:23:58 +0200 Subject: fedora-logos dependencies in F7 Message-ID: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> Grub depends on fedora-logos that in turn depends on gtk2-engines and pretty soon you have pulled in most of the X libraries. Thats an aweful lot to require for a boot menu, and we didn't have this problem for FC4, FC5 and FC6 atleast. Hope this will be fixed atleast in rawhide. Is there any reason for the logos package to depend on gtk2-engines at all? Shouldn't it be the other way around? -HK From buildsys at redhat.com Fri Jun 15 09:26:01 2007 From: buildsys at redhat.com (Build System) Date: Fri, 15 Jun 2007 05:26:01 -0400 Subject: rawhide report: 20070615 changes Message-ID: <200706150926.l5F9Q1Mv012457@porkchop.devel.redhat.com> New package avr-gdb GDB for (remote) debugging avr binaries New package conduit A synchronization solution for GNOME New package mdsplib METAR Decoder Software Package Library Updated Packages: aspell-nl-51:0.1e-5.fc8 ----------------------- * Thu Jun 14 2007 Ivana Varekova - 51:0.1e-5 - Resolves: #244159 add nl.rws * Fri Mar 30 2007 Ivana Varekova - 51:0.1e-4 - add nl_affix.dat * Fri Mar 30 2007 Ivana Varekova - 51:0.1e-3 - use configure script to create Makefile - update default buildroot - some minor spec changes bind-31:9.4.1-6.fc8 ------------------- * Tue Jun 12 2007 Adam Tkac 31:9.4.1-6.fc8 - major changes in initscript. Could be LSB compatible now - removed caching-nameserver subpackage. Move configs from this package to main bind package as default configuration and major configuration cleanup bluez-gnome-0.8-1.fc8 --------------------- * Thu Jun 14 2007 - Bastien Nocera - 0.8-1 - Update to 0.8 - Punt outdated patches - Add man pages, and translations - Add GConf and desktop file updating scriplets ddclient-3.7.2-1.fc8 -------------------- * Thu Jun 14 2007 Ville Skytt?? - 3.7.2-1 - 3.7.2. - Tweak default config to send less mail (eg. not on every shutdown). em8300-kmod-0.16.2-7.2.6.21_1.3228.fc7 -------------------------------------- * Thu Jun 14 2007 Ville Skytt?? - Rebuild for kernel 2.6.21-1.3228.fc7. evolution-2.11.3-5.fc8 ---------------------- * Thu Jun 14 2007 Matthew Barnes - 2.11.3-5.fc8 - Add patch for GNOME bug #447727 (remove EClippedLabel). * Wed Jun 06 2007 Matthew Barnes - 2.11.3-4.fc8 - Revise patch for GNOME bug #362638 to fix RH bug #240507 (hang on exit). * Wed Jun 06 2007 Matthew Barnes - 2.11.3-3.fc8 - Remove some debug messages that accidentally slipped in. evolution-data-server-1.11.3-2.fc8 ---------------------------------- * Thu Jun 14 2007 Matthew Barnes - 1.11.3-2.fc8 - Add patch for GNOME bug #312584 (renaming Exchange folders). farsight-0.1.20-1.fc8 --------------------- * Thu Jun 14 2007 Brian Pepple - 0.1.20-1 - Update to 0.1.20. foomatic-3.0.2-49.fc8 --------------------- * Thu Jun 14 2007 Tim Waugh 3.0.2-49 - Safe default margins for PPDs (bug #244161). - Added missing IEEE 1284 ID for HP Photosmart 380 (bug #241352). * Thu Jun 14 2007 Tim Waugh 3.0.2-48 - Updated db to 3.0-20070614. - Updated db-engine to 3.0-20070614. - Updated db-hpijs to 20070614. - Updated filters to 3.0-20070614. gnome-menus-2.19.3-2.fc8 ------------------------ * Thu Jun 14 2007 Colin Walters - 2.19.3-2 - Add patch gnome-menus-pythread-bgo442747.patch gscan2pdf-0.9.10-2.fc8 ---------------------- * Thu Jun 14 2007 Bernard Johnson - 0.9.10-2 - patch to fix paper size of output pdf file hal-cups-utils-0.6.11-2.fc8 --------------------------- * Thu Jun 14 2007 Tim Waugh 0.6.11-2 - Bumped system-config-printer-libs requirement to make sure that the PPDs class is available. - Removed explicit build dependency on cups; it's cups-devel we need. * Thu Jun 14 2007 Tim Waugh 0.6.11-1 - 0.6.11: - Fixed libhal API usage (bug #243165). - Use new PPDs class from system-config-printer to match Device IDs. hplip-1.7.4a-2.fc8 ------------------ * Thu Jun 14 2007 Tim Waugh 1.7.4a-2 - Don't try to write a /root/.hplip.conf file when running as a CUPS backend (bug #244205). hunspell-pl-0.20070614-1.fc8 ---------------------------- * Thu Jun 14 2007 Caolan McNamara - 0.20070614-1 - latest version hyperestraier-1.4.10-2.fc8 -------------------------- * Sat Jun 16 2007 Mamoru Tasaka - 1.4.10-2 - Fix java directory icu4j-0:3.6.1-1jpp.1.fc8 ------------------------ * Thu Jun 07 2007 Ben Konrath - 0:3.6.1-1jpp.1 - 3.6.1. - Enable eclipse sub-package. kid3-0.9-1.fc8 -------------- * Wed Jun 13 2007 Ville Skytt?? - 0.9-1 - 0.9. liberation-fonts-0.2-1.fc8 -------------------------- * Thu Jun 14 2007 Caius Chance 0.2-1.fc8 - Updated new source tarball from upstream: '-3' (version 0.2). libraw1394-1.2.1-8.fc8 ---------------------- * Thu Jun 14 2007 Jarod Wilson - 1.2.1-8 - Switch kernel Requires to a Conflicts so we don't end up pulling kernels into build chroot, and bump to GA kernel ver libtunepimp-0.5.3-5.fc8 ----------------------- * Thu Jun 14 2007 Rex Dieter 0.5.3-5 - respin (again for libmpcdec), BR: libmpcdec-devel >= 1.2.6 (#244228) mimetic-0.9.3-1.fc8 ------------------- * Thu Jun 14 2007 Enrico Scholz - 0.9.3-1 - updated to 0.9.3 mock-0.7.1-1.fc8 ---------------- * Wed Jun 13 2007 Michael Brown - 0.7.1-1 - Fix problem with autocache where different users couldnt share same cache - Fix problem creating resolv.conf in rootfs - cleanup perms on rootfs /etc/ * Tue Jun 12 2007 Michael Brown - 0.7.1-1 - add EPEL 5 config files obconf-2.0.1-1.fc8 ------------------ * Thu Jun 14 2007 Miroslav Lichvar - 2.0.1-1 - Update to 2.0.1 postfix-2:2.4.3-2.fc8 --------------------- * Thu Jun 14 2007 Thomas Woerner 2:2.4.3-2 - diabled mysql support again (rhbz#185515) - added support flag for PostgreSQL build (rhbz#180579) Ben: Thanks for the patch - Fixed remaining rewiew problems (rhbz#226307) * Tue Jun 05 2007 Thomas Woerner 2:2.4.3-1 - allow to build without LDAP but SASL2 support (rhbz#216792) * Tue Jun 05 2007 Thomas Woerner 2:2.4.3-1 - new stable version 2.4.3 - enabled mysql support (rhbz#185515) - dropped build requirements for gawk, ed and sed pyparted-1.8.8-1.fc8 -------------------- * Fri Jun 15 2007 David Cantrell - 1.8.8-1 - Clean up wording in package description (#226337) - BR pkgconfig (#226337) * Fri Jun 15 2007 David Cantrell - 1.8.7-1 - Merge review (#226337) * Mon Apr 23 2007 David Cantrell - 1.8.6-2 - Ensure build env CFLAGS are included (#226337) qdbm-1.8.75-3.fc8 ----------------- * Sat Jun 16 2007 Mamoru Tasaka - 1.8.75-3 - Fix java directory rss-glx-0.8.1.p-7.fc8 --------------------- * Thu Jun 14 2007 Nils Philippsen 0.8.1.p-7 - build xscreensaver hack description files (#200881) - require %{bindir}/kxsconfig (#219106) seedit-2.1.1-2.fc8.1 -------------------- starfighter-1.1-9.fc8 --------------------- * Thu Jun 14 2007 Matthias Saou 1.1-9 - Move binary and data to "proper" locations by updating patch (#229197). sysprof-kmod-1.0.8-1.2.6.21_1.3194.fc7 -------------------------------------- system-config-samba-1.2.42-1.fc8 -------------------------------- * Thu Jun 14 2007 Nils Philippsen - 1.2.42 - don't mask workgroup key when set to default value "workgroup" (#244169) * Tue Apr 24 2007 Nils Philippsen - don't mark stuff translatable where it doesn't make sense (#237277) - merge translatable strings that only differ in case (#237275) tasks-0.8-1.fc8 --------------- * Thu Jun 14 2007 Dan Young - 0.8-1 - New upstream release telepathy-mission-control-4.24-3.fc8 ------------------------------------ vavoom-1.24-1.fc8 ----------------- * Thu Jun 14 2007 Hans de Goede 1.24-1 - New upstream release 1.24 - This also fixes bug 241611 viruskiller-1.0-4.fc8 --------------------- * Thu Jun 14 2007 Matthias Saou 1.0-4 - Move binary and data to "proper" locations by updating patch (#243031). - Remove executable bit from all files from the archive, it shouldn't be set. wallpapoz-0.4.1-1.fc8 --------------------- * Thu Jun 14 2007 Mamoru Tasaka - 0.4.1-1 - 0.4.1 xmlrpc-c-1.06.14-1.fc8 ---------------------- * Thu Jun 14 2007 Enrico Scholz - 1.06.14-1 - updated to 1.06.14 Broken deps for i386 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 postfix-pflogsumm - 2:2.4.3-2.fc8.i386 requires postfix = 0:2.4.3-2.fc8 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 postfix-pflogsumm - 2:2.4.3-2.fc8.x86_64 requires postfix = 0:2.4.3-2.fc8 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 postfix-pflogsumm - 2:2.4.3-2.fc8.ppc requires postfix = 0:2.4.3-2.fc8 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 postfix-pflogsumm - 2:2.4.3-2.fc8.ppc64 requires postfix = 0:2.4.3-2.fc8 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 From atkac at redhat.com Fri Jun 15 09:31:07 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 15 Jun 2007 11:31:07 +0200 Subject: End of caching-nameserver package In-Reply-To: <1181845585.15983.4.camel@localhost> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> <1181845585.15983.4.camel@localhost> Message-ID: <46725C5B.1020703@redhat.com> Callum Lerwick napsal(a): > On Thu, 2007-06-14 at 09:05 -0400, Bernardo Innocenti wrote: > >> By the way, I always wanted to ask... we use caching-nameserver >> because the libc resolver can only do per-process caching versus >> system-wide caching, right? >> >> If so, wouldn't nscd be a lighter weight daemon for this purpose? >> > > dnsmasq is specifically designed for this purpose, and in fact upstream > has added dbus support to it specifically so it can integrate nicely > with NetworkManager. Why we're not using it, I don't know. > Also BIND have intelligent D-BUS integration (-D parameter). If you run dhcdbd daemon and named simulateously named ask dhcdbd for forwarders and use it for forwarding. It's perfect solution for laptops - you get forwarders through DHCP and dhcdbd tells named about them so you have fully working caching-nameserver. Of course dnsmasq could be alternative solution for people who hates BIND. You could package it and start maintain :) Adam From atkac at redhat.com Fri Jun 15 09:33:57 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 15 Jun 2007 11:33:57 +0200 Subject: End of caching-nameserver package In-Reply-To: References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> Message-ID: <46725D05.8020501@redhat.com> Gianluca Sforna napsal(a): > On 6/14/07, Bernardo Innocenti wrote: >> Adam Tkac wrote: >> > Hi all, >> > >> > caching-nameserver package will be removed and configfiles will be >> moved >> > into main bind package. I did this decision because people often >> tell me >> > something like "Where is default /etc/named.conf?" and I tell them >> > "Please install caching-nameserver". So if you install bind package >> you >> > have also default configuration which is usable for >> caching-nameserver. >> >> By the way, I always wanted to ask... we use caching-nameserver >> because the libc resolver can only do per-process caching versus >> system-wide caching, right? >> >> If so, wouldn't nscd be a lighter weight daemon for this purpose? > > +1 > > /me just loves dnsmasq.... > BIND is better :) -A- From atkac at redhat.com Fri Jun 15 09:36:16 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 15 Jun 2007 11:36:16 +0200 Subject: End of caching-nameserver package In-Reply-To: <20070614184301.GG3522@nostromo.devel.redhat.com> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> <1181845585.15983.4.camel@localhost> <20070614184301.GG3522@nostromo.devel.redhat.com> Message-ID: <46725D90.5080106@redhat.com> Bill Nottingham napsal(a): > Callum Lerwick (seg at haxxed.com) said: > >> dnsmasq is specifically designed for this purpose, and in fact upstream >> has added dbus support to it specifically so it can integrate nicely >> with NetworkManager. Why we're not using it, I don't know. >> > > NM doesn't actually use caching-nameserver at the moment. > > Bill > I'm not sure why NM doesn't use it (If could remember correctly, NM used it). NM + dhcdbd + named could be good solution for save bandwidth. Adam From sundaram at fedoraproject.org Fri Jun 15 09:37:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 15 Jun 2007 15:07:07 +0530 Subject: fedora-logos dependencies in F7 In-Reply-To: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> Message-ID: <46725DC3.8020501@fedoraproject.org> Hans K. Rosbach wrote: > Grub depends on fedora-logos that in turn > depends on gtk2-engines and pretty soon you > have pulled in most of the X libraries. > > Thats an aweful lot to require for a boot menu, > and we didn't have this problem for FC4, FC5 > and FC6 atleast. Hope this will be fixed atleast > in rawhide. > See the archives of this list. This has been discussed extensively. > Is there any reason for the logos package to > depend on gtk2-engines at all? Shouldn't it > be the other way around? That doesn't make much sense to me. A engine isn't dependent on the theme. If the branding is removed from Grub then the dependencies can be avoided. Rahul From fedora at leemhuis.info Fri Jun 15 09:43:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 15 Jun 2007 11:43:07 +0200 Subject: random comments about secondary arch proposal In-Reply-To: <1181842826.3635.14.camel@localhost.localdomain> References: <1181842826.3635.14.camel@localhost.localdomain> Message-ID: <46725F2B.6010702@leemhuis.info> On 14.06.2007 19:40, Christopher Blizzard wrote: > Primary arch definition: need to make sure that part of the > responsibility is that individual maintainers are required to make sure > their stuff builds on all those arches. -1 -- Fedora Extras had lots of maintainers that are no programmers and/or have only access to i386. Those maintainers are Fedora maintainers these days. Saying they are "required to make sure their stuff builds on all primary arches" would increase the burden on the maintainer drastically. I think that's totally the wrong way forward. Further: if I would read something like that before becoming a contributor I'd say "hey, that's hard stuff; I know my knowledge is not enough to do that should I even run into a situation where something doesn't build on PPC; well, then I won't become a contributor for Fedora. Have fun guys, bye". Just as for secondary arches there should be SIGs/teams which a maintainer could ask for help in case they need help. That already works quite well for PPC (thanks to dwmw2 for all his work). CU thl From hk at circlestorm.org Fri Jun 15 09:46:32 2007 From: hk at circlestorm.org (Hans K. Rosbach) Date: Fri, 15 Jun 2007 11:46:32 +0200 Subject: fedora-logos dependencies in F7 References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> Message-ID: <085a01c7af32$0e6823c0$0a00000a@DEAD2> From: "Rahul Sundaram" > Hans K. Rosbach wrote: > > Grub depends on fedora-logos that in turn > > depends on gtk2-engines and pretty soon you > > have pulled in most of the X libraries. > > > > Thats an aweful lot to require for a boot menu, > > and we didn't have this problem for FC4, FC5 > > and FC6 atleast. Hope this will be fixed atleast > > in rawhide. > > See the archives of this list. This has been discussed extensively. I must be a bit too sleepy, I've been following that discussion myself.. Sorry about starting another thread on the matter. > > Is there any reason for the logos package to > > depend on gtk2-engines at all? Shouldn't it > > be the other way around? > > That doesn't make much sense to me. A engine isn't dependent on the > theme. If the branding is removed from Grub then the dependencies can be > avoided. I haven't checked what is in the fedora-logos package, but it just seems weird to me that some logos would _require_ an engine.. -HK From sundaram at fedoraproject.org Fri Jun 15 09:49:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 15 Jun 2007 15:19:30 +0530 Subject: fedora-logos dependencies in F7 In-Reply-To: <085a01c7af32$0e6823c0$0a00000a@DEAD2> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <085a01c7af32$0e6823c0$0a00000a@DEAD2> Message-ID: <467260AA.7070406@fedoraproject.org> Hans K. Rosbach wrote: > > I haven't checked what is in the fedora-logos package, but > it just seems weird to me that some logos would _require_ > an engine.. Wouldn't it be better to waste a second on looking at the files before starting a discussion on this? fedora-logos despite the name is not just simple logos but all trademarked images in a single package including customized themes which depend on specific theming engines. They are all in the same package because a clean separation is desirable form the legal perspective (trademark images have certain associated restrictions to protect the trademark and the brand) and to ease the process of creating derivative distributions. Rahul From hk at circlestorm.org Fri Jun 15 09:59:24 2007 From: hk at circlestorm.org (Hans K. Rosbach) Date: Fri, 15 Jun 2007 11:59:24 +0200 Subject: fedora-logos dependencies in F7 References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org><085a01c7af32$0e6823c0$0a00000a@DEAD2> <467260AA.7070406@fedoraproject.org> Message-ID: <086401c7af33$da6f0410$0a00000a@DEAD2> From: "Rahul Sundaram" > Hans K. Rosbach wrote: > > I haven't checked what is in the fedora-logos package, but > > it just seems weird to me that some logos would _require_ > > an engine.. > > Wouldn't it be better to waste a second on looking at the files before > starting a discussion on this? fedora-logos despite the name is not just > simple logos but all trademarked images in a single package including > customized themes which depend on specific theming engines. They are all > in the same package because a clean separation is desirable form the > legal perspective (trademark images have certain associated restrictions > to protect the trademark and the brand) and to ease the process of > creating derivative distributions. I have taken a look at the files list now and it's basically a bunch of images.. And I still cant believe that images can depend on programs. It's the other way around, a program should depend on the images. The images can clearly exist and be used without pulling in gtk2-engines. Sure gtk2-engines can use them, but none of them truly require the other to be present. I'm sorry but I simply see no reason to depend on gtk2-engines. -HK From ml at deadbabylon.de Fri Jun 15 09:59:40 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Fri, 15 Jun 2007 11:59:40 +0200 Subject: Bugzillas for yum-plugins? In-Reply-To: <200706151117.12591.opensource@till.name> References: <200706151045.15294.ml@deadbabylon.de> <200706151117.12591.opensource@till.name> Message-ID: <200706151159.40632.ml@deadbabylon.de> Am Fr 15.Juni 2007 schrieb Till Maas: > On Fr Juni 15 2007, Sebastian Vahl wrote: > > Just a short question: The plugins for yum aren't existing as components > > in bugzilla. Against which package should I fill a bug? > > It should be yum-utils, at least the changelog plugin is build from the > yum-utils src.rpm, you can see this in the output of "rpm -qi". Ah, right. Thanks! Sebastian FYI: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244369 -------------- 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 Jun 15 10:20:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 12:20:13 +0200 Subject: fedora-logos dependencies in F7 In-Reply-To: <46725DC3.8020501@fedoraproject.org> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> Message-ID: <20070615102013.GA9813@neu.nirvana> On Fri, Jun 15, 2007 at 03:07:07PM +0530, Rahul Sundaram wrote: > Hans K. Rosbach wrote: > >Grub depends on fedora-logos that in turn > >depends on gtk2-engines and pretty soon you > >have pulled in most of the X libraries. > > > >Thats an aweful lot to require for a boot menu, > >and we didn't have this problem for FC4, FC5 > >and FC6 atleast. Hope this will be fixed atleast > >in rawhide. > > > > See the archives of this list. This has been discussed extensively. Pointer or summary? Thanks! > >Is there any reason for the logos package to > >depend on gtk2-engines at all? Shouldn't it > >be the other way around? > > That doesn't make much sense to me. A engine isn't dependent on the > theme. If the branding is removed from Grub then the dependencies can be > avoided. > > Rahul > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 15 10:22:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 15 Jun 2007 15:52:54 +0530 Subject: fedora-logos dependencies in F7 In-Reply-To: <20070615102013.GA9813@neu.nirvana> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> Message-ID: <4672687E.3080005@fedoraproject.org> Axel Thimm wrote: > On Fri, Jun 15, 2007 at 03:07:07PM +0530, Rahul Sundaram wrote: >> Hans K. Rosbach wrote: >>> Grub depends on fedora-logos that in turn >>> depends on gtk2-engines and pretty soon you >>> have pulled in most of the X libraries. >>> >>> Thats an aweful lot to require for a boot menu, >>> and we didn't have this problem for FC4, FC5 >>> and FC6 atleast. Hope this will be fixed atleast >>> in rawhide. >>> >> See the archives of this list. This has been discussed extensively. > > Pointer or summary? Thanks! https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00595.html Rahul From Axel.Thimm at ATrpms.net Fri Jun 15 10:38:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 12:38:10 +0200 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <4672687E.3080005@fedoraproject.org> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> Message-ID: <20070615103810.GC9813@neu.nirvana> On Fri, Jun 15, 2007 at 03:52:54PM +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > >On Fri, Jun 15, 2007 at 03:07:07PM +0530, Rahul Sundaram wrote: > >>Hans K. Rosbach wrote: > >>>Grub depends on fedora-logos that in turn depends on gtk2-engines > >>>and pretty soon you have pulled in most of the X libraries. > >>> > >>>Thats an aweful lot to require for a boot menu, and we didn't > >>>have this problem for FC4, FC5 and FC6 atleast. Hope this will be > >>>fixed atleast in rawhide. > >>> > >>See the archives of this list. This has been discussed extensively. > > > >Pointer or summary? Thanks! > > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00595.html Argh! "but since it drops files into application directories, fedora-logos itself requires many things so that there are no unowned directories or so that the right application owns it's directories. This is perhaps one case where we can forgo the policy on directory ownership" Drop the policy for fedora-logos or make fedora-logos co-own the directories. We can't allow blind guideline-ism to create such awkward situations where simply booting the system requires gtk! Alternatively fedora-logos could split off the /boot/grub/splash.xpm.gz in a subpackage (still the same src.rpm) and grub would only require that. Please decide on what is better, if you want the FPC to exempt fedora-logos I'll bring it up there. But maybe the subpackage split is preferred. -- 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 dennis at ausil.us Fri Jun 15 11:26:38 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 15 Jun 2007 06:26:38 -0500 Subject: ArchTeam Wiki page(s) (WAS: Re: For your consideration: Secondary Architectures in Fedora) In-Reply-To: <46723C24.1010906@linux-kernel.at> References: <1180473516.6254.454.camel@localhost.localdomain> <4671A16E.1060800@linux-kernel.at> <46723C24.1010906@linux-kernel.at> Message-ID: <200706150626.44316.dennis@ausil.us> Once upon a time Friday 15 June 2007, Oliver Falk wrote: > On 06/14/2007 10:13 PM, Oliver Falk wrote: > > David Woodhouse schrieb: > >> On Tue, 2007-05-29 at 16:18 -0500, Tom "spot" Callaway wrote: > >>> This is a very early draft of what I am planning on presenting to FESCo > >>> in the near future: > >>> > >>> http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures > >>> > >>> I am very interested in comments and suggested changes. > >> > >> I know it's a wiki, but I didn't want to make changes you might not > >> agree with -- so I've added a 'Dissent' section at the bottom, outlining > >> the reasons why I strongly believe package builds should remain > >> synchronous even on new architectures. > > > > Yes, it is a Wiki: :-P > > https://fedoraproject.org/wiki/ArchTeam > > > > How do you like this? If you don't like it, just edit! Well its not a proposal just some information on the Arch Teams That information possibly should be added to arch specific pages AlphaTeam SPARCTeam etc > Hmmm. No feedback, but spot added his stuff. Great. I added sparc stuff There really is not much there to comment on > I would like to invite s390, PowerPC and others to also add their > team/resources. > > Thomas, can you add some words about this in your next Fedora Weekly News? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Fri Jun 15 11:38:28 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jun 2007 12:38:28 +0100 Subject: random comments about secondary arch proposal In-Reply-To: <46725F2B.6010702@leemhuis.info> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> Message-ID: <1181907508.25228.435.camel@pmac.infradead.org> On Fri, 2007-06-15 at 11:43 +0200, Thorsten Leemhuis wrote: > > On 14.06.2007 19:40, Christopher Blizzard wrote: > > > Primary arch definition: need to make sure that part of the > > responsibility is that individual maintainers are required to make sure > > their stuff builds on all those arches. > > -1 -- Fedora Extras had lots of maintainers that are no programmers > and/or have only access to i386. > > Those maintainers are Fedora maintainers these days. Saying they are > "required to make sure their stuff builds on all primary arches" would > increase the burden on the maintainer drastically. I think that's > totally the wrong way forward. I actually think it's the _right_ way forward. I think it's a really bad thing that we're letting people package and 'maintain' code which they don't even understand, and for which they can't handle bug reports. And we're shipping those packages with the 'Fedora' brand on them. I recently ditched the bluez-gnome package because I can only be a package-monkey for gnome/dbus stuff, and I just don't think it's right for me to be responsible for it in Fedora. But that doesn't seem to be the prevailing opinion, so I suppose we have to deal with the situation we have... You're right -- as things stand, we do need a team of folks who can help out with basic issues where the packager can't cope. It usually isn't arch-specific; very little really is when you get down to it. I actually think the primary responsibility for such a packager should be with his/her sponsor. If you sponsor someone who doesn't even know the language their package is written in, then _you_ should be expected to make sure the package is being looked after in a fashion which makes it acceptable for Fedora. Could the sponsor be listed as the 'QA contact' in bugzilla for these packages? Obviously, a team of people who can help out is also useful, but it's good for the packager to have a single point of contact; someone who's "on the hook" to help them out and/or redirect them to someone who knows best about whatever specific problem they're looking at. > Further: if I would read something like that before becoming a > contributor I'd say "hey, that's hard stuff; I know my knowledge is not > enough to do that should I even run into a situation where something > doesn't build on PPC; well, then I won't become a contributor for > Fedora. Have fun guys, bye". As long as they're willing to learn, and they'll _become_ capable of basic package maintenance in time, I agree that it's best not to turn them away. If they're _never_ going to learn, then we run the risk of sacrificing quality for quantity; I'm very wary of that approach. And it's not just "...should I ever run into a situation where something doesn't build on PPC". It's "...should I ever run into a bug which is hard to find and fix". The 'doesn't build on $ARCH' bugs are generally either arch-specific bugs which such a packager could use ExcludeArch for and call in the ArchTeam, or more often than not they're actually _generic_ bugs which just happen to get tickled on that arch first. And yes, that kind of hard-to-reproduce bug is usually the 'hard' kind, but it doesn't necessarily require much arch-specific knowledge. Just a clue and a lot of coffee. -- dwmw2 ? other than new ports and 'IBM made us break it', as I said before. From kevin.kofler at chello.at Fri Jun 15 11:48:09 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 11:48:09 +0000 (UTC) Subject: random comments about secondary arch proposal References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <1181907508.25228.435.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > The 'doesn't build on $ARCH' bugs are generally either arch-specific > bugs which such a packager could use ExcludeArch for and call in the > ArchTeam, or more often than not they're actually _generic_ bugs which > just happen to get tickled on that arch first. And yes, that kind of > hard-to-reproduce bug is usually the 'hard' kind, but it doesn't > necessarily require much arch-specific knowledge. Just a clue and a lot > of coffee. For an example of such a generic bug (a runtime failure which manifests on x86_64, but is just plain broken everywhere), see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235546 (I already attached a fix for this one.) Kevin Kofler From dwmw2 at infradead.org Fri Jun 15 12:05:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jun 2007 13:05:09 +0100 Subject: random comments about secondary arch proposal In-Reply-To: References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <1181907508.25228.435.camel@pmac.infradead.org> Message-ID: <1181909109.25228.458.camel@pmac.infradead.org> On Fri, 2007-06-15 at 11:48 +0000, Kevin Kofler wrote: > For an example of such a generic bug (a runtime failure which > manifests on > x86_64, but is just plain broken everywhere), see: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235546 > (I already attached a fix for this one.) I looked through the historical FE-ExcludeArch-ppc bugs and posted a bunch more examples a few days ago too. It actually seems to be _more_ common to find it's really a generic bug, than it is to find it's arch-specific. That's why I so strongly oppose just shipping the packages anyway when the build fails on some arch it used to work on. It's a _really_ bad idea. -- dwmw2 From dsmith at redhat.com Fri Jun 15 12:59:34 2007 From: dsmith at redhat.com (David Smith) Date: Fri, 15 Jun 2007 07:59:34 -0500 Subject: Fedora and Cross Compiling In-Reply-To: <1181894996.13412.116.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> Message-ID: <46728D36.7010003@redhat.com> Ralf Corsepius wrote: > On Fri, 2007-06-15 at 08:25 +0100, Andy Green wrote: >> Ralf Corsepius wrote: > >>>>>> When cross >>>>>> building you need to pull in a mixture of native (host-arch) and cross >>>>>> (target arch) packages to meet the build dependencies. This is part of >>>>>> where the "fun" is. >>>>> Well, I question the "need", but consider this kind of implementation to >>>>> be "an option". >>>> It can be necessary though, for example if the package build wants yacc >>>> or bison or whatever to build, with cross building they are going to be >>>> host yacc and bison despite you are building for a different target arch >>> If I understand you correctly the problem you are referring to is >>> separating "tools being used at build-time on the host" from >>> "tools being used at run-time on the target". >>> (Classic situation: building inserts hard-coded directories/paths >>> referring to files on the build-host into target-files) >> No the issue I (and Brendan I believe) am talking about is, >> "BuildRequires... required where?". Consider >> >> BuildRequires: yacc libblah-devel > Understood. > >> rpmbuild should go and confirm that the packages mentioned here are >> installed before doing the build. > Hmm, difficult. The problem is actually a bit worse than that. bison and flex are actually required for the host *and* target. You need the host version for the actual bison/flex executable and you need the target version for the static library both typically include. I used to be part of Brendan's group. Here's how we solved this problem in the past (they might have changed things since I last looked). Assume a package that originally has the following line for native compiles: BuildPrereq: autoconf, bison, flex, libblah-devel, sed For cross compiles we change it to look like this: %if "%{_arch}" == %{_build_arch} BuildPrereq: autoconf, bison, flex, libblah-devel, sed %else BuildPrereq: bison, flex, libblah-devel %endif% Note that we leave things so that native compiles still work. We then check native dependencies (_arch == _build_arch) against our mock chroot's native rpm database, then check cross dependencies (_arch != _build_arch) against the mock chroot's target rpm database. Target versions of autoconf and sed aren't needed since nothing links against anything in those packages (those packages are only run natively). The only problem with this scheme is that we end up with an extra native dependency of libblah-devel (which really isn't needed since nothing links against it in the cross compile). But the benefit of unaffected native compiles outweighed the extra dependency. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From mclasen at redhat.com Fri Jun 15 12:55:08 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 15 Jun 2007 08:55:08 -0400 Subject: fedora-logos dependencies in F7 In-Reply-To: <086401c7af33$da6f0410$0a00000a@DEAD2> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org><085a01c7af32$0e6823c0$0a00000a@DEAD2> <467260AA.7070406@fedoraproject.org> <086401c7af33$da6f0410$0a00000a@DEAD2> Message-ID: <1181912108.3453.0.camel@localhost.localdomain> On Fri, 2007-06-15 at 11:59 +0200, Hans K. Rosbach wrote: > From: "Rahul Sundaram" > > Hans K. Rosbach wrote: > > > I haven't checked what is in the fedora-logos package, but > > > it just seems weird to me that some logos would _require_ > > > an engine.. > > > > Wouldn't it be better to waste a second on looking at the files before > > starting a discussion on this? fedora-logos despite the name is not just > > simple logos but all trademarked images in a single package including > > customized themes which depend on specific theming engines. They are all > > in the same package because a clean separation is desirable form the > > legal perspective (trademark images have certain associated restrictions > > to protect the trademark and the brand) and to ease the process of > > creating derivative distributions. > > I have taken a look at the files list now and it's basically a bunch of > images.. And I still cant believe that images can depend on programs. > It's the other way around, a program should depend on the images. > > The images can clearly exist and be used without pulling in gtk2-engines. > Sure gtk2-engines can use them, but none of them truly require the other > to be present. I'm sorry but I simply see no reason to depend on > gtk2-engines. A look at the spec file would suffice: # for /usr/share/icons/Bluecurve Requires: redhat-artwork # for /usr/share/icons/hicolor Requires: hicolor-icon-theme From mclasen at redhat.com Fri Jun 15 12:58:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 15 Jun 2007 08:58:34 -0400 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <20070615103810.GC9813@neu.nirvana> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> Message-ID: <1181912314.3453.2.camel@localhost.localdomain> On Fri, 2007-06-15 at 12:38 +0200, Axel Thimm wrote: > Please decide on what is better, if you want the FPC to exempt > fedora-logos I'll bring it up there. But maybe the subpackage split is > preferred. It has been extensively discussed that splitting is not an option because legal wants us to keep all trademarked images in a single package. From dwmw2 at infradead.org Fri Jun 15 13:20:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jun 2007 14:20:46 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <46728D36.7010003@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> Message-ID: <1181913646.25228.510.camel@pmac.infradead.org> On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote: > > Note that we leave things so that native compiles still work. We then > check native dependencies (_arch == _build_arch) against our mock > chroot's native rpm database, then check cross dependencies (_arch != > _build_arch) against the mock chroot's target rpm database. > > Target versions of autoconf and sed aren't needed since nothing links > against anything in those packages (those packages are only run > natively). The only problem with this scheme is that we end up with an > extra native dependency of libblah-devel (which really isn't needed > since nothing links against it in the cross compile). But the benefit > of unaffected native compiles outweighed the extra dependency. I might go so far as to suggest that the benefit of avoiding that %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh the extra dependencies on autoconf and sed, too. One way of handling dependencies in mock for cross-builds might be to install the full set of dependencies for _both_ host and target architectures. -- dwmw2 From notting at redhat.com Fri Jun 15 13:21:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 09:21:03 -0400 Subject: End of caching-nameserver package In-Reply-To: <46725C5B.1020703@redhat.com> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> <1181845585.15983.4.camel@localhost> <46725C5B.1020703@redhat.com> Message-ID: <20070615132103.GA6965@nostromo.devel.redhat.com> Adam Tkac (atkac at redhat.com) said: > Also BIND have intelligent D-BUS integration (-D parameter). Is that at all upstream? Bill From cmadams at hiwaay.net Fri Jun 15 13:22:54 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 15 Jun 2007 08:22:54 -0500 Subject: End of caching-nameserver package In-Reply-To: <46725C5B.1020703@redhat.com> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> <1181845585.15983.4.camel@localhost> <46725C5B.1020703@redhat.com> Message-ID: <20070615132253.GA1540422@hiwaay.net> Once upon a time, Adam Tkac said: > Of course dnsmasq could be alternative > solution for people who hates BIND. You could package it and start > maintain :) dnsmasq is already in FC7. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kevin.kofler at chello.at Fri Jun 15 13:18:31 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 13:18:31 +0000 (UTC) Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> Message-ID: Matthias Clasen redhat.com> writes: > It has been extensively discussed that splitting is not an option > because legal wants us to keep all trademarked images in a single > package. ... which they already aren't! rpm -qf /usr/share/gdm/themes/FedoraFlyingHigh/logo.png redhat-artwork-7.0.0-11.fc7 rpm -qf /usr/share/apps/kdm/themes/FedoraFlyingHigh/logo.png redhat-artwork-kde-7.0.0-11.fc7 Kevin Kofler From notting at redhat.com Fri Jun 15 13:32:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 09:32:19 -0400 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> Message-ID: <20070615133219.GA6888@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > Matthias Clasen redhat.com> writes: > > It has been extensively discussed that splitting is not an option > > because legal wants us to keep all trademarked images in a single > > package. > > ... which they already aren't! Argh. File a bug, please. Bill From rc040203 at freenet.de Fri Jun 15 13:36:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 Jun 2007 15:36:42 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1181913646.25228.510.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> Message-ID: <1181914603.3221.54.camel@mccallum.corsepiu.local> On Fri, 2007-06-15 at 14:20 +0100, David Woodhouse wrote: > On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote: > > > > Note that we leave things so that native compiles still work. We then > > check native dependencies (_arch == _build_arch) against our mock > > chroot's native rpm database, then check cross dependencies (_arch != > > _build_arch) against the mock chroot's target rpm database. > > > > Target versions of autoconf and sed aren't needed since nothing links > > against anything in those packages (those packages are only run > > natively). The only problem with this scheme is that we end up with an > > extra native dependency of libblah-devel (which really isn't needed > > since nothing links against it in the cross compile). But the benefit > > of unaffected native compiles outweighed the extra dependency. > > I might go so far as to suggest that the benefit of avoiding that > %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh > the extra dependencies on autoconf and sed, too. ACK, esp. because "%_arch and %_build_arch", aren't the correct defines to use. They should be %_host and %target. > One way of handling dependencies in mock for cross-builds might be to > install the full set of dependencies for _both_ host and target > architectures. Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default "rpmroot"? e.g. to run rpm -i -r /usr/share//var/lib/rpm xxx.sparc.rpm on non-sparc systems? Ralf From dsmith at redhat.com Fri Jun 15 13:38:10 2007 From: dsmith at redhat.com (David Smith) Date: Fri, 15 Jun 2007 08:38:10 -0500 Subject: Fedora and Cross Compiling In-Reply-To: <1181913646.25228.510.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> Message-ID: <46729642.2030500@redhat.com> David Woodhouse wrote: > On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote: >> Note that we leave things so that native compiles still work. We then >> check native dependencies (_arch == _build_arch) against our mock >> chroot's native rpm database, then check cross dependencies (_arch != >> _build_arch) against the mock chroot's target rpm database. >> >> Target versions of autoconf and sed aren't needed since nothing links >> against anything in those packages (those packages are only run >> natively). The only problem with this scheme is that we end up with an >> extra native dependency of libblah-devel (which really isn't needed >> since nothing links against it in the cross compile). But the benefit >> of unaffected native compiles outweighed the extra dependency. > > I might go so far as to suggest that the benefit of avoiding that > %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh > the extra dependencies on autoconf and sed, too. > > One way of handling dependencies in mock for cross-builds might be to > install the full set of dependencies for _both_ host and target > architectures. I certainly see your point, but when bootstrapping an arch you sometimes get in these cases where X requires Y which requires Z which requires X, so you have to start chopping requires down to the minimal. Plus, if a native require is for something quite complicated like perl or python, you typically want to postpone that pain for as long as possible... -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From mclasen at redhat.com Fri Jun 15 13:33:37 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 15 Jun 2007 09:33:37 -0400 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> Message-ID: <1181914417.3453.6.camel@localhost.localdomain> On Fri, 2007-06-15 at 13:18 +0000, Kevin Kofler wrote: > Matthias Clasen redhat.com> writes: > > It has been extensively discussed that splitting is not an option > > because legal wants us to keep all trademarked images in a single > > package. > > ... which they already aren't! > > rpm -qf /usr/share/gdm/themes/FedoraFlyingHigh/logo.png > redhat-artwork-7.0.0-11.fc7 > > rpm -qf /usr/share/apps/kdm/themes/FedoraFlyingHigh/logo.png > redhat-artwork-kde-7.0.0-11.fc7 > > Kevin Kofler Ah, thats a bug then. Can you file it, please ? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jun 15 13:40:50 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 15 Jun 2007 15:40:50 +0200 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <20070615133219.GA6888@nostromo.devel.redhat.com> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <20070615133219.GA6888@nostromo.devel.redhat.com> Message-ID: <20070615154050.517f35ac@python3.es.egwn.lan> Bill Nottingham wrote : > Kevin Kofler (kevin.kofler at chello.at) said: > > Matthias Clasen redhat.com> writes: > > > It has been extensively discussed that splitting is not an option > > > because legal wants us to keep all trademarked images in a single > > > package. > > > > ... which they already aren't! > > Argh. File a bug, please. ...asking to split further? ;-) I don't really care what the solution is, but I'm part of those who want to be able to install servers (with grub) without pulling in all of multilib X because of a couple of otherwise unowned directories. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 3.82 3.30 2.65 From hughsient at gmail.com Fri Jun 15 13:40:14 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 15 Jun 2007 14:40:14 +0100 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <20070615133219.GA6888@nostromo.devel.redhat.com> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <20070615133219.GA6888@nostromo.devel.redhat.com> Message-ID: <1181914814.21041.13.camel@work> On Fri, 2007-06-15 at 09:32 -0400, Bill Nottingham wrote: > Kevin Kofler (kevin.kofler at chello.at) said: > > Matthias Clasen redhat.com> writes: > > > It has been extensively discussed that splitting is not an option > > > because legal wants us to keep all trademarked images in a single > > > package. > > > > ... which they already aren't! > > Argh. File a bug, please. Why can't we just have one meta-package "fedora-artwork" and have packages with depends on this? In that way, legal can just say "remove fedora-artwork" and then all the packages with fedora stuff in get removed. IANAL. :-) Richard. From dsmith at redhat.com Fri Jun 15 13:42:44 2007 From: dsmith at redhat.com (David Smith) Date: Fri, 15 Jun 2007 08:42:44 -0500 Subject: Fedora and Cross Compiling In-Reply-To: <1181914603.3221.54.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <1181914603.3221.54.camel@mccallum.corsepiu.local> Message-ID: <46729754.6030009@redhat.com> Ralf Corsepius wrote: > Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default > "rpmroot"? > > e.g. to run > rpm -i -r /usr/share//var/lib/rpm xxx.sparc.rpm > on non-sparc systems? Sure. I believe we used the '--root PATH' feature of rpm. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From dwmw2 at infradead.org Fri Jun 15 13:44:24 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jun 2007 14:44:24 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <46729642.2030500@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <46729642.2030500@redhat.com> Message-ID: <1181915064.25228.524.camel@pmac.infradead.org> On Fri, 2007-06-15 at 08:38 -0500, David Smith wrote: > I certainly see your point, but when bootstrapping an arch you sometimes > get in these cases where X requires Y which requires Z which requires X, > so you have to start chopping requires down to the minimal. For bootstrapping, yes. But that mess doesn't see the light of day -- by the time you get close to applying to become a secondary architecture for Fedora, that should all be a thing of the past. > Plus, if a native require is for something quite complicated like perl > or python, you typically want to postpone that pain for as long as > possible... Again, you're talking about the initial bootstrap. In which case ignore me -- I wasn't thinking about that. -- dwmw2 From andy at warmcat.com Fri Jun 15 13:45:11 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 15 Jun 2007 14:45:11 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <1181913646.25228.510.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> Message-ID: <467297E7.70907@warmcat.com> David Woodhouse wrote: > On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote: >> Note that we leave things so that native compiles still work. We then >> check native dependencies (_arch == _build_arch) against our mock >> chroot's native rpm database, then check cross dependencies (_arch != >> _build_arch) against the mock chroot's target rpm database. >> >> Target versions of autoconf and sed aren't needed since nothing links >> against anything in those packages (those packages are only run >> natively). The only problem with this scheme is that we end up with an >> extra native dependency of libblah-devel (which really isn't needed >> since nothing links against it in the cross compile). But the benefit >> of unaffected native compiles outweighed the extra dependency. > > I might go so far as to suggest that the benefit of avoiding that > %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh > the extra dependencies on autoconf and sed, too. > > One way of handling dependencies in mock for cross-builds might be to > install the full set of dependencies for _both_ host and target > architectures. I would be the first to reach for a dirty but unanswerably effective hack to get me where I am going... But in this case I think the only true answer is to tag BuildRequires as being host or target in the spec file, not to unmanageably duplicate the target-world dependencies in the host. Eg HostBuildRequires: byacc (<-- for it is he) BuildRequires: libblah-devel ...where they are considered the same deal when hostArch == buildArch. We can see if this logic raises objections anywhere given the effective forkage of rpm but I suspect it is a basic fact necessary for cross to work in rpm semantics. -Andy From rc040203 at freenet.de Fri Jun 15 13:45:39 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 Jun 2007 15:45:39 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <46729754.6030009@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <1181914603.3221.54.camel@mccallum.corsepiu.local> <46729754.6030009@redhat.com> Message-ID: <1181915140.3221.57.camel@mccallum.corsepiu.local> On Fri, 2007-06-15 at 08:42 -0500, David Smith wrote: > Ralf Corsepius wrote: > > Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default > > "rpmroot"? > > > > e.g. to run > > rpm -i -r /usr/share//var/lib/rpm xxx.sparc.rpm > > on non-sparc systems? > > Sure. I believe we used the '--root PATH' feature of rpm. How about scriptlets? One could try to run the host tools with paths altered, but ... Ralf From notting at redhat.com Fri Jun 15 13:51:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 09:51:59 -0400 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <1181914814.21041.13.camel@work> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <20070615133219.GA6888@nostromo.devel.redhat.com> <1181914814.21041.13.camel@work> Message-ID: <20070615135159.GB6888@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > Why can't we just have one meta-package "fedora-artwork" and have > packages with depends on this? In that way, legal can just say "remove > fedora-artwork" and then all the packages with fedora stuff in get > removed. Icons, themes, etc. aren't trademarked. The logo and logotype is. Bill From notting at redhat.com Fri Jun 15 13:52:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 09:52:19 -0400 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <20070615154050.517f35ac@python3.es.egwn.lan> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <20070615133219.GA6888@nostromo.devel.redhat.com> <20070615154050.517f35ac@python3.es.egwn.lan> Message-ID: <20070615135219.GC6888@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > > ... which they already aren't! > > > > Argh. File a bug, please. > > ...asking to split further? ;-) To move those files to fedora-logos. Bill From rdieter at math.unl.edu Fri Jun 15 13:53:21 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 15 Jun 2007 08:53:21 -0500 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> Message-ID: Kevin Kofler wrote: > Matthias Clasen redhat.com> writes: >> It has been extensively discussed that splitting is not an option >> because legal wants us to keep all trademarked images in a single >> package. It's a single srpm... :) In all likelyhood, it more that legal doesn't care/understand the complexities imposed by disallowing subpkgs. > ... which they already aren't! > > rpm -qf /usr/share/gdm/themes/FedoraFlyingHigh/logo.png > redhat-artwork-7.0.0-11.fc7 > > rpm -qf /usr/share/apps/kdm/themes/FedoraFlyingHigh/logo.png > redhat-artwork-kde-7.0.0-11.fc7 I'm confused, I thought we were talking about fedora-logos. ?? -- Rex From dsmith at redhat.com Fri Jun 15 13:54:25 2007 From: dsmith at redhat.com (David Smith) Date: Fri, 15 Jun 2007 08:54:25 -0500 Subject: Fedora and Cross Compiling In-Reply-To: <1181915140.3221.57.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <1181914603.3221.54.camel@mccallum.corsepiu.local> <46729754.6030009@redhat.com> <1181915140.3221.57.camel@mccallum.corsepiu.local> Message-ID: <46729A11.8050902@redhat.com> Ralf Corsepius wrote: > On Fri, 2007-06-15 at 08:42 -0500, David Smith wrote: >> Ralf Corsepius wrote: >>> Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default >>> "rpmroot"? >>> >>> e.g. to run >>> rpm -i -r /usr/share//var/lib/rpm xxx.sparc.rpm >>> on non-sparc systems? >> Sure. I believe we used the '--root PATH' feature of rpm. > How about scriptlets? > > One could try to run the host tools with paths altered, but ... We just ran with '--noscripts' for cross rpms when installing build dependencies (if I remember correctly). Probably more than %90 of build dependencies (libfoo-devel) just run ldconfig, which isn't needed for link purposes. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From rdieter at math.unl.edu Fri Jun 15 13:55:54 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 15 Jun 2007 08:55:54 -0500 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> Message-ID: Rex Dieter wrote: >> rpm -qf /usr/share/gdm/themes/FedoraFlyingHigh/logo.png >> redhat-artwork-7.0.0-11.fc7 >> >> rpm -qf /usr/share/apps/kdm/themes/FedoraFlyingHigh/logo.png >> redhat-artwork-kde-7.0.0-11.fc7 > > I'm confused, I thought we were talking about fedora-logos. ?? nevermind, I'm less confused now (thanks to Bill's followup explanation). -- Rex From obi at unixkiste.org Fri Jun 15 14:06:02 2007 From: obi at unixkiste.org (Stefan Held) Date: Fri, 15 Jun 2007 16:06:02 +0200 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <1181914417.3453.6.camel@localhost.localdomain> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <1181914417.3453.6.camel@localhost.localdomain> Message-ID: <1181916362.3327.3.camel@workstation.unixkiste.local> Am Freitag, den 15.06.2007, 09:33 -0400 schrieb Matthias Clasen: > Ah, thats a bug then. Can you file it, please ? Maybe one can also write an Email to Legal and explain what is bad with that decission and ask if it is good enough if we keep this for the SRPM but are allowed to split packages? Which Legal was this if i am allowed to asked kindly, Fedora Legal or RedHat Legal? -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sundaram at fedoraproject.org Fri Jun 15 14:14:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 15 Jun 2007 19:44:47 +0530 Subject: guideline-isms leading to dependency bloats In-Reply-To: <1181916362.3327.3.camel@workstation.unixkiste.local> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <1181914417.3453.6.camel@localhost.localdomain> <1181916362.3327.3.camel@workstation.unixkiste.local> Message-ID: <46729ED7.7030202@fedoraproject.org> Stefan Held wrote: > Am Freitag, den 15.06.2007, 09:33 -0400 schrieb Matthias Clasen: > >> Ah, thats a bug then. Can you file it, please ? > > Maybe one can also write an Email to Legal and explain what is bad with > that decission and ask if it is good enough if we keep this for the SRPM > but are allowed to split packages? > > Which Legal was this if i am allowed to asked kindly, Fedora Legal or > RedHat Legal? Fedora Legal is Red Hat Legal. Rahul From dwmw2 at infradead.org Fri Jun 15 14:15:57 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jun 2007 15:15:57 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <46729A11.8050902@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <1181914603.3221.54.camel@mccallum.corsepiu.local> <46729754.6030009@redhat.com> <1181915140.3221.57.camel@mccallum.corsepiu.local> <46729A11.8050902@redhat.com> Message-ID: <1181916957.25228.536.camel@pmac.infradead.org> On Fri, 2007-06-15 at 08:54 -0500, David Smith wrote: > We just ran with '--noscripts' for cross rpms when installing build > dependencies (if I remember correctly). Probably more than %90 of build > dependencies (libfoo-devel) just run ldconfig, which isn't needed for > link purposes. Hm. Would be it be sensible for us to use --noscripts to speed up mock/koji builds? And just run ldconfig once before actually starting the build? -- dwmw2 From dwmw2 at infradead.org Fri Jun 15 14:17:11 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jun 2007 15:17:11 +0100 Subject: {Co,}maintainer for bluez-* packages solicited Message-ID: <1181917031.25228.538.camel@pmac.infradead.org> I've done a fairly poor job of maintaining the various Bluetooth packages recently. Partly due to lack of time, and partly because they're increasingly less just low-level code interfacing to the kernel, and more involved with dbus and other system stuff. I'm becoming just a package-monkey for them, rather than being able to maintain them properly as they need. I've already donated bluez-gnome to Bastien because it's _entirely_ over my head, but the other packages could probably do with some love too. Would anyone like to {co,}maintain them? -- dwmw2 From jonathan.underwood at gmail.com Fri Jun 15 15:06:28 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 15 Jun 2007 16:06:28 +0100 Subject: XFCE desktop needs ... tetex ? In-Reply-To: References: <645d17210706061527k5237fe0ci7c7aeccdd8e9f5a@mail.gmail.com> Message-ID: <645d17210706150806y1a98b5bcse098fc5109331946@mail.gmail.com> On 15/06/07, Kevin Kofler wrote: > Jonathan Underwood gmail.com> writes: > > > I trimmed down the output from yum to show the dependency chain. > > > xfprint requires a2ps which requires tetex. > > > > Hm. I wonder if xfprint could be patched to use enscript instead of > > a2ps - enscript doesn't have such dependencies. > > What's wrong with using LaTeX for printing? It's one of the best Free Software > PostScript generators out there. Absolutely nothing :) But since the OP felt that the dependencies of xfprint were gratutitous, I wondered if equivalent functionality was provided by a program with smaller dependencies. Seems not. From ajackson at redhat.com Fri Jun 15 15:13:08 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 15 Jun 2007 11:13:08 -0400 Subject: R500 initial driver release In-Reply-To: <1181875613.2370.2.camel@scrappy.miketc.com> References: <20070612194904.GA4750@dudweiler.stuttgart.redhat.com> <1181684022.2680.4.camel@scrappy.miketc.com> <1181829422.30663.72.camel@localhost.localdomain> <1181852757.30663.99.camel@localhost.localdomain> <1181875613.2370.2.camel@scrappy.miketc.com> Message-ID: <1181920388.30663.104.camel@localhost.localdomain> On Thu, 2007-06-14 at 21:46 -0500, Mike Chambers wrote: > On Thu, 2007-06-14 at 16:25 -0400, Adam Jackson wrote: > > > Well, it doesn't work on my T60p, for lack of PCI ID if nothing else. > > > > Test build: > > > > http://people.redhat.com/ajackson/avivo/ > > Didn't work on my x1300 neither. Lack of PCI ID I guess as well. > > Is any of this stuff getting reported upstream already, and/or do we > need to open a bug # to help keep track here to help keep up with the > progress or anything? Single bug for "avivo isn't working" isn't really helpful because I'll never be able to close it. File individual issue bugs if you like, but I'm collecting the issues I hear of as well and making sure they're either known or fixed upstream. - ajax From laxathom at fedoraproject.org Fri Jun 15 15:21:40 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 15 Jun 2007 11:21:40 -0400 Subject: {Co,}maintainer for bluez-* packages solicited In-Reply-To: <1181917031.25228.538.camel@pmac.infradead.org> References: <1181917031.25228.538.camel@pmac.infradead.org> Message-ID: <62bc09df0706150821t4520dd8fv70989efa40c37515@mail.gmail.com> 2007/6/15, David Woodhouse : > > I've done a fairly poor job of maintaining the various Bluetooth > packages recently. Partly due to lack of time, and partly because > they're increasingly less just low-level code interfacing to the kernel, > and more involved with dbus and other system stuff. I'm becoming just a > package-monkey for them, rather than being able to maintain them > properly as they need. > > I've already donated bluez-gnome to Bastien because it's _entirely_ over > my head, but the other packages could probably do with some love too. > Would anyone like to {co,}maintain them? i do interested i generaly use them so i'll glad to co-maintain them with you :). Also plan to do some " bluetooth developping things " -- > dwmw2 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtimms at iinet.net.au Fri Jun 15 15:42:31 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 16 Jun 2007 01:42:31 +1000 Subject: F8devel - UI "responsiveness" improvements In-Reply-To: <1181829565.30663.75.camel@localhost.localdomain> References: <46705A88.9000207@iinet.net.au> <1181829565.30663.75.camel@localhost.localdomain> Message-ID: <4672B367.1000206@iinet.net.au> Adam Jackson wrote: > On Thu, 2007-06-14 at 06:58 +1000, David Timms wrote: >> I'd like to suggest a goal for future Fedora of ensuring every >> application / task performed with Fedora actually provides user feedback >> at a minimum 1 {one} second interval. >> >> Culprits: >> - anaconda between go-ahead with install and first package installing >> {especially noticeable because the {boring} X screen saver kicks in. You >> then move the mouse to get the screen back - but there is no update to >> the screen for maybe one minute or more. >> >> - pup during an update run with about 30-40 packages. It took nearly an >> hour. Each time an app covered its windows they may not have been >> redrawn for some minutes. > > Just to clarify, it's not that you want continuous screen updates, it's > that you don't want to see apps in the middle of redraw. Just to clarify your clarification: I meant that eg you cover the window|switch desktop|alt-tab, and then when you go back to view progress of the app, the window decorations are drawn but the bits that have been covered (or unminimized} show as grey, and might stay this way for some time. Or during anaconda, this occurs in the transition between one step and one where it reads the package list in. There is an initial draw, but then no change for 30secs. Eg: during boot, my dhcp server is not responding. In the text mode, we could add a "." each second that there was no response. {actually that conflicts with the next para :( }. Or/And text stating no dhcp server has responded within a "normal" time frame. Then the fact that the dhcp request has been sent again is more progress. The other side is that I feel that the app should show some effective "I am still working normally but the thing I'm doing is going to take some time". If it was a 10MB download and the app received bytes - then it is making progress. I would be strongly against making fake progress - eg a ms progress dialog that moves along saying it's making progress, when in fact you have pulled the internet connection on it. Or worse still - progress bars that get to the end and then clear and start again based only on time counting. {-1 also to progress dialogs that move from right to left}. Adding an estimate of amount of time until completion would be the icing; this should take into account the "work" to be done, and the amount of work toward that end that has actually been completed. And I realize this is probably the opposite to what "usability studies" might tell ms or us. If I remember rightly, anaconda used to have estimated time to completion of install, but I think this has disappeared in recent releases. With the push to save power at the cpu level, any timer's should really be aligned with another ticking timer {like after the seconds on the clock}. > We could solve this trivially by turning on automatic compositing by > default but I don't think that's ready yet. Would the "automatic compositing" mean that an apps visuals are stored by the ~window system~ so that they can be redrawn by the window manager, without waiting for the app 2 update itself ? Are these sort of issues worth working on as a common goal ? Or do I bugzilla them as enhancements / fixes in the respective apps ? DaveT. From ken at bitsko.slc.ut.us Fri Jun 15 15:23:29 2007 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Fri, 15 Jun 2007 10:23:29 -0500 Subject: Fedora and Cross Compiling In-Reply-To: <1181914603.3221.54.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri\, 15 Jun 2007 15\:36\:42 +0200") References: <46686D85.5000603@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <1181914603.3221.54.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Fri, 2007-06-15 at 14:20 +0100, David Woodhouse wrote: > Is rpm able to install arbitrary "foreign arch'ed rpms" to a > non-default "rpmroot"? > > e.g. to run > rpm -i -r /usr/share//var/lib/rpm xxx.sparc.rpm > on non-sparc systems? Yes, with --noscripts as mentioned elsewhere. I posted a patch to Yum the other day that adds cross-arch build installs. The patch needs to be reworked some so people don't try to use it to do, say, cross-arch NFS root installs, which do need the scripts to run natively or some other solution ultimately. Also posted were patches to mock to support building a target filesystem and cross-tools root. I'm updating this to current mock and some suggested cleanups. I mis-posted the earlier patch notice so people probably didn't see it, https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01716.html The patch does not address BuildRequires but my thought was to go with the approach suggested here: BuildRequires is the target native build requirements and a new header or other way to give HostBuildRequires, if different. -- Ken From Axel.Thimm at ATrpms.net Fri Jun 15 16:00:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 18:00:42 +0200 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <1181912314.3453.2.camel@localhost.localdomain> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> Message-ID: <20070615160042.GI9813@neu.nirvana> On Fri, Jun 15, 2007 at 08:58:34AM -0400, Matthias Clasen wrote: > On Fri, 2007-06-15 at 12:38 +0200, Axel Thimm wrote: > > > Please decide on what is better, if you want the FPC to exempt > > fedora-logos I'll bring it up there. But maybe the subpackage split is > > preferred. > > It has been extensively discussed that splitting is not an option > because legal wants us to keep all trademarked images in a single > package. Spliting is *the option* along with teaching legal not to impose such braindead non-technical issues. I'm sorry, but I see no reason fro that. Next legal will ask to put all in one folder (so goodbye / vs /usr split) or all in one file (hey, it's legal, it doesn't need to make sense, they have the final say). So please whoever lives and works near the legal people at Red Hat buy them some coffee over lunch and ask them to raise the legalism crap. And finally if all they care is the mention of a package in the EULA, changing "fedora-logo" to "fedora-logo and fedora-logo-no-X" or whatever won't cost them more than 5 minutes of their life. -- 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 Jun 15 16:04:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 18:04:38 +0200 Subject: random comments about secondary arch proposal In-Reply-To: <46725F2B.6010702@leemhuis.info> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> Message-ID: <20070615160438.GJ9813@neu.nirvana> On Fri, Jun 15, 2007 at 11:43:07AM +0200, Thorsten Leemhuis wrote: > > > On 14.06.2007 19:40, Christopher Blizzard wrote: > > > Primary arch definition: need to make sure that part of the > > responsibility is that individual maintainers are required to make sure > > their stuff builds on all those arches. > > -1 -- Fedora Extras had lots of maintainers that are no programmers > and/or have only access to i386. Don't they have access to *build* their package through koji by definition on all archs? > Those maintainers are Fedora maintainers these days. Saying they are > "required to make sure their stuff builds on all primary arches" would > increase the burden on the maintainer drastically. I think that's > totally the wrong way forward. > > Further: if I would read something like that before becoming a > contributor I'd say "hey, that's hard stuff; I know my knowledge is not > enough to do that should I even run into a situation where something > doesn't build on PPC; well, then I won't become a contributor for > Fedora. Have fun guys, bye". But pcc is not a primary arch, or is it? I thought only i386/x86_64 would get the quality stamp "primary arch". :) I would go as far as to suggest test boxes on i386/x86_64 (e.g. primary archs) for packages to test their koji builds on in case they want to, but don't have the archs available otherwise. Sure, some packages like the kernel and glibc can't just be tested on a rmeote machine, but I hope the maintainers of these packages have access to more than just an i386 system ;=) -- 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 dtimms at iinet.net.au Fri Jun 15 16:07:19 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 16 Jun 2007 02:07:19 +1000 Subject: F8devel - user configuration storage locations In-Reply-To: <20070615094441.1482e8aa@cluestix.noc.ams-ix.net> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <20070614045607.GA17173@serv.smile.org.ua> <20070615094441.1482e8aa@cluestix.noc.ams-ix.net> Message-ID: <4672B937.4020703@iinet.net.au> Steven Bakker wrote: > On Thu, 14 Jun 2007 11:03:20 -0400 Tony Nelson wrote: > >>>> cp -a ~/.* >>> Not simple. If you do that you'll try to copy over the parent tree due to >>> '..' (that is satisfy your code) represents parent and '.' represents >>> current folder. >> Not simple, but how about: >> >> cp -a ~/.[!.]* . > > chsh -s /bin/zsh > cp -a ~/.* > > ;-) All those howto' are nice, but perhaps miss the point. Let's say I am a new linux user. Many apps I start store their config somewhere. Where ? Why make the configs files hidden at all ? Are there secrets in them ? Isn't this os/platform/distro built on openness ? If this user wanted to remove the settings and get back to the original default config by erasing a config for a certain app {say they mis-configured something} where would they imagine to find them ? Should they add a new user and start their settings all over again ? http://standards.freedesktop.org/basedir-spec/latest/ and related other standards on http://www.freedesktop.org/wiki/Specifications/ do provide some guidance for programmers. But do the storage locations actually make sense to non-programmers ? The first of the two links is definitely a difficult read. ps: I'll throw in that having a user "home" directory that isn't actually called "home" is another weird thing that is cause for confusion. I'd be one of those people who have "home" and "work" things on my computer, stored in folders named that. And then we have the users' home directory which is actually called "home"; that could perhaps be called "homes" or "homedirs", both would be less confusing. The current situation is that I go to my "home" directory within my user "home" directory called david, itself located within "/home". DaveT. From kevin.kofler at chello.at Fri Jun 15 16:11:17 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 16:11:17 +0000 (UTC) Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <20070615133219.GA6888@nostromo.devel.redhat.com> Message-ID: Bill Nottingham redhat.com> writes: > Argh. File a bug, please. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244428 Kevin Kofler From dtimms at iinet.net.au Fri Jun 15 16:34:32 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 16 Jun 2007 02:34:32 +1000 Subject: F8devel - user configuration storage locations In-Reply-To: <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> Message-ID: <4672BF98.4080309@iinet.net.au> Arthur Pemberton wrote: > On 6/13/07, David Timms wrote: >> A potential goal for Fedora: >> Cleanup user settings configuration >> >> For a long time applications creates a {hidden} .mysetting file in the >> user's home directory, if multiple config/settings under a >> .myapp/.various files. > > I would hate this That is the already the current state of play -or do I misread you ? >> I think this should be tidied up by creating a single directory at the >> users home folder to store all setting/configs that apps make. >> - The folder should not be hidden. > > I would hate this even more Is this hate directed toward the visibility, or to the idea of having all settings in a subfolder of the user's home dir ? >> - It should have a default text file indicating that it contains hidden >> files that store settings for installed applications. > > why? 1. So newsers know what it is and why it is there. 2. So newsers don't try to erase it. >> - It should be well named: configuration | config | application_config ? > > seems unnecessary To name it well ? Or to even have such a structure ? >> - All packages to use this folder > > good luck with that For all I know this location is just some system call, environment variable or something - does your experience show this would in fact require individual adjustment of each app ? >> I see some problems: >> - breaks FHStandard ? >> - every app would need to have a one time adjustment and package >> rebuilt ? > > You make that sound trivial Only because I haven't the foggiest what it would involve. >> Some advantages: >> - not mixing user data folders and application config in the same top >> level {user home} folder. > > I guess that's based on your point of view. These are user specific > configurations, which I consider to be part of my user data To some extent I would agree: eg thunderbird config and email storage are linked. > >> - less files to read / show / search when apps ask for the home dir file >> list > > I'm sorry if Gnome's dialog shows you everything by default, > but some of us use KDE, and it doesn't do that, so that's a non-issue No nautilus / gnome dialogs don't by default, I happen to set it this way. It is how I realized there is just so much crap stored in the user home folder. Mine has over 2000 files. About 14 directories and 50 are files I put there. Then there is 77 .folders and remainder what seems to be .config files for various apps, and temp files of some sort: .serverauth.2268 and similar dating back 8+ months. Perhaps there should be more adherence to using the /tmp folder, or a new special users/tmp folder that gets cleared each time the machine is booted, or the user logged in ? >> - easily move/copy all user configs to backup or a different machine > > cp -a ~/.* How do you do that in KDE, if it doesn't show the files ? Would you be able to configure a .textconfigfile from the filesystem viewer ? Would a newser be able to work it out without guidance ? I realize that these ideas are probably so adverse to age-old unix ways that it may not be possible to actually change it for existing apps ? DaveT. From tonynelson at georgeanelson.com Fri Jun 15 16:31:34 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 15 Jun 2007 12:31:34 -0400 Subject: F8devel - user configuration storage locations In-Reply-To: <4672B937.4020703@iinet.net.au> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <20070614045607.GA17173@serv.smile.org.ua> <20070615094441.1482e8aa@cluestix.noc.ams-ix.net> <4672B937.4020703@iinet.net.au> Message-ID: At 2:07 AM +1000 6/16/07, David Timms wrote: >Steven Bakker wrote: >> On Thu, 14 Jun 2007 11:03:20 -0400 Tony Nelson wrote: >> >>>>> cp -a ~/.* >>>> Not simple. If you do that you'll try to copy over the parent tree due to >>>> '..' (that is satisfy your code) represents parent and '.' represents >>>> current folder. >>> Not simple, but how about: >>> >>> cp -a ~/.[!.]* . >> >> chsh -s /bin/zsh >> cp -a ~/.* >> >> ;-) >All those howto' are nice, but perhaps miss the point. Let's say I am a >new linux user. Many apps I start store their config somewhere. Where ? > >Why make the configs files hidden at all ? ... ... So new users won't edit them or delete them. Really. There is no information in those files that a *new* user can safely change. They must get competent technical assistance first, which will know about .files as well as which files to change and how. This is *nix, and it is not "safe". Stupid user story: About 10 years ago, my brother commented that he'd grown to approve of Mac OS after his boss was moved from MSWindows (version?) to a Mac. His boss would "free up space" by deleting any file or directory that struck his fancy. This made MSWindows stop working, when he would delete applications or system directories, and it took a while to fix. On the Mac, putting files in the trash did no horm, and my brother would, once a week, select all files that shouldn't have been deleted and use the Put Away command on them, and then empty the trash. -- ____________________________________________________________________ TonyN.:' ' From tonynelson at georgeanelson.com Fri Jun 15 16:36:17 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 15 Jun 2007 12:36:17 -0400 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <20070615160042.GI9813@neu.nirvana> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <20070615160042.GI9813@neu.nirvana> Message-ID: At 6:00 PM +0200 6/15/07, Axel Thimm wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="tctmm6wHVGT/P6vA" >Content-Disposition: inline > >On Fri, Jun 15, 2007 at 08:58:34AM -0400, Matthias Clasen wrote: >> On Fri, 2007-06-15 at 12:38 +0200, Axel Thimm wrote: >> >> > Please decide on what is better, if you want the FPC to exempt >> > fedora-logos I'll bring it up there. But maybe the subpackage split is >> > preferred. >> >> It has been extensively discussed that splitting is not an option >> because legal wants us to keep all trademarked images in a single >> package. > >Spliting is *the option* along with teaching legal not to impose such >braindead non-technical issues. ... I would guess that Legal wants there to be a single package whose removal removes all trademarked artwork. I think their purpose is to make it simple for third parties to do legal re-issues from source, as CentOS does. Perhaps third parties also like having a single RPM to redo from scratch. -- ____________________________________________________________________ TonyN.:' ' From kevin.kofler at chello.at Fri Jun 15 16:42:24 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 16:42:24 +0000 (UTC) Subject: F8devel - user configuration storage locations References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <4672BF98.4080309@iinet.net.au> Message-ID: David Timms iinet.net.au> writes: > > cp -a ~/.* > How do you do that in KDE, if it doesn't show the files ? View / Show Hidden Files :-) Did you really think Konqueror wouldn't let you enable this? KDE is a highly configurable desktop environment! Kevin Kofler From fedora at leemhuis.info Fri Jun 15 16:51:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 15 Jun 2007 18:51:14 +0200 Subject: random comments about secondary arch proposal In-Reply-To: <20070615160438.GJ9813@neu.nirvana> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <20070615160438.GJ9813@neu.nirvana> Message-ID: <4672C382.4040809@leemhuis.info> On 15.06.2007 18:04, Axel Thimm wrote: > On Fri, Jun 15, 2007 at 11:43:07AM +0200, Thorsten Leemhuis wrote: >> >> On 14.06.2007 19:40, Christopher Blizzard wrote: >> >>> Primary arch definition: need to make sure that part of the >>> responsibility is that individual maintainers are required to make sure >>> their stuff builds on all those arches. >> -1 -- Fedora Extras had lots of maintainers that are no programmers >> and/or have only access to i386. > Don't they have access to *build* their package through koji by > definition on all archs? That's a help only for "have only access to i386" people; and even then it's often a lot easier to do it on a machine you have direct access to then to until builds_on_ppc() do look at the code write a patch to fix a issue commit a patch to CVS tag build wait done >> Those maintainers are Fedora maintainers these days. Saying they are >> "required to make sure their stuff builds on all primary arches" would >> increase the burden on the maintainer drastically. I think that's >> totally the wrong way forward. >> >> Further: if I would read something like that before becoming a >> contributor I'd say "hey, that's hard stuff; I know my knowledge is not >> enough to do that should I even run into a situation where something >> doesn't build on PPC; well, then I won't become a contributor for >> Fedora. Have fun guys, bye". > But pcc is not a primary arch, or is it? There is not final decision yet (or I missed it), but afaics it looks like PPC will be one at least for the near future until the secondary arch stuff works fine for another arch. > [...] > I would go as far as to suggest test boxes on i386/x86_64 > (e.g. primary archs) for packages to test their koji builds on in case > they want to, but don't have the archs available otherwise. Sure, some > packages like the kernel and glibc can't just be tested on a rmeote > machine, but I hope the maintainers of these packages have access to > more than just an i386 system ;=) Yes, something like that would be nice to have; but I'm not sure if other stuff would be more important (automatic tests for example). CU thl From dtimms at iinet.net.au Fri Jun 15 16:58:05 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 16 Jun 2007 02:58:05 +1000 Subject: guideline-isms leading to dependency bloats In-Reply-To: References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> <1181912314.3453.2.camel@localhost.localdomain> <20070615160042.GI9813@neu.nirvana> Message-ID: <4672C51D.9040405@iinet.net.au> Tony Nelson wrote: > At 6:00 PM +0200 6/15/07, Axel Thimm wrote: >> Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; boundary="tctmm6wHVGT/P6vA" >> Content-Disposition: inline >> >> On Fri, Jun 15, 2007 at 08:58:34AM -0400, Matthias Clasen wrote: >>> On Fri, 2007-06-15 at 12:38 +0200, Axel Thimm wrote: >>> >>>> Please decide on what is better, if you want the FPC to exempt >>>> fedora-logos I'll bring it up there. But maybe the subpackage split is >>>> preferred. >>> It has been extensively discussed that splitting is not an option >>> because legal wants us to keep all trademarked images in a single >>> package. >> Spliting is *the option* along with teaching legal not to impose such >> braindead non-technical issues. > ... > > I would guess that Legal wants there to be a single package whose removal > removes all trademarked artwork. I think their purpose is to make it > simple for third parties to do legal re-issues from source, as CentOS does. > Perhaps third parties also like having a single RPM to redo from scratch. Actually, couldn't that be done if the package was split into subpackages, and the new subpackage containing logos required at boot became a requirement of fedora-logos ? If you then pirut or yum remove fedora-logos, fedora-logos-boot would get uninstalled as well ? And legal stays happy :) DaveT. From drago01 at gmail.com Fri Jun 15 17:11:24 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 15 Jun 2007 19:11:24 +0200 Subject: F8devel - UI "responsiveness" improvements In-Reply-To: <1181829565.30663.75.camel@localhost.localdomain> References: <46705A88.9000207@iinet.net.au> <1181829565.30663.75.camel@localhost.localdomain> Message-ID: On 6/14/07, Adam Jackson wrote: > > On Thu, 2007-06-14 at 06:58 +1000, David Timms wrote: > > I'd like to suggest a goal for future Fedora of ensuring every > > application / task performed with Fedora actually provides user feedback > > at a minimum 1 {one} second interval. > > > > Culprits: > > - anaconda between go-ahead with install and first package installing > > {especially noticeable because the {boring} X screen saver kicks in. You > > then move the mouse to get the screen back - but there is no update to > > the screen for maybe one minute or more. > > > > - pup during an update run with about 30-40 packages. It took nearly an > > hour. Each time an app covered its windows they may not have been > > redrawn for some minutes. > > Just to clarify, it's not that you want continuous screen updates, it's > that you don't want to see apps in the middle of redraw. > > We could solve this trivially by turning on automatic compositing by > default but I don't think that's ready yet. multithreading would also solve this isses... use a thread for the gui and one that does the real work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From williams at redhat.com Fri Jun 15 20:25:33 2007 From: williams at redhat.com (Clark Williams) Date: Fri, 15 Jun 2007 15:25:33 -0500 Subject: Fedora and Cross Compiling In-Reply-To: <1181915140.3221.57.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <1181914603.3221.54.camel@mccallum.corsepiu.local> <46729754.6030009@redhat.com> <1181915140.3221.57.camel@mccallum.corsepiu.local> Message-ID: <4672F5BD.50508@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: > On Fri, 2007-06-15 at 08:42 -0500, David Smith wrote: >> Ralf Corsepius wrote: >>> Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default >>> "rpmroot"? >>> >>> e.g. to run >>> rpm -i -r /usr/share//var/lib/rpm xxx.sparc.rpm >>> on non-sparc systems? >> Sure. I believe we used the '--root PATH' feature of rpm. > How about scriptlets? > > One could try to run the host tools with paths altered, but ... > We actually do that. When composing a rootfs from a bag of target rpms, we extract the %pre's, move the 'binaries' directories (bin, lib, ...) in the target rootfs to .save, symlink in the host equivalents, run the scriptlets, undo the moves, do an rpm install with --noscripts, extract the %posts, move off the binaries, link in the hosts, run the posts, undo the moves. Surprisingly effective for 90% or more of scriptlets, since most of them just modify a data file. Of course this is Python wrapper code that utilized the RPM module to pull scriptlets, etc. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGcvWwHyuj/+TTEp0RAtVGAKCk+Zu5k3alK96ieU5q8ppIlj+FcgCdEbcr Sk5QIo5r7JPNTrkR+w53gL0= =C8BA -----END PGP SIGNATURE----- From Matt_Domsch at dell.com Fri Jun 15 20:26:24 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 15 Jun 2007 15:26:24 -0500 Subject: random comments about secondary arch proposal In-Reply-To: <20070615160438.GJ9813@neu.nirvana> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <20070615160438.GJ9813@neu.nirvana> Message-ID: <20070615202624.GA21659@auslistsprd01.us.dell.com> On Fri, Jun 15, 2007 at 06:04:38PM +0200, Axel Thimm wrote: > But pcc is not a primary arch, or is it? I thought only i386/x86_64 > would get the quality stamp "primary arch". :) yes, ppc is still a primary arch. http://fedoraproject.org/wiki/Board/Meetings/2007-06-12#head-42420222399530fe68e82110587b5ac5c08d75a4 -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From greno at verizon.net Fri Jun 15 19:51:27 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 15 Jun 2007 15:51:27 -0400 Subject: FC6: devhelp: missing dependency Message-ID: <4672EDBF.60901@verizon.net> ]# yum install devhelp Loading "installonlyn" plugin Setting up Install Process Setting up repositories Reading repository metadata in from local files Excluding Packages from Livna for Fedora Core 6 - i386 - Base Finished Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package devhelp.i386 0:0.12-11.fc6 set to be updated --> Running transaction check --> Processing Dependency: gecko-libs = 1.8.0.12 for package: devhelp --> Finished Dependency Resolution Error: Missing Dependency: gecko-libs = 1.8.0.12 is needed by package devhelp <============== # yum list gecko-libs Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Livna for Fedora Core 6 - i386 - Base Finished # From limb at jcomserv.net Fri Jun 15 19:43:05 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 15 Jun 2007 14:43:05 -0500 (CDT) Subject: Unsigned package In-Reply-To: <27855.65.192.24.164.1181840840.squirrel@mail.jcomserv.net> References: <16808.65.192.24.190.1181239686.squirrel@mail.jcomserv.net> <200706110920.04931.jkeating@redhat.com> <46701E75.6040605@theholbrooks.org> <200706131311.13201.jkeating@redhat.com> <27855.65.192.24.164.1181840840.squirrel@mail.jcomserv.net> Message-ID: <64656.65.192.24.164.1181936585.squirrel@mail.jcomserv.net> Working on the mirror upstream of mine. Thanks! > >> On Wednesday 13 June 2007 12:42:29 Brandon Holbrook wrote: >>> Any updates on this? I see scons and php-pear-Mail-Mime are still both >>> unsigned on download.f.r.c. And just to clarify, as the Mail-Mime >>> maintainer, this build was my first experiment with koji. Was there >>> some error on my part? If a mirror sync is too troublesome, I don't >>> mind bumping the release and rebuilding :) >> >> It wasn't your fault, just a tools and oversight issue on our part. The >> tree >> was supposed to be synced last night, looking into why it didn't happen. > > (Daily sync check) :) > >> -- >> Jesse Keating >> Release Engineer: Fedora >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- > novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From chitlesh at fedoraproject.org Fri Jun 15 18:58:08 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 15 Jun 2007 20:58:08 +0200 Subject: Summary - Broken deps in Fedora 7 + Test Updates - 2007-06-14 In-Reply-To: <20070614152025.27947.93929@extras64.linux.duke.edu> References: <20070614152025.27947.93929@extras64.linux.duke.edu> Message-ID: <13dbfe4f0706151158p2426f157oe381701b4a08a0f8@mail.gmail.com> On 6/14/07, Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > > cgoorah AT yahoo.com.au > geda-examples - 20070216-2.fc7.noarch (12 days) > Broken packages in fedora-7-ppc64: > geda-examples-20070216-2.fc7.noarch requires geda-gschem A new upstream release will be out soon, which I'll be waiting for the update. Chitlesh -- http://clunixchit.blogspot.com From katzj at redhat.com Fri Jun 15 18:27:49 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 15 Jun 2007 14:27:49 -0400 Subject: Fedora 8 Schedule Message-ID: <1181932070.7422.13.camel@erebor.boston.redhat.com> The Fedora 8 schedule has been finalized by the Fedora Engineering Steering Committee. Based on the schedule proposed by the board, FESCo has made some slight changes to better accommodate the schedules of some of our high-profile upstream projects. Highlights of the schedule are: 1 August 2007 -- Fedora 8 Test1 released 5 September 2007 -- Fedora 8 Test2 released 3 October 2007 -- Fedora 8 Test3 released 7 November 2007 -- Fedora 8 General Availability As always, see http://fedoraproject.org/wiki/Releases/8/Schedule for the full details including freeze dates, translation schedules, etc Jeremy _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From buildsys at fedoraproject.org Fri Jun 15 18:21:09 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 15 Jun 2007 14:21:09 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-15 Message-ID: <20070615182109.681EF152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 19 NEW avr-gdb-6.6-4.fc6 : GDB for (remote) debugging avr binaries NEW conduit-0.3.1-2.fc6 : A synchronization solution for GNOME easytag-2.1-1.fc6 freetds-0.64-6.fc6 gimmie-0.2.7-1.fc6 gparted-0.3.3-3.fc6 gscan2pdf-0.9.10-2.fc6 libtasn1-0.3.10-1.fc6 mimetic-0.9.3-1.fc6 muParser-1.27-5.fc6 nautilus-actions-1.4.1-1.fc6 php-extras-5.1.6-3.fc6 postgresql-pgpool-II-1.1.1-1.fc6 (!) postgresql_autodoc-1.30-2.fc6 : INVALID rebuild, not published! python-psycopg2-2.0.6-1.fc6 rdiff-backup-1.0.5-2.fc6 starfighter-1.1-9.fc6 texmaker-1.5-2.fc6 viruskiller-1.0-4.fc6 Packages built and released for Fedora Extras 5: 9 gscan2pdf-0.9.10-2.fc5 liferea-1.0.24-4.fc5 muParser-1.27-5.fc5 nautilus-actions-1.4.1-1.fc5 postgresql-pgpool-II-1.1.1-1.fc5 python-psycopg2-2.0.6-1.fc5 starfighter-1.1-9.fc5 texmaker-1.5-2.fc5 viruskiller-1.0-4.fc5 Changes in Fedora Extras 6: avr-gdb-6.6-4.fc6 ----------------- * Thu Jun 14 2007 Hans de Goede 6.6-4 - Add BuildRequires: ncurses-devel (bz 243248) - Use VPATh building (bz 243248) * Mon Jun 11 2007 Hans de Goede 6.6-3 - Remove bogus avr-gcc-c++ Requires (bz 243248) * Fri Jun 08 2007 Hans de Goede 6.6-2 - Various specfile cleanups * Thu May 31 2007 Lennart Kneppers 6.6-1 - Initial release conduit-0.3.1-2.fc6 ------------------- * Mon Jun 11 2007 Bernard Johnson - 0.3.1-2 - remove Application from desktop file category * Fri Jun 08 2007 Bernard Johnson - 0.3.1-1 - v 0.3.1 - use disttag macros to require python-elementtree when required - tidy summary to be easier to read - remove icon substitution, no longer needed - remove fixup of Categories in .desktop file * Thu May 24 2007 Bernard Johnson - 0.3.0-3 - change source0 url to use %name and %version macros easytag-2.1-1.fc6 ----------------- * Tue May 08 2007 Matthias Saou 2.1-1 - Update to 2.1. * Wed May 02 2007 Matthias Saou 2.0.2-1 - Update to 2.0.2. freetds-0.64-6.fc6 ------------------ * Fri Jun 15 2007 Dmitry Butskoy - 0.64-6 - bump release to provide update path over Livna gimmie-0.2.7-1.fc6 ------------------ * Thu Jun 14 2007 Deji Akingunola - 0.2.7-1 - New release gparted-0.3.3-3.fc6 ------------------- * Mon Jun 11 2007 Deji Akingunola - 0.3.3-3 - Apply patch to only detect real devices, useful for correcting gparted slow startup in situations when floppy drives doesn't exist but are enabled in bios (BZ #208821). gscan2pdf-0.9.10-2.fc6 ---------------------- * Thu Jun 14 2007 Bernard Johnson - 0.9.10-2 - patch to fix paper size of output pdf file libtasn1-0.3.10-1.fc6 --------------------- * Thu Jun 14 2007 Enrico Scholz - 0.3.10-1 - updated to 0.3.10 mimetic-0.9.3-1.fc6 ------------------- * Thu Jun 14 2007 Enrico Scholz - 0.9.3-1 - updated to 0.9.3 muParser-1.27-5.fc6 ------------------- * Fri Jun 15 2007 Frank B?ttner - 1.27-5.fc6 - fix bug #244309 nautilus-actions-1.4.1-1.fc6 ---------------------------- * Wed May 30 2007 Deji Akingunola - 1.4.1-1 - New (bug-fix) release php-extras-5.1.6-3.fc6 ---------------------- * Fri Jun 15 2007 Dmitry Butskoy - 5.1.6-3 - add --with-libdir=%{_lib} to handle 64bit arches properly * Thu Jun 14 2007 Dmitry Butskoy - 5.1.6-2 - add php-mssql support postgresql-pgpool-II-1.1.1-1.fc6 -------------------------------- * Fri Jun 15 2007 Devrim Gunduz 1.1.1-1 - Update to 1.1.1 postgresql_autodoc-1.30-2.fc6 ----------------------------- * Sat Jun 09 2007 - Devrim GUNDUZ 1.30-2 - Some more fixes ber bugzilla review #200630 python-psycopg2-2.0.6-1.fc6 --------------------------- * Fri Jun 15 2007 - Devrim GUNDUZ 2.0.6-1 - Update to 2.0.6 * Wed Dec 06 2006 - Devrim GUNDUZ 2.0.5.1-4 - Rebuilt for PostgreSQL 8.2.0 * Mon Sep 11 2006 - Devrim GUNDUZ 2.0.5.1-3 - Rebuilt * Wed Sep 06 2006 - Devrim GUNDUZ 2.0.5.1-2 - Remove ghost'ing, per Python Packaging Guidelines rdiff-backup-1.0.5-2.fc6 ------------------------ * Fri Jun 15 2007 Gavin Henry 1.0.5-2 - Applied patch from Marcin Zajaczkowski for addition of pylibacl, pyxattr in Requires section starfighter-1.1-9.fc6 --------------------- * Thu Jun 14 2007 Matthias Saou 1.1-9 - Move binary and data to "proper" locations by updating patch (#229197). texmaker-1.5-2.fc6 ------------------ * Fri Jun 15 2007 Deji Akingunola - 1.5-2 - Fix for crash on x86_64 by Kevin Kofler (BZ #235546) viruskiller-1.0-4.fc6 --------------------- * Thu Jun 14 2007 Matthias Saou 1.0-4 - Move binary and data to "proper" locations by updating patch (#243031). - Remove executable bit from all files from the archive, it shouldn't be set. * Fri Feb 02 2007 Matthias Saou 1.0-3 - Make in-game help display the proper location for the manual.html (#220404). Changes in Fedora Extras 5: gscan2pdf-0.9.10-2.fc5 ---------------------- * Thu Jun 14 2007 Bernard Johnson - 0.9.10-2 - patch to fix paper size of output pdf file liferea-1.0.24-4.fc5 -------------------- * Fri Jun 15 2007 Brian Pepple - 1.0.24-4 - Build against new seamonkey. muParser-1.27-5.fc5 ------------------- * Fri Jun 15 2007 Frank B?ttner - 1.27-5.fc5 - fix bug #244309 nautilus-actions-1.4.1-1.fc5 ---------------------------- * Wed May 30 2007 Deji Akingunola - 1.4.1-1 - New (bug-fix) release postgresql-pgpool-II-1.1.1-1.fc5 -------------------------------- * Fri Jun 15 2007 Devrim Gunduz 1.1.1-1 - Update to 1.1.1 python-psycopg2-2.0.6-1.fc5 --------------------------- * Fri Jun 15 2007 - Devrim GUNDUZ 2.0.6-1 - Update to 2.0.6 starfighter-1.1-9.fc5 --------------------- * Thu Jun 14 2007 Matthias Saou 1.1-9 - Move binary and data to "proper" locations by updating patch (#229197). * Mon Aug 28 2006 Matthias Saou 1.1-8 - FC6 rebuild. texmaker-1.5-2.fc5 ------------------ * Fri Jun 15 2007 Deji Akingunola - 1.5-2 - Fix for crash on x86_64 by Kevin Kofler (BZ #235546) viruskiller-1.0-4.fc5 --------------------- * Thu Jun 14 2007 Matthias Saou 1.0-4 - Move binary and data to "proper" locations by updating patch (#243031). - Remove executable bit from all files from the archive, it shouldn't be set. * Fri Feb 02 2007 Matthias Saou 1.0-3 - Make in-game help display the proper location for the manual.html (#220404). * Mon Aug 28 2006 Matthias Saou 1.0-2 - FC6 rebuild. - Add -lz to LIBS in the makefile patch (no longer in SDL libs?). For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lmacken at redhat.com Fri Jun 15 17:55:01 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 15 Jun 2007 13:55:01 -0400 Subject: bodhi server error In-Reply-To: <1181897843.13412.126.camel@mccallum.corsepiu.local> References: <1181897843.13412.126.camel@mccallum.corsepiu.local> Message-ID: <20070615175501.GD14190@tomservo.rochester.rr.com> On Fri, Jun 15, 2007 at 10:57:23AM +0200, Ralf Corsepius wrote: > Bodhi bombs out with the error when accessing this URL: > > https://admin.fedoraproject.org/updates/testing/F7/mock-0.7.1-1.fc7 > > 500 Internal error > The server encountered an unexpected condition which prevented it from > fulfilling the request. > > Powered by CherryPy 2.2.1 Works for me. This issue is most likely due to a session timeout issue that we've been experiencing. CherryPy seems to be tossing the following exception after a users session times out and they continue to use the site, instead of bringing them back to the login page. [cherrypy.msg] INFO HTTP: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cherrypy/_cphttptools.py", line 103, in _run applyFilters('before_main') File "/usr/lib/python2.4/site-packages/cherrypy/filters/__init__.py", line 151, in applyFilters method() File "/usr/lib/python2.4/site-packages/cherrypy/filters/decodingfilter.py", line 31, in before_main self.decode(enc) File "/usr/lib/python2.4/site-packages/cherrypy/filters/decodingfilter.py", line 50, in decode decodedParams[key] = value.decode(enc) AttributeError: 'dict' object has no attribute 'decode' We're looking into it. luke From kevin.kofler at chello.at Fri Jun 15 20:33:04 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 20:33:04 +0000 (UTC) Subject: Please don't let updates sit in testing forever Message-ID: Maintainers, please don't let your F7 updates linger in updates-testing forever. I've posted nag comments to the updates 2 weeks or more old, but I guess a lot of the 1-2 weeks old updates could also use getting pushed to stable. Either the update is broken or it's not. If it's broken, it should be withdrawn (unpushed) from updates-testing. If it works, why not mark it as stable? And I don't think waiting for feedback for more than 2 weeks makes sense, 1 week was pretty much the consensus in the discussions here and on fedora-maintainers. If there are no complaints in 2 weeks, the package can't be that broken, or if it is it most likely won't affect many people or someone would have noticed. :-) And no, pushing to stable after a timeout is currently not automatic. Kevin Kofler From dwmw2 at infradead.org Fri Jun 15 19:58:41 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jun 2007 20:58:41 +0100 Subject: random comments about secondary arch proposal In-Reply-To: <20070615160438.GJ9813@neu.nirvana> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <20070615160438.GJ9813@neu.nirvana> Message-ID: <1181937522.5211.72.camel@shinybook.infradead.org> On Fri, 2007-06-15 at 18:04 +0200, Axel Thimm wrote: > But pcc is not a primary arch, or is it? I thought only i386/x86_64 > would get the quality stamp "primary arch". :) It was agreed that PPC wouldn't be moved to 'secondary' status until some other architecture has come online and shown that the whole thing actually works. > I would go as far as to suggest test boxes on i386/x86_64 > (e.g. primary archs) for packages to test their koji builds on in case > they want to, but don't have the archs available otherwise. http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures#head-2d743396d13013a983793ba4f3f020adf2a23c74 -- dwmw2 From debarshi.ray at gmail.com Fri Jun 15 18:28:55 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 15 Jun 2007 23:58:55 +0530 Subject: bodhi server error In-Reply-To: <3170f42f0706151111o594a6d27w744e1657d0b3b0a7@mail.gmail.com> References: <1181897843.13412.126.camel@mccallum.corsepiu.local> <3170f42f0706151111o594a6d27w744e1657d0b3b0a7@mail.gmail.com> Message-ID: <3170f42f0706151128t7db4ac2aofcce205776c31630@mail.gmail.com> Seems to be working fine now. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Fri Jun 15 18:11:54 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 15 Jun 2007 23:41:54 +0530 Subject: bodhi server error In-Reply-To: <1181897843.13412.126.camel@mccallum.corsepiu.local> References: <1181897843.13412.126.camel@mccallum.corsepiu.local> Message-ID: <3170f42f0706151111o594a6d27w744e1657d0b3b0a7@mail.gmail.com> https://admin.fedoraproject.org/updates/ gives me: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /updates/. Reason: DNS lookup failure for: app5.fedora.phx.redhat.com Apache/2.2.3 (Red Hat) Server at admin.fedoraproject.org Port 443 Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From pemboa at gmail.com Fri Jun 15 18:25:58 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 15 Jun 2007 13:25:58 -0500 Subject: F8devel - user configuration storage locations In-Reply-To: <4672BF98.4080309@iinet.net.au> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <4672BF98.4080309@iinet.net.au> Message-ID: <16de708d0706151125n56395057ye6ea57215c92048b@mail.gmail.com> On 6/15/07, David Timms wrote: > Arthur Pemberton wrote: > > On 6/13/07, David Timms wrote: > >> A potential goal for Fedora: > >> Cleanup user settings configuration > >> > >> For a long time applications creates a {hidden} .mysetting file in the > >> user's home directory, if multiple config/settings under a > >> .myapp/.various files. > > > > I would hate this > That is the already the current state of play -or do I misread you ? I wasn't clear, I would hate forcing all apps into a single directory. > >> I think this should be tidied up by creating a single directory at the > >> users home folder to store all setting/configs that apps make. > >> - The folder should not be hidden. > > > > I would hate this even more > Is this hate directed toward the visibility, or to the idea of having > all settings in a subfolder of the user's home dir ? Both. I applaud Windows for making system files hidden by default. A user who doesn't know how to unhide files shouldn't be playing with those files. It's a low bar, but I think a necessary one. > >> - It should have a default text file indicating that it contains hidden > >> files that store settings for installed applications. > > > > why? > 1. So newsers know what it is and why it is there. > 2. So newsers don't try to erase it. See. In my opinion, you just created two problems by creating this config directory, and then gave a weak solution to them - I can't think of a stronger solution myself. > >> - It should be well named: configuration | config | application_config ? > > > > seems unnecessary > To name it well ? Or to even have such a structure ? To have such a structure - I really should have been clearer. > >> - All packages to use this folder > > > > good luck with that > For all I know this location is just some system call, environment > variable or something - does your experience show this would in fact > require individual adjustment of each app ? Yes, I'm pretty sure most programs just get the $HOME variable and put stuff in there. There's a separate $CONFIG variable (I think) which points to /etc. I do not think there's a $HOMECONFIG or equivalent variable. > >> I see some problems: > >> - breaks FHStandard ? > >> - every app would need to have a one time adjustment and package > >> rebuilt ? > > > > You make that sound trivial > Only because I haven't the foggiest what it would involve. I'm pretty sure it involves what you suggested "every app needs to have a one time adjustment and package rebuilt" , except the change would be the same, I'm not sure the exact adjustment would be the same. [ snip ] > >> - less files to read / show / search when apps ask for the home dir file > >> list > > > > I'm sorry if Gnome's dialog shows you everything by default, > > but some of us use KDE, and it doesn't do that, so that's a non-issue > No nautilus / gnome dialogs don't by default, I happen to set it this > way. It is how I realized there is just so much crap stored in the user > home folder. > > Mine has over 2000 files. About 14 directories and 50 are files I put > there. Then there is 77 .folders and remainder what seems to be .config > files for various apps, and temp files of some sort: > .serverauth.2268 and similar dating back 8+ months. Do you use Gnome? > Perhaps there should be more adherence to using the /tmp folder, or a > new special users/tmp folder that gets cleared each time the machine is > booted, or the user logged in ? Those folders aren't temporary, in the sense that the apps use them when they reopen (although most can be safely deleted) > >> - easily move/copy all user configs to backup or a different machine > > > > cp -a ~/.* > How do you do that in KDE, if it doesn't show the files ? Well that's a command prompt command. But anyways, in KDE it's extremely easy to switch between hidden files shown and not shown. > Would you be > able to configure a .textconfigfile from the filesystem viewer ? Would a > newser be able to work it out without guidance ? I would, but that is very rarely necessary. Rare enough that I have can remember doing it less than a half dozen times. > I realize that these ideas are probably so adverse to age-old unix ways > that it may not be possible to actually change it for existing apps ? > > DaveT. That may be true, but they do in fact work quite well. These kind of files are use specific, so they are in the user's homedir, but aren't really for the toying of the average user, so they are hidden. They are in multiple directories since they are all already in home, and having them in another singer directory within home makes them a bit more vunerable to accidental deletion. Looking back on my response, it seems a bit disrespectful. I respect your suggestions, but I do not agree with them. -- Fedora Core 6 and proud From Axel.Thimm at ATrpms.net Fri Jun 15 20:46:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 22:46:37 +0200 Subject: random comments about secondary arch proposal In-Reply-To: <20070615202624.GA21659@auslistsprd01.us.dell.com> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <20070615160438.GJ9813@neu.nirvana> <20070615202624.GA21659@auslistsprd01.us.dell.com> Message-ID: <20070615204637.GA32080@neu.nirvana> On Fri, Jun 15, 2007 at 03:26:24PM -0500, Matt Domsch wrote: > On Fri, Jun 15, 2007 at 06:04:38PM +0200, Axel Thimm wrote: > > But pcc is not a primary arch, or is it? I thought only i386/x86_64 > > would get the quality stamp "primary arch". :) > > yes, ppc is still a primary arch. > http://fedoraproject.org/wiki/Board/Meetings/2007-06-12#head-42420222399530fe68e82110587b5ac5c08d75a4 Well in fact that's up to interpretation: "Decisions: * PPC will remain a primary architecture until: 1. secondary arch process is finalized 2. there are no other secondary architectures * Board approves and welcomes ARM as a secondary architecture" So the second part of the requirement is already fulfilled, and what remains is just to have the infrastructure for secondary archs ready, e.g. separate storage and koji not rejecting builds due to secondary archs. Maybe I'm missing another secondary arch implementation detail, but these tasks look rather managable. So I think one can read this as "ppc/arm have been decided to become secondary arches, we junst need to setup the infrastructure for them". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Fri Jun 15 20:41:27 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 15 Jun 2007 16:41:27 -0400 Subject: Please don't let updates sit in testing forever In-Reply-To: References: Message-ID: <1181940087.3635.14.camel@localhost.localdomain> On Fri, 2007-06-15 at 20:33 +0000, Kevin Kofler wrote: > Maintainers, please don't let your F7 updates linger in updates-testing > forever. I've posted nag comments to the updates 2 weeks or more old, but I > guess a lot of the 1-2 weeks old updates could also use getting pushed to > stable. > > Either the update is broken or it's not. If it's broken, it should be withdrawn > (unpushed) from updates-testing. If it works, why not mark it as stable? And I > don't think waiting for feedback for more than 2 weeks makes sense, 1 week was > pretty much the consensus in the discussions here and on fedora-maintainers. If > there are no complaints in 2 weeks, the package can't be that broken, or if it > is it most likely won't affect many people or someone would have noticed. :-) > > And no, pushing to stable after a timeout is currently not automatic. The old fedora updates tool sent nag mail...I assume that updates will be pushed to stable more regularly once that is implemented in bodhi. From mschwendt.tmp0701.nospam at arcor.de Fri Jun 15 20:48:00 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 15 Jun 2007 22:48:00 +0200 Subject: FC6: devhelp: missing dependency In-Reply-To: <4672EDBF.60901@verizon.net> References: <4672EDBF.60901@verizon.net> Message-ID: <20070615224800.feb75aee.mschwendt.tmp0701.nospam@arcor.de> On Fri, 15 Jun 2007 15:51:27 -0400, Gerry Reno wrote: > ]# yum install devhelp > Loading "installonlyn" plugin > Setting up Install Process > Setting up repositories > Reading repository metadata in from local files > Excluding Packages from Livna for Fedora Core 6 - i386 - Base > Finished > Parsing package install arguments > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package devhelp.i386 0:0.12-11.fc6 set to be updated > --> Running transaction check > --> Processing Dependency: gecko-libs = 1.8.0.12 for package: devhelp > --> Finished Dependency Resolution > Error: Missing Dependency: gecko-libs = 1.8.0.12 is needed by package > devhelp <============== > > # yum list gecko-libs It is provided by package "firefox", e.g. $ rpm --query --provides firefox |grep gecko gecko-libs = 1.8.0.12 Is there a newer firefox for FC6? I don't see any update in the master repo yet. From j.w.r.degoede at hhs.nl Fri Jun 15 21:06:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 15 Jun 2007 23:06:36 +0200 Subject: Please don't let updates sit in testing forever In-Reply-To: <1181940087.3635.14.camel@localhost.localdomain> References: <1181940087.3635.14.camel@localhost.localdomain> Message-ID: <4672FF5C.30103@hhs.nl> Matthias Clasen wrote: > On Fri, 2007-06-15 at 20:33 +0000, Kevin Kofler wrote: >> Maintainers, please don't let your F7 updates linger in updates-testing >> forever. I've posted nag comments to the updates 2 weeks or more old, but I >> guess a lot of the 1-2 weeks old updates could also use getting pushed to >> stable. >> >> Either the update is broken or it's not. If it's broken, it should be withdrawn >> (unpushed) from updates-testing. If it works, why not mark it as stable? And I >> don't think waiting for feedback for more than 2 weeks makes sense, 1 week was >> pretty much the consensus in the discussions here and on fedora-maintainers. If >> there are no complaints in 2 weeks, the package can't be that broken, or if it >> is it most likely won't affect many people or someone would have noticed. :-) >> >> And no, pushing to stable after a timeout is currently not automatic. > > The old fedora updates tool sent nag mail...I assume that updates will > be pushed to stable more regularly once that is implemented in bodhi. > Nag mail is not the answer, an option saying push this automatically to stable after X days is the answer. And yes I know not everyone wants this to happen for their packages, thus it should be an option. Regards, Hans From mclasen at redhat.com Fri Jun 15 20:56:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 15 Jun 2007 16:56:22 -0400 Subject: Please don't let updates sit in testing forever In-Reply-To: <4672FF5C.30103@hhs.nl> References: <1181940087.3635.14.camel@localhost.localdomain> <4672FF5C.30103@hhs.nl> Message-ID: <1181940982.3635.17.camel@localhost.localdomain> On Fri, 2007-06-15 at 23:06 +0200, Hans de Goede wrote: > Matthias Clasen wrote: > > On Fri, 2007-06-15 at 20:33 +0000, Kevin Kofler wrote: > >> Maintainers, please don't let your F7 updates linger in updates-testing > >> forever. I've posted nag comments to the updates 2 weeks or more old, but I > >> guess a lot of the 1-2 weeks old updates could also use getting pushed to > >> stable. > >> > >> Either the update is broken or it's not. If it's broken, it should be withdrawn > >> (unpushed) from updates-testing. If it works, why not mark it as stable? And I > >> don't think waiting for feedback for more than 2 weeks makes sense, 1 week was > >> pretty much the consensus in the discussions here and on fedora-maintainers. If > >> there are no complaints in 2 weeks, the package can't be that broken, or if it > >> is it most likely won't affect many people or someone would have noticed. :-) > >> > >> And no, pushing to stable after a timeout is currently not automatic. > > > > The old fedora updates tool sent nag mail...I assume that updates will > > be pushed to stable more regularly once that is implemented in bodhi. > > > > Nag mail is not the answer, an option saying push this automatically to stable > after X days is the answer. And yes I know not everyone wants this to happen > for their packages, thus it should be an option. Pushing automatically is inferior to nag mail since nag mail makes me go back to the update, look at possible feedback in fedora-test-list and bugzilla, and then make a conscious decision to push it. Automating this just further devalues updates-testing. IMO From kevin.kofler at chello.at Fri Jun 15 21:05:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 21:05:35 +0000 (UTC) Subject: Please don't let updates sit in testing forever References: <1181940087.3635.14.camel@localhost.localdomain> Message-ID: Matthias Clasen redhat.com> writes: > The old fedora updates tool sent nag mail...I assume that updates will > be pushed to stable more regularly once that is implemented in bodhi. Or once someone manually copies&pastes the nag comments. :-) So, should I do this for the 1-week-old updates too? ;-) Kevin Kofler From denis at poolshark.org Fri Jun 15 21:22:42 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 15 Jun 2007 23:22:42 +0200 Subject: Automating pam_keyring... Message-ID: <46730322.6020400@poolshark.org> Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 problem for me: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741 I'll push an update shortly. Installing pam_keyring isn't enough though, it still requires manual edition of /etc/pam.d/gdm to make it work. I was hoping to start some discussions on what needs to happen to make its behavior enabled automatically upon installation, especially since this is on the F-8 wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). Or add a patch to the gdm package and make it require pam_keyring ? Or do we want to make this feature optional from authconfig ? Another issue is how do we update the keyring password when the user changes his/her password ? denis From axel.azerty at laposte.net Fri Jun 15 21:24:11 2007 From: axel.azerty at laposte.net (Axel) Date: Fri, 15 Jun 2007 23:24:11 +0200 Subject: user created at install added in sudoers ? Message-ID: <4673037B.3030105@laposte.net> What do you think about adding the user created at install to the sudoers list ? For newbies like me, understanding the sudoers file isn't so easy, but nevertheless they may need the sudo command. In my case, I'd rather my account would have been added automatically to the sudoers list :) Axel From ajackson at redhat.com Fri Jun 15 21:20:45 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 15 Jun 2007 17:20:45 -0400 Subject: guideline-isms leading to dependency bloats (was: fedora-logos dependencies in F7) In-Reply-To: <20070615103810.GC9813@neu.nirvana> References: <05a101c7af2e$e6fa53b0$0a00000a@DEAD2> <46725DC3.8020501@fedoraproject.org> <20070615102013.GA9813@neu.nirvana> <4672687E.3080005@fedoraproject.org> <20070615103810.GC9813@neu.nirvana> Message-ID: <1181942445.30663.148.camel@localhost.localdomain> On Fri, 2007-06-15 at 12:38 +0200, Axel Thimm wrote: > On Fri, Jun 15, 2007 at 03:52:54PM +0530, Rahul Sundaram wrote: > > Axel Thimm wrote: > > >On Fri, Jun 15, 2007 at 03:07:07PM +0530, Rahul Sundaram wrote: > > >>Hans K. Rosbach wrote: > > >>>Grub depends on fedora-logos that in turn depends on gtk2-engines > > >>>and pretty soon you have pulled in most of the X libraries. > > >>> > > >>>Thats an aweful lot to require for a boot menu, and we didn't > > >>>have this problem for FC4, FC5 and FC6 atleast. Hope this will be > > >>>fixed atleast in rawhide. > > >>> > > >>See the archives of this list. This has been discussed extensively. > > > > > >Pointer or summary? Thanks! > > > > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00595.html > > Argh! > > "but since it drops files into application directories, fedora-logos > itself requires many things so that there are no unowned directories > or so that the right application owns it's directories. This is > perhaps one case where we can forgo the policy on directory ownership" > > Drop the policy for fedora-logos or make fedora-logos co-own the > directories. YAFIYGI. fedora-logos 6.0.98-4 no longer Requires on anything, and co-owns the two directories in question. This is entirely likely to break respins and whatnot. I'm trying to test with a rawhide respin, but pungi is, uh, not the fastest. Note, this is rawhide-only atm. Once we figure out what breaks in rawhide we can look at maybe doing this as a 7 update. - ajax From austinf at cetoncorp.com Fri Jun 15 21:28:41 2007 From: austinf at cetoncorp.com (Austin Foxley) Date: Fri, 15 Jun 2007 14:28:41 -0700 Subject: user created at install added in sudoers ? In-Reply-To: <4673037B.3030105@laposte.net> References: <4673037B.3030105@laposte.net> Message-ID: <46730489.6010304@cetoncorp.com> Axel wrote: > What do you think about adding the user created at install to the > sudoers list ? > > For newbies like me, understanding the sudoers file isn't so easy, but > nevertheless they may need the sudo command. In my case, I'd rather my > account would have been added automatically to the sudoers list :) > > Axel +1 -- Austin Foxley Ceton Corporation http://www.cetoncorp.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Fri Jun 15 21:31:13 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 21:31:13 +0000 (UTC) Subject: Automating pam_keyring... References: <46730322.6020400@poolshark.org> Message-ID: Denis Leroy poolshark.org> writes: > Installing pam_keyring isn't enough though, it still requires manual > edition of /etc/pam.d/gdm to make it work. I was hoping to start some > discussions on what needs to happen to make its behavior enabled > automatically upon installation, especially since this is on the F-8 > wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in > %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). > Or add a patch to the gdm package and make it require pam_keyring ? Or > do we want to make this feature optional from authconfig ? What about /etc/pam.d/kdm and /etc/pam.d/kdm-np? Not every gnome-keyring-using application necessarily always runs inside a GDM session. ;-) Kevin Kofler From jon.nettleton at gmail.com Fri Jun 15 21:40:05 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 15 Jun 2007 17:40:05 -0400 Subject: Automating pam_keyring... In-Reply-To: <46730322.6020400@poolshark.org> References: <46730322.6020400@poolshark.org> Message-ID: <1181943605.5852.4.camel@birkoff> On Fri, 2007-06-15 at 23:22 +0200, Denis Leroy wrote: > Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 problem > for me: okay this isn't a release, release. It is a pre-release that fixes the F-7 problems. > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741 > > I'll push an update shortly. > > Installing pam_keyring isn't enough though, it still requires manual > edition of /etc/pam.d/gdm to make it work. I was hoping to start some > discussions on what needs to happen to make its behavior enabled > automatically upon installation, especially since this is on the F-8 > wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in > %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). > Or add a patch to the gdm package and make it require pam_keyring ? Or > do we want to make this feature optional from authconfig ? I have a mostly functional addition to authconfig for enabling and disabling it. I am wondering if the architecture for this app needs to be extended to make it easy for each pam_package to add an xml file somewhere to add support for it in authconfig. > > Another issue is how do we update the keyring password when the user > changes his/her password ? The release above has 95% of the code for support of pam_sm_chauthtok. It has a couple of small bugs that I plan on fixing for full functionality in supporting changing the keyring password in the pam_stack. This will change partially again in 2.20 when we add support for a on_login keyring in gnome-keyring. I just got wiki write access and will create a page about it this weekend. Jon From jon.nettleton at gmail.com Fri Jun 15 21:45:12 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 15 Jun 2007 17:45:12 -0400 Subject: Automating pam_keyring... In-Reply-To: References: <46730322.6020400@poolshark.org> Message-ID: <1181943912.5852.8.camel@birkoff> On Fri, 2007-06-15 at 21:31 +0000, Kevin Kofler wrote: > Denis Leroy poolshark.org> writes: > > Installing pam_keyring isn't enough though, it still requires manual > > edition of /etc/pam.d/gdm to make it work. I was hoping to start some > > discussions on what needs to happen to make its behavior enabled > > automatically upon installation, especially since this is on the F-8 > > wish list. Should it use a scriptlet that modifies /etc/pam.d/gdm in > > %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). > > Or add a patch to the gdm package and make it require pam_keyring ? Or > > do we want to make this feature optional from authconfig ? > > What about /etc/pam.d/kdm and /etc/pam.d/kdm-np? Not every gnome-keyring-using > application necessarily always runs inside a GDM session. ;-) wow proposed mixed desktop relations. How risque. Probably if we write this into authconfig we should think how this should work. Maybe an advanced option. I have definitely had e-mails from very upset kde people that were very upset that pam_keyring was starting up gnome_keyring_daemon in their session. Just something to keep in mind. Jon From jspaleta at gmail.com Fri Jun 15 21:46:32 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 15 Jun 2007 13:46:32 -0800 Subject: Automating pam_keyring... In-Reply-To: <46730322.6020400@poolshark.org> References: <46730322.6020400@poolshark.org> Message-ID: <604aa7910706151446v40d29ef1m112ae195c3451508@mail.gmail.com> On 6/15/07, Denis Leroy wrote: > Should it use a scriptlet that modifies /etc/pam.d/gdm in > %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). It should just work for default desktop installs moving forward. I frankly don't care how. > Or add a patch to the gdm package and make it require pam_keyring ? uhm should avoid making this a hard requirement for gdm. Can pam deal with a scenario where pam_keyring is referenced as an optional rule in the auth stack but the pam_keyring module is not actually installed? And don't we at least have to also consider this being used in the pam stack for kdm, since kdm can start a gnome desktop session? > Or do we want to make this feature optional from authconfig ? I'm not sure if this makes much sense. Since the keyring isn't referencing any systemwide or networkwide resources when doing the authing and is inherently a per user thing I'm not sure I see a clear use case where this needs to be configurable (other than spite.) > Another issue is how do we update the keyring password when the user > changes his/her password ? Do you really want to automate this for all users? Some users might want a deliberately separate password. -jef From kevin.kofler at chello.at Fri Jun 15 21:50:55 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jun 2007 21:50:55 +0000 (UTC) Subject: Automating pam_keyring... References: <46730322.6020400@poolshark.org> <1181943912.5852.8.camel@birkoff> Message-ID: Jon Nettleton gmail.com> writes: > wow proposed mixed desktop relations. How risque. > > Probably if we write this into authconfig we should think how this > should work. Maybe an advanced option. I have definitely had e-mails > from very upset kde people that were very upset that pam_keyring was > starting up gnome_keyring_daemon in their session. Just something to > keep in mind. This is indeed a problem, if people don't have anything using gnome_keyring_daemon, they'll hate having it autostarted, if they do have something using it, they'll complain if it doesn't get autostarted. You can't win. :-( Well, maybe pam_keyring could be taught to just do nothing (not error or anything) if gnome_keyring is not installed and the package not made to require it. It might still get dragged in due to some wacky indirect dependencies and end up autostarted even where not needed that way though. Or maybe the hack of having the pam_keyring scriptlet change the pam configuration is really the way to go, then users could just install it when needed and leave it off where not needed or wanted, it does sound like a pretty hackish solution to me though. Kevin Kofler From blc at redhat.com Fri Jun 15 22:28:49 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 15 Jun 2007 16:28:49 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181884164.13412.45.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> Message-ID: <467312A1.6020103@redhat.com> Ralf Corsepius wrote: > Why? To the host, a target's binaries are non-executable, > host-independent blobs of binary data (==arch). I see where you're coming from here, but can't quite agree. For the greater purpose of cross compilation discussion, I'll leave it there for now. > Let me try to elaborate: > You want to mix different archs inside of the host's rpmdb. Yes, definitely a place the build system has to intervene. [snip] > rpm-wise the working principle probably would be very similar to that of > how mock and mach setup their chroots. Yes, in-fact, leveraging mock is going to a key to cross building bliss. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From nathanael at gnat.ca Fri Jun 15 22:34:49 2007 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Fri, 15 Jun 2007 16:34:49 -0600 Subject: user created at install added in sudoers ? In-Reply-To: <4673037B.3030105@laposte.net> References: <4673037B.3030105@laposte.net> Message-ID: <46731409.8060701@gnat.ca> Axel wrote: > What do you think about adding the user created at install to the > sudoers list ? > > For newbies like me, understanding the sudoers file isn't so easy, but > nevertheless they may need the sudo command. In my case, I'd rather my > account would have been added automatically to the sudoers list :) > > Axel > +1 From blc at redhat.com Fri Jun 15 22:39:47 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 15 Jun 2007 16:39:47 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181891208.13412.80.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> Message-ID: <46731533.1050706@redhat.com> Ralf Corsepius wrote: > I prefer using -gcc-*.i386.rpm Likewise. > If sys-rooting such a toolchain, it's toolchain's target-libs could be packaged into a > -sys-root-*.noarch.rpm To add a little granularity to the discussion, I'm going to point out that there are (at least) two camps of people who want cross compilers in Fedora: 1) Those who want cross compilers for nifty gadgets, generally not running Linux at all. Having a -sys-root-*.noarch.rpm such as Ralf suggests makes sense in this context. 2) Those who want cross compilers that target other linux architectures such as arm, ppc, s390, etc. Having a -sys-root-*.noarch.rpm does not make sense in this context. That is because you want to work with and make packages for your target arch rather than nebulous binary blobs. I'm particularly interested in #2, but believe Fedora can accommodate both. It's also a logical line along which to split package maintainership duties since the tools in question are used for such very different purposes. > What I am doing is aiming at cross-building target-binaries, not target > packages/rpms. Yep. Ok, I concede your noarch binary blob answer for non-linux targets. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Fri Jun 15 22:53:53 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 15 Jun 2007 16:53:53 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <467297E7.70907@warmcat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <467297E7.70907@warmcat.com> Message-ID: <46731881.3050708@redhat.com> Andy Green wrote: > I would be the first to reach for a dirty but unanswerably effective > hack to get me where I am going... But in this case I think the only > true answer is to tag BuildRequires as being host or target in the spec > file, not to unmanageably duplicate the target-world dependencies in the > host. Eg > > HostBuildRequires: byacc (<-- for it is he) > BuildRequires: libblah-devel > > ...where they are considered the same deal when hostArch == buildArch. Or TargetBuildRequires. Either way it's invasive and should be avoided if it can be worked around. You really want the build system to do as much as it can so you don't impact package maintainers unless absolutely necessary. > We can see if this logic raises objections anywhere given the effective > forkage of rpm but I suspect it is a basic fact necessary for cross to > work in rpm semantics. Forkage? -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From blc at redhat.com Fri Jun 15 22:55:19 2007 From: blc at redhat.com (Brendan Conoboy) Date: Fri, 15 Jun 2007 16:55:19 -0600 Subject: Fedora and Cross Compiling In-Reply-To: <1181810438.25228.204.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <467068D3.2060808@redhat.com> <1181774536.5211.21.camel@shinybook.infradead.org> <46707581.3010003@warmcat.com> <1181810438.25228.204.camel@pmac.infradead.org> Message-ID: <467318D7.1080205@redhat.com> David Woodhouse wrote: > Yeah, it's not impossible. Then we just need to let koji/mock know that > it must do this when building a cross-compiler... Er, "building with"? -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From sb at monkey-mind.net Fri Jun 15 23:12:57 2007 From: sb at monkey-mind.net (Steven Bakker) Date: Sat, 16 Jun 2007 01:12:57 +0200 Subject: user created at install added in sudoers ? In-Reply-To: <46731409.8060701@gnat.ca> References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> Message-ID: <20070616011257.051622a4@cluestix.noc.ams-ix.net> On Fri, 15 Jun 2007 16:34:49 -0600 Nathanael D. Noblet wrote: > Axel wrote: > > What do you think about adding the user created at install to the > > sudoers list ? > > > > For newbies like me, understanding the sudoers file isn't so easy, but > > nevertheless they may need the sudo command. In my case, I'd rather my > > account would have been added automatically to the sudoers list :) Or alternatively: * Create a "sudoers" group at install time. * Have the "%sudoers" in /etc/sudoers by default. Then: * Make the user to be created at install a member of "sudoers" OR * Let the user add him/herself to the sudoers group with the user manager application. The former is a bit more OSX-like. If you want to go that way, I'd only recommend it for desktop/workstation installs, not servers (assuming people installing servers know enough to do "visudo" if necessary). Regards, -- Steven From cmarcelo at gmail.com Sat Jun 16 01:23:29 2007 From: cmarcelo at gmail.com (Caio Marcelo) Date: Fri, 15 Jun 2007 22:23:29 -0300 Subject: user created at install added in sudoers ? In-Reply-To: <20070616011257.051622a4@cluestix.noc.ams-ix.net> References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: On 6/15/07, Steven Bakker wrote: > Or alternatively: > > * Create a "sudoers" group at install time. > * Have the "%sudoers" in /etc/sudoers by default. Just a small note: there's a "wheel" group, which has entries in /etc/sudoers by default, but commented. This group is usually for the administration users AFAIK, so it could be used instead of "sudoers" group. Cheers, Caio Marcelo From dtimms at iinet.net.au Sat Jun 16 02:56:44 2007 From: dtimms at iinet.net.au (David Timms) Date: Sat, 16 Jun 2007 12:56:44 +1000 Subject: Please don't let updates sit in testing forever In-Reply-To: <1181940982.3635.17.camel@localhost.localdomain> References: <1181940087.3635.14.camel@localhost.localdomain> <4672FF5C.30103@hhs.nl> <1181940982.3635.17.camel@localhost.localdomain> Message-ID: <4673516C.9060505@iinet.net.au> Matthias Clasen wrote: > On Fri, 2007-06-15 at 23:06 +0200, Hans de Goede wrote: >> Matthias Clasen wrote: >>> On Fri, 2007-06-15 at 20:33 +0000, Kevin Kofler wrote: >>>> Maintainers, please don't let your F7 updates linger in updates-testing >>>> forever. I've posted nag comments to the updates 2 weeks or more old, but I >>>> guess a lot of the 1-2 weeks old updates could also use getting pushed to >>>> stable. >>>> >>>> Either the update is broken or it's not. If it's broken, it should be withdrawn >>>> (unpushed) from updates-testing. If it works, why not mark it as stable? And I >>>> don't think waiting for feedback for more than 2 weeks makes sense, 1 week was >>>> pretty much the consensus in the discussions here and on fedora-maintainers. If >>>> there are no complaints in 2 weeks, the package can't be that broken, or if it >>>> is it most likely won't affect many people or someone would have noticed. :-) >>>> >>>> And no, pushing to stable after a timeout is currently not automatic. >>> The old fedora updates tool sent nag mail...I assume that updates will >>> be pushed to stable more regularly once that is implemented in bodhi. >>> >> Nag mail is not the answer, an option saying push this automatically to stable >> after X days is the answer. And yes I know not everyone wants this to happen >> for their packages, thus it should be an option. > > Pushing automatically is inferior to nag mail since nag mail makes me go > back to the update, look at possible feedback in fedora-test-list and > bugzilla, and then make a conscious decision to push it. Automating this > just further devalues updates-testing. IMO Would it be useful to get some sort of estimate of download stats for each file in -testing ? I don't expect that it would be possible to count downloads from the mirrors, however, even the download stats for the repodata and the rpms {complete, not just the header {byte range}} from the sites within fedora control would give some {poor} impression of whether _anyone_ has actually at least downloaded it yet. A download doesn't mean installed nor tested. The same availability of stats for the new build system in relation to counting rpm's that get downloaded directly would possibly be useful as well. The actual testing side could be improved by requiring that _at least one_ independent {ie not the code developer nor the package maintainer} person reports success in bugzilla for the issue that the update is supposed to fix. Then it would be up 2 the package maintainer to solicit feedback if none has been forthcoming. Perhaps there could be a way for non-packager users of packages to add themselves to a hidden list of people interested in the progress of certain packages, and who may be willing to run the updates-testing packages. If no feedback had been forthcoming the maintainer could click a link that sends email to the "interested" users soliciting feedback. This can sort of be done at the moment in bugzilla, but only if the user had previously found the particular bug and had added themselves to the cc list. DaveT. From kevin.kofler at chello.at Sat Jun 16 03:31:16 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 16 Jun 2007 03:31:16 +0000 (UTC) Subject: Please don't let updates sit in testing forever References: <1181940087.3635.14.camel@localhost.localdomain> <4672FF5C.30103@hhs.nl> <1181940982.3635.17.camel@localhost.localdomain> <4673516C.9060505@iinet.net.au> Message-ID: David Timms iinet.net.au> writes: > The actual testing side could be improved by requiring that _at least > one_ independent {ie not the code developer nor the package maintainer} > person reports success in bugzilla for the issue that the update is > supposed to fix. Then it would be up 2 the package maintainer to solicit > feedback if none has been forthcoming. Some updates would literally sit in testing forever (well, until EOL) if that rule is enforced. So I don't think this is a good idea to have as a requirement. It could be useful as a "SHOULD" type guideline though (but whether independent testing makes sense really depends on what the update is supposed to fix). Kevin Kofler From dwmw2 at infradead.org Sat Jun 16 07:56:12 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 16 Jun 2007 08:56:12 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <467318D7.1080205@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <467068D3.2060808@redhat.com> <1181774536.5211.21.camel@shinybook.infradead.org> <46707581.3010003@warmcat.com> <1181810438.25228.204.camel@pmac.infradead.org> <467318D7.1080205@redhat.com> Message-ID: <1181980572.25228.593.camel@pmac.infradead.org> On Fri, 2007-06-15 at 16:55 -0600, Brendan Conoboy wrote: > David Woodhouse wrote: > > Yeah, it's not impossible. Then we just need to let koji/mock know that > > it must do this when building a cross-compiler... > > Er, "building with"? Both. -- dwmw2 From andy at warmcat.com Sat Jun 16 09:24:33 2007 From: andy at warmcat.com (Andy Green) Date: Sat, 16 Jun 2007 10:24:33 +0100 Subject: Fedora and Cross Compiling In-Reply-To: <46731881.3050708@redhat.com> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <466F8DF6.7000805@redhat.com> <466F9893.80809@hhs.nl> <1181725313.2121.100.camel@mccallum.corsepiu.local> <466FB223.5020602@hhs.nl> <46700A35.5010902@redhat.com> <1181751707.2121.190.camel@mccallum.corsepiu.local> <467065A2.9020305@redhat.com> <1181790349.2121.210.camel@mccallum.corsepiu.local> <467180A5.5030305@redhat.com> <1181884164.13412.45.camel@mccallum.corsepiu.local> <46722B24.9000606@warmcat.com> <1181891208.13412.80.camel@mccallum.corsepiu.local> <46723EDC.8060004@warmcat.com> <1181894996.13412.116.camel@mccallum.corsepiu.local> <46728D36.7010003@redhat.com> <1181913646.25228.510.camel@pmac.infradead.org> <467297E7.70907@warmcat.com> <46731881.3050708@redhat.com> Message-ID: <4673AC51.6050103@warmcat.com> Brendan Conoboy wrote: > Andy Green wrote: >> I would be the first to reach for a dirty but unanswerably effective >> hack to get me where I am going... But in this case I think the only >> true answer is to tag BuildRequires as being host or target in the spec >> file, not to unmanageably duplicate the target-world dependencies in the >> host. Eg >> >> HostBuildRequires: byacc (<-- for it is he) >> BuildRequires: libblah-devel >> >> ...where they are considered the same deal when hostArch == buildArch. > > Or TargetBuildRequires. Either way it's invasive and should be avoided > if it can be worked around. You really want the build system to do as > much as it can so you don't impact package maintainers unless absolutely > necessary. Yep, it is invasive but it is also defensible I think. It's the kind of thing that could be patched into the specfile at buildtime per-arch if that is what ends up happening. But here's an alternative Heuristic that isn't as reliable but might cope and has no specfile footprint 1) Package is called lib* or *-devel? goto 8 2) Check build host rpmdb 3) If present, check if any of the files in the package match /usr/lib/*.so or /usr/lib/*.a or /usr/include/*... if not, consider it present, else... 4) Check target arch rpmdb 5) If absent, goto 7 6) check if any of the files in the package match /usr/lib/*.so or /usr/lib/*.a or /usr/include/*... if so, consider it present, else... 7) error out with "package not installed on build host" (it didn't have a footprint in /usr/lib or /usr/include, take as a host utility) 8) Check target arch rpmdb 9) if absent, error out with "package not installed for $arch" 10) consider it present -Andy >> We can see if this logic raises objections anywhere given the effective >> forkage of rpm but I suspect it is a basic fact necessary for cross to >> work in rpm semantics. > > Forkage? There's rpm5.org and there's rpm.org trees now. If it was the plan to add a new spec keyword, one would want it to be globally accepted and not become one tree's special sauce. -Andy From buildsys at redhat.com Sat Jun 16 10:19:34 2007 From: buildsys at redhat.com (Build System) Date: Sat, 16 Jun 2007 06:19:34 -0400 Subject: rawhide report: 20070616 changes Message-ID: <200706161019.l5GAJYrC012172@porkchop.devel.redhat.com> New package klibido NNTP (Usenet) file grabber for KDE New package perl-CGI-FastTemplate Perl extension for managing templates and performing variable interpolation New package postgresql_autodoc PostgreSQL AutoDoc Utility New package wammu Mobile Phone Manager - Gammu GUI Updated Packages: anaconda-11.3.0.2-1 ------------------- * Fri Jun 15 2007 Jeremy Katz - 11.3.0.2-1 - fix syntax error (jkeating) - don't capture passwords from kickstart in exception dumps (clumens) - don't write out unicode text to install.log (clumens, #243477) * Fri Jun 15 2007 Chris Lumens - 11.3.0.1-1 - Fix call to mksquashfs in mk-images so we get stage2.img again. - Other minor image creation fixes. - Flush drive dict so zFCP devices get device nodes (dcantrell, #236903). arts-8:1.5.7-3.fc8 ------------------ * Thu Jun 14 2007 Rex Dieter 6:1.5.7-3 - cleanup gslconfig.h/multilib bits, -ia64, +sparc64/sparc * Mon Jun 11 2007 Rex Dieter 6:1.5.7-2 - (re)add (experimental) libtool patches * Mon Jun 04 2007 Than Ngo - 6:1.5.7-1.fc7 - 1.5.7 cvs-1.11.22-10.fc8 ------------------ * Fri Jun 15 2007 Stepan Kasal - 1.11.22-10 - make sccs2rcs non-executable, so that find-requires do not add dependency on /bin/csh when /bin/csh is available - add CSH=/bin/csh to configure, so that sccs2rcs #! line is not corrupted when /bin/csh is not available - replace the deprecated %makeinstall (see Packaging Guidelines) * Mon Feb 19 2007 Jindrich Novy - 1.11.22-9 - fix permissions of cvs.sh, add cvs.csh to /etc/profile.d (#225672) * Fri Jan 05 2007 Jindrich Novy - 1.11.22-8 - fix post/preun scriptlets so that they won't fail with docs disabled easytag-2.1-1.fc8 ----------------- * Tue May 08 2007 Matthias Saou 2.1-1 - Update to 2.1. * Wed May 02 2007 Matthias Saou 2.0.2-1 - Update to 2.0.2. evolution-data-server-1.11.3-3.fc8 ---------------------------------- * Fri Jun 15 2007 Matthew Barnes - 1.11.3-3.fc8 - Add patch for GNOME bug #224277 (Camel IMAP security flaw). farsight-0.1.20-2.fc8 --------------------- * Fri Jun 15 2007 Brian Pepple - 0.1.20-2 - Add min version of libjingle needed. fedora-logos-6.0.98-4.fc8 ------------------------- * Fri Jun 15 2007 Adam Jackson 6.0.98-4 - Remove the Requires on redhat-artwork and fedora-icon-theme, and just multi-own the directories. Fixes some hilarious dependency chains. freeradius-1.1.6-2.fc8 ---------------------- * Fri Jun 15 2007 Thomas Woerner 1.1.6-2 - radiusd expects /etc/raddb to not be world readable or writable /etc/raddb now belongs to radiusd, post script sets permissions * Fri Jun 15 2007 Thomas Woerner 1.1.6-1 - new version 1.1.6 freetds-0.64-6.fc8 ------------------ * Fri Jun 15 2007 Dmitry Butskoy - 0.64-6 - bump release to provide update path over Livna gcc-4.1.2-13 ------------ * Fri Jun 15 2007 Jakub Jelinek 4.1.2-13 - update from gcc-4_1-branch (-r124365:125727) - PRs libfortran/31409, libfortran/31880, libfortran/31964, rtl-optimization/31691, target/31022, target/31480, target/31701, target/31876, target/32163, tree-optimization/26998 - gomp updates from the trunk (-r125541:125542, -r125543:125544) and from gcc-4_2-branch (-r125184:125185) - PRs tree-optimization/31769, c++/32177 - don't set TREE_READONLY on C++ objects that need runtime initialization (PRs c++/31806, c++/31809) - fix computation of common pointer type (PR tree-optimization/32139) - precompute const and pure fn calls inside another fn call arguments with accumulating outgoing args (PRs middle-end/32285, tree-optimization/30493) - fix handling of RESULT_DECLs in points-to analysis (#243438, PR tree-optimization/32353) - work around java.lang.reflect.Modifier.INTERPRETED clash with java.lang.reflect.Modifier.SYNTHETIC (Andrew Haley, #240720) gnome-vfs2-obexftp-0.3-1.fc8 ---------------------------- * Fri Jun 15 2007 - Bastien Nocera - 0.3-1 - Update to 0.3 - Drop merged patches - Licence clarification are now in the upstream AUTHORS file - Move TODO items to upstream bug tool gtk2-2.11.3-1.fc8 ----------------- * Fri Jun 15 2007 Matthias Clasen - 1.11.3-1 - Update to 2.11.3 - Drop upstreamed patches * Wed Jun 06 2007 Matthias Clasen - 1.11.2-1 - Update to 2.11.2 * Mon Jun 04 2007 Matthias Clasen - 1.11.1-1 - Update to 2.11.1 - Update patches gzip-1.3.12-3.fc8 ----------------- * Fri Jun 15 2007 Ivana Varekova - 1.3.12-3 - remove useless patches (fixed in upstream version) isomaster-1.0-1.fc8 ------------------- * Sun Jun 10 2007 Marcin Zajaczkowski - 1.0-1 - updated to 1.0 jd-1.9.5-0.4.svn1136.fc8 ------------------------ * Sat Jun 16 2007 Mamoru Tasaka - 1.9.5-0.4.svn1136 - svn 1136 * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.4.beta070611 - 1.9.5 beta 070611 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta 070528 kdelibs-6:3.5.7-4.fc8 --------------------- * Fri Jun 15 2007 Rex Dieter - 6:3.5.7-4 - omit lib_loader patch (doesn't apply cleanly) * Fri Jun 15 2007 Rex Dieter - 6:3.5.7-3 - include experimental libtool patches * Mon Jun 11 2007 Rex Dieter - 6:3.5.7-2 - kdesu: sudo support (kde bug #20914), Requires(hint): sudo libraw1394-1.2.1-9.fc8 ---------------------- * Fri Jun 15 2007 Jarod Wilson - 1.2.1-9 - Drop Conficts, causes interesting issues if people have an older kernel installed and/or kernel-xen installed (#244474) libuser-0.56.4-1 ---------------- * Fri Jun 15 2007 Miloslav Trma?? - 0.56.4-1 - Update the last password change date field when changing passwords Resolves: #243854 libwpd-0.8.10-1.fc8 ------------------- * Fri Jun 15 2007 Caolan McNamara - 0.8.10-1 - next version metacity-2.19.13-1.fc8 ---------------------- * Fri Jun 15 2007 Matthias Clasen - 2.19.13-1 - Update to 2.19.13 * Mon Jun 11 2007 Matthias Clasen - 2.19.8-2 - Don't ship .so.0 in the -devel package (#243689) mirage-0.8.3-2.fc8 ------------------ * Fri Jun 15 2007 Mamoru Tasaka - 0.8.3-2 - Remove Version= entry (on F-8+) mod_fcgid-2.1-3.fc8 ------------------- * Fri Jun 15 2007 Paul Howarth 2.1-3 - Major update of SELinux policy, supporting accessing data on NFS/CIFS shares and a new boolean, httpd_fastcgi_can_sendmail, to allow connections to SMTP servers - Fix for SELinux policy on Fedora 7, which didn't work due to changes in the permissions macros in the underlying selinux-policy package * Wed Mar 21 2007 Paul Howarth 2.1-2 - Add RHEL5 with SELinux support - Rename README.Fedora to README.RPM muParser-1.27-5.fc8 ------------------- * Fri Jun 15 2007 Frank B??ttner - 1.27-5.fc8 - fix bug #244309 mugshot-1.1.43-2.fc8 -------------------- * Fri Jun 15 2007 Owen Taylor - 1.1.43-2 - Bump release to be newer than F-7 build, and rebuild * Fri Jun 15 2007 Owen Taylor - 1.1.43-1 - 1.1.43 newt-0.52.7-1.fc8 ----------------- * Fri Jun 15 2007 Miroslav Lichvar - 0.52.7-1 - add support to snack for multiple selection and border in listbox and cursorAtEnd in entry (patch by Shawn Starr) - fix scrollbar positioning in listbox - cope with backward system time jumps (#240691) - free helplines and windows in newtFinished, check for overflow (#239992) - add release to -devel and -static requires (#238784) pidgin-2.0.2-1.fc8 ------------------ * Fri Jun 15 2007 Stu Tomlinson - 2.0.2-1 - 2.0.2 * Wed Jun 06 2007 Stu Tomlinson - 2.0.1-5 - Enable Bonjour support (#242949) - Fix building against latest evolution-data-server * Tue Jun 05 2007 Stu Tomlinson - 2.0.1-4 - Fix purple-remote for AIM & ICQ accounts (#240589) - Add missing Requires to -devel packages - Add missing BuildRequires for libxml2-devel postfix-2:2.4.3-3.fc8 --------------------- * Fri Jun 15 2007 Thomas Woerner 2:2.4.3-3 - added missing epoch in requirement of pflogsumm sub package postgresql-pgpool-II-1.1.1-1.fc8 -------------------------------- * Fri Jun 15 2007 Devrim Gunduz 1.1.1-1 - Update to 1.1.1 proftpd-1.3.0a-5.fc8 -------------------- * Fri Jun 15 2007 Matthias Saou 1.3.0a-5 - Remove _smp_mflags to (hopefully) fix build failure. * Fri Jun 15 2007 Matthias Saou 1.3.0a-4 - Fix PAM entry for F7+ (#244168). Still doesn't work with selinux, though. * Fri May 04 2007 Matthias Saou 1.3.0a-4 - Fix auth bypass vulnerability (#237533, upstream #2922)... not! :-( python-psycopg2-2.0.6-1.fc8 --------------------------- * Fri Jun 15 2007 - Devrim GUNDUZ 2.0.6-1 - Update to 2.0.6 qt4-4.3.0-4.fc8 --------------- * Sat Jun 30 2007 Rex Dieter 4.3.0-4 - .desktop Category cleanup * Sat Jun 30 2007 Rex Dieter 4.3.0-3 - cleanup qconfig.h/multilib bits, add s390x/s390 rrdtool-1.2.999-0.2.r1127.fc8 ----------------------------- * Fri Jun 15 2007 Jarod Wilson 1.2.999-0.2.r1127 - Fix up BuildRequires * Fri Jun 15 2007 Jarod Wilson 1.2.999-0.1.r1127 - Update to rrdtool pre-1.3 svn snapshot (svn r1127) ruby-zoom-0.2.2-3.fc8 --------------------- sane-backends-1.0.18-7.fc8 -------------------------- * Fri Jun 15 2007 Nils Philippsen - 1.0.18-7 - call usb_reset() prior to usb_close() to workaround hanging USB hardware (#149027, #186766) slang-2.1.0-1.fc8 ----------------- * Fri Jun 15 2007 Miroslav Lichvar - 2.1.0-1 - update to 2.1.0 - create -slsh subpackage for slsh and modules system-config-printer-0.7.68-1.fc8 ---------------------------------- * Fri Jun 15 2007 Tim Waugh 0.7.68-1 - 0.7.68: - Fixed the notification bubbles. - Ship my-default-printer utility. texmaker-1:1.5-2.fc8 -------------------- * Fri Jun 15 2007 Deji Akingunola - 1.5-2 - Fix for crash on x86_64 by Kevin Kofler (BZ #235546) tsclient-0.150-1.fc8 -------------------- * Fri Jun 15 2007 Matthias Clasen - 0.150-1 - Update to 0.150 - Readd the applet yaz-3.0.6-1.fc8 --------------- * Fri Jun 15 2007 Konstantin Ryabitsev - 3.0.6-1 - New major upstream version 3.0.6 Broken deps for i386 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3194.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3194.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3194.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3194.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3194.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3194.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From fedora at camperquake.de Sat Jun 16 12:08:16 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 16 Jun 2007 14:08:16 +0200 Subject: random comments about secondary arch proposal In-Reply-To: <1181907508.25228.435.camel@pmac.infradead.org> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <1181907508.25228.435.camel@pmac.infradead.org> Message-ID: <20070616140816.5d40b3b7@lain.camperquake.de> Hi. On Fri, 15 Jun 2007 12:38:28 +0100, David Woodhouse wrote > You're right -- as things stand, we do need a team of folks who can > help out with basic issues where the packager can't cope. It usually > isn't arch-specific; very little really is when you get down to it. Arch specific in the sense of "this does not work on PPC": yes, I can agree with that. Arch specific in the sense of "does work on i386 and nowhere else": it seems to me that there is quite an amount of C code that assumes that an int is 32 bit and the world is little endian. From dwmw2 at infradead.org Sat Jun 16 13:12:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 16 Jun 2007 14:12:37 +0100 Subject: random comments about secondary arch proposal In-Reply-To: <20070616140816.5d40b3b7@lain.camperquake.de> References: <1181842826.3635.14.camel@localhost.localdomain> <46725F2B.6010702@leemhuis.info> <1181907508.25228.435.camel@pmac.infradead.org> <20070616140816.5d40b3b7@lain.camperquake.de> Message-ID: <1181999557.2808.25.camel@pmac.infradead.org> On Sat, 2007-06-16 at 14:08 +0200, Ralf Ertzinger wrote: > On Fri, 15 Jun 2007 12:38:28 +0100, David Woodhouse wrote > > You're right -- as things stand, we do need a team of folks who can > > help out with basic issues where the packager can't cope. It usually > > isn't arch-specific; very little really is when you get down to it. > > Arch specific in the sense of "this does not work on PPC": yes, I can > agree with that. That's what I meant, yes. > Arch specific in the sense of "does work on i386 and nowhere else": > it seems to me that there is quite an amount of C code that assumes > that an int is 32 bit and the world is little endian. Code written _that_ badly is rarely good enough to be shipped with the 'Fedora' label on it anyway, for a variety of reasons. It's also a case which I was mostly ignoring as uninteresting in this context, since it's the "needs porting" case which just gets a one-off ExcludeArch; either when the package is first imported or when the arch team build all packages for their arch before applying to become a Secondary Architecture. It hardly takes any effort for the package owner at all; certainly not any recurring effort. The _important_ case we have to care about is when a package _used_ to build and suddenly doesn't. I think that's the one that people are concerned about. Perhaps because they haven't actually looked at the data and didn't realise that a significant proportion (and probably even the _majority_) of such failures aren't actually arch-specific bugs at all, when you get down to the root of it. And even the failures which _are_ arch-specific can easily be handled with a retrospective ExcludeArch and the 'ship it anyway' button. -- dwmw2 From snecklifter at gmail.com Sat Jun 16 14:13:56 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sat, 16 Jun 2007 15:13:56 +0100 Subject: kqemu inclusion in kernel Message-ID: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> Hi folks, I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods it would be good to know if this is being queued up for mainline. If not then can it be backported for Fedora kernels. If that is not possible then can it be moved into the default repos to save users (me) bolting on another repo (no offence Axel). Please forgive dual list posting but I know DJ reads the kernel list and might want to comment whereas I'm not sure AT does. And vice versa. Regards Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Sat Jun 16 14:21:45 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 16 Jun 2007 10:21:45 -0400 Subject: kqemu inclusion in kernel In-Reply-To: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> Message-ID: <20070616142145.GJ23417@redhat.com> On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote: > I've started playing around with virtualization at work and the first thing > I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was > GPL'd in February and although I realise Axel is packaging kmdl/kmods it > would be good to know if this is being queued up for mainline. not afaik.. I've not heard of anyone working on it since its initial opensource'ing, which seemed to be a reactionary thing in response to kvm's gaining popularity. > If not then can it be backported for Fedora kernels. It was fairly big (but not really invasive fwir), but it's still a delta that we'd perpetually have to carry vs upstream. Each patch adds a burden towards rebasing, and with no clear path for this to get upstream, it's questionable how long we'd have to carry it, so I'm not too enthusiastic to be honest. Dave -- http://www.codemonkey.org.uk From otto_rey at yahoo.com.ar Sat Jun 16 17:14:35 2007 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Sat, 16 Jun 2007 10:14:35 -0700 (PDT) Subject: F8devel - Review HAL policy about hiding partitions Message-ID: <694505.63542.qm@web52401.mail.re2.yahoo.com> Why we continue hiding partitions with HAL policy (/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi)?? It's for security? Really? We can put some ACL's instead of hiding partitions if it is a security thing... Well... just suggestion... Otto Rey __________________________________________________ Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). ?Probalo ya! http://www.yahoo.com.ar/respuestas -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Sat Jun 16 17:17:22 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 16 Jun 2007 18:17:22 +0100 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <694505.63542.qm@web52401.mail.re2.yahoo.com> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> Message-ID: <1182014242.2309.7.camel@work> On Sat, 2007-06-16 at 10:14 -0700, Otto Rey wrote: > Why we continue hiding partitions with HAL policy > (/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi)?? My policy has always been that if a user is able to boot a system with a live-cd then all security is void. I've been arguing for many months that 99-redhat-... should only be for RHEL builds, and not for fedora. I think David Zeuthen is working very hard on PolicyKit, which might solve this type of permissions problem one and for all. Richard. From lemenkov at gmail.com Sat Jun 16 17:02:36 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 16 Jun 2007 17:02:36 +0000 (UTC) Subject: rawhide report: 20070616 changes References: <200706161019.l5GAJYrC012172@porkchop.devel.redhat.com> Message-ID: Build System redhat.com> writes: > fedora-logos-6.0.98-4.fc8 > ------------------------- > * Fri Jun 15 2007 Adam Jackson redhat.com> 6.0.98-4 > - Remove the Requires on redhat-artwork and fedora-icon-theme, and just > multi-own the directories. Fixes some hilarious dependency chains. O yeah! I've been waiting this for a long time. From pertusus at free.fr Sat Jun 16 17:22:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 16 Jun 2007 19:22:08 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <20070610212349.GE2371@neu.nirvana> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610212349.GE2371@neu.nirvana> Message-ID: <20070616172208.GC3316@free.fr> On Sun, Jun 10, 2007 at 11:23:49PM +0200, Axel Thimm wrote: > > Requiring yelp only because an app ships a yelp file is like requiring > evince for shipping pdf docu or firefox for shipping html docu. That's not the same at all. yelp is needed when there is a button in the UI such that, when clicked, launches yelp, not when there is a yelp file. Similarly, if a program calls evince or htmlviewer when clicking on a button, then it should considered to add it as a Requires. -- Pat From tmz at pobox.com Sat Jun 16 19:31:57 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 16 Jun 2007 15:31:57 -0400 Subject: Errors building packages for F7 and rawhide in mock Message-ID: <20070616193157.GD30917@psilocybe.teonanacatl.org> I'm trying to build some packages for F7 and rawhide using mock (0.7.1-1.fc7.i386). I'm getting errors at the prep stage that appear to be due to problems installing buildsys-build. The relevant error in the mock logs is (full log is attached): Executing timeout(0): /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-7-i386/root install buildsys-build http://koji.fedoraproject.org/static-repos/dist-fc7-build-current/i386/repodata/filelists.xml.gz: [Errno 4] Socket Error: timed out Trying other mirror. Error: failure: repodata/filelists.xml.gz from local: [Errno 256] No more mirrors to try. I have not changed the default mock configs. Nor do I have any problem downloading the file mentioned in the error manually from the same system, so I don't think it's a network problem on my system. I tried adding a timeout= line to the yum.conf in the mock chroot, but even bumping it to 180 (seconds, that is) did not cure the problem. I've gotten the prep to go further than grabbing the filelists.xml.gz, but have yet to get it to fully populate the chroot and build a package. Does anyone have ideas on what is wrong and how I can correct it? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nothing is wrong with California that a rise in the ocean level wouldn't cure. -- Ross MacDonald (1915-1983) -------------- next part -------------- ensuring dir /var/lib/mock/fedora-7-i386/state Cleaning Root Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-7-i386/root/proc umount: /var/lib/mock/fedora-7-i386/root/proc: not mounted Executing timeout(0): /usr/sbin/mock-helper rm -rf /var/lib/mock/fedora-7-i386 ensuring dir /var/lib/mock/fedora-7-i386 ensuring dir /var/lib/mock/fedora-7-i386/root ensuring dir /var/lib/mock/fedora-7-i386/state ensuring dir /var/lib/mock/fedora-7-i386/result ensuring dir /var/lib/mock/fedora-7-i386 ensuring dir /var/lib/mock/fedora-7-i386/root ensuring dir /var/lib/mock/fedora-7-i386/state ensuring dir /var/lib/mock/fedora-7-i386/result ensuring dir /var/lib/mock/fedora-7-i386/root/var/lib/rpm ensuring dir /var/lib/mock/fedora-7-i386/root/var/log ensuring dir /var/lib/mock/fedora-7-i386/root/var/lock/rpm ensuring dir /var/lib/mock/fedora-7-i386/root/dev ensuring dir /var/lib/mock/fedora-7-i386/root/etc/rpm ensuring dir /var/lib/mock/fedora-7-i386/root/tmp ensuring dir /var/lib/mock/fedora-7-i386/root/var/tmp ensuring dir /var/lib/mock/fedora-7-i386/root/etc/yum.repos.d ensuring dir /var/lib/mock/fedora-7-i386/root/proc Executing timeout(0): /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-7-i386/root/proc ensuring dir /var/lib/mock/fedora-7-i386/root/dev Executing timeout(0): /usr/sbin/mock-helper mount --bind /dev /var/lib/mock/fedora-7-i386/root/dev ensuring dir /var/lib/mock/fedora-7-i386/root/dev/pts Executing timeout(0): /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-7-i386/root/dev/pts Executing timeout(0): /usr/sbin/mock-helper chmod 2775 /var/lib/mock/fedora-7-i386/root/etc Executing timeout(0): /usr/sbin/mock-helper chown 502.496 /var/lib/mock/fedora-7-i386/root/etc ensuring dir /var/lib/mock/fedora-7-i386/root/etc/yum Executing timeout(0): /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-7-i386/root install buildsys-build http://koji.fedoraproject.org/static-repos/dist-fc7-build-current/i386/repodata/filelists.xml.gz: [Errno 4] Socket Error: timed out Trying other mirror. Error: failure: repodata/filelists.xml.gz from local: [Errno 256] No more mirrors to try. Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-7-i386/root/dev/pts Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-7-i386/root/dev Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-7-i386/root/proc Cleaning up... Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-7-i386/root/proc umount: /var/lib/mock/fedora-7-i386/root/proc: not mounted Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-7-i386/root/dev umount: /var/lib/mock/fedora-7-i386/root/dev: not mounted Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-7-i386/root/dev/pts mock-helper: error: /var/lib/mock/fedora-7-i386/root/dev/pts: No such file or directory Done. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Jun 16 20:31:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 16 Jun 2007 22:31:27 +0200 Subject: Errors building packages for F7 and rawhide in mock In-Reply-To: <20070616193157.GD30917@psilocybe.teonanacatl.org> References: <20070616193157.GD30917@psilocybe.teonanacatl.org> Message-ID: <1182025887.23816.1.camel@rousalka.dyndns.org> Le samedi 16 juin 2007 ? 15:31 -0400, Todd Zullinger a ?crit : > I'm trying to build some packages for F7 and rawhide using mock > (0.7.1-1.fc7.i386). I'm getting errors at the prep stage that appear > to be due to problems installing buildsys-build. Seems koji was not designed with mock in mind and the koji repositories are not stable enough for yum (which mock uses). Koji build repo probably need mirroring or redesign if mock is to be supported post Fedora 7. -------------- 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 tmz at pobox.com Sat Jun 16 20:39:59 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 16 Jun 2007 16:39:59 -0400 Subject: Errors building packages for F7 and rawhide in mock In-Reply-To: <1182025887.23816.1.camel@rousalka.dyndns.org> References: <20070616193157.GD30917@psilocybe.teonanacatl.org> <1182025887.23816.1.camel@rousalka.dyndns.org> Message-ID: <20070616203959.GF30917@psilocybe.teonanacatl.org> Nicolas Mailhot wrote: > Seems koji was not designed with mock in mind and the koji > repositories are not stable enough for yum (which mock uses). Koji > build repo probably need mirroring or redesign if mock is to be > supported post Fedora 7. I disabled the local repo in the F7 mock config and things worked much better. If this isn't a known problem between mock and koji, which of the two components should a bug be filed under? Thanks, -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's reassuring to know that if you behave strangely enough, society will take full responsibility for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Jun 16 21:38:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 16 Jun 2007 23:38:34 +0200 Subject: Errors building packages for F7 and rawhide in mock In-Reply-To: <20070616203959.GF30917@psilocybe.teonanacatl.org> References: <20070616193157.GD30917@psilocybe.teonanacatl.org> <1182025887.23816.1.camel@rousalka.dyndns.org> <20070616203959.GF30917@psilocybe.teonanacatl.org> Message-ID: <1182029915.23816.3.camel@rousalka.dyndns.org> Le samedi 16 juin 2007 ? 16:39 -0400, Todd Zullinger a ?crit : > Nicolas Mailhot wrote: > > Seems koji was not designed with mock in mind and the koji > > repositories are not stable enough for yum (which mock uses). Koji > > build repo probably need mirroring or redesign if mock is to be > > supported post Fedora 7. > > I disabled the local repo in the F7 mock config and things worked much > better. If this isn't a known problem between mock and koji, which of > the two components should a bug be filed under? It's a problem with koji which static repos have not been designed to be remotely accessed through yum -- 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 kevin.kofler at chello.at Sat Jun 16 22:17:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 16 Jun 2007 22:17:18 +0000 (UTC) Subject: F8devel - Review HAL policy about hiding partitions References: <694505.63542.qm@web52401.mail.re2.yahoo.com> Message-ID: Otto Rey yahoo.com.ar> writes: > Why we continue hiding partitions with HAL policy > (/usr/share/hal/fdi/policy/10osvendor/ > 99-redhat-storage-policy-fixed-drives.fdi)?? Call me old-fashioned, but IMHO mounting of fixed disk partitions is what /etc/fstab is for. (And I'm not even a sysadmin, just a home user adminning my own machines.) > It's for security? Not only, see the bug report this was discussed in. The other problems with the automounting were: * mountpoint not easily settable (An easy way to set a HAL policy fixing the mountpoint could help there. But you'll still see resistance from sysadmins who won't understand why they have to learn a new way when /etc/fstab has worked fine for ages.) * default mountpoint can be different across reboots (Is this problem resolved yet? Fixed partitions should really be mounted to the same place at each reboot.) * "updating" of ext2/ext3 partitions containing older GNU/Linux distributions with new ext3 features, making those fail to boot (I see no easy solution for this one.) IMHO, the best way to deal with fixed disk partitions would be to offer an easy setting to add them to fstab within Anaconda, or maybe firstboot. I really don't understand the advantage of HAL over fstab for fixed disks. HAL is great for stuff which can be unplugged or inserted at runtime, but we're talking about fixed disk drives here. Kevin Kofler From naheemzaffar at gmail.com Sat Jun 16 22:22:32 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 16 Jun 2007 23:22:32 +0100 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: References: <694505.63542.qm@web52401.mail.re2.yahoo.com> Message-ID: <3adc77210706161522s19961b5di33af904f0fabed01@mail.gmail.com> For NTFS there is the tool called ntfs-config which changes the policy. Maybe this should be generalised to a tool for all storage formats? (call it system-config-storage or summat?) Also, is /etc/fstab not on it's way out? I thought the plan was for it to be autogenerated at some point? On 16/06/07, Kevin Kofler wrote: > Otto Rey yahoo.com.ar> writes: > > Why we continue hiding partitions with HAL policy > > (/usr/share/hal/fdi/policy/10osvendor/ > > 99-redhat-storage-policy-fixed-drives.fdi)?? > > Call me old-fashioned, but IMHO mounting of fixed disk partitions is > what /etc/fstab is for. (And I'm not even a sysadmin, just a home user > adminning my own machines.) > > > It's for security? > > Not only, see the bug report this was discussed in. The other problems with the > automounting were: > * mountpoint not easily settable (An easy way to set a HAL policy fixing the > mountpoint could help there. But you'll still see resistance from sysadmins who > won't understand why they have to learn a new way when /etc/fstab has worked > fine for ages.) > * default mountpoint can be different across reboots (Is this problem resolved > yet? Fixed partitions should really be mounted to the same place at each > reboot.) > * "updating" of ext2/ext3 partitions containing older GNU/Linux distributions > with new ext3 features, making those fail to boot (I see no easy solution for > this one.) > > IMHO, the best way to deal with fixed disk partitions would be to offer an easy > setting to add them to fstab within Anaconda, or maybe firstboot. I really > don't understand the advantage of HAL over fstab for fixed disks. HAL is great > for stuff which can be unplugged or inserted at runtime, but we're talking > about fixed disk drives here. > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From kevin.kofler at chello.at Sat Jun 16 22:37:05 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 16 Jun 2007 22:37:05 +0000 (UTC) Subject: F8devel - Review HAL policy about hiding partitions References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <3adc77210706161522s19961b5di33af904f0fabed01@mail.gmail.com> Message-ID: Naheem Zaffar gmail.com> writes: > Also, is /etc/fstab not on it's way out? I thought the plan was for it > to be autogenerated at some point? Oh great, let's GNOMEize partition mounting too. Who needs configurability? In fact, I suggest the automatically generated mountpoints to be called C:, D:, E:, ..., Z: to match the expectations of new users. Let's deal with such pesky things as fitting partitions into the FHS hierarchy at another time. Sigh... Kevin Kofler From jspaleta at gmail.com Sat Jun 16 22:50:47 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 16 Jun 2007 14:50:47 -0800 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <3adc77210706161522s19961b5di33af904f0fabed01@mail.gmail.com> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <3adc77210706161522s19961b5di33af904f0fabed01@mail.gmail.com> Message-ID: <604aa7910706161550k39beda66ja5ee3a9b7389d94a@mail.gmail.com> On 6/16/07, Naheem Zaffar wrote: > Also, is /etc/fstab not on it's way out? I thought the plan was for it > to be autogenerated at some point? You aren't going to be able to get rid of manual edits of fstab without a significant overhaul of a lot of things... the init system included. There are a lot of real world usage cases where a desktop-centric single-user interface design isn't going to work too well as the only way to deal with system-wide mountpoints covering all possible configuration of filesystem types that mount knows about. I very much want to see PolicyKit fielded as a desktop oriented way of dealing with storage from a home or single user system. And I surely would love to see all desktops embrace it as a technology. But even in the ideal hugs and kisses future of unanimous desktop integration we have to keep the flexibility of manual edits for less mundane usages. -jef From nicolas.mailhot at laposte.net Sun Jun 17 00:09:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 17 Jun 2007 02:09:58 +0200 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: References: <694505.63542.qm@web52401.mail.re2.yahoo.com> Message-ID: <1182038998.27100.4.camel@rousalka.dyndns.org> Le samedi 16 juin 2007 ? 22:17 +0000, Kevin Kofler a ?crit : > Otto Rey yahoo.com.ar> writes: > > Why we continue hiding partitions with HAL policy > > (/usr/share/hal/fdi/policy/10osvendor/ > > 99-redhat-storage-policy-fixed-drives.fdi)?? > > Call me old-fashioned, but IMHO mounting of fixed disk partitions is > what /etc/fstab is for. (And I'm not even a sysadmin, just a home user > adminning my own machines.) And you haven't seen everything, new mounting system is either dropping a file there or using the magic underdocumented gnome mount command. So you have three different places now where mount can be setup, and how stuff actually happens moved beyond mere mortals comprehension If you're lucky your device is owned by a developper and has been pre-configured. -- 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 Axel.Thimm at ATrpms.net Sun Jun 17 01:04:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 17 Jun 2007 03:04:04 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <20070616172208.GC3316@free.fr> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610212349.GE2371@neu.nirvana> <20070616172208.GC3316@free.fr> Message-ID: <20070617010404.GG13629@neu.nirvana> On Sat, Jun 16, 2007 at 07:22:08PM +0200, Patrice Dumas wrote: > On Sun, Jun 10, 2007 at 11:23:49PM +0200, Axel Thimm wrote: > > Requiring yelp only because an app ships a yelp file is like requiring > > evince for shipping pdf docu or firefox for shipping html docu. > > Similarly, if a program calls evince or htmlviewer when clicking on a > button, then it should considered to add it as a Requires. So what about FF? Would you suggest that it should require evince? -- 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 pertusus at free.fr Sun Jun 17 01:18:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 17 Jun 2007 03:18:39 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <20070617010404.GG13629@neu.nirvana> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610212349.GE2371@neu.nirvana> <20070616172208.GC3316@free.fr> <20070617010404.GG13629@neu.nirvana> Message-ID: <20070617011839.GB3217@free.fr> On Sun, Jun 17, 2007 at 03:04:04AM +0200, Axel Thimm wrote: > On Sat, Jun 16, 2007 at 07:22:08PM +0200, Patrice Dumas wrote: > > On Sun, Jun 10, 2007 at 11:23:49PM +0200, Axel Thimm wrote: > > > Requiring yelp only because an app ships a yelp file is like requiring > > > evince for shipping pdf docu or firefox for shipping html docu. > > > > Similarly, if a program calls evince or htmlviewer when clicking on a > > button, then it should considered to add it as a Requires. > > So what about FF? Would you suggest that it should require evince? I am not completly understanding your point. FF is firefox, right? Why should it require evince? -- Pat From cr33dog at gmail.com Sun Jun 17 01:51:55 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Sat, 16 Jun 2007 20:51:55 -0500 Subject: mysql-administrator segfaults Message-ID: Hi, mysql-administrator segfaults whenever I create a new schema (logged in locally, as root). Anybody else seeing this? I'm hunting in BZ right now... Thanks, Chris From cr33dog at gmail.com Sun Jun 17 01:53:19 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Sat, 16 Jun 2007 20:53:19 -0500 Subject: mysql-administrator segfaults In-Reply-To: References: Message-ID: On 6/16/07, Chris Mohler wrote: > Hi, > > mysql-administrator segfaults whenever I create a new schema (logged > in locally, as root). > > Anybody else seeing this? I'm hunting in BZ right now... > > Thanks, > Chris > Nevermind: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238188 From sundaram at fedoraproject.org Sun Jun 17 02:04:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 17 Jun 2007 07:34:15 +0530 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <1182014242.2309.7.camel@work> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <1182014242.2309.7.camel@work> Message-ID: <4674969F.7040208@fedoraproject.org> Richard Hughes wrote: > On Sat, 2007-06-16 at 10:14 -0700, Otto Rey wrote: >> Why we continue hiding partitions with HAL policy >> (/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi)?? > > My policy has always been that if a user is able to boot a system with a > live-cd then all security is void. Wouldn't filesystem encryption make this not quite true? Rahul From bpepple at fedoraproject.org Sun Jun 17 01:52:56 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 16 Jun 2007 21:52:56 -0400 Subject: FESCo Meeting Summary for 2007-06-14 Message-ID: <1182045176.2834.5.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Tom Callaway (spot) * Rex Dieter (rdieter) * Christian Iseli (c4chris) * Warren Togami (warren) === Absent === * Josh Boyer (jwb) == Summary === === Upgrade path enforcement === * FESCo approved the rel-eng policy proposal for not breaking the upgrade path for packages. https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01603.html === Secondary Arches === * Long discussion of secondary arches. spot is going to take the suggestions from the discussion and modify his proposal, and we'll revisit this next week. === Merge Reviews === * Long discussion on whether to make the completion of the former core packages reviews a feature for F8. There are approx. 700+ packages in the queue, and it's debatable if it's a realistic goal for them to be completed by F8 test 2. The discussion will be taken to the mailing list to get community members opinions on a reasonable way to get this task completed. === F8 Schedule === * FESCo worked on a finalized schedule for F8, which jeremy presented to the Fedora Advisory Board for approval. It's been subsequently approved. https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01888.html === Misc === * jeremy is currently working on the documentation for package building with koji/bohdi that will be put on the wiki. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070614 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From frosario777 at gmail.com Sun Jun 17 05:59:58 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Sat, 16 Jun 2007 22:59:58 -0700 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: I know that Ubuntu disables the root account by default and automatically enables the first user added to the system to have sudo access. That might not be a bad idea as it guards against brute force attempts against the root account. That would be a good argument in favor of that change but can anyone think of any reasons against this sudo setup? On 6/15/07, Caio Marcelo wrote: > > On 6/15/07, Steven Bakker wrote: > > Or alternatively: > > > > * Create a "sudoers" group at install time. > > * Have the "%sudoers" in /etc/sudoers by default. > > Just a small note: there's a "wheel" group, which has entries > in /etc/sudoers by default, but commented. This group is usually > for the administration users AFAIK, so it could be used instead of > "sudoers" group. > > > Cheers, > Caio Marcelo > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- --Freddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From lightsolphoenix at gmail.com Sun Jun 17 06:28:55 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 17 Jun 2007 02:28:55 -0400 Subject: source RPM for latest version of Wine Message-ID: <200706170228.56112.lightsolphoenix@gmail.com> I'm posting this here instead of making a Package Review topic because I believe someone's already handling this package. ?However, there hasn't been an update for a while, so I figured I'd post the updated source RPM I made for it so that anyone who wants to can create the more up-to-date RPM's for Wine (that'd be version 0.9.39). I made it from the specfile used for the official Wine packages; I simply updated the patches and the file list to work with the latest version. http://crystalsanctuary.rpgsource.net/packages/source/wine-0.9.39-1.fc7.src.rpm -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From manuel at todo-linux.com Sun Jun 17 07:21:53 2007 From: manuel at todo-linux.com (Manuel Arostegui Ramirez) Date: Sun, 17 Jun 2007 09:21:53 +0200 Subject: mysql-administrator segfaults In-Reply-To: References: Message-ID: <200706170921.53623.manuel@todo-linux.com> El Domingo, 17 de Junio de 2007 03:51, Chris Mohler escribi?: > Hi, > > mysql-administrator segfaults whenever I create a new schema (logged > in locally, as root). > > Anybody else seeing this? I'm hunting in BZ right now... > > Thanks, > Chris Did you take a look at the strace output? -- Manuel Arostegui Ramirez. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. From cr33dog at gmail.com Sun Jun 17 07:28:15 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Sun, 17 Jun 2007 02:28:15 -0500 Subject: mysql-administrator segfaults In-Reply-To: <200706170921.53623.manuel@todo-linux.com> References: <200706170921.53623.manuel@todo-linux.com> Message-ID: On 6/17/07, Manuel Arostegui Ramirez wrote: [...] > > Did you take a look at the strace output? > No - but there's a stack trace on this (duplicate?)bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244090 Seems it's fixed upstream and we just need an update... Chris From hughsient at gmail.com Sun Jun 17 08:28:03 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 17 Jun 2007 09:28:03 +0100 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <4674969F.7040208@fedoraproject.org> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <1182014242.2309.7.camel@work> <4674969F.7040208@fedoraproject.org> Message-ID: <1182068883.2324.3.camel@work> On Sun, 2007-06-17 at 07:34 +0530, Rahul Sundaram wrote: > Richard Hughes wrote: > > On Sat, 2007-06-16 at 10:14 -0700, Otto Rey wrote: > >> Why we continue hiding partitions with HAL policy > >> (/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi)?? > > > > My policy has always been that if a user is able to boot a system with a > > live-cd then all security is void. > > Wouldn't filesystem encryption make this not quite true? To a degree, yes, but I think I can count all the fedora users of encrypted root on one hand... :-) Richard. From sundaram at fedoraproject.org Sun Jun 17 07:40:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 17 Jun 2007 13:10:23 +0530 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <1182068883.2324.3.camel@work> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <1182014242.2309.7.camel@work> <4674969F.7040208@fedoraproject.org> <1182068883.2324.3.camel@work> Message-ID: <4674E567.4060404@fedoraproject.org> Richard Hughes wrote: > On Sun, 2007-06-17 at 07:34 +0530, Rahul Sundaram wrote: >> Richard Hughes wrote: >>> On Sat, 2007-06-16 at 10:14 -0700, Otto Rey wrote: >>>> Why we continue hiding partitions with HAL policy >>>> (/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi)?? >>> My policy has always been that if a user is able to boot a system with a >>> live-cd then all security is void. >> Wouldn't filesystem encryption make this not quite true? > > To a degree, yes, but I think I can count all the fedora users of > encrypted root on one hand... :-) Really? I would guess it would be more than that. We include more than one method for doing this including dm-crypt and encfs. Hopefully this feature gets into Fedora 8 http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems Rahul From hughsient at gmail.com Sun Jun 17 08:59:22 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 17 Jun 2007 09:59:22 +0100 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <4674E567.4060404@fedoraproject.org> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <1182014242.2309.7.camel@work> <4674969F.7040208@fedoraproject.org> <1182068883.2324.3.camel@work> <4674E567.4060404@fedoraproject.org> Message-ID: <1182070762.2324.10.camel@work> On Sun, 2007-06-17 at 13:10 +0530, Rahul Sundaram wrote: > Richard Hughes wrote: > > On Sun, 2007-06-17 at 07:34 +0530, Rahul Sundaram wrote: > >> Richard Hughes wrote: > >>> On Sat, 2007-06-16 at 10:14 -0700, Otto Rey wrote: > >>>> Why we continue hiding partitions with HAL policy > >>>> (/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi)?? > >>> My policy has always been that if a user is able to boot a system with a > >>> live-cd then all security is void. > >> Wouldn't filesystem encryption make this not quite true? > > > > To a degree, yes, but I think I can count all the fedora users of > > encrypted root on one hand... :-) > > Really? I would guess it would be more than that. We include more than > one method for doing this including dm-crypt and encfs. Totally, but until we include a little ticky box in anaconda that number will be still sub-0.01 percent. I'm not l33t enough to setup root encryption with working suspend/resume, so the average newbie has no chance. Richard, From luya_tfz at thefinalzone.com Sun Jun 17 08:35:43 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Sun, 17 Jun 2007 04:35:43 -0400 Subject: source RPM for latest version of Wine In-Reply-To: <200706170228.56112.lightsolphoenix@gmail.com> References: <200706170228.56112.lightsolphoenix@gmail.com> Message-ID: <1182069343.4674f25f35c1a@ssl.mecca.ca> Quoting Kelly : > I'm posting this here instead of making a Package Review topic because I > believe someone's already handling this package. ??However, there hasn't been > an update for a while, so I figured I'd post the updated source RPM I made > for it so that anyone who wants to can create the more up-to-date RPM's for > Wine (that'd be version 0.9.39). Actually, wine 0.9.38 is available via koji and bodhi for testing. Version 0.9.39 will come shortly under update-testing. -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From buildsys at redhat.com Sun Jun 17 11:10:32 2007 From: buildsys at redhat.com (Build System) Date: Sun, 17 Jun 2007 07:10:32 -0400 Subject: rawhide report: 20070617 changes Message-ID: <200706171110.l5HBAWxA013948@porkchop.devel.redhat.com> New package kodos Visual regular expression editor New package postgresql-pgpoolAdmin PgpoolAdmin - web-based pgpool administration New package tesseract Raw OCR Engine Updated Packages: asymptote-1.30-1.fc8 -------------------- * Sat Jun 16 2007 Jose Pedro Oliveira - 1.30-1 - Update to 1.30. * Sat Jun 16 2007 Jose Pedro Oliveira - 1.29-3 - Using "evince" as the default PS and PDF viewers (#244151). (patch file: asymptote-1.29-settings.patch) - Use relative symbolic links in the {emacs,xemacs}-common triggers (#155750). - Use relative symbolic links in the vim-common triggers. geomview-1.9.2-1.fc8 -------------------- * Sat Jun 16 2007 Rex Dieter 1.9.2-1 - geomview-1.9.2 gtk2-2.11.3-2.fc8 ----------------- * Sat Jun 16 2007 Caolan McNamara - 1.11.3-2 - Resolves: rhbz#244516 avoid typename in headers for C++ * Fri Jun 15 2007 Matthias Clasen - 1.11.3-1 - Update to 2.11.3 - Drop upstreamed patches * Wed Jun 06 2007 Matthias Clasen - 1.11.2-1 - Update to 2.11.2 gtkterm-0.99.5-4.fc8 -------------------- * Sat Jun 16 2007 Hans de Goede 0.99.5-4 - Fix various CR LF handling issues (bug 244182) hunspell-pl-0.20070616-1.fc8 ---------------------------- * Sat Jun 16 2007 Caolan McNamara - 0.20070616-1 - latest version jd-1.9.5-0.5.beta070616.fc8 --------------------------- * Sat Jun 16 2007 Mamoru Tasaka - 1.9.5-0.5.beta070616 - 1.9.5 beta 070616 * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.4.beta070611 - 1.9.5 beta 070611 * Mon May 28 2007 Mamoru Tasaka - 1.9.5-0.3.beta070528 - 1.9.5 beta 070528 kdeaccessibility-1:3.5.7-2.fc8 ------------------------------ * Sat Jun 16 2007 Rex Dieter - 1:3.5.7-2 - portability (rhel) - omit .desktop patch (doesn't apply) * Sat Jun 16 2007 Rex Dieter - 1:3.5.7-1 - cleanup * Thu Jun 07 2007 Than Ngo - 1:3.5.7-0.1.fc7 - 3.5.7 kdeaddons-3.5.7-2.fc8 --------------------- * Sat Jun 16 2007 Rex Dieter 3.5.7-2 - use versioned Obsoletes - drop Conflicts: akregator * Mon Jun 11 2007 Rex Dieter 3.5.7-1 - minor cleanups * Thu Jun 07 2007 Than Ngo - 3.5.7-0.1.fc7 - 3.5.7 kdeadmin-7:3.5.7-2.fc8 ---------------------- * Sat Jun 16 2007 Rex Dieter - 7:3.5.7-2 - update knetworkconf patch - portability (rhel) bits * Mon Jun 11 2007 Rex Dieter - 7:3.5.7-1 - kdeadmin-3.5.7 - make use of consoleheloper optional for kdesu-aware apps (default yes) kdeartwork-3.5.7-1.fc8 ---------------------- * Mon Jun 11 2007 Rex Dieter 3.5.7-1 - 3.5.7 kdebase-6:3.5.7-3.fc8 --------------------- * Fri Jun 15 2007 Rex Dieter - 6:3.5.7-3 - specfile portability * Mon Jun 11 2007 Rex Dieter - 6:3.5.7-2 - fix BR: kdelibs-devel - cleanup Req's wrt kde-settings * Mon Jun 11 2007 Than Ngo - 6:3.5.7-1.fc7.1 - remove kdebase-3.4.2-npapi-64bit-fixes.patch, it's included in new upstream kdeedu-3.5.7-1.fc8 ------------------ * Mon Jun 11 2007 Rex Dieter - 3.5.7-1 - 3.5.7 kdegames-6:3.5.7-1.fc8 ---------------------- * Mon Jun 11 2007 Rex Dieter - 6:3.5.7-1 - 3.5.7 * Tue Apr 24 2007 Than Ngo - 6:3.5.6-3.fc7 - cleanup kdegraphics-7:3.5.7-1.fc8 ------------------------- * Mon Jun 11 2007 Rex Dieter - 7:3.5.7-1 - 3.5.7 kdelibs-6:3.5.7-5.fc8 --------------------- * Sat Jun 16 2007 Rex Dieter - 6:3.5.7-5 - -devel: +Requires: libutempter-devel kdemultimedia-6:3.5.7-1.fc8 --------------------------- * Wed Jun 06 2007 Than Ngo - 6:3.5.7-1 - 3.5.7 * Wed May 16 2007 Rex Dieter - 6:3.5.6-7 - -extras scriptlets * Wed May 09 2007 Rex Dieter - 6:3.5.6-6 - extras=1 (BR: akode-devel libsamplerate-devel taglib-devel xine-lib-devel) kdenetwork-7:3.5.7-1.fc8 ------------------------ * Mon Jun 11 2007 Rex Dieter 7:3.5.7-1 - 3.5.7 kdepim-6:3.5.7-2.fc8 -------------------- * Wed Jun 13 2007 Rex Dieter - 6:3.5.7-2 - +BR: libopensync-devel * Wed Jun 13 2007 Than Ngo - 6:3.5.7-1.fc7 - bump release version * Wed Jun 06 2007 Than Ngo - 6:3.5.7-0.1.fc7 - 3.5.7 kdetoys-7:3.5.7-1.fc8 --------------------- * Mon Jun 11 2007 Rex Dieter 7:3.5.7-1 - kde-3.5.7 kdeutils-6:3.5.7-1.fc8 ---------------------- * Mon Jun 11 2007 Rex Dieter - 6:3.5.7-1 - 3.5.7 kernel-2.6.21-1.3223.fc8 ------------------------ * Sat Jun 16 2007 Dave Jones - 2.6.22-rc4-git8. (utrace broke, temporarily disabled). * Fri Jun 15 2007 Dave Jones - 2.6.22-rc4-git7. * Wed Jun 13 2007 John W. Linville - Refresh wireless-dev patch - Drop iwlwifi patch (0.0.25 now in wireless-dev!) net6-1.3.5-1.fc8 ---------------- * Sat Jun 16 2007 Luke Macken - 1.3.5-1 - 1.3.5 perl-Cairo-1.040-1.fc8 ---------------------- * Sat Jun 16 2007 Jose Pedro Oliveira - 1.040-1 - Update to 1.040. perl-MailTools-1.77-1.fc7 ------------------------- * Fri May 11 2007 Paul Howarth 1.77-1 - Update to 1.77 perl-Perl-Critic-1.053-1.fc8 ---------------------------- * Sat Jun 16 2007 Jose Pedro Oliveira - 1.053-1 - Update to 1.053. perl-Text-CSV_XS-0.29-1.fc8 --------------------------- * Sat Jun 16 2007 Jose Pedro Oliveira - 0.29-1 - Update to 0.29. * Sat Jun 16 2007 Jose Pedro Oliveira - 0.27-1 - Update to 0.27. - New upstream maintainer. phpPgAdmin-4.1.2-1.fc7 ---------------------- * Fri Jun 01 2007 Devrim Gunduz 4.1.2-1 - Update to 4.1.2 - Fix for Red Hat Bugzilla #241489 postr-0.7-1.fc8 --------------- * Sat Jun 16 2007 Trond Danielsen - 0.7-1 - New version. redet-doc-8.22-1.fc8 -------------------- sysprof-kmod-1.0.8-1.2.6.21_1.3228.fc7 -------------------------------------- wesnoth-1.2.5-2.fc8 ------------------- * Sat Jun 16 2007 Brian Pepple - 1.2.5-2 - Drop wmlxgettext. * Sat Jun 16 2007 Brian Pepple - 1.2.5-1 - Update to 1.2.5. wp_tray-0.5.3-4.fc7 ------------------- * Wed May 09 2007 Denis Leroy - 0.5.3-4 - Added patch to make change lib-notifications optional - Cleaned up gnomewp patch * Tue May 08 2007 Denis Leroy - 0.5.3-3 - Added patch to make gnome wp addition optional, minor glade fixes Broken deps for i386 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-impress oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-math oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-writer oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-calc oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-base oooqs2 - 1.0-3.fc6.ppc64 requires openoffice.org-draw openoffice.org-dict-cs_CZ - 20060303-5.fc7.ppc64 requires openoffice.org-core php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From Axel.Thimm at ATrpms.net Sun Jun 17 12:08:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 17 Jun 2007 14:08:38 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <20070617011839.GB3217@free.fr> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610212349.GE2371@neu.nirvana> <20070616172208.GC3316@free.fr> <20070617010404.GG13629@neu.nirvana> <20070617011839.GB3217@free.fr> Message-ID: <20070617120838.GB23310@neu.nirvana> On Sun, Jun 17, 2007 at 03:18:39AM +0200, Patrice Dumas wrote: > On Sun, Jun 17, 2007 at 03:04:04AM +0200, Axel Thimm wrote: > > On Sat, Jun 16, 2007 at 07:22:08PM +0200, Patrice Dumas wrote: > > > On Sun, Jun 10, 2007 at 11:23:49PM +0200, Axel Thimm wrote: > > > > Requiring yelp only because an app ships a yelp file is like requiring > > > > evince for shipping pdf docu or firefox for shipping html docu. > > > > > > Similarly, if a program calls evince or htmlviewer when clicking on a > > > button, then it should considered to add it as a Requires. > > > > So what about FF? Would you suggest that it should require evince? > > I am not completly understanding your point. FF is firefox, right? Why > should it require evince? Because if you click on a pdf file it will try to run 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 andy at smile.org.ua Sun Jun 17 12:15:32 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Sun, 17 Jun 2007 15:15:32 +0300 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: <20070617121532.GA3255@serv.smile.org.ua> Hi Caio Marcelo! On Fri, Jun 15, 2007 at 10:23:29PM -0300, Caio Marcelo wrote next: > Just a small note: there's a "wheel" group, which has entries > in /etc/sudoers by default, but commented. This group is usually > for the administration users AFAIK, so it could be used instead of > "sudoers" group. +1 voice to make users under wheel group. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From pertusus at free.fr Sun Jun 17 13:20:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 17 Jun 2007 15:20:07 +0200 Subject: To Require yelp or not to require yelp In-Reply-To: <20070617120838.GB23310@neu.nirvana> References: <466BA0D6.8050603@hhs.nl> <466B9F79.2040601@redhat.com> <20070610212349.GE2371@neu.nirvana> <20070616172208.GC3316@free.fr> <20070617010404.GG13629@neu.nirvana> <20070617011839.GB3217@free.fr> <20070617120838.GB23310@neu.nirvana> Message-ID: <20070617132007.GD3064@free.fr> On Sun, Jun 17, 2007 at 02:08:38PM +0200, Axel Thimm wrote: > > Because if you click on a pdf file it will try to run it. It is not exactly the same situation, since the pdf is not part of the firefox package, and it could then apply to any file opened with firefox. firefox as a file manager doesn't need to have all of the document types handling applications required. So it is definitely a different situation. -- Pat From dtimms at iinet.net.au Sun Jun 17 13:31:52 2007 From: dtimms at iinet.net.au (David Timms) Date: Sun, 17 Jun 2007 23:31:52 +1000 Subject: updates-testing is not useful In-Reply-To: <604aa7910706091404p45c84d58m369bf9e19fca094e@mail.gmail.com> References: <466AB51E.7090000@redhat.com> <200706091225.31422.jkeating@redhat.com> <20070609194442.GB8740@wolff.to> <604aa7910706091404p45c84d58m369bf9e19fca094e@mail.gmail.com> Message-ID: <467537C8.5070507@iinet.net.au> Jeff Spaleta wrote: > On 6/9/07, Bruno Wolff III wrote: >> fedora-test-list gets notices about new packages in updates-testing >> already. > > Let me suggest, that if we would like to see these packages more > widely tested, then it might not be wise to send this just to > test-list.... nothing like preaching to the choir...a relatively small > choir at that. You want to drive a summary of a test annoucements > into the most commonly used discussion channels for end-users... to > aid in the chance of noticing that crap is going into testing at all. I would tend to agree, however, it should be no more than a single message per day, with links for the actual details. DaveT. From jkeating at redhat.com Sun Jun 17 13:27:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Jun 2007 09:27:05 -0400 Subject: Errors building packages for F7 and rawhide in mock In-Reply-To: <1182029915.23816.3.camel@rousalka.dyndns.org> References: <20070616193157.GD30917@psilocybe.teonanacatl.org> <20070616203959.GF30917@psilocybe.teonanacatl.org> <1182029915.23816.3.camel@rousalka.dyndns.org> Message-ID: <200706170927.05506.jkeating@redhat.com> On Saturday 16 June 2007 17:38:34 Nicolas Mailhot wrote: > Le samedi 16 juin 2007 ? 16:39 -0400, Todd Zullinger a ?crit : > > Nicolas Mailhot wrote: > > > Seems koji was not designed with mock in mind and the koji > > > repositories are not stable enough for yum (which mock uses). Koji > > > build repo probably need mirroring or redesign if mock is to be > > > supported post Fedora 7. > > > > I disabled the local repo in the F7 mock config and things worked much > > better. If this isn't a known problem between mock and koji, which of > > the two components should a bug be filed under? > > It's a problem with koji which static repos have not been designed to be > remotely accessed through yum Actually that's exactly what the static-repos were created for. The static-repos are publically accessable, perhaps it was a network timeout? This is the same functionality as the old "local" repo that was in mock, which pointed at the plague needsign queue. Can you not click on that repodata file url and download it? Can your system not reach the koji website? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmz at pobox.com Sun Jun 17 14:02:18 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 17 Jun 2007 10:02:18 -0400 Subject: Errors building packages for F7 and rawhide in mock In-Reply-To: <200706170927.05506.jkeating@redhat.com> References: <20070616193157.GD30917@psilocybe.teonanacatl.org> <20070616203959.GF30917@psilocybe.teonanacatl.org> <1182029915.23816.3.camel@rousalka.dyndns.org> <200706170927.05506.jkeating@redhat.com> Message-ID: <20070617140218.GG30917@psilocybe.teonanacatl.org> Jesse Keating wrote: > On Saturday 16 June 2007 17:38:34 Nicolas Mailhot wrote: >> Le samedi 16 juin 2007 ? 16:39 -0400, Todd Zullinger a ?crit : >>> Nicolas Mailhot wrote: >>>> Seems koji was not designed with mock in mind and the koji >>>> repositories are not stable enough for yum (which mock uses). >>>> Koji build repo probably need mirroring or redesign if mock is to >>>> be supported post Fedora 7. >>> >>> I disabled the local repo in the F7 mock config and things worked >>> much better. If this isn't a known problem between mock and koji, >>> which of the two components should a bug be filed under? >> >> It's a problem with koji which static repos have not been designed >> to be remotely accessed through yum > > Actually that's exactly what the static-repos were created for. The > static-repos are publically accessable, perhaps it was a network > timeout? This is the same functionality as the old "local" repo > that was in mock, which pointed at the plague needsign queue. Can > you not click on that repodata file url and download it? Can your > system not reach the koji website? Yeah, I can reach the files in the koji repo that way. So I don't think that it's a network problem on my end (though I couldn't rule out something odd happening inside mock). I tried bumping the timeout value in the yum.conf for the mock chroot and that didn't resolve the problem either (with up to a 3 minute timeout). Disabling the local (koji) repo in the mock config allowed me to build the things I wanted to build in mock. I'm happy to turn on any debug level you think might show what's wrong and try again. I tried over the course of a day numerous times and never was able to get a chroot to successfully pass the prep stage as long as the local koji repo was enabled. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I never forget a face, but in your case I'll be glad to make an exception. -- Groucho Marx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From dtimms at iinet.net.au Sun Jun 17 14:29:27 2007 From: dtimms at iinet.net.au (David Timms) Date: Mon, 18 Jun 2007 00:29:27 +1000 Subject: F8devel - user configuration storage locations In-Reply-To: <16de708d0706151125n56395057ye6ea57215c92048b@mail.gmail.com> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <4672BF98.4080309@iinet.net.au> <16de708d0706151125n56395057ye6ea57215c92048b@mail.gmail.com> Message-ID: <46754547.2000708@iinet.net.au> Arthur Pemberton wrote: > On 6/15/07, David Timms wrote: >> Arthur Pemberton wrote: >> > On 6/13/07, David Timms wrote: >> >> A potential goal for Fedora: >> >> Cleanup user settings configuration >> >> >> >> For a long time applications creates a {hidden} .mysetting file in the >> >> user's home directory, if multiple config/settings under a >> >> .myapp/.various files. >> > >> > I would hate this >> That is the already the current state of play -or do I misread you ? > > I wasn't clear, I would hate forcing all apps into a single directory. What I meant is that we could have a single sub dir that resides below the user's home directory. If an app currently uses the ~/ dir to store config, it would then store it in ~/config/ instead. If it creates it's own directory under ~/ to store its multiple {usually} config files, then in future it could store it in the same name folder underneath ~/config/ >> >> I think this should be tidied up by creating a single directory at the >> >> users home folder to store all setting/configs that apps make. >> >> - The folder should not be hidden. >> > >> > I would hate this even more >> Is this hate directed toward the visibility, or to the idea of having >> all settings in a subfolder of the user's home dir ? > > Both. I applaud Windows for making system files hidden by default. A > user who doesn't know how to unhide files shouldn't be playing with > those files. It's a low bar, but I think a necessary one. So maybe making it visible is perhaps not such a good idea. >> >> - It should have a default text file indicating that it contains >> hidden >> >> files that store settings for installed applications. >> > >> > why? >> 1. So newsers know what it is and why it is there. >> 2. So newsers don't try to erase it. > > See. In my opinion, you just created two problems by creating this > config directory, and then gave a weak solution to them - I can't > think of a stronger solution myself. The configs are already there, it is just one folder higher in the directory tree, and interspersed between all the other user data files and directories. So tidying this up is actually a bad thing in your opinion or "simply difficult" ? ... >> >> - All packages to use this folder >> > >> > good luck with that >> For all I know this location is just some system call, environment >> variable or something - does your experience show this would in fact >> require individual adjustment of each app ? > > Yes, I'm pretty sure most programs just get the $HOME variable and put > stuff in there. There's a separate $CONFIG variable (I think) which > points to /etc. I do not think there's a $HOMECONFIG or equivalent > variable. I don't see one in the result of set. So a new environment variable $HOMECONFIG as a start. >> >> I see some problems: >> >> - breaks FHStandard ? >> >> - every app would need to have a one time adjustment and package >> >> rebuilt ? >> > >> > You make that sound trivial >> Only because I haven't the foggiest what it would involve. > > I'm pretty sure it involves what you suggested "every app needs to > have a one time adjustment and package rebuilt" , except the change > would be the same, I'm not sure the exact adjustment would be the > same. And I would need to convince all application programmers to make the changes in their source, if that is the case. It would need to be universally accepted; Matej mentions the freedesktop standards, ... >> Mine has over 2000 files. About 14 directories and 50 are files I put >> there. Then there is 77 .folders and remainder what seems to be .config >> files for various apps, and temp files of some sort: >> .serverauth.2268 and similar dating back 8+ months. > > Do you use Gnome? Yes, and over time there has been various little issues, apps needing death etc. But why did they have files in my home {main} folder in the first place. >> Perhaps there should be more adherence to using the /tmp folder, or a >> new special users/tmp folder that gets cleared each time the machine is >> booted, or the user logged in ? > > Those folders aren't temporary, in the sense that the apps use them > when they reopen (although most can be safely deleted) Maybe they are more temporary state files, that aren't useful after a relogin/reboot. If so, isn't there better places for them. >> >> - easily move/copy all user configs to backup or a different machine >> > >> > cp -a ~/.* >> How do you do that in KDE, if it doesn't show the files ? > > Well that's a command prompt command. But anyways, in KDE it's > extremely easy to switch between hidden files shown and not shown. >> Would you be >> able to configure a .textconfigfile from the filesystem viewer ? Would a >> newser be able to work it out without guidance ? > > I would, but that is very rarely necessary. Rare enough that I have > can remember doing it less than a half dozen times. > >> I realize that these ideas are probably so adverse to age-old unix ways >> that it may not be possible to actually change it for existing apps ? >> >> DaveT. > > That may be true, but they do in fact work quite well. These kind of > files are use specific, so they are in the user's homedir, but aren't > really for the toying of the average user, so they are hidden. They > are in multiple directories since they are all already in home, and > having them in another singer directory within home makes them a bit > more vunerable to accidental deletion. But they would still be .hidden files, therefore not easily deletable. > Looking back on my response, it seems a bit disrespectful. I respect > your suggestions, but I do not agree with them. I understand - I imagine your time was short, but you wanted to say a lot, thanks for that. Arthur, am I overstepping the mark by summarizing your view as "making config files visible would be a bad thing", but the general idea is sane ? DaveT. From andreas.bierfert at lowlatency.de Sun Jun 17 14:29:13 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 17 Jun 2007 16:29:13 +0200 Subject: source RPM for latest version of Wine In-Reply-To: <200706170228.56112.lightsolphoenix@gmail.com> References: <200706170228.56112.lightsolphoenix@gmail.com> Message-ID: <20070617162913.4df671f8@alkaid.a.lan> On Sun, 17 Jun 2007 02:28:55 -0400 Kelly wrote: > I'm posting this here instead of making a Package Review topic because I > believe someone's already handling this package. ?However, there hasn't been > an update for a while, so I figured I'd post the updated source RPM I made > for it so that anyone who wants to can create the more up-to-date RPM's for > Wine (that'd be version 0.9.39). If you take a look: 0.9.38 has been in updates-testing for a while. .39 was released on Thursday and I have updated cvs this morning. Build for EPEL already been pushed as well as for devel and F-7. I think this is a reasonable timeframe for upgrades. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sun Jun 17 14:38:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 17 Jun 2007 16:38:31 +0200 Subject: Errors building packages for F7 and rawhide in mock In-Reply-To: <200706170927.05506.jkeating@redhat.com> References: <20070616193157.GD30917@psilocybe.teonanacatl.org> <20070616203959.GF30917@psilocybe.teonanacatl.org> <1182029915.23816.3.camel@rousalka.dyndns.org> <200706170927.05506.jkeating@redhat.com> Message-ID: <1182091112.28790.10.camel@rousalka.dyndns.org> Le dimanche 17 juin 2007 ? 09:27 -0400, Jesse Keating a ?crit : > On Saturday 16 June 2007 17:38:34 Nicolas Mailhot wrote: > > Le samedi 16 juin 2007 ? 16:39 -0400, Todd Zullinger a ?crit : > > > Nicolas Mailhot wrote: > > > > Seems koji was not designed with mock in mind and the koji > > > > repositories are not stable enough for yum (which mock uses). Koji > > > > build repo probably need mirroring or redesign if mock is to be > > > > supported post Fedora 7. > > > > > > I disabled the local repo in the F7 mock config and things worked much > > > better. If this isn't a known problem between mock and koji, which of > > > the two components should a bug be filed under? > > > > It's a problem with koji which static repos have not been designed to be > > remotely accessed through yum > > Actually that's exactly what the static-repos were created for. The > static-repos are publically accessable, perhaps it was a network timeout? > This is the same functionality as the old "local" repo that was in mock, > which pointed at the plague needsign queue. Can you not click on that > repodata file url and download it? Can your system not reach the koji > website? I'm afraid they're not working. They were more or less ok when koji was released and no one was using them (except for a few testers:)) but now koji is in cruise mode and a koji-using mock was released they just fall over all the time. You have to restart yum/mock a dozen times before it manages to download repodata or packages (and I've a proxy so my system never downloads the same rpm twice) (for repodata the fact we have a merged repo and koji includes debuginfo stuff is not helping ? koji repodata is huge, but even direct package download is not working 100% of the times, and as yum has been designed to fail at the slightest problem mock/yum koji runs will just fail most of the times) Koji server logs probably trace all the package/repodata interupted downloads. Each one is sufficient to kill a mock/yum run -- 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 buildsys at fedoraproject.org Sun Jun 17 15:30:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 17 Jun 2007 11:30:35 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-17 Message-ID: <20070617153035.7C4AC152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 17 asymptote-1.30-1.fc6 audacious-plugins-1.3.5-2.fc6 ez-ipupdate-3.0.11-0.14.b8.fc6 fluxbox-1.0.0-0.2.rc3.fc6 gtkterm-0.99.5-4.fc6 isomaster-1.0-1.fc6 jd-1.9.5-0.5.beta070616.fc6 NEW kodos-2.4.9-4.fc6 : Visual regular expression editor mugshot-1.1.43-1.fc6 pan-0.131-1.fc6 NEW perl-CGI-FastTemplate-1.09-3.fc6 : Perl extension for managing templates and performing variable interpolation NEW postgresql-pgpoolAdmin-1.0.0-6.fc6 : PgpoolAdmin - web-based pgpool administration postr-0.7-1.fc6 redet-doc-8.22-1.fc6 rxvt-unicode-8.2-1.fc6 scribes-0.3.2.8-1.fc6 scribus-1.3.3.9-1.fc6 Packages built and released for Fedora Extras 5: 3 isomaster-1.0-1.fc5 jd-1.9.5-0.5.beta070616.fc5 rxvt-unicode-8.2-1.fc5 Changes in Fedora Extras 6: asymptote-1.30-1.fc6 -------------------- * Sat Jun 16 2007 Jose Pedro Oliveira - 1.30-1 - Update to 1.30. * Sat Jun 16 2007 Jose Pedro Oliveira - 1.29-3 - Using "evince" as the default PS and PDF viewers (#244151). (patch file: asymptote-1.29-settings.patch) - Use relative symbolic links in the {emacs,xemacs}-common triggers (#155750). - Use relative symbolic links in the vim-common triggers. * Sat Jun 02 2007 Jose Pedro Oliveira - 1.29-2 - Add asy-faq to install-info (#155750). - Add support for vim 7.1. audacious-plugins-1.3.5-2.fc6 ----------------------------- * Sat Jun 16 2007 Ralf Ertzinger 1.3.5-2.fc6 - Update to 1.3.5 ez-ipupdate-3.0.11-0.14.b8.fc6 ------------------------------ * Fri Jun 15 2007 J. Randall Owens - 3.0.11-0.14.b8 - fix doc directory permissions * Thu Mar 08 2007 Jeff Layton - 3.0.11-0.13.b8 - remove Requires(postun) for user/groupdel since they're no longer needed fluxbox-1.0.0-0.2.rc3.fc6 ------------------------- * Sun Jun 03 2007 Andreas Bierfert 1.0.0-0.2.rc3 - fix #242187 gtkterm-0.99.5-4.fc6 -------------------- * Sat Jun 16 2007 Hans de Goede 0.99.5-4 - Fix various CR LF handling issues (bug 244182) isomaster-1.0-1.fc6 ------------------- * Sun Jun 10 2007 Marcin Zajaczkowski - 1.0-1 - updated to 1.0 jd-1.9.5-0.5.beta070616.fc6 --------------------------- * Sat Jun 16 2007 Mamoru Tasaka - 1.9.5-0.5.beta070616 - 1.9.5 beta 070616 kodos-2.4.9-4.fc6 ----------------- * Sat Jun 16 2007 Konstantin Ryabitsev - 2.4.9-4 - Remove leftover useless Requires. * Sun Jun 10 2007 Konstantin Ryabitsev - 2.4.9-3 - Don't add X-Fedora to desktop-file-install - Don't run update-desktop-database, since there's no MimeType to worry about mugshot-1.1.43-1.fc6 -------------------- * Fri Jun 15 2007 Owen Taylor - 1.1.43-1 - 1.1.43 * Thu Apr 26 2007 Owen Taylor - 1.1.42-2 - 1.1.42 pan-0.131-1.fc6 --------------- * Sat Jun 16 2007 Alexander Dalloz - 1:0.131-1 - Update to 0.131 (fixing #241610) * Sat May 12 2007 Alexander Dalloz - 1:0.129-1 - Update to 0.129 perl-CGI-FastTemplate-1.09-3.fc6 -------------------------------- * Fri Jun 15 2007 Jeffrey C. Ollie - 1.09-3 - Fix grammar in summary. * Fri Jun 15 2007 Jeffrey C. Ollie - 1.09-2 - Remove perl and perl-devel BR, BR perl(ExtUtils::MakeMaker) - Fix license. * Fri Jun 01 2007 Jeffrey C. Ollie - 1.09-1 - First version for Fedora postgresql-pgpoolAdmin-1.0.0-6.fc6 ---------------------------------- * Sat Jun 02 2007 Devrim Gunduz 1.0.0-6 - Fixes for bugzilla review #229323 postr-0.7-1.fc6 --------------- * Sat Jun 16 2007 Trond Danielsen - 0.7-1 - New version. * Tue Jun 05 2007 Trond Danielsen - 0.6-1 - New version. redet-doc-8.22-1.fc6 -------------------- * Sat Jun 16 2007 Nigel Jones 8.22-1 - Bring redet-doc up to par with redet - Patch0 (Makefile fixes) has been removed, personally I have no idea why it was even there, I wasn't using make! rxvt-unicode-8.2-1.fc6 ---------------------- * Tue May 08 2007 Andreas Bierfert 8.2-1 - version upgrade (#239421) scribes-0.3.2.8-1.fc6 --------------------- * Sat Jun 16 2007 Peter Gordon - 0.3.2.8-1 - Update to new upstream release (0.3.2.8). scribus-1.3.3.9-1.fc6 --------------------- * Sat Jun 02 2007 Andreas Bierfert 1.3.3.9-1 - version upgrade Changes in Fedora Extras 5: isomaster-1.0-1.fc5 ------------------- * Sun Jun 10 2007 Marcin Zajaczkowski - 1.0-1 - updated to 1.0 * Mon Mar 19 2007 Marcin Zajaczkowski - 0.8.1-1 - updated to 0.8.1 - removed unused patches (merged with upstream) - using desktop file from upstream jd-1.9.5-0.5.beta070616.fc5 --------------------------- * Sat Jun 16 2007 Mamoru Tasaka - 1.9.5-0.5.beta070616 - 1.9.5 beta 070616 rxvt-unicode-8.2-1.fc5 ---------------------- * Tue May 08 2007 Andreas Bierfert 8.2-1 - version upgrade (#239421) For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From snecklifter at gmail.com Sun Jun 17 16:12:58 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sun, 17 Jun 2007 17:12:58 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <4673037B.3030105@laposte.net> References: <4673037B.3030105@laposte.net> Message-ID: <364d303b0706170912i7a742e5dt5cfece21916abf58@mail.gmail.com> On 15/06/07, Axel wrote: > > What do you think about adding the user created at install to the > sudoers list ? > > For newbies like me, understanding the sudoers file isn't so easy, but > nevertheless they may need the sudo command. In my case, I'd rather my > account would have been added automatically to the sudoers list :) > +1 Don't we have to run it through legal first though as someone just patented it. :) Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at apestaart.org Sun Jun 17 16:25:44 2007 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 17 Jun 2007 18:25:44 +0200 Subject: python-twisted needs a newer version In-Reply-To: <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> Message-ID: <1182097544.28924.8.camel@level.fluendo.lan> On Sun, 2007-06-10 at 17:41 +0530, Deependra Shekhawat wrote: > There already is a bug > > Bug 236254 > > But it seems like no-one wants to see it. Please don't make assumptions. The world is not out to get you. If you want to help in a constructive way, a good first step would be to build updated packages and try them on everything in fedora right now that uses twisted (off the top of my head - flumotion, buildbot, bittorrent, but I am sure there are other things). Thomas From debarshi.ray at gmail.com Sun Jun 17 17:18:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 17 Jun 2007 22:48:03 +0530 Subject: python-twisted needs a newer version In-Reply-To: <57127b5f0706100948l205cdda3v149581bac37b3ed9@mail.gmail.com> References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> <57127b5f0706100948l205cdda3v149581bac37b3ed9@mail.gmail.com> Message-ID: <3170f42f0706171018o27b19631i36b2297ade56aa11@mail.gmail.com> > Sorry. I copy pasted from the bugzilla never noticed it would look so ugly. > LOL. > But it made my point more stronger i guess. There is nothing to LOL or laugh about. Do not use HTML mails on a mailing list. Use plain text only. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From cmarcelo at gmail.com Sun Jun 17 18:17:35 2007 From: cmarcelo at gmail.com (Caio Marcelo) Date: Sun, 17 Jun 2007 15:17:35 -0300 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: On 6/17/07, Freddie Rosario wrote: > I know that Ubuntu disables the root account by default and automatically > enables the first user added to the system to have sudo access. That might +1 Just another note: one related change is all "administrative" tasks (System > Administration, or running virt-manager with privilegies) should run via sudo (or some GUI over sudo) instead of asking for root password. Cheers, Caio Marcelo From ivazqueznet at gmail.com Sun Jun 17 18:39:47 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 17 Jun 2007 14:39:47 -0400 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: <1182105587.21142.2.camel@ignacio.lan> On Sun, 2007-06-17 at 15:17 -0300, Caio Marcelo wrote: > Just another note: one related change is all "administrative" tasks > (System > Administration, or running virt-manager with privilegies) > should run via sudo (or some GUI over sudo) instead of asking > for root password. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188 -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sb at monkey-mind.net Sun Jun 17 19:35:08 2007 From: sb at monkey-mind.net (Steven Bakker) Date: Sun, 17 Jun 2007 21:35:08 +0200 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: <20070617213508.320c6600@cluestix.noc.ams-ix.net> On Sun, 17 Jun 2007 15:17:35 -0300 Caio Marcelo wrote: > On 6/17/07, Freddie Rosario wrote: > > I know that Ubuntu disables the root account by default and automatically > > enables the first user added to the system to have sudo access. That might > > +1 I guess that makes sense, as it would prevent people from running X sessions as root. However, I would hesitate to do this on a server install by default. Also, does disabling the root account prevent me from doing "sudo sh" (I wouldn't like to lose that ability), or does that depend on _how_ the root account is disabled? Cheers, Steven From pemboa at gmail.com Sun Jun 17 20:50:06 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 17 Jun 2007 15:50:06 -0500 Subject: F8devel - user configuration storage locations In-Reply-To: <46754547.2000708@iinet.net.au> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <4672BF98.4080309@iinet.net.au> <16de708d0706151125n56395057ye6ea57215c92048b@mail.gmail.com> <46754547.2000708@iinet.net.au> Message-ID: <16de708d0706171350l755bfc5ch5434014dd7532515@mail.gmail.com> On 6/17/07, David Timms wrote: [ snip ] > > Looking back on my response, it seems a bit disrespectful. I respect > > your suggestions, but I do not agree with them. > I understand - I imagine your time was short, but you wanted to say a > lot, thanks for that. > Arthur, am I overstepping the mark by summarizing your view as "making > config files visible would be a bad thing", but the general idea is sane ? No not exactly. The general idea is sane, but not worth the effort IMHO. And having the files visible by default is just a bad idea. -- Fedora Core 6 and proud From nicolas.mailhot at laposte.net Sun Jun 17 21:07:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 17 Jun 2007 23:07:40 +0200 Subject: F8devel - user configuration storage locations In-Reply-To: <16de708d0706171350l755bfc5ch5434014dd7532515@mail.gmail.com> References: <46705D4F.10307@iinet.net.au> <16de708d0706131646m55d90f40xbb530836b34a9df0@mail.gmail.com> <4672BF98.4080309@iinet.net.au> <16de708d0706151125n56395057ye6ea57215c92048b@mail.gmail.com> <46754547.2000708@iinet.net.au> <16de708d0706171350l755bfc5ch5434014dd7532515@mail.gmail.com> Message-ID: <1182114460.4906.6.camel@rousalka.dyndns.org> Le dimanche 17 juin 2007 ? 15:50 -0500, Arthur Pemberton a ?crit : > On 6/17/07, David Timms wrote: > [ snip ] > > > Looking back on my response, it seems a bit disrespectful. I respect > > > your suggestions, but I do not agree with them. > > I understand - I imagine your time was short, but you wanted to say a > > lot, thanks for that. > > Arthur, am I overstepping the mark by summarizing your view as "making > > config files visible would be a bad thing", but the general idea is sane ? > > > No not exactly. > > The general idea is sane, but not worth the effort IMHO. That's what the KDE and GNOME people said a few years ago. Considering most of our desktop components have been fully or partly rewritten since the cleanup could have been largely finished by now otherwise. It would take a long time, but if the right people agreed with it we have enough code churn for other reasons it would be done in a few years without special efforts. You just don't have to think about it like a 6-month expensive task force. -- 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 darth_linux at ameritech.net Mon Jun 18 00:13:47 2007 From: darth_linux at ameritech.net (eah) Date: Sun, 17 Jun 2007 20:13:47 -0400 Subject: x86_64 kde live cd image > 800MB Message-ID: <200706172013.47230.darth_linux@ameritech.net> Hello all, Is there a reason why x86_64 images are bigger than x86 images? Why is the x86_64 KDE live CD > 800MB? Are there plans to fix this? Has anyone successfully burned and used this KDE live CD? I've used and installed the x86 live CD, but the 64-bit version can't fit to CD. thanks in advance, eah (Eric Hartwell) From jkeating at redhat.com Mon Jun 18 00:10:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Jun 2007 20:10:16 -0400 Subject: Errors building packages for F7 and rawhide in mock In-Reply-To: <1182091112.28790.10.camel@rousalka.dyndns.org> References: <20070616193157.GD30917@psilocybe.teonanacatl.org> <200706170927.05506.jkeating@redhat.com> <1182091112.28790.10.camel@rousalka.dyndns.org> Message-ID: <200706172010.19719.jkeating@redhat.com> On Sunday 17 June 2007 10:38:31 Nicolas Mailhot wrote: > I'm afraid they're not working. > They were more or less ok when koji was released and no one was using > them (except for a few testers:)) but now koji is in cruise mode and a > koji-using mock was released they just fall over all the time. You have > to restart yum/mock a dozen times before it manages to download repodata > or packages (and I've a proxy so my system never downloads the same rpm > twice) > > (for repodata the fact we have a merged repo and koji includes debuginfo > stuff is not helping ? koji repodata is huge, but even direct package > download is not working 100% of the times, and as yum has been designed > to fail at the slightest problem mock/yum koji runs will just fail most > of the times) > > Koji server logs probably trace all the package/repodata interupted > downloads. Each one is sufficient to kill a mock/yum run I wonder if this is due to some settings on the http daemon on koji.fp.o. I suspect that we could serve the came content out via a different machine (or machines) and this might get better. Will investigate. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 18 00:16:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Jun 2007 20:16:51 -0400 Subject: x86_64 kde live cd image > 800MB In-Reply-To: <200706172013.47230.darth_linux@ameritech.net> References: <200706172013.47230.darth_linux@ameritech.net> Message-ID: <200706172016.52174.jkeating@redhat.com> On Sunday 17 June 2007 20:13:47 eah wrote: > Hello all, > > Is there a reason why x86_64 images are bigger than x86 images? > Why is the x86_64 KDE live CD > 800MB? Are there plans to fix this? Has > anyone successfully burned and used this KDE live CD? I've used and > installed the x86 live CD, but the 64-bit version can't fit to CD. > > thanks in advance, > > eah (Eric Hartwell) It's not a Live"CD". It's Live Media. You'll have to use a DVD or USB key for it. Due to multilib, the x86_64 Live media is bigger than the pure i386 one. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hunter at userfriendly.net Mon Jun 18 01:25:34 2007 From: hunter at userfriendly.net (Michael Weiner) Date: Sun, 17 Jun 2007 21:25:34 -0400 Subject: x86_64 kde live cd image > 800MB In-Reply-To: <200706172016.52174.jkeating@redhat.com> References: <200706172013.47230.darth_linux@ameritech.net> <200706172016.52174.jkeating@redhat.com> Message-ID: On 6/17/07, Jesse Keating wrote: > > On Sunday 17 June 2007 20:13:47 eah wrote: > > Hello all, > > > > Is there a reason why x86_64 images are bigger than x86 images? > > Why is the x86_64 KDE live CD > 800MB? Are there plans to fix this? Has > > anyone successfully burned and used this KDE live CD? I've used and > > installed the x86 live CD, but the 64-bit version can't fit to CD. > > > > thanks in advance, > > > > eah (Eric Hartwell) > > It's not a Live"CD". It's Live Media. You'll have to use a DVD or USB > key > for it. Due to multilib, the x86_64 Live media is bigger than the pure > i386 > one. I wondered the exact same thing, and now that its been explained i would formally like to request that the file name be changed. It is quite misleading and makes one wonder how the f&*^@#($^%!@ to burn it successfully to CD, as there is no documentation saying otherwise. Just my 2 pesos Michael Weiner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeevanullas at gmail.com Mon Jun 18 02:10:43 2007 From: jeevanullas at gmail.com (Deependra Shekhawat) Date: Mon, 18 Jun 2007 07:40:43 +0530 Subject: python-twisted needs a newer version In-Reply-To: <1182097544.28924.8.camel@level.fluendo.lan> References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> <1182097544.28924.8.camel@level.fluendo.lan> Message-ID: <57127b5f0706171910g3b9715cdp57b3f3588c592f31@mail.gmail.com> Where can I get a .spec file to do the compilation stuff. On 6/17/07, Thomas Vander Stichele wrote: > > On Sun, 2007-06-10 at 17:41 +0530, Deependra Shekhawat wrote: > > There already is a bug > > > > Bug 236254 > > > > But it seems like no-one wants to see it. > > Please don't make assumptions. The world is not out to get you. > > If you want to help in a constructive way, a good first step would be to > build updated packages and try them on everything in fedora right now > that uses twisted (off the top of my head - flumotion, buildbot, > bittorrent, but I am sure there are other things). > > Thomas > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Enjoy Life ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeevanullas at gmail.com Mon Jun 18 02:10:20 2007 From: jeevanullas at gmail.com (Deependra Shekhawat) Date: Mon, 18 Jun 2007 07:40:20 +0530 Subject: python-twisted needs a newer version In-Reply-To: <3170f42f0706171018o27b19631i36b2297ade56aa11@mail.gmail.com> References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> <57127b5f0706100948l205cdda3v149581bac37b3ed9@mail.gmail.com> <3170f42f0706171018o27b19631i36b2297ade56aa11@mail.gmail.com> Message-ID: <57127b5f0706171910q7aa1ed7wfd191589465a18a9@mail.gmail.com> Thanks for the info. I will keep that in mind. On 6/17/07, Debarshi 'Rishi' Ray wrote: > > > Sorry. I copy pasted from the bugzilla never noticed it would look so > ugly. > > LOL. > > But it made my point more stronger i guess. > > There is nothing to LOL or laugh about. Do not use HTML mails on a > mailing list. Use plain text only. > > Regards, > Debarshi > -- > GPG key ID: 63D4A5A7 > Key server: pgp.mit.edu > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Enjoy Life ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From darth_linux at ameritech.net Mon Jun 18 01:45:34 2007 From: darth_linux at ameritech.net (eah) Date: Sun, 17 Jun 2007 21:45:34 -0400 Subject: x86_64 kde live cd image > 800MB In-Reply-To: <200706172016.52174.jkeating@redhat.com> References: <200706172013.47230.darth_linux@ameritech.net> <200706172016.52174.jkeating@redhat.com> Message-ID: <200706172145.35311.darth_linux@ameritech.net> On Sunday 17 June 2007 20:16:51 Jesse Keating wrote: > On Sunday 17 June 2007 20:13:47 eah wrote: > > Hello all, > > > > Is there a reason why x86_64 images are bigger than x86 images? > > Why is the x86_64 KDE live CD > 800MB? Are there plans to fix this? Has > > anyone successfully burned and used this KDE live CD? I've used and > > installed the x86 live CD, but the 64-bit version can't fit to CD. > > > > thanks in advance, > > > > eah (Eric Hartwell) > > It's not a Live"CD". It's Live Media. You'll have to use a DVD or USB key > for it. Due to multilib, the x86_64 Live media is bigger than the pure > i386 one. pardon my confusion. it comes from k3b forcing me to use a CD-R to burn the iso to disk. is there a way to tell k3b (or other burning software) to allow write to DVD media? thanks, eah From debarshi.ray at gmail.com Mon Jun 18 02:18:55 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 18 Jun 2007 07:48:55 +0530 Subject: user created at install added in sudoers ? In-Reply-To: <20070617213508.320c6600@cluestix.noc.ams-ix.net> References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> <20070617213508.320c6600@cluestix.noc.ams-ix.net> Message-ID: <3170f42f0706171918i16c3db8y30e7b2621765f361@mail.gmail.com> > Also, does disabling the root account prevent me > from doing "sudo sh" You can always do: $ sudo su - Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Mon Jun 18 02:22:28 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 18 Jun 2007 07:52:28 +0530 Subject: python-twisted needs a newer version In-Reply-To: <57127b5f0706171910q7aa1ed7wfd191589465a18a9@mail.gmail.com> References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> <57127b5f0706100948l205cdda3v149581bac37b3ed9@mail.gmail.com> <3170f42f0706171018o27b19631i36b2297ade56aa11@mail.gmail.com> <57127b5f0706171910q7aa1ed7wfd191589465a18a9@mail.gmail.com> Message-ID: <3170f42f0706171922m309c059amb47e798f151cf0aa@mail.gmail.com> > Thanks for the info. I will keep that in mind. Use the "plain text" option in GMail's web interface while composing the mail. Your mails are still HTML ones. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From cmarcelo at gmail.com Mon Jun 18 02:40:03 2007 From: cmarcelo at gmail.com (Caio Marcelo) Date: Sun, 17 Jun 2007 23:40:03 -0300 Subject: user created at install added in sudoers ? In-Reply-To: <1182105587.21142.2.camel@ignacio.lan> References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> <1182105587.21142.2.camel@ignacio.lan> Message-ID: On 6/17/07, Ignacio Vazquez-Abrams wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188 Nice! So, if I got right what has been done already, it's just a matter of tweaking the defaults of these /etc/security/console.apps/* files? Cheers, Caio Marcelo From wolfy at nobugconsulting.ro Mon Jun 18 03:09:53 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 18 Jun 2007 06:09:53 +0300 Subject: x86_64 kde live cd image > 800MB In-Reply-To: <200706172145.35311.darth_linux@ameritech.net> References: <200706172013.47230.darth_linux@ameritech.net> <200706172016.52174.jkeating@redhat.com> <200706172145.35311.darth_linux@ameritech.net> Message-ID: <4675F781.80200@nobugconsulting.ro> On 06/18/2007 04:45 AM, eah wrote: > On Sunday 17 June 2007 20:16:51 Jesse Keating wrote: > >> On Sunday 17 June 2007 20:13:47 eah wrote: >> >>> Hello all, >>> >>> Is there a reason why x86_64 images are bigger than x86 images? >>> Why is the x86_64 KDE live CD > 800MB? Are there plans to fix this? Has >>> anyone successfully burned and used this KDE live CD? I've used and >>> installed the x86 live CD, but the 64-bit version can't fit to CD. >>> >>> thanks in advance, >>> >>> eah (Eric Hartwell) >>> >> It's not a Live"CD". It's Live Media. You'll have to use a DVD or USB key >> for it. Due to multilib, the x86_64 Live media is bigger than the pure >> i386 one. >> > > pardon my confusion. it comes from k3b forcing me to use a CD-R to burn the > iso to disk. is there a way to tell k3b (or other burning software) to allow > write to DVD media? > Tools -> Burn DVD iso image -> burn'> > or as an alternate, click on the icon corresponding to "burn DVD image" > in the lower panel and select the ISO image from the browser which pops up > or, yet another alternative method, drag the icon corresponding to the > ISO file from the "Contents" panel and drop it over the icon > corresponding to "burn DVD iso" from the lower panel thanks for that. i tried that right after sending the e-mail. (duh on me) i'm sending this e-mail as a result of that install. thanks again Jesse and Manuel. eah From karsten at redhat.com Mon Jun 18 13:09:48 2007 From: karsten at redhat.com (Karsten Hopp) Date: Mon, 18 Jun 2007 15:09:48 +0200 Subject: Root filesystem encryption update In-Reply-To: References: Message-ID: <4676841C.6080103@redhat.com> Thomas Swan schrieb: > Here's another go. > > This patch applies to the current mkinitrd SRPM set (except the > mkinitrd.spec file) and the patched mkinitrd package is available via > yum at < http://www.cygnetech.com/linux/repos/> > > I incorporated the feedback I have received and have changed the patches > to use options stored in /etc/sysconfig/mkinitrd. > > I have one option in development that will let you boot and reference > the root filesystem by UUID, but it's not finished yet. The current > developmental UUID hack relies on bash and find included in the initrd > image, but I want a static binary or cryptsetup patch. > > I'm also exploring creating some screens for anaconda, but that's a > steep learning curve. > > Should encryption be an option on the disk partition option or an option > to pick the type of installation right after the greeting? > UUID support needs a patch in e2fsprogs which I've submitted upstream for review some time ago. This makes bash hacks obsolete. My system is running with UUIDs only in fstab and crypttab, there are no hardcoded device names required anymore. Please note that I've achieved this with the mkinitrd patch available in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 , but I'll take a look at your patch as well. There's also a wiki page about encryption at http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems Regards Karsten -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From dtimms at iinet.net.au Mon Jun 18 13:42:34 2007 From: dtimms at iinet.net.au (David Timms) Date: Mon, 18 Jun 2007 23:42:34 +1000 Subject: wiki account v fedora account system Message-ID: <46768BCA.6010003@iinet.net.au> Hi, I'm sure this has been asked before but it isn't showing up in a search: I organised the CLA and wiki sign up last year, and also have a bugzilla account. Does these accounts move to the new fedora account system, or do I need to do the whole process as described in: http://fedoraproject.org/wiki/Infrastructure/AccountSystem if I want to be able contribute to more than the wiki ? DaveT. From mclasen at redhat.com Mon Jun 18 13:40:29 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 18 Jun 2007 09:40:29 -0400 Subject: rawhide report: 20070618 changes In-Reply-To: <46767517.8040603@ioa.s.u-tokyo.ac.jp> References: <200706181025.l5IAPIVr001653@porkchop.devel.redhat.com> <46767517.8040603@ioa.s.u-tokyo.ac.jp> Message-ID: <1182174029.3533.0.camel@dhcp83-186.boston.redhat.com> On Mon, 2007-06-18 at 21:05 +0900, Mamoru Tasaka wrote: > Build System wrote, at 06/18/2007 07:25 PM +9:00: > > gnome-session-2.19.4-1.fc8 > > -------------------------- > > * Sun Jun 17 2007 Matthias Clasen - 2.19.4-1 > > - Update to 2.19.4 > > For me, this gnome-session causes hang up on login. > 2.19.3 seems no problem. Works fine here. Can you find out where it hangs ? From notting at redhat.com Mon Jun 18 04:06:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Jun 2007 00:06:10 -0400 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <4674E567.4060404@fedoraproject.org> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <1182014242.2309.7.camel@work> <4674969F.7040208@fedoraproject.org> <1182068883.2324.3.camel@work> <4674E567.4060404@fedoraproject.org> Message-ID: <20070618040610.GB6186@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Really? I would guess it would be more than that. We include more than > one method for doing this including dm-crypt and encfs. Don't forget ecryptfs. Bill From jdieter at gmail.com Mon Jun 18 14:31:51 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 18 Jun 2007 17:31:51 +0300 Subject: Official presto repositories for Rawhide Message-ID: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> I would like to request the creation of presto repositories for Rawhide. I believe the yum-presto plugin has moved into (at the very least) a late beta when it comes to stability, and Jeremy Katz has done some great work in making deltarpm deal with multiarch correctly. The presto repository creation tools probably need to be looked over, but I think it's time to start creating "official" deltarpms if we're going to make it into F8. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jun 18 14:33:04 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 18 Jun 2007 23:33:04 +0900 Subject: rawhide report: 20070618 changes In-Reply-To: <1182174029.3533.0.camel@dhcp83-186.boston.redhat.com> References: <200706181025.l5IAPIVr001653@porkchop.devel.redhat.com> <46767517.8040603@ioa.s.u-tokyo.ac.jp> <1182174029.3533.0.camel@dhcp83-186.boston.redhat.com> Message-ID: <467697A0.3030206@ioa.s.u-tokyo.ac.jp> Matthias Clasen wrote, at 06/18/2007 10:40 PM +9:00: > On Mon, 2007-06-18 at 21:05 +0900, Mamoru Tasaka wrote: >> Build System wrote, at 06/18/2007 07:25 PM +9:00: >>> gnome-session-2.19.4-1.fc8 >>> -------------------------- >>> * Sun Jun 17 2007 Matthias Clasen - 2.19.4-1 >>> - Update to 2.19.4 >> For me, this gnome-session causes hang up on login. >> 2.19.3 seems no problem. > > Works fine here. Can you find out where it hangs ? Currently no idea. After login, the screen is just black and no progress from there. Maybe I should file on bugzilla and discuss there? Mamoru From jkeating at redhat.com Mon Jun 18 14:34:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 Jun 2007 10:34:31 -0400 Subject: Official presto repositories for Rawhide In-Reply-To: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: <200706181034.31361.jkeating@redhat.com> On Monday 18 June 2007 10:31:51 Jonathan Dieter wrote: > I would like to request the creation of presto repositories for Rawhide. > I believe the yum-presto plugin has moved into (at the very least) a > late beta when it comes to stability, and Jeremy Katz has done some > great work in making deltarpm deal with multiarch correctly. > > The presto repository creation tools probably need to be looked over, > but I think it's time to start creating "official" deltarpms if we're > going to make it into F8. Is there a usable tool for creating presto repos yet? Something to automate? What is the impact on mirrors? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Jun 18 14:48:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 18 Jun 2007 20:18:48 +0530 Subject: F8devel - Review HAL policy about hiding partitions In-Reply-To: <20070618040610.GB6186@nostromo.devel.redhat.com> References: <694505.63542.qm@web52401.mail.re2.yahoo.com> <1182014242.2309.7.camel@work> <4674969F.7040208@fedoraproject.org> <1182068883.2324.3.camel@work> <4674E567.4060404@fedoraproject.org> <20070618040610.GB6186@nostromo.devel.redhat.com> Message-ID: <46769B50.9000700@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> Really? I would guess it would be more than that. We include more than >> one method for doing this including dm-crypt and encfs. > > Don't forget ecryptfs. I haven't but unfortunately it has been struck in review. Rahul From thomas.swan at gmail.com Mon Jun 18 14:53:55 2007 From: thomas.swan at gmail.com (Thomas Swan) Date: Mon, 18 Jun 2007 09:53:55 -0500 Subject: Root filesystem encryption update In-Reply-To: <4676841C.6080103@redhat.com> References: <4676841C.6080103@redhat.com> Message-ID: The UUID works fine without bash for unencrypted ext3 partitions. The UUID hack I am talking about is for finding which device to decrypt based on the UUID of the LUKS partition. On 6/18/07, Karsten Hopp wrote: > > Thomas Swan schrieb: > > Here's another go. > > > > This patch applies to the current mkinitrd SRPM set (except the > > mkinitrd.spec file) and the patched mkinitrd package is available via > > yum at < http://www.cygnetech.com/linux/repos/> > > > > I incorporated the feedback I have received and have changed the patches > > to use options stored in /etc/sysconfig/mkinitrd. > > > > I have one option in development that will let you boot and reference > > the root filesystem by UUID, but it's not finished yet. The current > > developmental UUID hack relies on bash and find included in the initrd > > image, but I want a static binary or cryptsetup patch. > > > > I'm also exploring creating some screens for anaconda, but that's a > > steep learning curve. > > > > Should encryption be an option on the disk partition option or an option > > to pick the type of installation right after the greeting? > > > > > UUID support needs a patch in e2fsprogs which I've submitted upstream for > review some time ago. This makes bash hacks obsolete. My system is running > with UUIDs only in fstab and crypttab, there are no hardcoded device names > required anymore. > Please note that I've achieved this with the mkinitrd patch available in > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 , but I'll > take > a look at your patch as well. > There's also a wiki page about encryption at > http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems > > Regards > > Karsten > > > -- > Karsten Hopp | Mail: karsten at redhat.de > Red Hat Deutschland | Tel: +49-711-96437-0 > Hauptstaetterstr.58 | Fax: +49-711-613590 > D-70178 Stuttgart | http://www.redhat.de > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- The early bird may get the worm, but the it's the second mouse that gets the cheese. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajackson at redhat.com Mon Jun 18 14:55:15 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 18 Jun 2007 10:55:15 -0400 Subject: rawhide report: 20070616 changes In-Reply-To: References: <200706161019.l5GAJYrC012172@porkchop.devel.redhat.com> Message-ID: <1182178515.30663.163.camel@localhost.localdomain> On Sat, 2007-06-16 at 17:02 +0000, Peter Lemenkov wrote: > Build System redhat.com> writes: > > > fedora-logos-6.0.98-4.fc8 > > ------------------------- > > * Fri Jun 15 2007 Adam Jackson redhat.com> 6.0.98-4 > > - Remove the Requires on redhat-artwork and fedora-icon-theme, and just > > multi-own the directories. Fixes some hilarious dependency chains. > > O yeah! > I've been waiting this for a long time. If you didn't catch the discussion of this elsewhere: This is entirely likely to break respin tools if they were relying on these Requires. Please report any breakages. - ajax From jdieter at gmail.com Mon Jun 18 15:04:19 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 18 Jun 2007 18:04:19 +0300 Subject: Official presto repositories for Rawhide In-Reply-To: <200706181034.31361.jkeating@redhat.com> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <200706181034.31361.jkeating@redhat.com> Message-ID: <1182179059.4303.22.camel@jndwidescreen.lesbg.loc> On Mon, 2007-06-18 at 10:34 -0400, Jesse Keating wrote: > Is there a usable tool for creating presto repos yet? Something to automate? > What is the impact on mirrors? Yes there is. See http://www.lesbg.com/jdieter/presto/createprestorepo-0.1.0.tar.bz2 . To summarize, there are two binaries to run: makedeltarepo to generate the deltarpms and then createprestorepo to generate the metadata. The tools probably need a bit of tweaking and I'm happy to do it if I'm told what to tweak. The only impact on mirrors is having to store more data (the deltarpms), though they should see less bandwidth used (as people download the deltas rather than the full rpms). We can also choose how much space to dedicate to the deltarpms by limiting how far back we make new deltas for. On the test server (before our web hosting provider wiped all the rpms and deltarpms), I think we went up to 1 GB for FC6 i386 updates +extras and that was making deltarpms for *all* intermediate rpms. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Mon Jun 18 15:12:03 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 18 Jun 2007 10:12:03 -0500 Subject: Root filesystem encryption update In-Reply-To: References: Message-ID: <20070618151203.GA3999@wolff.to> On Mon, Jun 18, 2007 at 03:11:15 -0500, Thomas Swan wrote: > > Should encryption be an option on the disk partition option or an option to > pick the type of installation right after the greeting? I think people are normally going to want the encrption run right below the file systems (as opposed to say between software raid and the real device). So it seems that encryption could be a checkbox on the same page where you pick file system type. You could also do some checks to make sure /boot isn't encrypted (until grub handles it) and / isn't encrypted unless there is a separate /boot partition. From d.lesca at solinos.it Mon Jun 18 15:12:58 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Mon, 18 Jun 2007 17:12:58 +0200 Subject: F7: acpi question Message-ID: <1182179578.4234.21.camel@lesca.home.solinos.it> Hi, why in F7 acpid-*.rpm it has been removed from DVD setup? It has been replaced with some other package? How to I can do some action, when a ACPI event is generated? Many thanks for your reply. -- Dario Lesca From obi at unixkiste.org Mon Jun 18 15:18:05 2007 From: obi at unixkiste.org (Stefan Held) Date: Mon, 18 Jun 2007 17:18:05 +0200 Subject: rawhide report: 20070616 changes In-Reply-To: <1182178515.30663.163.camel@localhost.localdomain> References: <200706161019.l5GAJYrC012172@porkchop.devel.redhat.com> <1182178515.30663.163.camel@localhost.localdomain> Message-ID: <1182179885.4124.8.camel@workstation.unixkiste.local> Am Montag, den 18.06.2007, 10:55 -0400 schrieb Adam Jackson: > If you didn't catch the discussion of this elsewhere: > > This is entirely likely to break respin tools if they were relying on > these Requires. Please report any breakages. Please don't get me wrong. Instead of fixing this garbage at the right place (legal) we have to make a technical second or more worse, third place solution? > - ajax You said you are trying to make a respin, did you? Did it work? What has happend? I never saw you complaining it does break anything actually. Only it could. I still think it would be way better to have an even non official grub-boot-gfx without any fedora logo (even an Fedora Blue Background would fit) in it than this solution. -- Stefan Held VI has only 2 Modes: obi unixkiste org The first one is for beeping all the time, FreeNode: foo_bar the second destroys the text. --------------------------------------------------------------------------- Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- GPG-Keyprint = 75C0 F029 CA71 F061 6C07 0640 38F7 E5F9 4EA5 A385 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From karsten at redhat.com Mon Jun 18 15:34:16 2007 From: karsten at redhat.com (Karsten Hopp) Date: Mon, 18 Jun 2007 17:34:16 +0200 Subject: Root filesystem encryption update In-Reply-To: References: <4676841C.6080103@redhat.com> Message-ID: <4676A5F8.3000801@redhat.com> Thomas Swan schrieb: > The UUID works fine without bash for unencrypted ext3 partitions. The > UUID hack I am talking about is for finding which device to decrypt > based on the UUID of the LUKS partition. > Right, and I'm talking about LUKS UUIDs. Neither nash nor blkid know about those atm. and this makes it difficult to find the partition with the right LUKS UUID. My patch adds probing for LUKS encrypted partitions to libblkid and nash can use that to find the correct partition as it already does with normal (non-LUKS) partitions. Karsten -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From hughsient at gmail.com Mon Jun 18 15:43:12 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 18 Jun 2007 16:43:12 +0100 Subject: F7: acpi question In-Reply-To: <1182179578.4234.21.camel@lesca.home.solinos.it> References: <1182179578.4234.21.camel@lesca.home.solinos.it> Message-ID: <1182181392.2493.36.camel@work> On Mon, 2007-06-18 at 17:12 +0200, Dario Lesca wrote: > Hi, why in F7 acpid-*.rpm it has been removed from DVD setup? You've got two options; * yum install acpid * Use gnome-power-manager or kpowersaved Richard. From rdieter at math.unl.edu Mon Jun 18 14:56:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Jun 2007 09:56:55 -0500 Subject: Official presto repositories for Rawhide References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: Jonathan Dieter wrote: > I would like to request the creation of presto repositories for Rawhide. ... > The presto repository creation tools probably need to be looked over, > but I think it's time to start creating "official" deltarpms if we're > going to make it into F8. Prereq: presto repository creation tools need to be submitted for review, and imported into Fedora. -- Rex From tmraz at redhat.com Mon Jun 18 16:10:10 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 18 Jun 2007 18:10:10 +0200 Subject: Automating pam_keyring... In-Reply-To: <604aa7910706151446v40d29ef1m112ae195c3451508@mail.gmail.com> References: <46730322.6020400@poolshark.org> <604aa7910706151446v40d29ef1m112ae195c3451508@mail.gmail.com> Message-ID: <1182183010.3266.14.camel@perun.kabelta.loc> On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote: > On 6/15/07, Denis Leroy wrote: > > Should it use a scriptlet that modifies /etc/pam.d/gdm in > > %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). > > It should just work for default desktop installs moving forward. I > frankly don't care how. > > > Or add a patch to the gdm package and make it require pam_keyring ? > > uhm should avoid making this a hard requirement for gdm. Can pam deal > with a scenario > where pam_keyring is referenced as an optional rule in the auth stack > but the pam_keyring module is not actually installed? And don't we at > least have to also consider this being used in the pam stack for kdm, > since kdm can start a gnome desktop session? Pam deals with it fine (allows login for nonexistent 'optional' modules), but it will issue a nasty warning in syslog. I think that editing gdm config within a %post script is fine. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From 1 at 234.cx Mon Jun 18 15:03:22 2007 From: 1 at 234.cx (Pete Chown) Date: Mon, 18 Jun 2007 15:03:22 +0000 (UTC) Subject: The updates firehose References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> Message-ID: Christopher Blizzard wrote: > Are people complaining? Are we actually breaking stuff in the process? Since you particularly asked, I will say that the volume of updates is a problem for me. (Normally I don't believe in complaining about volunteer efforts, so I would have kept quiet.) You asked if you were breaking stuff in the process. This morning I was hit by this problem, which appears to result from the PAM update: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244534 Although actually downgrading the PAM package is easy, it did take a certain amount of time. I had to work out what was going on, check that downgrading wouldn't leave my system vulnerable, and so on. I also eventually gave up trying to use a Wacom tablet with Fedora. Most times a kernel update came out, the tablet would fail, always in a slightly different way. It could generally be made to work again, but eventually I felt it was taking too much time, and went back to a normal PS/2 mouse. > Are you upset with the amount of bandwith we're eating or just based on > principal? Actually the raw bandwidth isn't the important thing for me. The frustration comes from updates that don't work properly, forcing me to spend time debugging a system that was previously working. The perfect solution, IMHO, would be two separate update streams. There would be a "recommended updates" stream for security patches and fixes for major bugs. Then there would be an "optional updates" stream for minor bugs, new upstream versions, that sort of thing. Then I could install all the recommended updates, but I could leave the optional updates unless I particularly needed the improved functionality. It might be that the "recommended updates" are almost identical to the RHEL fixes, since they would have the same goal. Pete From jdieter at gmail.com Mon Jun 18 16:14:50 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 18 Jun 2007 19:14:50 +0300 Subject: Official presto repositories for Rawhide In-Reply-To: References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: <1182183290.4303.27.camel@jndwidescreen.lesbg.loc> On Mon, 2007-06-18 at 09:56 -0500, Rex Dieter wrote: > Jonathan Dieter wrote: > > > I would like to request the creation of presto repositories for Rawhide. > ... > > The presto repository creation tools probably need to be looked over, > > but I think it's time to start creating "official" deltarpms if we're > > going to make it into F8. > > Prereq: presto repository creation tools need to be submitted for review, > and imported into Fedora. Okay, let me see what I can get done tomorrow at work. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon Jun 18 16:52:39 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 12:52:39 -0400 Subject: Automating pam_keyring... In-Reply-To: <1182183010.3266.14.camel@perun.kabelta.loc> References: <46730322.6020400@poolshark.org> <604aa7910706151446v40d29ef1m112ae195c3451508@mail.gmail.com> <1182183010.3266.14.camel@perun.kabelta.loc> Message-ID: <1182185559.4576.1.camel@aglarond.local> On Mon, 2007-06-18 at 18:10 +0200, Tomas Mraz wrote: > On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote: > > On 6/15/07, Denis Leroy wrote: > > > Should it use a scriptlet that modifies /etc/pam.d/gdm in > > > %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). > > > > It should just work for default desktop installs moving forward. I > > frankly don't care how. > > > > > Or add a patch to the gdm package and make it require pam_keyring ? > > > > uhm should avoid making this a hard requirement for gdm. Can pam deal > > with a scenario > > where pam_keyring is referenced as an optional rule in the auth stack > > but the pam_keyring module is not actually installed? And don't we at > > least have to also consider this being used in the pam stack for kdm, > > since kdm can start a gnome desktop session? > Pam deals with it fine (allows login for nonexistent 'optional' > modules), but it will issue a nasty warning in syslog. I think that > editing gdm config within a %post script is fine. Editing pam configs in package scriptlets strikes me as a really bad idea... it's not something that's ever been done and so a lot of people are going to get very surprised by it. Especially if they've customized their configs at all. And doing it once is going to set the precedent for it to be done more... Jeremy From katzj at redhat.com Mon Jun 18 16:55:31 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 12:55:31 -0400 Subject: Root filesystem encryption update In-Reply-To: <20070618151203.GA3999@wolff.to> References: <20070618151203.GA3999@wolff.to> Message-ID: <1182185731.4576.4.camel@aglarond.local> On Mon, 2007-06-18 at 10:12 -0500, Bruno Wolff III wrote: > On Mon, Jun 18, 2007 at 03:11:15 -0500, > Thomas Swan wrote: > > > > Should encryption be an option on the disk partition option or an option to > > pick the type of installation right after the greeting? > > I think people are normally going to want the encrption run right below > the file systems (as opposed to say between software raid and the real > device). So it seems that encryption could be a checkbox on the same > page where you pick file system type. You could also do some checks to > make sure /boot isn't encrypted (until grub handles it) and / isn't encrypted > unless there is a separate /boot partition. Is this where I chime in with something about keymaps and locales again? I'm thinking probably so... ;-) Jeremy From skvidal at linux.duke.edu Mon Jun 18 17:20:00 2007 From: skvidal at linux.duke.edu (Seth Vidal) Date: Mon, 18 Jun 2007 13:20:00 -0400 (EDT) Subject: Automating pam_keyring... In-Reply-To: <1182185559.4576.1.camel@aglarond.local> References: <46730322.6020400@poolshark.org> <604aa7910706151446v40d29ef1m112ae195c3451508@mail.gmail.com> <1182183010.3266.14.camel@perun.kabelta.loc> <1182185559.4576.1.camel@aglarond.local> Message-ID: On Mon, 18 Jun 2007, Jeremy Katz wrote: > > Editing pam configs in package scriptlets strikes me as a really bad > idea... it's not something that's ever been done and so a lot of people > are going to get very surprised by it. Especially if they've customized > their configs at all. And doing it once is going to set the precedent > for it to be done more... > +1. I always add pam_access to pam configs in my %post of kickstarts and I'd not want that mucked with. -sv From adrian at lisas.de Mon Jun 18 17:53:22 2007 From: adrian at lisas.de (Adrian Reber) Date: Mon, 18 Jun 2007 19:53:22 +0200 Subject: Official presto repositories for Rawhide In-Reply-To: <200706181034.31361.jkeating@redhat.com> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <200706181034.31361.jkeating@redhat.com> Message-ID: <20070618175322.GA6436@lisas.de> On Mon, Jun 18, 2007 at 10:34:31AM -0400, Jesse Keating wrote: > On Monday 18 June 2007 10:31:51 Jonathan Dieter wrote: > > I would like to request the creation of presto repositories for Rawhide. > > I believe the yum-presto plugin has moved into (at the very least) a > > late beta when it comes to stability, and Jeremy Katz has done some > > great work in making deltarpm deal with multiarch correctly. > > > > The presto repository creation tools probably need to be looked over, > > but I think it's time to start creating "official" deltarpms if we're > > going to make it into F8. > > Is there a usable tool for creating presto repos yet? Something to automate? > What is the impact on mirrors? As a mirror admin I can say that I disabled all the deltarpms on the opensuse tree on our mirror server because it contained thousands of small files. I am not 100% sure that presto deltarpms are the same suse uses but from a standpoint of our mirror server it is horrible to have all of sudden thousands of small files instead the big one we used to have. Adrian From david at lovesunix.net Mon Jun 18 18:11:52 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 18 Jun 2007 20:11:52 +0200 Subject: user created at install added in sudoers ? In-Reply-To: <4673037B.3030105@laposte.net> References: <4673037B.3030105@laposte.net> Message-ID: <1182190312.2893.5.camel@dawkins> fre, 15 06 2007 kl. 23:24 +0200, skrev Axel: > What do you think about adding the user created at install to the > sudoers list ? > > For newbies like me, understanding the sudoers file isn't so easy, but > nevertheless they may need the sudo command. In my case, I'd rather my > account would have been added automatically to the sudoers list :) Why do you need sudo, I mean what does it add that a correctly seperated privilaged user doesn't? - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From denis at poolshark.org Mon Jun 18 18:26:57 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 18 Jun 2007 20:26:57 +0200 Subject: Automating pam_keyring... In-Reply-To: <1182185559.4576.1.camel@aglarond.local> References: <46730322.6020400@poolshark.org> <604aa7910706151446v40d29ef1m112ae195c3451508@mail.gmail.com> <1182183010.3266.14.camel@perun.kabelta.loc> <1182185559.4576.1.camel@aglarond.local> Message-ID: <4676CE71.7090103@poolshark.org> Jeremy Katz wrote: > On Mon, 2007-06-18 at 18:10 +0200, Tomas Mraz wrote: >> On Fri, 2007-06-15 at 13:46 -0800, Jeff Spaleta wrote: >>> On 6/15/07, Denis Leroy wrote: >>>> Should it use a scriptlet that modifies /etc/pam.d/gdm in >>>> %post (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232857 ). >>> It should just work for default desktop installs moving forward. I >>> frankly don't care how. >>> >>>> Or add a patch to the gdm package and make it require pam_keyring ? >>> uhm should avoid making this a hard requirement for gdm. Can pam deal >>> with a scenario >>> where pam_keyring is referenced as an optional rule in the auth stack >>> but the pam_keyring module is not actually installed? And don't we at >>> least have to also consider this being used in the pam stack for kdm, >>> since kdm can start a gnome desktop session? >> Pam deals with it fine (allows login for nonexistent 'optional' >> modules), but it will issue a nasty warning in syslog. I think that >> editing gdm config within a %post script is fine. > > Editing pam configs in package scriptlets strikes me as a really bad > idea... it's not something that's ever been done and so a lot of people > are going to get very surprised by it. Especially if they've customized > their configs at all. And doing it once is going to set the precedent > for it to be done more... I tend to agree, but what's the alternative ? From sundaram at fedoraproject.org Mon Jun 18 18:45:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 00:15:07 +0530 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> Message-ID: <4676D2B3.7090005@fedoraproject.org> Pete Chown wrote: > > The perfect solution, IMHO, would be two separate update streams. There > would be a "recommended updates" stream for security patches and fixes > for major bugs. Then there would be an "optional updates" stream for > minor bugs, new upstream versions, that sort of thing. Then I could > install all the recommended updates, but I could leave the optional > updates unless I particularly needed the improved functionality. Wouldn't the ability to filter updates based on classifications (security, bug fixes, enhancements etc) provide what you want instead of separate update streams? yum security plugin provides some of that already and extending it is what is planned afaik. Rahul From notting at redhat.com Mon Jun 18 18:47:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Jun 2007 14:47:20 -0400 Subject: Automating pam_keyring... In-Reply-To: <4676CE71.7090103@poolshark.org> References: <46730322.6020400@poolshark.org> <604aa7910706151446v40d29ef1m112ae195c3451508@mail.gmail.com> <1182183010.3266.14.camel@perun.kabelta.loc> <1182185559.4576.1.camel@aglarond.local> <4676CE71.7090103@poolshark.org> Message-ID: <20070618184720.GA16470@nostromo.devel.redhat.com> Denis Leroy (denis at poolshark.org) said: > >Editing pam configs in package scriptlets strikes me as a really bad > >idea... it's not something that's ever been done and so a lot of people > >are going to get very surprised by it. Especially if they've customized > >their configs at all. And doing it once is going to set the precedent > >for it to be done more... > > I tend to agree, but what's the alternative ? Add support in authconfig, set it up by default but require existing users to run authconfig once? Bill From bruno at wolff.to Mon Jun 18 19:07:33 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 18 Jun 2007 14:07:33 -0500 Subject: Root filesystem encryption update In-Reply-To: <1182185731.4576.4.camel@aglarond.local> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> Message-ID: <20070618190733.GA31493@wolff.to> On Mon, Jun 18, 2007 at 12:55:31 -0400, Jeremy Katz wrote: > > Is this where I chime in with something about keymaps and locales again? > I'm thinking probably so... ;-) That is certainly a problem. But for some people running encryption through a block device that respects things such as write barriers, is going to be more attractive than some of the other solutions. Heck, for key maps there probably aren't so many that you can't try multiple possibilities after getting the password. The password prompts being in the wrong locale, might look ugly, but should be servicable. People using the grub menu have to deal with that now as far as I know. From vonbrand at inf.utfsm.cl Mon Jun 18 19:14:13 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 18 Jun 2007 15:14:13 -0400 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> Message-ID: <200706181914.l5IJEDU1004851@laptop13.inf.utfsm.cl> Pete Chown <1 at 234.cx> wrote: [...] > The perfect solution, IMHO, would be two separate update streams. There > would be a "recommended updates" stream for security patches and fixes > for major bugs. Then there would be an "optional updates" stream for > minor bugs, new upstream versions, that sort of thing. Then I could > install all the recommended updates, but I could leave the optional > updates unless I particularly needed the improved functionality. The resulting divergence will lead to *two* Fedoras, the "stable branch" and the "aggressive updates branch". Most users will stay on the first one, and complain that they don't get all the shiny, new toys that are in the second one; most developers will track the second branch and let the first one fall into disrepair. Been there, done that (look for the extensive discussion and rationale for the "new kernel development model" if you want to see this in action and the grief it gives). And allowing people to mix and match gives an even worse quagmire of "Fedora X, with just /this/ mix of stable/agressive". Better (try to) make sure that procedures in place give no problems when updating. We clearly aren't there yet. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From fedora at camperquake.de Mon Jun 18 19:58:01 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 18 Jun 2007 21:58:01 +0200 Subject: Root filesystem encryption update In-Reply-To: <20070618190733.GA31493@wolff.to> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> Message-ID: <20070618215801.46239c06@lain.camperquake.de> Hi. On Mon, 18 Jun 2007 14:07:33 -0500, Bruno Wolff III wrote > Heck, for key maps there probably aren't so many that you can't try > multiple possibilities after getting the password. The password > prompts being in the wrong locale, might look ugly, but should be > servicable. People using the grub menu have to deal with that now as > far as I know. Well, dmctypt for example does not validate your password. It just uses it to decrypt the block device. If the password was wrong, well, you'll get junk. For the record, I use dmcrypt, but not on the root partition. From snecklifter at gmail.com Mon Jun 18 20:05:27 2007 From: snecklifter at gmail.com (Chris Brown) Date: Mon, 18 Jun 2007 21:05:27 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <1182190312.2893.5.camel@dawkins> References: <4673037B.3030105@laposte.net> <1182190312.2893.5.camel@dawkins> Message-ID: <364d303b0706181305t4d8109a6xe935451785cb9a09@mail.gmail.com> On 18/06/07, David Nielsen wrote: > > fre, 15 06 2007 kl. 23:24 +0200, skrev Axel: > > What do you think about adding the user created at install to the > > sudoers list ? > > > > For newbies like me, understanding the sudoers file isn't so easy, but > > nevertheless they may need the sudo command. In my case, I'd rather my > > account would have been added automatically to the sudoers list :) > > Why do you need sudo, I mean what does it add that a correctly seperated > privilaged user doesn't? > For me, the ability to automatically lose root priv's after a specified period of time when I forget to drop out of root and have walked away from my machine. :) I imagine/hope there are better reasons but for me it is this. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Mon Jun 18 20:35:25 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 18 Jun 2007 15:35:25 -0500 Subject: Root filesystem encryption update In-Reply-To: <20070618215801.46239c06@lain.camperquake.de> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <20070618215801.46239c06@lain.camperquake.de> Message-ID: <20070618203525.GA28083@wolff.to> On Mon, Jun 18, 2007 at 21:58:01 +0200, Ralf Ertzinger wrote: > > Well, dmctypt for example does not validate your password. It just uses > it to decrypt the block device. If the password was wrong, well, you'll > get junk. And it will be pretty easy to tell that there is a file system header where one is expected. So the process doing the mounting could try passwords under the assumptions of using an alternate keymaps in what would probably be a reasonable amount of time. LUKS does some stuff to slow down password guessing, but as long as there aren't too many keymaps to test, this shouldn't be a problem. From katzj at redhat.com Mon Jun 18 20:51:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 16:51:55 -0400 Subject: Root filesystem encryption update In-Reply-To: <20070618190733.GA31493@wolff.to> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> Message-ID: <1182199915.16956.38.camel@erebor.boston.redhat.com> On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote: > On Mon, Jun 18, 2007 at 12:55:31 -0400, > Jeremy Katz wrote: > > Is this where I chime in with something about keymaps and locales again? > > I'm thinking probably so... ;-) > > That is certainly a problem. But for some people running encryption through > a block device that respects things such as write barriers, is going to be > more attractive than some of the other solutions. As an English speaker, sure. What if you only speak Japanese? If we're only solving the problem for those that speak English, then (and apologies for shouting...) WE'RE NOT SOLVING THE PROBLEM. People use Fedora world-wide and we need to actually have our features work within that context. > Heck, for key maps there probably aren't so many that you can't try multiple > possibilities after getting the password. There are at least 30-40 that we allow in the installer alone at the console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140. I don't think that trying either is really that practical. > The password prompts being in the > wrong locale, might look ugly, but should be servicable. Not for use within some countries... that's why translations are a big deal > People using the > grub menu have to deal with that now as far as I know. The goal is that you never _see_ the grub menu. Also, one of the things that's being worked on with grub2 is the infrastructure to have some support for i18n/l10n. We really shouldn't be adding new things that don't take it into account. Especially if they're going to be highly visible new features. Jeremy From Lam at Lam.pl Mon Jun 18 20:52:30 2007 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 18 Jun 2007 22:52:30 +0200 Subject: Official presto repositories for Rawhide In-Reply-To: <20070618175322.GA6436@lisas.de> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <200706181034.31361.jkeating@redhat.com> <20070618175322.GA6436@lisas.de> Message-ID: <1182199950.6648.5.camel@pensja.lam.pl> Dnia 18-06-2007, pon o godzinie 19:53 +0200, Adrian Reber napisa?(a): > As a mirror admin I can say that I disabled all the deltarpms on the > opensuse tree on our mirror server because it contained thousands of > small files. Hundreds, maybe. What's wrong with that? Do you have that limited inode space? Fedora (since FC3 IIRC) by default gives you indexed directories on ext3, so big dirs are not a problem anymore, right? > from a standpoint of our mirror server it is horrible to have all of > sudden thousands of small files instead the big one we used to have. Updates are not one big file, it's a collection of packages. Deltas would bring 3 times as much files (full rpm, delta from GA, delta from previous version), but can save your bandwidth by a factor of 10. Isn't it worth few wasted inodes? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From bruno at wolff.to Mon Jun 18 21:50:35 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 18 Jun 2007 16:50:35 -0500 Subject: Root filesystem encryption update In-Reply-To: <1182199915.16956.38.camel@erebor.boston.redhat.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> Message-ID: <20070618215035.GA11450@wolff.to> On Mon, Jun 18, 2007 at 16:51:55 -0400, Jeremy Katz wrote: > On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote: > > On Mon, Jun 18, 2007 at 12:55:31 -0400, > > Jeremy Katz wrote: > > > Is this where I chime in with something about keymaps and locales again? > > > I'm thinking probably so... ;-) > > > > That is certainly a problem. But for some people running encryption through > > a block device that respects things such as write barriers, is going to be > > more attractive than some of the other solutions. > > As an English speaker, sure. What if you only speak Japanese? If we're > only solving the problem for those that speak English, then (and > apologies for shouting...) WE'RE NOT SOLVING THE PROBLEM. People use > Fedora world-wide and we need to actually have our features work within > that context. I would see a pause with some strange prompt and figure it is waiting for me to enter something and that it must be my password. I think waiting for a complete solution is not the way to proceed. There are several different steps involved with the solution. If some of the steps have workable solutions, getting them included in the distribution will help get them tested and allow other people to build upon the previous work. It might be hard to recruit people to do some of the things that will be eventually needed until there is some base functionallity for them to play with. You don't have to advertise full disk encryption for the masses as soon as there is some support for booting with an encrypted root partition. > > Heck, for key maps there probably aren't so many that you can't try multiple > > possibilities after getting the password. > > There are at least 30-40 that we allow in the installer alone at the > console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140. > I don't think that trying either is really that practical. 40 probably isn't too many to make trying them all impractical. I expect that it will take less than a second to try each one even with measures to slow down password guessing. That's not nice for suspend resume, but wouldn't be a deal breaker for initial boots. > > > The password prompts being in the > > wrong locale, might look ugly, but should be servicable. > > Not for use within some countries... that's why translations are a big > deal > > > People using the > > grub menu have to deal with that now as far as I know. > > The goal is that you never _see_ the grub menu. Also, one of the things > that's being worked on with grub2 is the infrastructure to have some > support for i18n/l10n. We really shouldn't be adding new things that > don't take it into account. Especially if they're going to be highly > visible new features. We should be able to use some of the ideas that get used in grub2. They are going to have to solve essentially the same problem (fonts and keymaps without the bloat of X). Some people are going to want to see the grub menu, so eventually you are going to want to have some sort of localization solution there. From jkeating at redhat.com Mon Jun 18 21:59:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 Jun 2007 17:59:15 -0400 Subject: Root filesystem encryption update In-Reply-To: <20070618215035.GA11450@wolff.to> References: <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> Message-ID: <200706181759.19712.jkeating@redhat.com> On Monday 18 June 2007 17:50:35 Bruno Wolff III wrote: > I would see a pause with some strange prompt and figure it is waiting for > me to enter something and that it must be my password. Ugh, I don't think I'd want to blindly enter my password into a prompt I can't understand / validate. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Jun 18 22:05:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 18:05:35 -0400 Subject: Root filesystem encryption update In-Reply-To: <20070618215035.GA11450@wolff.to> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> Message-ID: <1182204335.16956.55.camel@erebor.boston.redhat.com> On Mon, 2007-06-18 at 16:50 -0500, Bruno Wolff III wrote: > On Mon, Jun 18, 2007 at 16:51:55 -0400, > Jeremy Katz wrote: > > On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote: > > > On Mon, Jun 18, 2007 at 12:55:31 -0400, > > > Jeremy Katz wrote: > > > > Is this where I chime in with something about keymaps and locales again? > > > > I'm thinking probably so... ;-) > > > > > > That is certainly a problem. But for some people running encryption through > > > a block device that respects things such as write barriers, is going to be > > > more attractive than some of the other solutions. > > > > As an English speaker, sure. What if you only speak Japanese? If we're > > only solving the problem for those that speak English, then (and > > apologies for shouting...) WE'RE NOT SOLVING THE PROBLEM. People use > > Fedora world-wide and we need to actually have our features work within > > that context. > > I would see a pause with some strange prompt and figure it is waiting for > me to enter something and that it must be my password. And many would just think that something was broken. > I think waiting for a complete solution is not the way to proceed. There are > several different steps involved with the solution. If some of the steps > have workable solutions, getting them included in the distribution will > help get them tested and allow other people to build upon the previous work. > It might be hard to recruit people to do some of the things that will be > eventually needed until there is some base functionallity for them to play > with. > > You don't have to advertise full disk encryption for the masses as soon as > there is some support for booting with an encrypted root partition. If the idea is to actually _support_ full disk encryption in Fedora, then it has to be everywhere. In the installer. On upgrades (at least for the Fedora n+1 release :-). In the documentation. Otherwise, we're doing ourselves a great disservice by talking out of one side of our mouth saying it's supported but on the other claiming "well, maybe not so much". > > > Heck, for key maps there probably aren't so many that you can't try multiple > > > possibilities after getting the password. > > > > There are at least 30-40 that we allow in the installer alone at the > > console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140. > > I don't think that trying either is really that practical. > > 40 probably isn't too many to make trying them all impractical. I expect > that it will take less than a second to try each one even with measures > to slow down password guessing. That's not nice for suspend resume, but > wouldn't be a deal breaker for initial boots. If it takes less than a second, then that means the measures to slow down password guessing are pretty bad ;-) You want an exponential backoff that gets pretty slow pretty fast or it becomes way too easy to brute force. And even for initial boots, another of the goals for Fedora 8 is actually making things faster. Why would we make two features work directly against each other? > > > The password prompts being in the > > > wrong locale, might look ugly, but should be servicable. > > > > Not for use within some countries... that's why translations are a big > > deal > > > > > People using the > > > grub menu have to deal with that now as far as I know. > > > > The goal is that you never _see_ the grub menu. Also, one of the things > > that's being worked on with grub2 is the infrastructure to have some > > support for i18n/l10n. We really shouldn't be adding new things that > > don't take it into account. Especially if they're going to be highly > > visible new features. > > We should be able to use some of the ideas that get used in grub2. They > are going to have to solve essentially the same problem (fonts and keymaps > without the bloat of X). Similar problems, but pretty different constraints and available things to make use of. eg, in the bootloader there are real mode graphics modes as an option. Those aren't available once we're into userspace. And things that use fbcon (eg, bterm or kon) have tended to cause more problems than they've helped. Jeremy From katzj at redhat.com Mon Jun 18 22:11:47 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 18:11:47 -0400 Subject: Official presto repositories for Rawhide In-Reply-To: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: <1182204707.16956.62.camel@erebor.boston.redhat.com> On Mon, 2007-06-18 at 17:31 +0300, Jonathan Dieter wrote: > I would like to request the creation of presto repositories for Rawhide. > I believe the yum-presto plugin has moved into (at the very least) a > late beta when it comes to stability, and Jeremy Katz has done some > great work in making deltarpm deal with multiarch correctly. > > The presto repository creation tools probably need to be looked over, > but I think it's time to start creating "official" deltarpms if we're > going to make it into F8. Yeah, this is definitely something we want to start looking at. The question is where in the process does it make sense to generate the deltas. Do we do them in the build system (the koji level)? Do we do them in the update system?[1] Do we do them at tree compose (mash) time? Each has tradeoffs... not sure which is really the best. I'm pretty sure whichever route we go, we need to go with something that preserves the deltas and likely at least stores them in the koji store (with info about them in the kojidb). Perhaps similar to how signing works? At the same time, I think we should sit down and look at how presto is doing things on the yum side to simplify things a bit. I think that if we get rid of the concept of a separate standalone delta repository, we can just make it so that there's a (simpler) XML file to parse with the delta information and then just add it to the repodata with modifyrepo[2]. Then, we can also get rid of the duplication of repo code presented by the PrestoRepository class. I've been trying to get to mocking something up, but keep having other things come up and steal time instead. Hopefully tonight/tomorrow... Jeremy [1] The downside of the update system is that it then isn't being used in rawhide. Which I strongly suspect we want at least for testing, even though it sort of makes less sense there. [2] Much like is done for the updateinfo.xml From katzj at redhat.com Mon Jun 18 22:13:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 18:13:06 -0400 Subject: Official presto repositories for Rawhide In-Reply-To: <20070618175322.GA6436@lisas.de> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <200706181034.31361.jkeating@redhat.com> <20070618175322.GA6436@lisas.de> Message-ID: <1182204786.16956.65.camel@erebor.boston.redhat.com> On Mon, 2007-06-18 at 19:53 +0200, Adrian Reber wrote: > On Mon, Jun 18, 2007 at 10:34:31AM -0400, Jesse Keating wrote: > > On Monday 18 June 2007 10:31:51 Jonathan Dieter wrote: > > > I would like to request the creation of presto repositories for Rawhide. > > > I believe the yum-presto plugin has moved into (at the very least) a > > > late beta when it comes to stability, and Jeremy Katz has done some > > > great work in making deltarpm deal with multiarch correctly. > > > > > > The presto repository creation tools probably need to be looked over, > > > but I think it's time to start creating "official" deltarpms if we're > > > going to make it into F8. > > > > Is there a usable tool for creating presto repos yet? Something to automate? > > What is the impact on mirrors? > > As a mirror admin I can say that I disabled all the deltarpms on the > opensuse tree on our mirror server because it contained thousands of > small files. I am not 100% sure that presto deltarpms are the same suse uses > but from a standpoint of our mirror server it is horrible to have all of > sudden thousands of small files instead the big one we used to have. The deltas are generated the same way as they are for opensuse (using the same tools, etc). The questions are mostly around policy for how many you keep around, etc. I would be interested in understanding why the more small files caused problems for you. Jeremy From axel.azerty at laposte.net Mon Jun 18 22:06:29 2007 From: axel.azerty at laposte.net (Axel) Date: Tue, 19 Jun 2007 00:06:29 +0200 Subject: user created at install added in sudoers ? In-Reply-To: <1182190312.2893.5.camel@dawkins> References: <4673037B.3030105@laposte.net> <1182190312.2893.5.camel@dawkins> Message-ID: <467701E5.8010501@laposte.net> David Nielsen a ?crit : > > Why do you need sudo, I mean what does it add that a correctly seperated > privilaged user doesn't? > > - David Nielsen > For tasks like yum by example, just "sudo" is simplier than su, yum and then exit, and it prevents from forgetting to logout. I understand that there aren't a lot of differences, but when I tried ubuntu, I found that useful. From Axel.Thimm at ATrpms.net Mon Jun 18 22:40:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 19 Jun 2007 00:40:25 +0200 Subject: Official presto repositories for Rawhide In-Reply-To: <1182204707.16956.62.camel@erebor.boston.redhat.com> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> Message-ID: <20070618224025.GC7747@neu.nirvana> On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote: > The question is where in the process does it make sense to generate > the deltas. Do we do them in the build system (the koji level)? Do > we do them in the update system?[1] Do we do them at tree compose > (mash) time? Each has tradeoffs... not sure which is really the > best. The problme domain are the limited bandwidth of end users, so you want it to run on what end users consume. This can be different for released versions vs rawhide, but in general released versions would only perform this on updates-released (not updates-testing) and for rawhide on everything. -- 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 notting at redhat.com Mon Jun 18 22:42:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Jun 2007 18:42:22 -0400 Subject: Root filesystem encryption update In-Reply-To: <20070618215035.GA11450@wolff.to> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> Message-ID: <20070618224222.GA20375@nostromo.devel.redhat.com> Bruno Wolff III (bruno at wolff.to) said: > I think waiting for a complete solution is not the way to proceed. There are > several different steps involved with the solution. If some of the steps > have workable solutions, getting them included in the distribution will > help get them tested and allow other people to build upon the previous work. > It might be hard to recruit people to do some of the things that will be > eventually needed until there is some base functionallity for them to play > with. > > You don't have to advertise full disk encryption for the masses as soon as > there is some support for booting with an encrypted root partition. The problem is, you want to get at least the basic design more or less right. We added the cryptsetup stuff in rc.sysinit as an initial hack along these lines... and therefore got stuck with its fundamental problems that broke most users of it on F7 upgrades. Bill From n0dalus+redhat at gmail.com Tue Jun 19 00:06:28 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 19 Jun 2007 09:36:28 +0930 Subject: Root filesystem encryption update In-Reply-To: <20070618215035.GA11450@wolff.to> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> Message-ID: <6280325c0706181706j7013b7f7s4fa0af1c8bd11be3@mail.gmail.com> On 6/19/07, Bruno Wolff III wrote: > > I think waiting for a complete solution is not the way to proceed. There are > several different steps involved with the solution. If some of the steps > have workable solutions, getting them included in the distribution will > help get them tested and allow other people to build upon the previous work. > It might be hard to recruit people to do some of the things that will be > eventually needed until there is some base functionallity for them to play > with. > > You don't have to advertise full disk encryption for the masses as soon as > there is some support for booting with an encrypted root partition. > Does full disk encryption have many advantages over directory-based encryption? It seems like a lot less pain to be able to boot into X and just have important directories encrypted. One problem I see in both approaches is access control. Many computers are used by more than one person, and instead of giving everyone the one password (and having to change it whenever someone leaves the pool of trusted people), it might be better to make sure these methods use username/password combos which can be added and revoked. n0dalus. From katzj at redhat.com Tue Jun 19 01:19:19 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 21:19:19 -0400 Subject: Official presto repositories for Rawhide In-Reply-To: <20070618224025.GC7747@neu.nirvana> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> Message-ID: <1182215959.7680.6.camel@aglarond.local> On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote: > On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote: > > The question is where in the process does it make sense to generate > > the deltas. Do we do them in the build system (the koji level)? Do > > we do them in the update system?[1] Do we do them at tree compose > > (mash) time? Each has tradeoffs... not sure which is really the > > best. > > The problme domain are the limited bandwidth of end users, so you want > it to run on what end users consume. This can be different for > released versions vs rawhide, but in general released versions would > only perform this on updates-released (not updates-testing) and > for rawhide on everything. Yeah, it's easy to see that deltas for -updates and -updates-testing[1] from the release and probably the last update make sense[2]. rawhide is definitely the trickier to figure out where to draw the line. The more I think about it, the more I think we want it integrated kind of similar to how the signing works -- koji plays a role but is driven with external info to know what to create deltas for. The deltas are then associated with a given nevra of a package and stored along side them. Then, when we mash a tree (be it updates or rawhide), there's policy to get the appropriate deltas given the policy and koji generates them behind the scenes if needed. Jeremy [1] Arguably, the answer is to do deltas for foo-1 -> foo-2, foo-2 -> foo-3, foo-3 -> foo-4 and foo-1 -> foo-4. The last can be generated from just combining the earlier three for convenience of the entirely not updated user. From katzj at redhat.com Tue Jun 19 01:23:31 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 21:23:31 -0400 Subject: Official presto repositories for Rawhide In-Reply-To: <1182215959.7680.6.camel@aglarond.local> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> Message-ID: <1182216211.7680.11.camel@aglarond.local> On Mon, 2007-06-18 at 21:19 -0400, Jeremy Katz wrote: > On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote: > > On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote: > > > The question is where in the process does it make sense to generate > > > the deltas. Do we do them in the build system (the koji level)? Do > > > we do them in the update system?[1] Do we do them at tree compose > > > (mash) time? Each has tradeoffs... not sure which is really the > > > best. > > > > The problme domain are the limited bandwidth of end users, so you want > > it to run on what end users consume. This can be different for > > released versions vs rawhide, but in general released versions would > > only perform this on updates-released (not updates-testing) and > > for rawhide on everything. > > Yeah, it's easy to see that deltas for -updates and -updates-testing[1] > from the release and probably the last update make sense[2]. rawhide is > definitely the trickier to figure out where to draw the line. > > The more I think about it, the more I think we want it integrated kind > of similar to how the signing works -- koji plays a role but is driven > with external info to know what to create deltas for. The deltas are > then associated with a given nevra of a package and stored along side > them. Then, when we mash a tree (be it updates or rawhide), there's > policy to get the appropriate deltas given the policy and koji generates > them behind the scenes if needed. Should have been.. [1] Since we want people making sure the deltas work when they're downloading from -updates-testing too! and the following should have been [2]... > [1] Arguably, the answer is to do deltas for foo-1 -> foo-2, foo-2 -> > foo-3, foo-3 -> foo-4 and foo-1 -> foo-4. The last can be generated > from just combining the earlier three for convenience of the entirely > not updated user. Jeremy From katzj at redhat.com Tue Jun 19 01:25:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 18 Jun 2007 21:25:25 -0400 Subject: Root filesystem encryption update In-Reply-To: <6280325c0706181706j7013b7f7s4fa0af1c8bd11be3@mail.gmail.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <6280325c0706181706j7013b7f7s4fa0af1c8bd11be3@mail.gmail.com> Message-ID: <1182216325.7680.15.camel@aglarond.local> On Tue, 2007-06-19 at 09:36 +0930, n0dalus wrote: > On 6/19/07, Bruno Wolff III wrote: > > I think waiting for a complete solution is not the way to proceed. There are > > several different steps involved with the solution. If some of the steps > > have workable solutions, getting them included in the distribution will > > help get them tested and allow other people to build upon the previous work. > > It might be hard to recruit people to do some of the things that will be > > eventually needed until there is some base functionallity for them to play > > with. > > > > You don't have to advertise full disk encryption for the masses as soon as > > there is some support for booting with an encrypted root partition. > > Does full disk encryption have many advantages over directory-based > encryption? It seems like a lot less pain to be able to boot into X > and just have important directories encrypted. Well, encrypting subtrees (directories) is technically harder and the code for doing so isn't 100% there yet. eCryptFS is working on it, but there's still some work to be done for it to be there. I tend to think that it has a lot of advantages because of the ability to be on the running system, etc. Then you can really * encrypt home directories on a per-user basis with per-user keys * have subdirectories in your home directory with a different passphrase if they're more security sensitive * prompt for passphrases at log-in time when we have a full system * use polyinstantiated /tmp (which has other security advantages) that's actually under the user's home directory * encrypt swap just as a block device with a random key -- this still needs fiddling to figure out how hibernate works > One problem I see in both approaches is access control. Many computers > are used by more than one person, and instead of giving everyone the > one password (and having to change it whenever someone leaves the pool > of trusted people), it might be better to make sure these methods use > username/password combos which can be added and revoked. The idea with pretty much all of the methods is that you can have multiple keys defined and then delete keys at any point. Jeremy From tonynelson at georgeanelson.com Tue Jun 19 01:57:51 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 18 Jun 2007 21:57:51 -0400 Subject: Root filesystem encryption update In-Reply-To: <20070618215035.GA11450@wolff.to> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> Message-ID: At 4:50 PM -0500 6/18/07, Bruno Wolff III wrote: >On Mon, Jun 18, 2007 at 16:51:55 -0400, > Jeremy Katz wrote: >> On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote: ... >> > Heck, for key maps there probably aren't so many that you can't try >> > multiple possibilities after getting the password. >> >> There are at least 30-40 that we allow in the installer alone at the >> console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140. >> I don't think that trying either is really that practical. > >40 probably isn't too many to make trying them all impractical. I expect >that it will take less than a second to try each one even with measures >to slow down password guessing. That's not nice for suspend resume, but >wouldn't be a deal breaker for initial boots. ... Couldn't it just start with the one that worked last time? -- ____________________________________________________________________ TonyN.:' ' From lists at sapience.com Tue Jun 19 02:08:49 2007 From: lists at sapience.com (Mail List) Date: Mon, 18 Jun 2007 22:08:49 -0400 Subject: Official presto repositories for Rawhide In-Reply-To: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: <200706182208.49319.lists@sapience.com> On Monday 18 June 2007 10:31:51 am Jonathan Dieter wrote: > I would like to request the creation of presto repositories for Rawhide. Not that deltarpm's are not a great idea - but just wondering - rsync does a decent job save for the server load - I wonder if the rsync server can be taught to calc whatever it needs on demand - ie once - and cache it. Then yum could just use rsync? From rodd at clarkson.id.au Tue Jun 19 02:18:54 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 19 Jun 2007 12:18:54 +1000 Subject: user created at install added in sudoers ? In-Reply-To: <1182190312.2893.5.camel@dawkins> References: <4673037B.3030105@laposte.net> <1182190312.2893.5.camel@dawkins> Message-ID: <1182219534.3434.25.camel@localhost.localdomain> On Mon, 2007-06-18 at 20:11 +0200, David Nielsen wrote: > fre, 15 06 2007 kl. 23:24 +0200, skrev Axel: > > What do you think about adding the user created at install to the > > sudoers list ? > > > > For newbies like me, understanding the sudoers file isn't so easy, but > > nevertheless they may need the sudo command. In my case, I'd rather my > > account would have been added automatically to the sudoers list :) > > Why do you need sudo, I mean what does it add that a correctly seperated > privilaged user doesn't? It's super convenient. I (or others I trust) can do root stuff without having to log in as root, or remember root's password, or give roots password to another user. It also means that I only run stuff as root that I mean to. Instead of having to log in as root (or su -) and then running everything as root I can just run the things that root needs to do. For example, when you compile software, you can compile everything as the user and then 'sudo make install' to do the final step. It's the first thing I configure now when I install a new system. R. > > - David Nielsen -- "It's a fine line between denial and faith. It's much better on my side" From bpepple at fedoraproject.org Tue Jun 19 03:28:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 18 Jun 2007 23:28:18 -0400 Subject: FESCo elections Message-ID: <1182223698.2796.0.camel@kennedy> Hi all, This is a reminder that we are still in the self-nominations phase for the upcoming FESCo election. If you are interested in being part of the committee that oversees the engineering side of Fedora, you might want to consider running for a seat. If your interested, please place your nomination on this page in the wiki: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations Originally, we were planning to have the election this week, but with the Fedora Board having their election soon, it made sense to push the FESCo election back a bit, since we haven't had a lot of people nominated yet. So, the plan is to have the FESCo election the week after the Fedora Board election. I will be sending out another reminder as we get closer to that date. For more information regarding the election, please refer to this: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue Jun 19 03:28:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 18 Jun 2007 23:28:18 -0400 Subject: FESCo elections Message-ID: <1182223698.2796.0.camel@kennedy> Hi all, This is a reminder that we are still in the self-nominations phase for the upcoming FESCo election. If you are interested in being part of the committee that oversees the engineering side of Fedora, you might want to consider running for a seat. If your interested, please place your nomination on this page in the wiki: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations Originally, we were planning to have the election this week, but with the Fedora Board having their election soon, it made sense to push the FESCo election back a bit, since we haven't had a lot of people nominated yet. So, the plan is to have the FESCo election the week after the Fedora Board election. I will be sending out another reminder as we get closer to that date. For more information regarding the election, please refer to this: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From n0dalus+redhat at gmail.com Tue Jun 19 04:53:18 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 19 Jun 2007 14:23:18 +0930 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: <6280325c0706182153rcd68487u5d3c2dd94ade7bba@mail.gmail.com> On 6/17/07, Freddie Rosario wrote: > I know that Ubuntu disables the root account by default and automatically > enables the first user added to the system to have sudo access. That might > not be a bad idea as it guards against brute force attempts against the root > account. That would be a good argument in favor of that change but can > anyone think of any reasons against this sudo setup? Giving some users sudo access by default can easily make things less secure. It means that accessing root becomes as easy as finding a standard users' password. If there is some exploit successfully executed on the user's account, I estimate chances are very high that they can find the account's password saved in either the browser or desktop environment settings and quickly gain root access. While some people take the effort to use a different root password and keep it separate from other passwords, very few people separate their user account password from the myriad of other authentications, and they shouldn't have to. It's reasonable and sensible that people reuse their more trivial passwords, and for them to save their commonly used passwords in commonly used applications. To my recollection, these are said advantages of sudo: (I will discuss them and ways of implementing them without needing regular users to be in sudoers directly) 1) Don't have to repeat password as often For people who want this feature, it is better written as a pam module instead, which would allow it to be used for su, sudo and any other access mechanisms (very extensible). 2) Commands are logged. While I have seen this touted as a security feature, it really provides no security. All it takes is a "sudo sh" or "sudo innocuous_looking_script" and that's all you get to see in the log (and even that can be easily erased from a local log after root privileges are gained). For general logging purposes, bash_history is far more useful. 3) Easier to type sudo blah etc than su -c "blah etc" Handy, though it would be trivial to write a wrapper script which does su -c "...". 4) Allows the root user to be disabled. Disabling the root user is not all that helpful. I recommend that root access be disallowed in {g,k,x}dm and ssh_config, but a root account is still good to have. If you want to restrict who is able to run su, or whether or not root can log in on vt's, this is better done in /etc/pam.d/su, /etc/pam.d/login and /etc/securetty. 5) Gives fine-grained access controls to root privileges. This is the only real advantage of sudo, and it's what it was designed for. While not many people would actually need this (there's usually only one person who needs root access), it can be setup in a way that minimises impact to security. The concept here is that if you need to share the root password with several people, it becomes very difficult to ever change the password or keep it from leaking. So instead what you do is give these people separate access to root, via individual username+passwords and sudo. This way access can be revoked if it's ever necessary. >From a security perspective, the passwords for these accounts should be treated as with superuser accounts. The problem I have with sudo as it is used in Some Other Distros (TM) is that regular desktop user accounts are added to sudoers. If sudo is to be used (which I am all for), passwords should be separate from the normal passwords for a desktop user. The usual way this is done is by having separate user accounts (one for each person that needs root access) which are meant to exclusively be used for doing privilege escalation. So people have a separate account for their day-to-day work and their web browsing and document writing, and su in to the special account to use sudo from there. A better way of giving users this kind of access is to allow the password to go from user -> root to be set to a different password than their usual login password (which would be essentially the same as having a second user). This could be implemented with a pam module, so users trying to sudo are not asked for their own password but a second password they set (and any dialogue would be clearly labelled to make clear which password was being asked for). This could then be integrated into consolehelper. Just my 2 cents, n0dalus. From thomas.swan at gmail.com Tue Jun 19 05:10:09 2007 From: thomas.swan at gmail.com (Thomas Swan) Date: Tue, 19 Jun 2007 00:10:09 -0500 Subject: Root filesystem encryption update In-Reply-To: <6280325c0706181706j7013b7f7s4fa0af1c8bd11be3@mail.gmail.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <6280325c0706181706j7013b7f7s4fa0af1c8bd11be3@mail.gmail.com> Message-ID: On 6/18/07, n0dalus wrote: > > On 6/19/07, Bruno Wolff III wrote: > > > > I think waiting for a complete solution is not the way to proceed. There > are > > several different steps involved with the solution. If some of the steps > > have workable solutions, getting them included in the distribution will > > help get them tested and allow other people to build upon the previous > work. > > It might be hard to recruit people to do some of the things that will be > > eventually needed until there is some base functionallity for them to > play > > with. > > > > You don't have to advertise full disk encryption for the masses as soon > as > > there is some support for booting with an encrypted root partition. > > > > Does full disk encryption have many advantages over directory-based > encryption? It seems like a lot less pain to be able to boot into X > and just have important directories encrypted. It generally starts to suck after the first password is entered and you have to have another. The great thing about encrypting / is config files. wpa_supplicant.conf which may have a key or password. DNS autoupdate scripts. There can be lots of private information for a personal workstation stored in /etc or in system scripts. In this system, only /boot needs to be unencrypted. One problem I see in both approaches is access control. Many computers > are used by more than one person, and instead of giving everyone the > one password (and having to change it whenever someone leaves the pool > of trusted people), it might be better to make sure these methods use > username/password combos which can be added and revoked. > > Let me chime in here. LUKS supports up to 8 passwords on one volume. This isn't hard to manage as long as the person doesn't remove your other password. This approach has a couple of novel advantages. With the LVM approach, swap is encrypted. It's encrypted on the layer under LVM, so you can hibernate on an encrypted volume. The restore operation is great. I know use the same approach with a larger swap, and use tmpfs backed /tmp to better utilized swap/temp and the extra beauty of suspending to encrypted swap. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Axel.Thimm at ATrpms.net Tue Jun 19 05:36:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 19 Jun 2007 07:36:57 +0200 Subject: Official presto repositories for Rawhide In-Reply-To: <1182216211.7680.11.camel@aglarond.local> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> <1182216211.7680.11.camel@aglarond.local> Message-ID: <20070619053657.GA5053@neu.nirvana> On Mon, Jun 18, 2007 at 09:23:31PM -0400, Jeremy Katz wrote: > On Mon, 2007-06-18 at 21:19 -0400, Jeremy Katz wrote: > > On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote: > > > On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote: > > > > The question is where in the process does it make sense to generate > > > > the deltas. Do we do them in the build system (the koji level)? Do > > > > we do them in the update system?[1] Do we do them at tree compose > > > > (mash) time? Each has tradeoffs... not sure which is really the > > > > best. > > > > > > The problme domain are the limited bandwidth of end users, so you want > > > it to run on what end users consume. This can be different for > > > released versions vs rawhide, but in general released versions would > > > only perform this on updates-released (not updates-testing) and > > > for rawhide on everything. > > > > Yeah, it's easy to see that deltas for -updates and -updates-testing[1] Actually not updates-testing for two reasons: a) it is and will not really ever become a bandwidth critical area, since only very few people (in relation to updates-released) will be using it, and the bandwidth limited will certainly not be on the top list for other reasons. b) updates-testing may contain parts that will be doomed as unreleasable (that's why we have a testing stage at all). Having all deltas makes it possible for the user to resurrect all old releases including the broken ones. So when a user may think he downgrades to a previous stable release he may be downgrading to an updates-testing one. b) can be handled by not inheriting the deltas from updates-testing, of course, but one needs to be aware of that. E.g. while updates-testing may have foo-1 -> 2 -> 3 -> ..., updates-released will have foo-1 -> 3 -> 7 etc. > > from the release and probably the last update make sense[2]. rawhide is > > definitely the trickier to figure out where to draw the line. > > > > The more I think about it, the more I think we want it integrated kind > > of similar to how the signing works -- koji plays a role but is driven > > with external info to know what to create deltas for. The deltas are > > then associated with a given nevra of a package and stored along side > > them. Then, when we mash a tree (be it updates or rawhide), there's > > policy to get the appropriate deltas given the policy and koji generates > > them behind the scenes if needed. > > Should have been.. > > [1] Since we want people making sure the deltas work when they're > downloading from -updates-testing too! > > and the following should have been [2]... > > [1] Arguably, the answer is to do deltas for foo-1 -> foo-2, foo-2 -> > > foo-3, foo-3 -> foo-4 and foo-1 -> foo-4. The last can be generated > > from just combining the earlier three for convenience of the entirely > > not updated user. > > Jeremy > -- 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 bruno at wolff.to Tue Jun 19 05:46:04 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 19 Jun 2007 00:46:04 -0500 Subject: Root filesystem encryption update In-Reply-To: <1182204335.16956.55.camel@erebor.boston.redhat.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <1182204335.16956.55.camel@erebor.boston.redhat.com> Message-ID: <20070619054604.GA29572@wolff.to> On Mon, Jun 18, 2007 at 18:05:35 -0400, Jeremy Katz wrote: > > If the idea is to actually _support_ full disk encryption in Fedora, > then it has to be everywhere. In the installer. On upgrades (at least > for the Fedora n+1 release :-). In the documentation. Otherwise, we're > doing ourselves a great disservice by talking out of one side of our > mouth saying it's supported but on the other claiming "well, maybe not > so much". > What that means is there should be a plausible path to all of this so people aren't working what is sure to be a blind alley. But if you expect the whole shebang to be done at once, that is a recipie for a project that never gets done. > If it takes less than a second, then that means the measures to slow > down password guessing are pretty bad ;-) You want an exponential > backoff that gets pretty slow pretty fast or it becomes way too easy to > brute force. And even for initial boots, another of the goals for > Fedora 8 is actually making things faster. Why would we make two > features work directly against each other? You can't do exponential back off in this context. The protection measures are against someone that has your disk. The typical way to do this is to rehash the password many times so that the cpu calculations take a significant amount of time for each guess. You aren't relying on an application delaying its response. One password per second isn't really all that bad; at that rate you only need about 25 bits of entropy in your password to protect you for a year. From bruno at wolff.to Tue Jun 19 05:52:46 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 19 Jun 2007 00:52:46 -0500 Subject: Root filesystem encryption update In-Reply-To: <6280325c0706181706j7013b7f7s4fa0af1c8bd11be3@mail.gmail.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <6280325c0706181706j7013b7f7s4fa0af1c8bd11be3@mail.gmail.com> Message-ID: <20070619055246.GB29572@wolff.to> On Tue, Jun 19, 2007 at 09:36:28 +0930, n0dalus wrote: > > Does full disk encryption have many advantages over directory-based > encryption? It seems like a lot less pain to be able to boot into X > and just have important directories encrypted. If you are going to run things like DMBS on top of an encrypted filesystem you need to know that it is going to have guarantees about when data is written to the disk. dmcrypt is designed to do that (though there is an issue with it on smp systems since 2.6.19 when it switched to work queues). I haven't seen this issue addressed by the other encryption systems being proposed, though I could have easily missed it. > One problem I see in both approaches is access control. Many computers > are used by more than one person, and instead of giving everyone the > one password (and having to change it whenever someone leaves the pool > of trusted people), it might be better to make sure these methods use > username/password combos which can be added and revoked. Only the people that need to boot the machine need the password if you are using dmcrypt with whole partition encryption. If there are several of these, each can have their own password. From bruno at wolff.to Tue Jun 19 05:59:15 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 19 Jun 2007 00:59:15 -0500 Subject: Root filesystem encryption update In-Reply-To: References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> Message-ID: <20070619055915.GC29572@wolff.to> On Mon, Jun 18, 2007 at 21:57:51 -0400, Tony Nelson wrote: > >On Mon, Jun 18, 2007 at 16:51:55 -0400, > > Jeremy Katz wrote: > > > >40 probably isn't too many to make trying them all impractical. I expect > >that it will take less than a second to try each one even with measures > >to slow down password guessing. That's not nice for suspend resume, but > >wouldn't be a deal breaker for initial boots. > ... > > Couldn't it just start with the one that worked last time? You could also have the person select a keymap when they enter a password, similar to how you select one when running anaconda. There are probably some other solutions as well. Another option would be to save the keys they hit instead of the characters. That poses some problems if a keyboard is swapped out for a different kind, but if you limited yourself to the more standard areas of the keyboard when entering the passphrase, that wouldn't be guaranteed to fail. From 1 at 234.cx Tue Jun 19 08:06:28 2007 From: 1 at 234.cx (Pete Chown) Date: Tue, 19 Jun 2007 08:06:28 +0000 (UTC) Subject: The updates firehose References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <4676D2B3.7090005@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Wouldn't the ability to filter updates based on classifications > (security, bug fixes, enhancements etc) provide what you want instead of > separate update streams? That would probably be better than what I suggested, actually, as it would allow for more detailed classification of updates. Pete From nlv19665 at natlab.research.philips.com Tue Jun 19 08:30:43 2007 From: nlv19665 at natlab.research.philips.com (LIN QIU) Date: Tue, 19 Jun 2007 10:30:43 +0200 Subject: can Kpowersave be installed on FC3? Message-ID: <1182241843.10697.1.camel@pc67244168.ddns.htc.nl.philips.com> Dear concerned, I am using FC3, can I install kpowersave? I had searched internet, but did not find available rpm. LIN From jdieter at gmail.com Tue Jun 19 08:54:48 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 19 Jun 2007 11:54:48 +0300 Subject: Official presto repositories for Rawhide In-Reply-To: <1182204707.16956.62.camel@erebor.boston.redhat.com> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> Message-ID: <1182243288.4303.38.camel@jndwidescreen.lesbg.loc> On Mon, 2007-06-18 at 18:11 -0400, Jeremy Katz wrote: > Yeah, this is definitely something we want to start looking at. The > question is where in the process does it make sense to generate the > deltas. Do we do them in the build system (the koji level)? Do we do > them in the update system?[1] Do we do them at tree compose (mash) > time? Each has tradeoffs... not sure which is really the best. I'm > pretty sure whichever route we go, we need to go with something that > preserves the deltas and likely at least stores them in the koji store > (with info about them in the kojidb). Perhaps similar to how signing > works? I would probably suggest running the script to generated the deltarpms on a per-package basis rather than a per-repo basis. The reason for this is that the script reads in information about *all* the rpms and deltarpms available, which can take a large amount of time if you're talking about a full repository. I don't know enough about our build system to know where exactly this should go. > At the same time, I think we should sit down and look at how presto is > doing things on the yum side to simplify things a bit. I think that if > we get rid of the concept of a separate standalone delta repository, we > can just make it so that there's a (simpler) XML file to parse with the > delta information and then just add it to the repodata with > modifyrepo[2]. Then, we can also get rid of the duplication of repo > code presented by the PrestoRepository class. I've been trying to get > to mocking something up, but keep having other things come up and steal > time instead. Hopefully tonight/tomorrow... At the moment, code is in place so that a delta repo added via updaterepo will be read via yum-presto without needing the whole concept of a "separate" presto repository. If you can simplify (or remove) much of the code in the PrestoRepository class, that would be brilliant. On a side note, the presto.xml.gz file is in a form such that it could easily be merged with updates.xml.gz. Not sure if that's the route we want to go. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jdieter at gmail.com Tue Jun 19 09:00:51 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 19 Jun 2007 12:00:51 +0300 Subject: Official presto repositories for Rawhide In-Reply-To: <20070619053657.GA5053@neu.nirvana> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> <1182216211.7680.11.camel@aglarond.local> <20070619053657.GA5053@neu.nirvana> Message-ID: <1182243651.4303.44.camel@jndwidescreen.lesbg.loc> On Tue, 2007-06-19 at 07:36 +0200, Axel Thimm wrote: > > Yeah, it's easy to see that deltas for -updates and -updates-testing[1] > > Actually not updates-testing for two reasons: > > a) it is and will not really ever become a bandwidth critical area, > since only very few people (in relation to updates-released) will > be using it, and the bandwidth limited will certainly not be on the > top list for other reasons. I totally see what you're saying, but I am on very limited bandwidth and I would love to be able to use updates-testing. > > b) updates-testing may contain parts that will be doomed as > unreleasable (that's why we have a testing stage at all). Having > all deltas makes it possible for the user to resurrect all old > releases including the broken ones. So when a user may think he > downgrades to a previous stable release he may be downgrading to an > updates-testing one. I'm not sure what you mean by resurrecting all old releases. Deltarpms can only go in one direction (unlike diffs), and yum-presto saves the final rpm in the same location yum would (i.e. /var/cache/yum/updates-testing/packages for updates-testing). > b) can be handled by not inheriting the deltas from updates-testing, of > course, but one needs to be aware of that. E.g. while updates-testing > may have foo-1 -> 2 -> 3 -> ..., updates-released will have foo-1 -> 3 > -> 7 etc. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Jun 19 09:54:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 19 Jun 2007 11:54:05 +0200 Subject: Official presto repositories for Rawhide In-Reply-To: <1182243651.4303.44.camel@jndwidescreen.lesbg.loc> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> <1182216211.7680.11.camel@aglarond.local> <20070619053657.GA5053@neu.nirvana> <1182243651.4303.44.camel@jndwidescreen.lesbg.loc> Message-ID: <20070619095405.GF5053@neu.nirvana> On Tue, Jun 19, 2007 at 12:00:51PM +0300, Jonathan Dieter wrote: > > b) updates-testing may contain parts that will be doomed as > > unreleasable (that's why we have a testing stage at all). Having > > all deltas makes it possible for the user to resurrect all old > > releases including the broken ones. So when a user may think he > > downgrades to a previous stable release he may be downgrading to an > > updates-testing one. > I'm not sure what you mean by resurrecting all old releases. Deltarpms > can only go in one direction (unlike diffs), Not? OK, I though that would be possible with deltas as well. If not, then my point is moot :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jun 19 10:34:44 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Jun 2007 06:34:44 -0400 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> Message-ID: <20070619103444.GA28744@jadzia.bu.edu> On Fri, Jun 15, 2007 at 10:23:29PM -0300, Caio Marcelo wrote: > >* Create a "sudoers" group at install time. > >* Have the "%sudoers" in /etc/sudoers by default. > Just a small note: there's a "wheel" group, which has entries > in /etc/sudoers by default, but commented. This group is usually > for the administration users AFAIK, so it could be used instead of > "sudoers" group. Yeah, +1. Let's not, you know, reinvent the wheel group. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Jun 19 10:39:39 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Jun 2007 06:39:39 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <1182190312.2893.5.camel@dawkins> References: <4673037B.3030105@laposte.net> <1182190312.2893.5.camel@dawkins> Message-ID: <20070619103939.GB28744@jadzia.bu.edu> On Mon, Jun 18, 2007 at 08:11:52PM +0200, David Nielsen wrote: > > For newbies like me, understanding the sudoers file isn't so easy, but > > nevertheless they may need the sudo command. In my case, I'd rather my > > account would have been added automatically to the sudoers list :) > Why do you need sudo, I mean what does it add that a correctly seperated > privilaged user doesn't? Principle of least privilege. Sudo provides a mechanism to add and drop certain privileges (in a course-grained user-account-based way) with a long-established history. We can and should make it work in a new and better way too, of course. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Jun 19 10:46:32 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Jun 2007 06:46:32 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706182153rcd68487u5d3c2dd94ade7bba@mail.gmail.com> References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> <6280325c0706182153rcd68487u5d3c2dd94ade7bba@mail.gmail.com> Message-ID: <20070619104632.GC28744@jadzia.bu.edu> On Tue, Jun 19, 2007 at 02:23:18PM +0930, n0dalus wrote: > Giving some users sudo access by default can easily make things less > secure. It means that accessing root becomes as easy as finding a > standard users' password. If there is some exploit successfully > executed on the user's account, I estimate chances are very high that > they can find the account's password saved in either the browser or > desktop environment settings and quickly gain root access. If they can compromise the user account of a system administrator who ever uses su or one of the usermode-enabled applications, the root password is very quickly suspect. This is largely a false sense of security. > While some people take the effort to use a different root password and > keep it separate from other passwords, very few people separate their > user account password from the myriad of other authentications, and > they shouldn't have to. It's reasonable and sensible that people reuse > their more trivial passwords, and for them to save their commonly used > passwords in commonly used applications. Yes, well, a system administrator enabled password isn't one of those trivial passwords. I agree with your point about myriads of passwords, but it's vital to recognize which ones are actually important. I'm not sure encouraging horrible password practice should be a design goal. > To my recollection, these are said advantages of sudo: (I will discuss > them and ways of implementing them without needing regular users to be > in sudoers directly) > 1) Don't have to repeat password as often > For people who want this feature, it is better written as a pam module > instead, which would allow it to be used for su, sudo and any other > access mechanisms (very extensible). Exists already. [...] > The usual way this is done is by having separate user accounts (one > for each person that needs root access) which are meant to exclusively > be used for doing privilege escalation. So people have a separate > account for their day-to-day work and their web browsing and document > writing, and su in to the special account to use sudo from there. This seems unrealistic. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Jun 19 10:50:58 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Jun 2007 06:50:58 -0400 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> <1182105587.21142.2.camel@ignacio.lan> Message-ID: <20070619105058.GD28744@jadzia.bu.edu> On Sun, Jun 17, 2007 at 11:40:03PM -0300, Caio Marcelo wrote: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188 > Nice! So, if I got right what has been done already, it's just a > matter of tweaking > the defaults of these /etc/security/console.apps/* files? Yes. However, the real right thing to do with those programs is to make them all work with PolicyKit to implement the same behavior but without running GUI apps as root. This is just a stop-gap until that can be done. The nice part is that (if the console.apps files were preconfigured), it'd be transparent to end-users when the new better way goes in. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at redhat.com Tue Jun 19 11:15:43 2007 From: buildsys at redhat.com (Build System) Date: Tue, 19 Jun 2007 07:15:43 -0400 Subject: rawhide report: 20070619 changes Message-ID: <200706191115.l5JBFhD6000304@porkchop.devel.redhat.com> New package bes Back-end server software framework for OPeNDAP New package etherbat Ethernet topology discovery New package mksh MirBSD enhanced version of the Korn Shell New package oxine Lightweight, purely OSD based xine frontend New package pfqueue Queue manager for the Postfix/Exim Mail Transport Agents New package postgresql-table_log Log data changes in a PostgreSQL table Updated Packages: ack-1.62-2.fc8 -------------- * Mon Jun 18 2007 Ian M. Burrell - 1.62-2 - Disable tests since bug not fixed * Sun Jun 17 2007 Ian Burrell - 1.62-1 - Update to 1.62 - Enable tests amarok-1.4.6-1.fc8 ------------------ * Mon Jun 18 2007 Aurelien Bompard 1.4.6-1 - version 1.4.6 * Mon Feb 19 2007 Aurelien Bompard 1.4.5-4 - have the visualisation subpackage require libvisual-plugins (bug 229131) * Thu Feb 15 2007 Aurelien Bompard 1.4.5-3 - fix patch (provided by upstream) anaconda-11.3.0.3-1 ------------------- * Mon Jun 18 2007 Chris Lumens - 11.3.0.3-1 - Remove obsolete language and loader options (notting). - Remove unused gzlib implementation (pjones). - Finish removing split ISO loopback method (#244258). - libbz2 has changed location (#243566). aspell-bg-50:0.50-15.fc7 ------------------------ * Wed May 02 2007 Ivana Varekova - 50:0.50-15 - Resolves: 238426 convert bulgarian.kbd file autofs-1:5.0.2-1 ---------------- * Mon Jun 18 2007 Ian Kent - 5.0.2-1 - Update to upstream release 5.0.2. bind-31:9.4.1-7.fc8 ------------------- * Wed Jun 13 2007 Adam Tkac 31:9.4.1-7.fc8 - marked caching-nameserver as obsolete (#244604) - fixed typo in initscript (causes that named doesn't detect NetworkManager correctly) - next cleanup in configuration - moved configfiles into config.tar - removed delay between start & stop in restart function in named.init checkpolicy-2.0.3-2.fc8 ----------------------- * Mon Jun 18 2007 Dan Walsh - 2.0.3-2 - Rebuild with the latest libsepol * Sun Jun 17 2007 Dan Walsh - 2.0.3-1 - Latest update from NSA * Merged fix for segfault on duplicate require of sensitivity from Caleb Case. * Merged fix for dead URLs in checkpolicy man pages from Dan Walsh. * Thu Apr 12 2007 Dan Walsh - 2.0.2-1 - Latest update from NSA * Merged checkmodule man page fix from Dan Walsh. control-center-1:2.19.4-1.fc8 ----------------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 curl-7.16.2-5.fc8 ----------------- * Mon Jun 18 2007 Jindrich Novy 7.16.2-5 - don't print like crazy (#236981), backported from upstream CVS * Fri Jun 15 2007 Jindrich Novy 7.16.2-4 - another series of review fixes (#225671), thanks to Paul Horwath - check version of ldap library automatically - don't use %makeinstall and preserve timestamps - drop useless patches * Fri May 11 2007 Jindrich Novy 7.16.2-3 - add automake BR to curl-devel to fix aclocal dir. ownership, thanks to Patrice Dumas dap-netcdf_handler-3.7.6-4.fc8 ------------------------------ * Mon Jun 18 2007 Patrice Dumas 3.7.6-4 - rebuild against bes dbus-python-0.81.1-1.fc7 ------------------------ * Tue Jun 12 2007 John (J5) Palmieri - 0.81.1-1 - Update to latest 0.81.1 which has many bug fixes devhelp-0.15-1.fc8 ------------------ * Mon Jun 18 2007 Matthew Barnes - 0.15-1.fc8 - Update to 0.15 dhcp-12:3.0.5-36.fc8 -------------------- * Fri Jun 15 2007 David Cantrell - 12:3.0.5-36 - BOOTP_BROADCAST_ALWAYS is not the same as ATSFP, fixed - Added anycast mac support to dhclient for OLPC * Tue May 22 2007 David Cantrell - 12:3.0.5-35 - Disable -fvisibility=hidden for now as it breaks dhcpv4_client() from the shared library (#240804) * Thu Apr 26 2007 David Cantrell - 12:3.0.5-34 - Init script fixes (#237985, #237983) - Reference correct scripts in dhclient-script.8 man page (#238036) docbook-style-xsl-1.72.0-3.fc8 ------------------------------ * Mon Jun 18 2007 Ondrej Vasik 1.72.0-3 - patch fixing #161619 taken from upstream dovecot-1.0.1-12.5.fc8 ---------------------- * Mon Jun 18 2007 Tomas Janousek - 1.0.1-12.5 - update to latest upstream eel2-2.19.4-1.fc8 ----------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 emacs-vm-8.0.0.453-1.fc8 ------------------------ * Tue Jun 19 2007 Jonathan G. Underwood - 8.0.0.453-1 - Update to version 8.0.0 devo 453 which removes the need for thr vmrf patch - No longer need to bundle vcard stuff as that is included upstream - Spec file cleanups - No longer use separate pixmaps * Thu May 17 2007 Jonathan G. Underwood - 7.19.devo282-11 - Fix missnaming of startup file - Fix changelog entry * Sun Mar 18 2007 Jonathan G. Underwood - 7.19.devo282-10 - Fixed error in specification of Source0 evince-0.9.1-1.fc8 ------------------ * Mon Jun 18 2007 Matthias Clasen - 0.9.1-1 - Update to 0.9.1 evolution-2.11.4-1.fc8 ---------------------- * Mon Jun 18 2007 Matthew Barnes - 2.11.4-1.fc8 - Update to 2.11.4 - Remove patch for GNOME bug #447727 (fixed upstream). * Thu Jun 14 2007 Matthew Barnes - 2.11.3-5.fc8 - Add patch for GNOME bug #447727 (remove EClippedLabel). * Wed Jun 06 2007 Matthew Barnes - 2.11.3-4.fc8 - Revise patch for GNOME bug #362638 to fix RH bug #240507 (hang on exit). evolution-data-server-1.11.4-1.fc8 ---------------------------------- * Mon Jun 18 2007 Matthew Barnes - 1.11.4-1.fc8 - Update to 1.11.4 - Remove patch for RH bug #202309 (fixed upstream). - Remove patch for GNOME bug #312854 (fixed upstream). - Remove patch for GNOME bug #447414 (fixed upstream). evolution-exchange-2.11.4-1.fc8 ------------------------------- * Mon Jun 18 2007 Matthew Barnes - 2.11.4-1.fc8 - Update to 2.11.4 - Remove patch for GNOME bug #444101 (fixed upstream). g-wrap-1.9.6-12 --------------- * Fri Jun 08 2007 Bill Nottingham - 1.9.6-12 - fix license tag - LGPL, not GPL (#222347) gcalctool-5.19.4-1.fc8 ---------------------- * Mon Jun 18 2007 Matthias Clasen - 5.19.4-1 - Update to 5.19.4 gdm-1:2.19.3-1.fc8 ------------------ * Mon Jun 18 2007 Ray Strode - 1:2.19.3-1 - Update to 2.19.3 git-1.5.2.2-1.fc8 ----------------- * Mon Jun 18 2007 James Bowes 1.5.2.2-1 - git-1.5.2.2 glib2-2.13.5-1.fc8 ------------------ * Mon Jun 18 2007 Matthias Clasen - 2.13.5-1 - Update to 2.13.5 gnome-games-1:2.19.4-1.fc8 -------------------------- * Mon Jun 18 2007 Matthias Clasen - 1:2.19.4-1 - Update to 2.19.4 gnome-mag-0.14.6-1.fc8 ---------------------- * Mon Jun 18 2007 Matthias Clasen - 0.14.6-1 - Update to 0.14.6 - Drop upstreamed patch gnome-system-monitor-2.19.4-1.fc8 --------------------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 gnome-terminal-2.18.1-1.fc8 --------------------------- * Mon Jun 18 2007 Matthias Clasen - 2.18.1-1 - Update to 2.18.1 gtk2-engines-2.11.2-1.fc8 ------------------------- * Mon Jun 18 2007 Matthias Clasen - 2.11.2-1 - Update to 2.11.2 gtkhtml3-3.15.4-1.fc8 --------------------- * Mon Jun 18 2007 Matthew Barnes - 3.15.4-1.fc8 - Update to 3.15.4 gtksourceview-1.90.1-1.fc8 -------------------------- * Mon Jun 18 2007 Matthias Clasen - 1.90.1-1 - Update to 1.90.1 - Update dependencies iscsi-initiator-utils-6.2.0.865-0.0.fc7 --------------------------------------- * Tue Jun 12 2007 Mike Christie - 6.2.0.865-0.0 - Rebase upstream jokosher-0.9-4.fc8 ------------------ * Mon Jun 18 2007 Christopher Brown - 0.9-4 - change menu entry location kernel-2.6.21-1.3228.fc8 ------------------------ * Mon Jun 18 2007 Dave Jones - 2.6.22-rc5-git1. * Mon Jun 18 2007 Jeremy Katz - add patch from upstream kvm to fix suspend/resume with kvm loaded (and guests running) * Sun Jun 17 2007 Dave Jones - Make the 686 kernel bootable on 586s. kexec-tools-1.101-70.fc8 ------------------------ * Mon Jun 18 2007 Neil Horman - 1.101-70.fc8 - Fixed kdump.init to properly read cmdline (bz 244649) * Wed Apr 11 2007 Neil Horman - 1.101-69.fc8 - Fixed up kdump.init to enforce mode 600 on authorized_keys2 (bz 235986) * Tue Apr 10 2007 Neil Horman - 1.101-68.fc8 - Fix alignment of bootargs and device-tree structures on ppc64 libgnome-2.19.0-1.fc8 --------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.0-1 - Update to 2.19.0 - Drop upstreamed patch * Thu Apr 19 2007 Matthias Clasen - 2.18.0-4 - Change the default icon theme to Fedora * Thu Apr 05 2007 Matthias Clasen - 2.18.0-3 - Fix patches to make changes in gconf default settings take effect again libgnomeui-2.19.0-1.fc8 ----------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.0-1 - Update to 2.19.0 * Tue Jun 12 2007 Ray Strode - 2.18.1-3 - Require yelp * Tue Apr 10 2007 Matthias Clasen - 2.18.1-2 - Add user-dirs support to the gnome-vfs filechooser backend libgsf-1.14.4-1.fc8 ------------------- * Mon Jun 18 2007 Caolan McNamara 1.14.4-1 - next version libgtop2-2.19.4-1.fc8 --------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 libibverbs-1.1.1-1.fc8 ---------------------- * Fri Jun 15 2007 Roland Dreier - 1.1.1-1 - New upstream release libwnck-2.19.4-1.fc8 -------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 mailcap-2.1.24-1.fc8 -------------------- * Mon Jun 18 2007 Miroslav Lichvar 2.1.24-1 - add text/x-vcard to mime.types (#243889) - mark configs noreplace, cleanup spec a bit metacity-2.19.21-1.fc8 ---------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.21-1 - Update to 2.19.21 nautilus-2.19.4-1.fc8 --------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 * Tue Jun 05 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 * Sat May 19 2007 Matthias Clasen - 2.19.2-1 - Update to 2.19.2 nginx-0.5.26-1.fc8 ------------------ * Mon Jun 18 2007 Jeremy Hinegardner - 0.5.26-1 - Update to 0.5.26 nss-3.11.7-4.fc8 ---------------- * Mon Jun 18 2007 Kai Engert - 3.11.7-4 - Better approach to ship freebl/softokn based on 3.11.5 - Remove link time dependency on softokn * Sun Jun 10 2007 Kai Engert - 3.11.7-3 - Fix unowned directories, rhbz#233890 * Fri Jun 01 2007 Kai Engert - 3.11.7-2 - Update to 3.11.7, but freebl/softokn remain at 3.11.5. - Use a workaround to avoid mozilla bug 51429. openoffice.org-1:2.2.1-18.3.fc8 ------------------------------- * Mon Jun 18 2007 Caolan McNamara - 1:2.2.1-18.3 - add ppc64 uno bridge (workspace.ppc64one.patch) - Resolves: rhbz#241875 get script detection right for range vs point in drawing objects ooo#72349 - Resolves: rhbz#242692 openoffice.org-2.2.1.oooXXXXX.xmloff.outofrange.patch - Resolves: rhbz#243305 missing xdg file for quickstart restart - Resolves: rhbz#243904 add openoffice.org-2.2.1.ooo78383.vcl.printxerror.patch - update stocmerge patch - add openoffice.org-2.2.1.ooo78392.sixtyfour.tools.patch - extend selinux patch for ppc64 and sparc * Fri Jun 15 2007 Caolan McNamara - 1:2.2.1-18.2 - ppc64 test * Thu May 31 2007 Caolan McNamara - 1:2.2.1-18.1 - next 2.2.1 release candidate - add Jan's stocmerge.all.patch perl-SVK-2.0.1-2.fc8 -------------------- * Mon Jun 18 2007 Ian M. Burrell - 2.0.1-2 - Add Compress::Zlib to BuildRequires * Sun Jun 17 2007 Ian Burrell - 2.0.1-1 - Update to 2.0.1 - Filter optional File::LibMagic * Tue May 29 2007 Ian M. Burrell - 2.0.0-1 - Update to 2.0.0 poppler-0.5.9-1.fc8 ------------------- * Mon Jun 18 2007 Matthias Clasen - 0.5.9-1 - Update to 0.5.9 powertop-1.7-1.fc8 ------------------ * Mon Jun 18 2007 Adam Jackson 1.7-1 - powertop 1.7. procps-3.2.7-14.fc8 ------------------- * Mon Jun 18 2007 Tomas Smetana 3.2.7-14 - fix #244152 ps truncates eip and esp to 32-bit values on 64-bit systems qucs-0.0.12-2.fc8 ----------------- * Sun Jun 17 2007 Eric Tanguy - 0.0.12-2 - Add perl and iverilog as require ragel-5.22-1.fc8 ---------------- * Mon Jun 18 2007 Jeremy Hinegardner - 5.22-1 - update to 5.22 - remove ragel-Makefile-in.patch - it was applied upstream - update ragel-rlcodegen-replace.patch to apply cleanly scim-pinyin-0.5.91-17.fc8 ------------------------- * Mon Jun 18 2007 Huang Peng - 0.5.91-17 - Drop patch scim-pinyin-shuangpin.patch to enable shuangpin and to fix bug (#233054) scim-qtimm-0.9.4-7.fc8 ---------------------- * Mon Jun 18 2007 Jens Petersen - 0.9.4-7 - add scim-qtimm-0.9.4-silence-debug-output-244200.patch to silence kconfig and ScimInputContextPlugin output from KDE apps (reported by Mary Ellen Foster, #244200) shorewall-3.4.4-1.fc8 --------------------- * Mon Jun 18 2007 Robert Marcano - 3.4.4-1 - Update to upstream 3.4.4 * Fri May 11 2007 Robert Marcano - 3.4.3-1 - Update to upstream 3.4.3 * Sun Apr 15 2007 Robert Marcano - 3.4.2-1 - Update to upstream 3.4.2 sound-juicer-2.19.2-1.fc8 ------------------------- * Mon Jun 18 2007 Matthias Clasen - 2.19.2-1 - Update to 2.19.2 thunderbird-2.0.0.4-1.fc7 ------------------------- * Fri Jun 15 2007 Christopher Aillon 2.0.0.4-1 - 2.0.0.4 * Fri Jun 08 2007 Christopher Aillon 2.0.0.4-0.rc1 - 2.0.0.4 rc1 vte-0.16.6-1.fc8 ---------------- * Mon Jun 18 2007 Matthias Clasen 0.16.6-1 - Update to 0.16.6 wine-0.9.39-2.fc8 ----------------- * Mon Jun 18 2007 Andreas Bierfert - 0.9.39-2 - fix desktop entries wireshark-0.99.6-0.pre2.fc8 --------------------------- * Fri Jun 15 2007 Radek Vok??l 0.99.6-0.pre2 - another pre-release - turn on ADNS support xfce4-places-plugin-0.3.0-1.fc7 ------------------------------- xorg-x11-drv-acecad-1.1.0-4.fc8 ------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-4 - Update BuildRequires and Requires. xorg-x11-drv-aiptek-1.0.1-4.fc8 ------------------------------- * Mon Jun 18 2007 Adam Jackson 1.0.1-4 - Update BuildRequires and Requires. xorg-x11-drv-apm-1.1.1-6.fc8 ---------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.1-6 - Update Requires and BuildRequires. xorg-x11-drv-ark-0.6.0-4.fc8 ---------------------------- * Mon Jun 18 2007 Adam Jackson 0.6.0-4 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-ast-0.81.0-5.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 0.81.0-5 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-ati-6.6.3-3.fc8 ---------------------------- * Mon Jun 18 2007 Adam Jackson 6.6.3-3 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-chips-1.1.1-4.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 1.1.1-4 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-cirrus-1.1.0-4.fc8 ------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-4 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-digitaledge-1.1.0-3.fc8 ------------------------------------ * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-dummy-0.2.0-4.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 0.2.0-4 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-elographics-1.1.0-3.fc8 ------------------------------------ * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-fbdev-0.3.1-3.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 0.3.1-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-fpit-1.1.0-3.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-glint-1.1.1-6.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 1.1.1-6 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-hyperpen-1.1.0-4.fc8 --------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-4 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-i128-1.2.0-6.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 1.2.0-6 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-i740-1.1.0-4.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-4 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-i810-2.0.0-5.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 2.0.0-5 - Update Requires and BuildRequires. xorg-x11-drv-jamstudio-1.1.0-3.fc8 ---------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-keyboard-1.1.0-4.fc8 --------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-4 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-magellan-1.1.0-3.fc8 --------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-magictouch-1.0.0.5-4.fc8 ------------------------------------- * Mon Jun 18 2007 Adam Jackson 1.0.0.5-4 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-mga-1.4.6.1-4.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 1.4.6.1-4 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-mouse-1.2.1-3.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 1.2.1-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-mutouch-1.1.0-4.fc8 -------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-4 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-nv-2.0.96-4.fc8 ---------------------------- * Mon Jun 18 2007 Adam Jackson 2.0.96-4 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-palmax-1.1.0-3.fc8 ------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-rendition-4.1.3-4.fc8 ---------------------------------- * Mon Jun 18 2007 Adam Jackson 4.1.3-4 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-s3-0.5.0-4.fc8 --------------------------- * Mon Jun 18 2007 Adam Jackson 0.5.0-4 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-s3virge-1.9.1-4.fc8 -------------------------------- * Mon Jun 18 2007 Adam Jackson 1.9.1-4 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-savage-2.1.2-4.fc8 ------------------------------- * Mon Jun 18 2007 Adam Jackson 2.1.2-4 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-siliconmotion-1.5.1-2.fc8 -------------------------------------- * Mon Jun 18 2007 Adam Jackson 1.5.1-2 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-sis-0.9.3-3.fc8 ---------------------------- * Mon Jun 18 2007 Adam Jackson 0.9.3-3 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-sisusb-0.8.1-6.fc8 ------------------------------- * Mon Jun 18 2007 Adam Jackson 0.8.1-6 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-spaceorb-1.1.0-3.fc8 --------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-summa-1.1.0-3.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-tdfx-1.3.0-5.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 1.3.0-5 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-tek4957-1.1.0-3.fc8 -------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. Use explicit filename instead of glob. xorg-x11-drv-trident-1.2.3-5.fc8 -------------------------------- * Mon Jun 18 2007 Adam Jackson 1.2.3-5 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-tseng-1.1.0-6.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 1.1.0-6 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-ur98-1.1.0-3.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-v4l-0.1.1-6.fc8 ---------------------------- * Mon Jun 18 2007 Adam Jackson 0.1.1-6 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-vesa-1.3.0-9.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 1.3.0-9 - Update Requires and BuildRequires. xorg-x11-drv-via-0.2.2-2.fc8 ---------------------------- * Mon Jun 18 2007 Adam Jackson 0.2.2-2 - Update Requires and BuildRequires. Add Requires: hwdata. xorg-x11-drv-vmmouse-12.4.0-3.fc8 --------------------------------- * Mon Jun 18 2007 Adam Jackson 12.4.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-vmware-10.14.1-2.fc8 --------------------------------- * Mon Jun 18 2007 Adam Jackson 10.14.1-2 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xorg-x11-drv-void-1.1.0-5.fc8 ----------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-5 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-voodoo-1.1.0-5.fc8 ------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-5 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. yum-presto-0.3.10-1.fc7 ----------------------- * Tue May 01 2007 Jonathan Dieter - 0.3.10-1 - Use new -a option to deltarpm to only check against a certain architecture. This allows us to work completely correctly on x86_64. - Add "*" to repository of deltarpm as it *doesn't* screw up depsolving. yum-utils-1.1.5-1.fc8 --------------------- * Mon Jun 18 2007 Tim Lauridsen - mark as 1.1.5 Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From hughsient at gmail.com Tue Jun 19 11:44:01 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 19 Jun 2007 12:44:01 +0100 Subject: rawhide report: 20070619 changes In-Reply-To: <200706191115.l5JBFhD6000304@porkchop.devel.redhat.com> References: <200706191115.l5JBFhD6000304@porkchop.devel.redhat.com> Message-ID: <1182253441.6041.1.camel@work> On Tue, 2007-06-19 at 07:15 -0400, Build System wrote: > kernel-2.6.21-1.3228.fc8 > ------------------------ > * Mon Jun 18 2007 Dave Jones > - 2.6.22-rc5-git1. > > * Mon Jun 18 2007 Jeremy Katz > - add patch from upstream kvm to fix suspend/resume with kvm > loaded (and guests running) If you are getting suspend failures in F7 due to the KVM modules failing to suspend, then please test this kernel. You'll have to remove kvm from SUSPEND_MODULES if you've added them there. Thanks for backporting the patch Jeremy, appreciated. Richard. From buildsys at fedoraproject.org Tue Jun 19 12:56:31 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 19 Jun 2007 08:56:31 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-19 Message-ID: <20070619125631.66867152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 18 ack-1.62-2.fc6 NEW etherbat-1.0.1-2.fc6 : Ethernet topology discovery funtools-1.3.0-0.5.b33.fc6 gnash-0.8.0-1.fc6 libibverbs-1.0.5-1.fc6 NEW mksh-29f-1.fc6 : MirBSD enhanced version of the Korn Shell mod_security-2.1.1-1.fc6 mysql-gui-tools-5.0r12-2.fc6 (!) nethack-vultures-2.1.0-9.fc6 : INVALID rebuild, not published! nginx-0.5.26-1.fc6 NEW oxine-0.6.6-3.fc6 : Lightweight, purely OSD based xine frontend perl-SVK-2.0.1-2.fc6 NEW pfqueue-0.5.6-4.fc6 : Queue manager for the Postfix/Exim Mail Transport Agents NEW postgresql-table_log-0.4.4-2.fc6 : Log data changes in a PostgreSQL table qucs-0.0.12-2.fc6 ragel-5.22-1.fc6 shorewall-3.4.4-1.fc6 NEW tcptraceroute-1.5-0.1.beta7.fc6 : A traceroute implementation using TCP packets Packages built and released for Fedora Extras 5: 8 ack-1.62-2.fc5 libibverbs-1.0.5-1.fc5 mod_security-2.1.1-1.fc5 (!) nethack-vultures-2.1.0-9.fc5 : INVALID rebuild, not published! nginx-0.5.26-1.fc5 qucs-0.0.12-2.fc5 ragel-5.22-1.fc5 shorewall-3.4.4-1.fc5 Changes in Fedora Extras 6: ack-1.62-2.fc6 -------------- * Mon Jun 18 2007 Ian M. Burrell - 1.62-2 - Disable tests since bug not fixed * Sun Jun 17 2007 Ian Burrell - 1.62-1 - Update to 1.62 - Enable tests etherbat-1.0.1-2.fc6 -------------------- * Tue Jun 12 2007 Jon Ciesla 1.0.1-2 - Fixed optflags for 64-bit build. * Thu May 31 2007 Jon Ciesla 1.0.1-1 - Patch removed, static libnet issue fixed upstream. * Thu May 31 2007 Jon Ciesla 1.0.0-1 - Initial packaging. funtools-1.3.0-0.5.b33.fc6 -------------------------- * Thu May 03 2007 Sergio Pascual 1.3.0-0.5.b33 - New upstream version gnash-0.8.0-1.fc6 ----------------- * Sun Jun 17 2007 Patrice Dumas 0.8.0-1 - update to 0.8.0 libibverbs-1.0.5-1.fc6 ---------------------- * Fri Jun 15 2007 Roland Dreier - 1.0.5-1 - New upstream release mksh-29f-1.fc6 -------------- * Sun Jun 03 2007 Robert Scheck 29f-1 - Upgrade to 29f - Initial spec file for Fedora and Red Hat Enterprise Linux mod_security-2.1.1-1.fc6 ------------------------ * Tue Jun 19 2007 Michael Fleming 2.1.1-1 - New upstream release - Drop ASCIIZ rule (fixed upstream) - Re-enable protocol violation/anomalies rules now that REQUEST_FILENAME is fixed upstream. mysql-gui-tools-5.0r12-2.fc6 ---------------------------- * Sun Jun 17 2007 Dennis Gilmore - 5.0r12-1 - add changelog entry * Sun Jun 17 2007 Dennis Gilmore - 5.0r12-1 - update to 5.0r12 nethack-vultures-2.1.0-9.fc6 ---------------------------- * Sat Mar 10 2007 Hans de Goede - 2.1.0-9 - Make the binaries run with their own gid instead of gid games, to minimize results of a possible privelidge escalation (bz 187382) - Fix the crashes on fs<->window toggle on a 16bpp X-server nginx-0.5.26-1.fc6 ------------------ * Mon Jun 18 2007 Jeremy Hinegardner - 0.5.26-1 - Update to 0.5.26 oxine-0.6.6-3.fc6 ----------------- * Fri Jun 15 2007 Matthias Saou 0.6.6-3 - Include desktop entry and icon based on a CD image from the default theme. perl-SVK-2.0.1-2.fc6 -------------------- * Mon Jun 18 2007 Ian M. Burrell - 2.0.1-2 - Add Compress::Zlib to BuildRequires * Sun Jun 17 2007 Ian Burrell - 2.0.1-1 - Update to 2.0.1 - Filter optional File::LibMagic * Tue May 29 2007 Ian M. Burrell - 2.0.0-1 - Update to 2.0.0 pfqueue-0.5.6-4.fc6 ------------------- * Mon Jun 18 2007 Michael Fleming 0.5.6-4 - Initial import into Fedora / EPEL - Fix Source URL * Wed Jun 13 2007 Michael Fleming 0.5.6-3.mf - Remove the rpath from binaries @ build time. postgresql-table_log-0.4.4-2.fc6 -------------------------------- * Sun Jun 17 2007 - Devrim GUNDUZ 0.4.4-2 - Added Requires, per bugzilla review #244536 (Thanks Ruben) - Renamed README file, per bugzilla review #244536 * Sat Jun 16 2007 - Devrim GUNDUZ 0.4.4-1 - Initial RPM packaging for Fedora qucs-0.0.12-2.fc6 ----------------- * Sun Jun 17 2007 Eric Tanguy - 0.0.12-2 - Add perl and iverilog as require * Sun Jun 17 2007 Eric Tanguy - 0.0.12-1 - Update to 0.0.12 * Sat May 05 2007 Eric Tanguy - 0.0.11-2 - Rebuild ragel-5.22-1.fc6 ---------------- * Mon Jun 18 2007 Jeremy Hinegardner - 5.22-1 - update to 5.22 - remove ragel-Makefile-in.patch - it was applied upstream - update ragel-rlcodegen-replace.patch to apply cleanly shorewall-3.4.4-1.fc6 --------------------- * Mon Jun 18 2007 Robert Marcano - 3.4.4-1 - Update to upstream 3.4.4 * Fri May 11 2007 Robert Marcano - 3.4.3-1 - Update to upstream 3.4.3 tcptraceroute-1.5-0.1.beta7.fc6 ------------------------------- * Fri May 04 2007 Sindre Pedersen Bj?rdal - 1.5-0.1.beta7 - Initial build Changes in Fedora Extras 5: ack-1.62-2.fc5 -------------- * Mon Jun 18 2007 Ian M. Burrell - 1.62-2 - Disable tests since bug not fixed * Sun Jun 17 2007 Ian Burrell - 1.62-1 - Update to 1.62 - Enable tests libibverbs-1.0.5-1.fc5 ---------------------- * Fri Jun 15 2007 Roland Dreier - 1.0.5-1 - New upstream release mod_security-2.1.1-1.fc5 ------------------------ * Tue Jun 19 2007 Michael Fleming 2.1.1-1 - New upstream release - Drop ASCIIZ rule (fixed upstream) - Re-enable protocol violation/anomalies rules now that REQUEST_FILENAME is fixed upstream. nethack-vultures-2.1.0-9.fc5 ---------------------------- * Sat Mar 10 2007 Hans de Goede - 2.1.0-9 - Make the binaries run with their own gid instead of gid games, to minimize results of a possible privelidge escalation (bz 187382) - Fix the crashes on fs<->window toggle on a 16bpp X-server nginx-0.5.26-1.fc5 ------------------ * Mon Jun 18 2007 Jeremy Hinegardner - 0.5.26-1 - Update to 0.5.26 qucs-0.0.12-2.fc5 ----------------- * Sun Jun 17 2007 Eric Tanguy - 0.0.12-2 - Add perl and iverilog as require * Sun Jun 17 2007 Eric Tanguy - 0.0.12-1 - Update to 0.0.12 * Sat May 05 2007 Eric Tanguy - 0.0.11-2 - Rebuild * Sun Mar 18 2007 Eric Tanguy - 0.0.11-1 - Update to 0.0.11 ragel-5.22-1.fc5 ---------------- * Mon Jun 18 2007 Jeremy Hinegardner - 5.22-1 - update to 5.22 - remove ragel-Makefile-in.patch - it was applied upstream - update ragel-rlcodegen-replace.patch to apply cleanly shorewall-3.4.4-1.fc5 --------------------- * Mon Jun 18 2007 Robert Marcano - 3.4.4-1 - Update to upstream 3.4.4 * Fri May 11 2007 Robert Marcano - 3.4.3-1 - Update to upstream 3.4.3 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jima at beer.tclug.org Tue Jun 19 13:33:09 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 19 Jun 2007 08:33:09 -0500 (CDT) Subject: End of caching-nameserver package In-Reply-To: <46725C5B.1020703@redhat.com> References: <467117F8.9070201@redhat.com> <46713D10.7080204@codewiz.org> <1181845585.15983.4.camel@localhost> <46725C5B.1020703@redhat.com> Message-ID: On Fri, 15 Jun 2007, Adam Tkac wrote: > Callum Lerwick napsal(a): >> dnsmasq is specifically designed for this purpose, and in fact upstream >> has added dbus support to it specifically so it can integrate nicely >> with NetworkManager. Why we're not using it, I don't know. >> > Of course dnsmasq could be alternative solution for people who hates > BIND. You could package it and start maintain :) As Fedora's dnsmasq maintainer for nearly 14 months, I'm a bit insulted by this. ;-P Jima From ffesti at redhat.com Tue Jun 19 13:39:34 2007 From: ffesti at redhat.com (Florian Festi) Date: Tue, 19 Jun 2007 15:39:34 +0200 Subject: Questions regarding my man/info summer project In-Reply-To: <200706121533.50219.vpivaini@cs.helsinki.fi> References: <200706121533.50219.vpivaini@cs.helsinki.fi> Message-ID: <4677DC96.3000301@redhat.com> Hi! I have to admit that I don't have any idea how (or better if) our man pages are kept up2date. After having a short look at the groff format I am very sure that no one wants to edit that. (Info pages are a different thing). So the question is how can the man pages transformed into wiki markup and back without loss of information. There is some groff markup that naturally translates into wiki markup. For all other stuff you could write MoinMoin macros. For creating the diffs you should be able to translate the wiki page back to groff and do the diffs between the groff versions insted of the wiki markup pages. That way the patches are much more likely to be useful for updating the man pages. The easiest way of translating page content is using an Formatter. But that won't help for the non MoinMoin markup features you'd modeled as macros. The way out is special casing the output of the macros depending on the formatter used. If they get an groff formatter they return the groff source otherwise they use the formatter to highlight the text properly. If you have questions feel free to ask my on #moin or #moin-dev. Florian Festi From jima at beer.tclug.org Tue Jun 19 13:53:25 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 19 Jun 2007 08:53:25 -0500 (CDT) Subject: user created at install added in sudoers ? In-Reply-To: <4673037B.3030105@laposte.net> References: <4673037B.3030105@laposte.net> Message-ID: On Fri, 15 Jun 2007, Axel wrote: > What do you think about adding the user created at install to the sudoers > list ? > > For newbies like me, understanding the sudoers file isn't so easy, but > nevertheless they may need the sudo command. In my case, I'd rather my > account would have been added automatically to the sudoers list :) I personally can't agree with this, as suggested. If, however, there were a checkbox (defaulted off!) saying "add this user to wheel group" (or whichever group), you'd get my vote. Jima From sundaram at fedoraproject.org Tue Jun 19 14:12:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 19:42:51 +0530 Subject: can Kpowersave be installed on FC3? In-Reply-To: <1182241843.10697.1.camel@pc67244168.ddns.htc.nl.philips.com> References: <1182241843.10697.1.camel@pc67244168.ddns.htc.nl.philips.com> Message-ID: <4677E463.80404@fedoraproject.org> LIN QIU wrote: > Dear concerned, > > I am using FC3, can I install kpowersave? I had searched internet, but > did not find available rpm. > You can probably find a old package or rebuild a existing package but Fedora Core 3 has stopped getting any updates for a long time now and would have a number of security holes in it. You really should update to a more recent version of Fedora like Fedora Core 6 or Fedora 7. Rahul From jwboyer at jdub.homelinux.org Tue Jun 19 14:17:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Jun 2007 09:17:34 -0500 Subject: can Kpowersave be installed on FC3? In-Reply-To: <4677E463.80404@fedoraproject.org> References: <1182241843.10697.1.camel@pc67244168.ddns.htc.nl.philips.com> <4677E463.80404@fedoraproject.org> Message-ID: <1182262654.6126.24.camel@weaponx.rchland.ibm.com> On Tue, 2007-06-19 at 19:42 +0530, Rahul Sundaram wrote: > LIN QIU wrote: > > Dear concerned, > > > > I am using FC3, can I install kpowersave? I had searched internet, but > > did not find available rpm. > > > > You can probably find a old package or rebuild a existing package but > Fedora Core 3 has stopped getting any updates for a long time now and > would have a number of security holes in it. You really should update to > a more recent version of Fedora like Fedora Core 6 or Fedora 7. Or use a distribution such as RHEL or CentOS if you need something with a longer support lifetime. josh From sundaram at fedoraproject.org Tue Jun 19 14:19:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 19:49:58 +0530 Subject: The updates firehose In-Reply-To: References: <200706091605.00638.jkeating@redhat.com> <1181421127.4813.33.camel@localhost.localdomain> <4676D2B3.7090005@fedoraproject.org> Message-ID: <4677E60E.3090204@fedoraproject.org> Pete Chown wrote: > Rahul Sundaram wrote: > >> Wouldn't the ability to filter updates based on classifications >> (security, bug fixes, enhancements etc) provide what you want instead of >> separate update streams? > > That would probably be better than what I suggested, actually, as it > would allow for more detailed classification of updates. So then you problem is already getting solved sooner or later when the update system gets the ability to push out the proper metadata. You might also want to look at the yum-security package meanwhile. Rahul From snecklifter at gmail.com Tue Jun 19 14:21:11 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 19 Jun 2007 15:21:11 +0100 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> Message-ID: <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> On 19/06/07, Jima wrote: > > On Fri, 15 Jun 2007, Axel wrote: > > What do you think about adding the user created at install to the > sudoers > > list ? > > > > For newbies like me, understanding the sudoers file isn't so easy, but > > nevertheless they may need the sudo command. In my case, I'd rather my > > account would have been added automatically to the sudoers list :) > > I personally can't agree with this, as suggested. If, however, there > were a checkbox (defaulted off!) saying "add this user to wheel group" (or > whichever group), you'd get my vote. > I like this option but would prefer something more newbie-friendly such as: "Add this user to sudo list" or "Give this user root privileges (with sudo)" or "Make this user an administrator (sudo)" or some such. Whatever, it would be good to see this in F8 as the code is already there and like Axel I find it a useful feature of other Linux distributions. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From snecklifter at gmail.com Tue Jun 19 14:28:30 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 19 Jun 2007 15:28:30 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> Message-ID: <364d303b0706190728p37f70aecxdd4aabd7ac4dc0d2@mail.gmail.com> On 19/06/07, Chris Brown wrote: > > On 19/06/07, Jima wrote: > > > > On Fri, 15 Jun 2007, Axel wrote: > > > What do you think about adding the user created at install to the > > sudoers > > > list ? > > > > > > For newbies like me, understanding the sudoers file isn't so easy, but > > > nevertheless they may need the sudo command. In my case, I'd rather my > > > account would have been added automatically to the sudoers list :) > > > > I personally can't agree with this, as suggested. If, however, there > > were a checkbox (defaulted off!) saying "add this user to wheel group" > > (or > > whichever group), you'd get my vote. > > > > I like this option but would prefer something more newbie-friendly such > as: > > "Add this user to sudo list" > or > "Give this user root privileges (with sudo)" > or > "Make this user an administrator (sudo)" > or some such. > > Whatever, it would be good to see this in F8 as the code is already there > and like Axel I find it a useful feature of other Linux distributions. I have re-opened the original RFE and linked to this discussion. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188 Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Tue Jun 19 14:29:31 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 19 Jun 2007 09:29:31 -0500 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> Message-ID: <16de708d0706190729h7c011240s6cc1f9ad8a8a56b0@mail.gmail.com> On 6/19/07, Chris Brown wrote: > On 19/06/07, Jima wrote: > > On Fri, 15 Jun 2007, Axel wrote: > > > What do you think about adding the user created at install to the > sudoers > > > list ? > > > > > > For newbies like me, understanding the sudoers file isn't so easy, but > > > nevertheless they may need the sudo command. In my case, I'd rather my > > > account would have been added automatically to the sudoers list :) > > > > I personally can't agree with this, as suggested. If, however, there > > were a checkbox (defaulted off!) saying "add this user to wheel group" (or > > whichever group), you'd get my vote. > > > > I like this option but would prefer something more newbie-friendly such as: > > "Add this user to sudo list" > or > "Give this user root privileges (with sudo)" > or > "Make this user an administrator (sudo)" > or some such. > > Whatever, it would be good to see this in F8 as the code is already there > and like Axel I find it a useful feature of other Linux distributions. > > > Regards > Chris +1 for "Giving this user administrative privileges" -- Fedora Core 6 and proud From n0dalus+redhat at gmail.com Tue Jun 19 14:48:04 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 20 Jun 2007 00:18:04 +0930 Subject: user created at install added in sudoers ? In-Reply-To: <20070619104632.GC28744@jadzia.bu.edu> References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> <6280325c0706182153rcd68487u5d3c2dd94ade7bba@mail.gmail.com> <20070619104632.GC28744@jadzia.bu.edu> Message-ID: <6280325c0706190748j740d67mf4f92dabdda6d2a8@mail.gmail.com> On 6/19/07, Matthew Miller wrote: > > > While some people take the effort to use a different root password and > > keep it separate from other passwords, very few people separate their > > user account password from the myriad of other authentications, and > > they shouldn't have to. It's reasonable and sensible that people reuse > > their more trivial passwords, and for them to save their commonly used > > passwords in commonly used applications. > > Yes, well, a system administrator enabled password isn't one of those > trivial passwords. I agree with your point about myriads of passwords, but > it's vital to recognize which ones are actually important. I'm not sure > encouraging horrible password practice should be a design goal. I think that's the point I was trying to make. Normal users don't treat their passwords as administrator passwords, they treat them as normal user passwords. By putting them in sudoers by default you are encouraging horrible password practice by making their normal user passwords equivalent to administrator passwords, when most users don't understand this or its implications. n0dalus. From jima at beer.tclug.org Tue Jun 19 14:50:12 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 19 Jun 2007 09:50:12 -0500 (CDT) Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> Message-ID: On Tue, 19 Jun 2007, Chris Brown wrote: > On 19/06/07, Jima wrote: >> I personally can't agree with this, as suggested. If, however, there >> were a checkbox (defaulted off!) saying "add this user to wheel group" (or >> whichever group), you'd get my vote. > > I like this option but would prefer something more newbie-friendly such as: > > "Add this user to sudo list" > or > "Give this user root privileges (with sudo)" > or > "Make this user an administrator (sudo)" > or some such. > > Whatever, it would be good to see this in F8 as the code is already there > and like Axel I find it a useful feature of other Linux distributions. I don't really care exactly what it says, just as long as it's a non-default option. Making it default behavior seems like it'd come with backlash. All of those text suggestions seem fine, BTW. :-) Jima From pemboa at gmail.com Tue Jun 19 14:56:51 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 19 Jun 2007 09:56:51 -0500 Subject: user created at install added in sudoers ? In-Reply-To: References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> Message-ID: <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> On 6/19/07, Jima wrote: > On Tue, 19 Jun 2007, Chris Brown wrote: > > On 19/06/07, Jima wrote: > >> I personally can't agree with this, as suggested. If, however, there > >> were a checkbox (defaulted off!) saying "add this user to wheel group" (or > >> whichever group), you'd get my vote. > > > > I like this option but would prefer something more newbie-friendly such as: > > > > "Add this user to sudo list" > > or > > "Give this user root privileges (with sudo)" > > or > > "Make this user an administrator (sudo)" > > or some such. > > > > Whatever, it would be good to see this in F8 as the code is already there > > and like Axel I find it a useful feature of other Linux distributions. > > I don't really care exactly what it says, just as long as it's a > non-default option. Making it default behavior seems like it'd come with > backlash. All of those text suggestions seem fine, BTW. :-) > > Jima This would be a good time to _bring back_ password strength testing/information on install. -- Fedora Core 6 and proud From pjones at redhat.com Tue Jun 19 15:11:11 2007 From: pjones at redhat.com (Peter Jones) Date: Tue, 19 Jun 2007 11:11:11 -0400 Subject: Root filesystem encryption update In-Reply-To: References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> Message-ID: <4677F20F.8050405@redhat.com> Tony Nelson wrote: > At 4:50 PM -0500 6/18/07, Bruno Wolff III wrote: >> On Mon, Jun 18, 2007 at 16:51:55 -0400, >> Jeremy Katz wrote: >>> On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote: > ... >>>> Heck, for key maps there probably aren't so many that you can't try >>>> multiple possibilities after getting the password. >>> There are at least 30-40 that we allow in the installer alone at the >>> console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140. >>> I don't think that trying either is really that practical. >> 40 probably isn't too many to make trying them all impractical. I expect >> that it will take less than a second to try each one even with measures >> to slow down password guessing. That's not nice for suspend resume, but >> wouldn't be a deal breaker for initial boots. > ... > > Couldn't it just start with the one that worked last time? Not really. We need to ask for the passphrase during thaw, in the initrd. At that time, the filesystem containing /boot is in the mounted state, so we can't mount it to write the data anywhere. There's also no mechanism to pass data from the running kernel to the one we're restoring into memory, which means we can't save the data during the userland thaw sequence, either. -- Peter From SteveD at redhat.com Tue Jun 19 15:15:50 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 19 Jun 2007 11:15:50 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> Message-ID: <4677F326.20905@RedHat.com> Arthur Pemberton wrote: > This would be a good time to _bring back_ password strength > testing/information on install. Here Here! As long as there is a way to get around it! ;-) I have to admit the way ubuntu has it set up is very convenient when it comes to adding printers and such. So I think it does make sense to create a default sudo entry on *only* workstation installation. Server installations are a different story.... The last think you want is everybody and their brother change anything and everything on a server... So, imho, depending on the uses of the machine should define if a sudo account will automatically be enabled... steved. From sb at monkey-mind.net Tue Jun 19 15:37:02 2007 From: sb at monkey-mind.net (Steven Bakker) Date: Tue, 19 Jun 2007 17:37:02 +0200 Subject: user created at install added in sudoers ? In-Reply-To: <4677F326.20905@RedHat.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> Message-ID: <20070619173702.4b491a51@cluestix.noc.ams-ix.net> On Tue, 19 Jun 2007 11:15:50 -0400 Steve Dickson wrote: > I have to admit the way ubuntu has it set up is very convenient > when it comes to adding printers and such. So I think it does > make sense to create a default sudo entry on *only* workstation > installation. Server installations are a different story.... > The last think you want is everybody and their brother change > anything and everything on a server... > > So, imho, depending on the uses of the machine should define > if a sudo account will automatically be enabled... +1 > steved. steveb From skvidal at linux.duke.edu Tue Jun 19 15:41:56 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 19 Jun 2007 11:41:56 -0400 Subject: rawhide report: 20070619 changes In-Reply-To: <1182253441.6041.1.camel@work> References: <200706191115.l5JBFhD6000304@porkchop.devel.redhat.com> <1182253441.6041.1.camel@work> Message-ID: <1182267716.2865.0.camel@hodge> On Tue, 2007-06-19 at 12:44 +0100, Richard Hughes wrote: > On Tue, 2007-06-19 at 07:15 -0400, Build System wrote: > > kernel-2.6.21-1.3228.fc8 > > ------------------------ > > * Mon Jun 18 2007 Dave Jones > > - 2.6.22-rc5-git1. > > > > * Mon Jun 18 2007 Jeremy Katz > > - add patch from upstream kvm to fix suspend/resume with kvm > > loaded (and guests running) > > If you are getting suspend failures in F7 due to the KVM modules failing > to suspend, then please test this kernel. You'll have to remove kvm from > SUSPEND_MODULES if you've added them there. > > Thanks for backporting the patch Jeremy, appreciated. is this the same build as 3228.fc7 w/just the distag difference? or are they more divergent? -sv From thomas.swan at gmail.com Tue Jun 19 15:48:44 2007 From: thomas.swan at gmail.com (Thomas Swan) Date: Tue, 19 Jun 2007 10:48:44 -0500 Subject: Root filesystem encryption update In-Reply-To: <4677F20F.8050405@redhat.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <4677F20F.8050405@redhat.com> Message-ID: On 6/19/07, Peter Jones wrote: > > Tony Nelson wrote: > > At 4:50 PM -0500 6/18/07, Bruno Wolff III wrote: > >> On Mon, Jun 18, 2007 at 16:51:55 -0400, > >> Jeremy Katz wrote: > >>> On Mon, 2007-06-18 at 14:07 -0500, Bruno Wolff III wrote: > > ... > >>>> Heck, for key maps there probably aren't so many that you can't try > >>>> multiple possibilities after getting the password. > >>> There are at least 30-40 that we allow in the installer alone at the > >>> console. find -type f /lib/kbd/keymaps/i386 | wc -l gives around 140. > >>> I don't think that trying either is really that practical. > >> 40 probably isn't too many to make trying them all impractical. I > expect > >> that it will take less than a second to try each one even with measures > >> to slow down password guessing. That's not nice for suspend resume, but > >> wouldn't be a deal breaker for initial boots. > > ... > > > > Couldn't it just start with the one that worked last time? > > Not really. We need to ask for the passphrase during thaw, in the > initrd. At that time, the filesystem containing /boot is in the mounted > state, so we can't mount it to write the data anywhere. There's also no > mechanism to pass data from the running kernel to the one we're > restoring into memory, which means we can't save the data during the > userland thaw sequence, either. I think we might be putting the cart before the horse. A user would be thawing from hibernation on a machine with an *existing* installation. Therefore language, and keymaps would have been chosen (during installation) prior to the hibernate operation. Could it be possible to store the keyboard map in the initrd. During the install we select all of these. So, adding an option to /etc/sysconfig/mkinitrd for KEYMAP and/or LANGUAGE and saving/loading it in the initrd (by regeneration) after installation should be pretty straightforward. We could switch to the encryption options after keyboard/language has been selected/loaded. Is this even plausible? -- The early bird may get the worm, but the it's the second mouse that gets the cheese. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Tue Jun 19 16:05:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Jun 2007 12:05:42 -0400 Subject: rawhide report: 20070619 changes In-Reply-To: <1182267716.2865.0.camel@hodge> References: <200706191115.l5JBFhD6000304@porkchop.devel.redhat.com> <1182253441.6041.1.camel@work> <1182267716.2865.0.camel@hodge> Message-ID: <20070619160542.GB19682@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > > If you are getting suspend failures in F7 due to the KVM modules failing > > to suspend, then please test this kernel. You'll have to remove kvm from > > SUSPEND_MODULES if you've added them there. > > > > Thanks for backporting the patch Jeremy, appreciated. > > is this the same build as 3228.fc7 w/just the distag difference? F7 kernels are 2.6.21.x, F8 are 2.6.22-rc. So, no. Bill From tchung at fedoraproject.org Tue Jun 19 16:32:58 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Tue, 19 Jun 2007 09:32:58 -0700 Subject: wiki account v fedora account system In-Reply-To: <46768BCA.6010003@iinet.net.au> References: <46768BCA.6010003@iinet.net.au> Message-ID: <369bce3b0706190932j7e6132dco94daf9ee9e8205d3@mail.gmail.com> On 6/18/07, David Timms wrote: > Hi, I'm sure this has been asked before but it isn't showing up in a search: > > I organised the CLA and wiki sign up last year, and also have a bugzilla > account. Does these accounts move to the new fedora account system, or > do I need to do the whole process as described in: > http://fedoraproject.org/wiki/Infrastructure/AccountSystem > if I want to be able contribute to more than the wiki ? > > DaveT. Hi David, Basically yes. You need to complete CLA as described in Fedora Account System[1]. There is even HOWTO[2] for it. :) Regards, [1] http://fedoraproject.org/wiki/Infrastructure/AccountSystem [2] http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From mattdm at mattdm.org Tue Jun 19 17:34:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Jun 2007 13:34:02 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> Message-ID: <20070619173402.GA29865@jadzia.bu.edu> On Tue, Jun 19, 2007 at 03:21:11PM +0100, Chris Brown wrote: > I like this option but would prefer something more newbie-friendly such as: > "Add this user to sudo list" > or > "Give this user root privileges (with sudo)" > or > "Make this user an administrator (sudo)" > or some such. I think the word "sudo" should be taken out, because sudo isn't actually involved if you're using usermode or (future) PolicyKit. > Whatever, it would be good to see this in F8 as the code is already there > and like Axel I find it a useful feature of other Linux distributions. And, not that we're copycats or anything, it's what Mac OS X does. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Jun 19 17:46:37 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Jun 2007 13:46:37 -0400 Subject: suggestions for admin-power users [was Re: user created at install added in sudoers ?] In-Reply-To: <364d303b0706190728p37f70aecxdd4aabd7ac4dc0d2@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <364d303b0706190728p37f70aecxdd4aabd7ac4dc0d2@mail.gmail.com> Message-ID: <20070619174637.GB29865@jadzia.bu.edu> On Tue, Jun 19, 2007 at 03:28:30PM +0100, Chris Brown wrote: > I have re-opened the original RFE and linked to this discussion. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188 And I've re-closed it, not to be a jerk, but because that basic infrastructure is all good and done. New issues should get new bugs. And actually, I think several separate ones: 1) Add a tab to system-config-securitylevel to manage the /etc/security/console.apps entries. This would let you choose which groups are added to UGROUPS for which programs. (It could also maybe allow individual users, but since Fedora does the per-user group thing, that's a bit redundant.) This tab could also configure various levels of sudo access, either by editing /etc/sudoers (a bit dangerous) or by adding and removing from predefined groups there. In the future, it would drive our Super Better Mechanism For Doing This Stuff. It might be nice to have an easy way to jump from here to system-config-users. (See #4.) 2) Choose default policies for the above -- maybe wheel group activated by default for some programs. 3) Add the "make this user an admin" checkbox in firstboot. 4) I have a patch which adds an "Admin" column to system-config-users -- checking it adds that user to the wheel group, unchecking removes. This is handy because it makes it obvious at a glace who has the power. 5) Can we pretty-please enable pam_passwdqc for all users, even root? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sean.stangl at gmail.com Tue Jun 19 18:00:12 2007 From: sean.stangl at gmail.com (Sean Stangl) Date: Tue, 19 Jun 2007 14:00:12 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <4677F326.20905@RedHat.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> Message-ID: <1182276012.20455.1.camel@moogle> On Tue, 2007-06-19 at 11:15 -0400, Steve Dickson wrote: > So, imho, depending on the uses of the machine should define > if a sudo account will automatically be enabled... Precisely why such a decision should not be an automatic but rather an install-time option, such as those which Chris Brown offered. -Sean From sundaram at fedoraproject.org Tue Jun 19 18:12:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 23:42:55 +0530 Subject: user created at install added in sudoers ? In-Reply-To: <1182276012.20455.1.camel@moogle> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> Message-ID: <46781CA7.2000706@fedoraproject.org> Sean Stangl wrote: > On Tue, 2007-06-19 at 11:15 -0400, Steve Dickson wrote: >> So, imho, depending on the uses of the machine should define >> if a sudo account will automatically be enabled... > > Precisely why such a decision should not be an automatic but rather an > install-time option, such as those which Chris Brown offered. Oh please. Just pick one choice and stick with it. People who know better can configure it to meet their needs. It is pretty miserably painful trying to document the amount of choices we offer already. Rahul From jdieter at gmail.com Tue Jun 19 18:32:48 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 19 Jun 2007 21:32:48 +0300 Subject: Official presto repositories for Rawhide In-Reply-To: References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: <1182277968.4303.59.camel@jndwidescreen.lesbg.loc> On Mon, 2007-06-18 at 09:56 -0500, Rex Dieter wrote: > Jonathan Dieter wrote: > > > I would like to request the creation of presto repositories for Rawhide. > ... > > The presto repository creation tools probably need to be looked over, > > but I think it's time to start creating "official" deltarpms if we're > > going to make it into F8. > > Prereq: presto repository creation tools need to be submitted for review, > and imported into Fedora. > > -- Rex > I've spent the last few hours doing some work on createprestorepo and createdeltarpms (renamed from makedeltarepo because it made no sense whatsoever). To highlight, you can now specify how many deltarpms to make per package from the command-line in createdeltarpms and createprestorepo now plays nicely with createrepo (to the point that it uses modifyrepo included with createrepo if the -m command-line switch is used). Fedoraproject.org seems to be down for the moment and it's time for me to head to bed, but I've put together a spec file, rpm and srpm for review. I'll do all the "fun" stuff of officially opening a bug, etc. tomorrow. Both the rpm and source rpm pass rpmlint with no errors. The links are: http://www.lesbg.com/jdieter/presto/presto-utils-0.2.0-1.fc7.noarch.rpm http://www.lesbg.com/jdieter/presto/presto-utils-0.2.0-1.fc7.src.rpm http://www.lesbg.com/jdieter/presto/presto-utils.spec Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Tue Jun 19 17:51:41 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 19 Jun 2007 20:51:41 +0300 Subject: Packaging guidelines: ScriptletSnippets fixes Message-ID: <200706192051.42210.ville.skytta@iki.fi> Guidelines change: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets The scriptlet snippets page in Wiki has been updated to fix some inaccuracies in scriptlet exit statuses and scriptlet termination causes. Changes: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&rev2=9&rev1=7 _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From a.badger at gmail.com Tue Jun 19 18:48:08 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Jun 2007 11:48:08 -0700 Subject: OCaml Guidelines Message-ID: <1182278888.29855.44.camel@localhost.localdomain> The guidelines created by our hardworking OCaml SIG have been approved by the Packaging Committee and FESCo. Everyone who has been wondering about the difference between a cmi, cmx, and cma can visit:: http://fedoraproject.org/wiki/Packaging/OCaml for the official word on what they mean and how to package them. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From a.badger at gmail.com Tue Jun 19 18:48:13 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Jun 2007 11:48:13 -0700 Subject: Bugzilla Products for Fedora Core and Fedora Extras merged Message-ID: <1182278893.29855.45.camel@localhost.localdomain> Greetings, Until yesterday, bugzilla.redhat.com was living in the past, holding onto the former glory memory of a separate Fedora Core and Fedora Extras. Thanks to the hard work of our bugzilla admins, bugzilla has caught up to the present and those products have been united under one simple name, Fedora. All old bugs targeting Fedora Extras or Fedora Core now target Fedora instead. All packages which were once a part of Fedora Core or Fedora Extras are now members of Fedora. As part of this change, owners.list has been updated. This was largely a trivial replacement of "Fedora Extras" or "Fedora Core" with "Fedora" but in a few places the package had been present in both Core and Extras. For these, the packages have been merged with the owners and initialcc list for each being combined. This means that a few packagers in Extras who gave up their packages to Core maintainers or vice versa may now be listed as a co-owner. You can check whether this is the case for any of your packages by checking out the current owners.list from cvs: CVSROOT=:ext:URSERNAME at cvs.fedora.redhat.com:/cvs/extras cvs co owners and verifying that your name is associated with the packages you wish. If everything is fine, nothing needs to be done. If you want to make a change, please follow the procedure here: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure to make your change requests. Thanks, Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jwboyer at jdub.homelinux.org Tue Jun 19 18:53:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Jun 2007 13:53:03 -0500 Subject: Bugzilla Products for Fedora Core and Fedora Extras merged In-Reply-To: <1182278893.29855.45.camel@localhost.localdomain> References: <1182278893.29855.45.camel@localhost.localdomain> Message-ID: <1182279183.6126.69.camel@weaponx.rchland.ibm.com> On Tue, 2007-06-19 at 11:48 -0700, Toshio Kuratomi wrote: > You can check whether this is the case for any of your packages by > checking out the current owners.list from cvs: > CVSROOT=:ext:URSERNAME at cvs.fedora.redhat.com:/cvs/extras cvs co owners :/cvs/pkgs Stop living in CVS past! ;) josh From opensource at till.name Tue Jun 19 18:48:49 2007 From: opensource at till.name (Till Maas) Date: Tue, 19 Jun 2007 20:48:49 +0200 Subject: x86_64 kde live cd image > 800MB In-Reply-To: <200706172016.52174.jkeating@redhat.com> References: <200706172013.47230.darth_linux@ameritech.net> <200706172016.52174.jkeating@redhat.com> Message-ID: <200706192048.53371.opensource@till.name> On Mo Juni 18 2007, Jesse Keating wrote: > It's not a Live"CD". It's Live Media. You'll have to use a DVD or USB key > for it. Due to multilib, the x86_64 Live media is bigger than the pure > i386 one. What about the release isos. Is it not possible to use them on an USB key or use the rescuecd on a DVD? Otherwise I suggest to rename F-7-$arch-DVD.iso to F-7-$arch.iso and F-7-$arch-rescuecd.iso to F-7-$arch-rescue.iso This will make it more obvious, that the images are not intended to be used only with a special kind of media. And because it is not a 8.3 filename anyway, I suggest to use "Fedora" instead of only "F" in the beginning of the iso filenames. Regards, Till From sundaram at fedoraproject.org Tue Jun 19 18:59:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Jun 2007 00:29:04 +0530 Subject: Bugzilla Products for Fedora Core and Fedora Extras merged In-Reply-To: <1182278893.29855.45.camel@localhost.localdomain> References: <1182278893.29855.45.camel@localhost.localdomain> Message-ID: <46782778.8080104@fedoraproject.org> Toshio Kuratomi wrote: > Greetings, > > Until yesterday, bugzilla.redhat.com was living in the past, > holding onto the former glory memory of a separate Fedora Core and > Fedora > Extras. https://bugzilla.redhat.com/ links to http://fedora.redhat.com/participate/communicate/ which should be replaced by http://fedoraproject.org/wiki/Communicate Rahul From opensource at till.name Tue Jun 19 19:25:31 2007 From: opensource at till.name (Till Maas) Date: Tue, 19 Jun 2007 21:25:31 +0200 Subject: Bugzilla Products for Fedora Core and Fedora Extras merged In-Reply-To: <1182279183.6126.69.camel@weaponx.rchland.ibm.com> References: <1182278893.29855.45.camel@localhost.localdomain> <1182279183.6126.69.camel@weaponx.rchland.ibm.com> Message-ID: <200706192125.33399.opensource@till.name> On Di Juni 19 2007, Josh Boyer wrote: > On Tue, 2007-06-19 at 11:48 -0700, Toshio Kuratomi wrote: > > You can check whether this is the case for any of your packages by > > checking out the current owners.list from cvs: > > CVSROOT=:ext:URSERNAME at cvs.fedora.redhat.com:/cvs/extras cvs co owners > > > :/cvs/pkgs > > Stop living in CVS past! ;) It sucks more and more, that the wiki is not up-to-date. I wondered, too, whether or not it is still /cvs/extras or not, but http://fedoraproject.org/wiki/PackageMaintainers/Join#head-29b1437eeedc9e87ea0e5c92a9e52684876c30a3 confirmed /cvs/extras. But your URL is not completely up-to-date, either, it is cvs.fedoraproject.org:/cvs/pkgs now. Regards, Till From jwboyer at jdub.homelinux.org Tue Jun 19 19:34:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Jun 2007 14:34:23 -0500 Subject: Bugzilla Products for Fedora Core and Fedora Extras merged In-Reply-To: <200706192125.33399.opensource@till.name> References: <1182278893.29855.45.camel@localhost.localdomain> <1182279183.6126.69.camel@weaponx.rchland.ibm.com> <200706192125.33399.opensource@till.name> Message-ID: <1182281663.6126.91.camel@weaponx.rchland.ibm.com> On Tue, 2007-06-19 at 21:25 +0200, Till Maas wrote: > On Di Juni 19 2007, Josh Boyer wrote: > > On Tue, 2007-06-19 at 11:48 -0700, Toshio Kuratomi wrote: > > > You can check whether this is the case for any of your packages by > > > checking out the current owners.list from cvs: > > > CVSROOT=:ext:URSERNAME at cvs.fedora.redhat.com:/cvs/extras cvs co owners > > > > > :/cvs/pkgs > > > > Stop living in CVS past! ;) > > It sucks more and more, that the wiki is not up-to-date. I wondered, too, I totally agree. > whether or not it is still /cvs/extras or not, but > http://fedoraproject.org/wiki/PackageMaintainers/Join#head-29b1437eeedc9e87ea0e5c92a9e52684876c30a3 > confirmed /cvs/extras. > > But your URL is not completely up-to-date, either, it is > > cvs.fedoraproject.org:/cvs/pkgs > > now. Correct. And I see you have updated that page. Many thanks! josh From anthonybryan at gmail.com Tue Jun 19 19:40:59 2007 From: anthonybryan at gmail.com (Anthony Bryan) Date: Tue, 19 Jun 2007 15:40:59 -0400 Subject: Improving availability and guaranteeing integrity in ISO downloads Message-ID: > On Sat, Jun 09, 2007 at 07:51:20PM +0200, Ruben Kerkhof wrote: > > On 9-jun-2007, at 14:39, Matt Domsch wrote: > > > > > >I replied on fedora-infrastructure-list just a bit ago. I'm happy to > > >see this functionality get added to mirrormanager, and am happy to > > >review patches as well. :-) The trick will be having a python module > > >that, given a list of URL/country tuples, generates the XML pages. > > >Which probably isn't that hard, really. > > > > File attached :-) > > > > My Python skills suck, so feel free to improve it. It doesn't > > implement all fields in the MetaLink specification, but it should do > > the job. > > Wow, that was fast. I'll look at this, but would you mind using the > MIT/X11 license (the same license as Python and TurboGears themselves > use, as does mirrormanager) rather than the GNU GPL? I'd rather not > get into a license incompatibility mess this early in mirrormanager's > life. :-) Hi Matt, Have you had a chance to look over Ruben's additions? Any feedback? He said he re-licensed it to line up w/ mirrormanager. Any ideas/comments for features in Metalink that could be of use to Fedora? thanks, -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, and Automatically Repairable Downloads From opensource at till.name Tue Jun 19 19:55:59 2007 From: opensource at till.name (Till Maas) Date: Tue, 19 Jun 2007 21:55:59 +0200 Subject: Bugzilla Products for Fedora Core and Fedora Extras merged In-Reply-To: <1182281663.6126.91.camel@weaponx.rchland.ibm.com> References: <1182278893.29855.45.camel@localhost.localdomain> <200706192125.33399.opensource@till.name> <1182281663.6126.91.camel@weaponx.rchland.ibm.com> Message-ID: <200706192156.03956.opensource@till.name> On Di Juni 19 2007, Josh Boyer wrote: > Correct. And I see you have updated that page. Many thanks! Hm, ich updated some other pages, too. There are a lot of pages that still mention cvs.fedora.redhat.com [1]. When I use the wiki, it only responds very slow to submitted data. Is there somewhere a tasklist, what still has to be done, to finish the merge? E.g. there is still the category "CategoryExtras" used and the french translation is seems not to be moved from "fr_FR/Extras" to "fr_FR/PackageMaintainers". I guess this affects other translations, too. And is there somewhere the difference between fedora.redhat.com and fedoraproject.org explained? Afaik everything should have moved from f.r.c to f.o to make the community aspect of Fedora more clear. But e.g. http://cvs.fedoraproject.com/ shows the Fedora Project page and http://cvs.fedora.redhat.com/ some somehow unmaintained and out-of-date cvs documentation. [1] http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge/FAQ?action=fullsearch&context=180&value=cvs.fedora.redhat.com&fullsearch=Text Regards, Till From williams at redhat.com Tue Jun 19 20:29:00 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 19 Jun 2007 15:29:00 -0500 Subject: Official presto repositories for Rawhide In-Reply-To: <1182215959.7680.6.camel@aglarond.local> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> Message-ID: <46783C8C.1000004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Katz wrote: > On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote: >> On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote: >>> The question is where in the process does it make sense to generate >>> the deltas. Do we do them in the build system (the koji level)? Do >>> we do them in the update system?[1] Do we do them at tree compose >>> (mash) time? Each has tradeoffs... not sure which is really the >>> best. >> The problme domain are the limited bandwidth of end users, so you want >> it to run on what end users consume. This can be different for >> released versions vs rawhide, but in general released versions would >> only perform this on updates-released (not updates-testing) and >> for rawhide on everything. > > Yeah, it's easy to see that deltas for -updates and -updates-testing[1] > from the release and probably the last update make sense[2]. rawhide is > definitely the trickier to figure out where to draw the line. Do you even want to draw that line in rawhide? To me, rawhide is dangerous enough that trying to add delta updates on top of it is just asking for (more) trouble. I think that -updates* is perfect for deltas, because the latest package is almost always going to be an iteration on the previous version(s). But rawhide might be a complete version jump, or changing toolchains, or trying something just plain whacky. The potential for space saving due to commonality doesn't seem to be there for rawhide. just my 0.02 (insert your monetary unit) Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGeDyLHyuj/+TTEp0RAqKPAKDlbfsvr+qCNBYCrbQ2d/QcsiSSsACfQZuM NSyJOH5eUvsvF3eB5BlyzV8= =UGWj -----END PGP SIGNATURE----- From katzj at redhat.com Tue Jun 19 20:35:31 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Jun 2007 16:35:31 -0400 Subject: Official presto repositories for Rawhide In-Reply-To: <46783C8C.1000004@redhat.com> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> <46783C8C.1000004@redhat.com> Message-ID: <1182285331.16660.6.camel@erebor.boston.redhat.com> On Tue, 2007-06-19 at 15:29 -0500, Clark Williams wrote: > Jeremy Katz wrote: > > On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote: > >> On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote: > >>> The question is where in the process does it make sense to generate > >>> the deltas. Do we do them in the build system (the koji level)? Do > >>> we do them in the update system?[1] Do we do them at tree compose > >>> (mash) time? Each has tradeoffs... not sure which is really the > >>> best. > >> The problme domain are the limited bandwidth of end users, so you want > >> it to run on what end users consume. This can be different for > >> released versions vs rawhide, but in general released versions would > >> only perform this on updates-released (not updates-testing) and > >> for rawhide on everything. > > > > Yeah, it's easy to see that deltas for -updates and -updates-testing[1] > > from the release and probably the last update make sense[2]. rawhide is > > definitely the trickier to figure out where to draw the line. > > Do you even want to draw that line in rawhide? To me, rawhide is > dangerous enough that trying to add delta updates on top of it is just > asking for (more) trouble. > > I think that -updates* is perfect for deltas, because the latest package > is almost always going to be an iteration on the previous version(s). > But rawhide might be a complete version jump, or changing toolchains, or > trying something just plain whacky. The potential for space saving due > to commonality doesn't seem to be there for rawhide. The space savings benefit isn't really the win for rawhide -- it's more the testing base and being able to ensure that things continue to work. Because nothing sucks more than doing a release and then realizing that some part doesn't work because it's not a regular part of your devel infrastructure. Jeremy From jwboyer at jdub.homelinux.org Tue Jun 19 20:43:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Jun 2007 15:43:37 -0500 Subject: Official presto repositories for Rawhide In-Reply-To: <1182285331.16660.6.camel@erebor.boston.redhat.com> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> <46783C8C.1000004@redhat.com> <1182285331.16660.6.camel@erebor.boston.redhat.com> Message-ID: <1182285817.6126.121.camel@weaponx.rchland.ibm.com> On Tue, 2007-06-19 at 16:35 -0400, Jeremy Katz wrote: > On Tue, 2007-06-19 at 15:29 -0500, Clark Williams wrote: > > Jeremy Katz wrote: > > > On Tue, 2007-06-19 at 00:40 +0200, Axel Thimm wrote: > > >> On Mon, Jun 18, 2007 at 06:11:47PM -0400, Jeremy Katz wrote: > > >>> The question is where in the process does it make sense to generate > > >>> the deltas. Do we do them in the build system (the koji level)? Do > > >>> we do them in the update system?[1] Do we do them at tree compose > > >>> (mash) time? Each has tradeoffs... not sure which is really the > > >>> best. > > >> The problme domain are the limited bandwidth of end users, so you want > > >> it to run on what end users consume. This can be different for > > >> released versions vs rawhide, but in general released versions would > > >> only perform this on updates-released (not updates-testing) and > > >> for rawhide on everything. > > > > > > Yeah, it's easy to see that deltas for -updates and -updates-testing[1] > > > from the release and probably the last update make sense[2]. rawhide is > > > definitely the trickier to figure out where to draw the line. > > > > Do you even want to draw that line in rawhide? To me, rawhide is > > dangerous enough that trying to add delta updates on top of it is just > > asking for (more) trouble. > > > > I think that -updates* is perfect for deltas, because the latest package > > is almost always going to be an iteration on the previous version(s). > > But rawhide might be a complete version jump, or changing toolchains, or > > trying something just plain whacky. The potential for space saving due > > to commonality doesn't seem to be there for rawhide. > > The space savings benefit isn't really the win for rawhide -- it's more > the testing base and being able to ensure that things continue to work. > Because nothing sucks more than doing a release and then realizing that > some part doesn't work because it's not a regular part of your devel > infrastructure. +10 josh From williams at redhat.com Tue Jun 19 20:47:49 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 19 Jun 2007 15:47:49 -0500 Subject: Official presto repositories for Rawhide In-Reply-To: <1182285331.16660.6.camel@erebor.boston.redhat.com> References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> <1182204707.16956.62.camel@erebor.boston.redhat.com> <20070618224025.GC7747@neu.nirvana> <1182215959.7680.6.camel@aglarond.local> <46783C8C.1000004@redhat.com> <1182285331.16660.6.camel@erebor.boston.redhat.com> Message-ID: <467840F5.8040503@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Katz wrote: > > The space savings benefit isn't really the win for rawhide -- it's more > the testing base and being able to ensure that things continue to work. > Because nothing sucks more than doing a release and then realizing that > some part doesn't work because it's not a regular part of your devel > infrastructure. > Agreed. Ok, I was looking at it from the paranoid rawhide-user viewpoint, not from an infrastructure viewpoint. And since what you're doing probably isn't going to affect me anyway (unless I want to use it), I'll just shut up and go back to trying to destroy my system with rawhide. :) Clark Wups, looks like I was succes... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGeED1Hyuj/+TTEp0RAtAXAKCf0EDW5IaALSZHQ5Z7tCdc47jImQCbBki/ Zehwy5tCmXYS4n3x93+hSek= =7H1c -----END PGP SIGNATURE----- From snecklifter at gmail.com Tue Jun 19 21:28:29 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 19 Jun 2007 22:28:29 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <46781CA7.2000706@fedoraproject.org> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> Message-ID: <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> On 19/06/07, Rahul Sundaram wrote: > > Sean Stangl wrote: > > On Tue, 2007-06-19 at 11:15 -0400, Steve Dickson wrote: > >> So, imho, depending on the uses of the machine should define > >> if a sudo account will automatically be enabled... > > > > Precisely why such a decision should not be an automatic but rather an > > install-time option, such as those which Chris Brown offered. > > Oh please. Just pick one choice and stick with it. That's a pretty lame argument. If I did that I'd still be running my BBC Micro. People who know > better can configure it to meet their needs. I'm not running Gentoo am I? You have a long discussion above involving the pro's and con's with few, if any, dissenters. In my opinion (and many others) this is A Good Thing(tm) and would be of benefit to the majority of people. It would also result in a more secure Fedora which I think we can all agree is a good thing. So lets get it debated (FESCo?) and hear some arguments against because so far yours appears to be the only one and it sucks. It is pretty miserably > painful trying to document the amount of choices we offer already. > Yes, I've seen the wiki. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Tue Jun 19 21:41:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Jun 2007 03:11:47 +0530 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> Message-ID: <46784D9B.8080608@fedoraproject.org> Chris Brown wrote: > > That's a pretty lame argument. If I did that I'd still be running my BBC > Micro. I don't know what relationship there exists between what you run and what choices the installer exposes. If you going to argue you need to do so in more generic terms. > I'm not running Gentoo am I? How am I supposed to know that? Debating both sides is good because it allows to choose one as default. Fedora should evaluate the choices and pick one as default. There is no reason every choice should be exposed by the installer. Installation documentation FYI is at docs.fedoraproject.org and not in the wiki. Rahul From snecklifter at gmail.com Tue Jun 19 22:05:17 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 19 Jun 2007 23:05:17 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <46784D9B.8080608@fedoraproject.org> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> Message-ID: <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> On 19/06/07, Rahul Sundaram wrote: > > Chris Brown wrote: > > > > > That's a pretty lame argument. If I did that I'd still be running my BBC > > Micro. > > I don't know what relationship there exists between what you run and > what choices the installer exposes. If you going to argue you need to do > so in more generic terms. ...and you in slightly less patronising ones. Wading in advising people to "pick one option and stick with it" smacks of narrow-mindedness and is an awful technical argument. > I'm not running Gentoo am I? > > How am I supposed to know that? You're not and I imagined you'd realise that as the question was rhetorical and this is a Fedora list. I don't disagree that users can configure to meet their needs but when a discussion involves users saying "Yeah, that's the first thing I do after install" then being able to make it a default option is a good thing as its: a) popular b) one less thing to do on a fresh install Debating both sides is good because it > allows to choose one as default. Fedora should evaluate the choices and > pick one as default. I couldn't agree more. There is no reason every choice should be exposed > by the installer. Again agreed, but the _right_ choices should and it is only right that this discussion be considered a chance to debate those. Installation documentation FYI is at > docs.fedoraproject.org and not in the wiki. I know. Anaconda documentation is however. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Iseli at licr.org Tue Jun 19 22:34:59 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 20 Jun 2007 00:34:59 +0200 Subject: Fedora Package Status of Jun 19, 2007 Message-ID: <20070620003459.5f9c7416@ludwig-alpha.unil.ch> Hi folks, Now that the BZ merge seems to be done, I have updated the PackageStatus page. There seems to be a problem somewhere though: a lot of ACCEPTed closed tickets seem to be missing. Dunno yet whether it's my script or bugzilla acting up (or maybe I just did this too early and the merge is not completed yet). I won't have time right now, but I'll go hunting ASAP. Feel free to post hints, too :-) There are a ton of open bugs, too... Cheers, C ==== Fedora Package Status of Jun 19, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4596 packages - 7570 binary rpms in devel - 110 orphans - 47 packages not available in devel or release Axel dot Thimm at ATrpms dot net vtkdata Axel dot Thimm at ATrpms dot net vtk ajackson at redhat dot com xorg-x11-drv-vermilion andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue andreas at bawue dot net perl-NetAddr-IP arnd at arndb dot de dtc bdpepple at ameritech dot net galago-filesystem bdpepple at ameritech dot net gaim-galago bdpepple at ameritech dot net telepathy-glib bnocera at redhat dot com gnome-launch-box cgoorah at yahoo dot com dot au netgen cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu gaim-gaym dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask dgoodwin at dangerouslyinc dot com testoob foolish at guezz dot net perl-Net-Packet foolish at guezz dot net tcptraceroute foolish at guezz dot net perl-SQLite-Simple gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils icon at fedoraproject dot org mod_evasive jafo at tummy dot com python-mechanoid jafo at tummy dot com python-memcached jmp at safe dot ca clement johnp at redhat dot com GConf2-dbus jorton at redhat dot com libc-client jwboyer at jdub dot homelinux dot org gaim-meanwhile lxtnow at gmail dot com gshutdown mastahnke at gmail dot com epel-release mastahnke at gmail dot com php-magpierss maxime at maxca dot info pypar2 mpg at redhat dot com sugar-artwork mpg at redhat dot com xapian-core paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman rvokal at redhat dot com gaim-guifications splinux at fedoraproject dot org drapes vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp wjhns174 at hardakers dot net perl-Crypt-OpenSSL-DSA wjhns174 at hardakers dot net perl-Crypt-OpenSSL-PKCS10 wjhns174 at hardakers dot net perl-Digest-SHA yufanyufan at gmail dot com audacious-plugins-docklet - 2 packages not available in devel but present in release caolanm at redhat dot com hunspell-he jorton at redhat dot com newt-perl - 12 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=222191,232702,232703,242566,244523 eclipse bkonrath at redhat.com perl-Compress-Raw-Bzip2 steve at silug.org perl-IO-Compress-Bzip2 steve at silug.org cegui packages at amiga-hardware.com ddrescue splinux25 at gmail.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221084,221717,224458,226725,227091,231861,243006 dkms Matt_Domsch at dell.com agg caolanm at redhat.com libsilc wtogami at redhat.com netgen cgoorah at yahoo.com.au objectweb-anttask rafaels at redhat.com cyrus-imapd tjanouse at redhat.com apr jorton at redhat.com - 3 packages present in the development repo which have no owners entry audacious-docklet s390utils ws-commons-util - 19 orphaned packages, yet available in devel docbook-dtds docbook-simple docbook-slides docbook-style-dsssl docbook-style-xsl docbook-utils driftnet gnome-bluetooth gob2 libbtctl libedit linuxdoc-tools luks-tools openjade opensp pam_usb udftools xmltex xmlto FE-ACCEPT packages stats: - 723 accepted, closed package reviews - 15 accepted, closed package reviews not in repo - 3 accepted, closed package reviews not in owners - 112 accepted, open package reviews older than 4 weeks; - 136 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 225 open tickets - 81 tickets with no activity in eight weeks - 26 tickets with no activity in four weeks - 18 closed tickets FE-NEW packages stats: - 983 open tickets - 762 tickets with no activity in eight weeks - 44 tickets with no activity in four weeks - 2 closed tickets FE-NEEDSPONSOR packages stats: - 47 open tickets - 3 tickets with no activity in eight weeks - 4 tickets with no activity in four weeks FE-LEGAL packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks OPEN-BUGS packages stats: - 7978 open tickets - 5073 tickets with no activity in eight weeks - 857 tickets with no activity in four weeks CVS stats: - 4601 packages with a devel directory - 4 packages with no owners entry isorelax-0-0.1.release20050331.1jpp.1.src.rpm mysql-administrator postgis tdma - 199 packages were dropped from Fedora Maintainers stats: - 380 maintainers - 2 inactive maintainers with open bugs - 3 inactive maintainers Dropped Fedora packages: - 2 packages were dropped since Fedora 7 Comps.xml files stats: - 2376 packages in comps-f8 file - 997 packages missing from comps-f8 file - 31 packages in comps-f8 but not in repo - 2378 packages in comps-f7 file - 932 packages missing from comps-f7 file - 42 packages in comps-f7 but not in repo From buildsys at fedoraproject.org Tue Jun 19 22:41:54 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 19 Jun 2007 18:41:54 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-19 Message-ID: <20070619224154.EDF55152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 4 gpredict-0.8.0-1.fc6 libkdcraw-0.1.1-1.fc6 NEW libnetfilter_log-0.0.13-4.fc6 : Netfilter logging userspace library mugshot-1.1.45-1.fc6 Packages built and released for Fedora Extras 5: 0 Changes in Fedora Extras 6: gpredict-0.8.0-1.fc6 -------------------- * Tue Jun 19 2007 Denis Leroy - 0.8.0-1 - Update to 0.8.0 - Fixed desktop file StartupNotify libkdcraw-0.1.1-1.fc6 --------------------- * Tue Jun 19 2007 Marcin Garski 0.1.1-1 - Update to libkdcraw-0.1.1 (#244872) - Spec fixes by Rex Dieter libnetfilter_log-0.0.13-4.fc6 ----------------------------- * Sun May 27 2007 Paul P Komkoff Jr - 0.0.13-4 - try to rebuild. * Sun May 27 2007 Paul P Komkoff Jr - 0.0.13-3 - stupid CVS import script keeps tagging all imported rpms with incorrect tags. mugshot-1.1.45-1.fc6 -------------------- * Tue Jun 19 2007 Owen Taylor - 1.1.45-1 - 1.1.45 * Fri Jun 15 2007 Owen Taylor - 1.1.44-1 - 1.1.44 (fix crash when Pidgin not running) Changes in Fedora Extras 5: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lyz27 at yahoo.com Tue Jun 19 23:07:51 2007 From: lyz27 at yahoo.com (Tom Lynema) Date: Tue, 19 Jun 2007 18:07:51 -0500 Subject: Questions regarding my man/info summer project In-Reply-To: <4677DC96.3000301@redhat.com> References: <200706121533.50219.vpivaini@cs.helsinki.fi> <4677DC96.3000301@redhat.com> Message-ID: <1182294471.6878.11.camel@core2.lynema.com> On Tue, 2007-06-19 at 15:39 +0200, Florian Festi wrote: > Hi! > > I have to admit that I don't have any idea how (or better if) our man pages > are kept up2date. > > After having a short look at the groff format I am very sure that no one > wants to edit that. (Info pages are a different thing). > > So the question is how can the man pages transformed into wiki markup and > back without loss of information. There is some groff markup that naturally > translates into wiki markup. For all other stuff you could write MoinMoin > macros. For creating the diffs you should be able to translate the wiki page > back to groff and do the diffs between the groff versions insted of the wiki > markup pages. That way the patches are much more likely to be useful for > updating the man pages. > > The easiest way of translating page content is using an Formatter. But that > won't help for the non MoinMoin markup features you'd modeled as macros. The > way out is special casing the output of the macros depending on the > formatter used. If they get an groff formatter they return the groff source > otherwise they use the formatter to highlight the text properly. > > If you have questions feel free to ask my on #moin or #moin-dev. > > Florian Festi > > Oddly enough, I just started working on a site with similar requirements. The bash command I used to convert the man pages to WikiMedia markup looked something like this: for i in `ls /usr/share/man/man3/*.bz2` ; do bunzip2 -c $i | man2html | html2wiki --dialect MediaWiki --encoding iso-8859-1 --base-uri http://wikux.org --wiki-uri http://wikux.org/ > /home/lyz/Programming/Web/Wikux.org/man3bz2/$i.wiki ; done As you can see, the main tools used were man2html and html2wiki. I never considered going the other way around, but did keep the markup results handy so they could be diffed to check for updated pages. There was also some sedding going on to get the links to work properly. The end result is at wikux.org if anyone is interested or wants to help out. Please CC me on emails that reply to this as I don't follow the very closely. ~tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From n0dalus+redhat at gmail.com Wed Jun 20 00:09:12 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 20 Jun 2007 09:39:12 +0930 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> Message-ID: <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> On 6/20/07, Chris Brown wrote: > > [...] In my opinion (and many > others) this is A Good Thing(tm) and would be of benefit to the majority of > people. It would also result in a more secure Fedora which I think we can > all agree is a good thing. So lets get it debated (FESCo?) and hear some > arguments against because so far yours appears to be the only one and it > sucks. > In what way would it benefit a majority of users? I could be wrong, but I suspect the majority of Fedora installations only have one administrator, in which case, sudo actually ends up making things _less_ secure (it provides another account by which root access can be cracked). The majority of Fedora setups, including many ones with just two or three administrators, would never have a need for revokable root access (which is the only real advantage sudo gives). I personally don't think it's an option that needs to be in the installer, since in the majority of cases it is not even helpful. In the other few cases, the person running the installation/firstboot will setup (and hence know) the root password themselves, so there is no need for a checkbox to add themselves to sudoers. Sudo is only really useful in multi-administrator environments, where root access needs to be revokable. For this case, it should be presented as an option in system-config-users so second and subsequent administrators can be set up, but it doesn't need to be in the installer/firstboot. n0dalus. From sundaram at fedoraproject.org Wed Jun 20 00:16:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Jun 2007 05:46:08 +0530 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> Message-ID: <467871C8.20308@fedoraproject.org> Chris Brown wrote: > On 19/06/07, *Rahul Sundaram* > wrote: > > Chris Brown wrote: > > > > > That's a pretty lame argument. If I did that I'd still be running > my BBC > > Micro. > > I don't know what relationship there exists between what you run and > what choices the installer exposes. If you going to argue you need > to do > so in more generic terms. > > > ...and you in slightly less patronising ones. Wading in advising people > to "pick one option and stick with it" smacks of narrow-mindedness and > is an awful technical argument. Try writing documentation for all these options and then tell me it is not a good technical argument. Rahul From mattdm at mattdm.org Wed Jun 20 00:24:07 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 19 Jun 2007 20:24:07 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> Message-ID: <20070620002407.GA28458@jadzia.bu.edu> On Wed, Jun 20, 2007 at 09:39:12AM +0930, n0dalus wrote: > In what way would it benefit a majority of users? I could be wrong, > but I suspect the majority of Fedora installations only have one > administrator, in which case, sudo actually ends up making things > _less_ secure (it provides another account by which root access can be > cracked). The majority of Fedora setups, including many ones with just It's a marginal benefit, though, because once that user account is compromised, the root password could be captured with relative ease. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From n0dalus+redhat at gmail.com Wed Jun 20 00:55:03 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 20 Jun 2007 10:25:03 +0930 Subject: user created at install added in sudoers ? In-Reply-To: <20070620002407.GA28458@jadzia.bu.edu> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> <20070620002407.GA28458@jadzia.bu.edu> Message-ID: <6280325c0706191755u2a231fffhcb62a6eea24eea8b@mail.gmail.com> On 6/20/07, Matthew Miller wrote: > On Wed, Jun 20, 2007 at 09:39:12AM +0930, n0dalus wrote: > > In what way would it benefit a majority of users? I could be wrong, > > but I suspect the majority of Fedora installations only have one > > administrator, in which case, sudo actually ends up making things > > _less_ secure (it provides another account by which root access can be > > cracked). The majority of Fedora setups, including many ones with just > > It's a marginal benefit, though, because once that user account is > compromised, the root password could be captured with relative ease. > Even so, sudo has offered no extra security or benefit in this case. n0dalus. From poelstra at redhat.com Wed Jun 20 00:58:50 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 19 Jun 2007 17:58:50 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-18 Message-ID: <46787BCA.1030001@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jun-18 Please make corrections and clarifications to the wiki page. == Schedule == * 20-July is the freeze date for Test1 * Prepare for Test1 starting on 13-July Decisions: * Release Engineering will deliver the following: 1. Fedora spin which is iso(s) + exploded installable tree 1. Fedora Live images for i386/x86_64 that are installable. 1. KDE Live images that are installable 1. Everything repo of packages that we can hopefully use with other install media to "make" it installable. * Various SIGs may be responsible for content definition for these various deliverables, as well as pre-generation and QA of them. * Release Engineering is only responsible for final production and signing of the content. * At least one week before Test1 freeze (13-July) rel-eng will be looking closer and attempting to fix up issues such as: 1. broken deps 1. broken upgrade paths 1. conflicts 1. other such tree issues. 1. Compose tools * should be somewhat stabilized (no changes to code) before this point so that pre-freeze trees can be generated and reviewed before the mad freeze rush. == Open Discussion == * wwoods--QA procedure for the Live spins is not well-defined at this point; need to add more of that stuff to the test matrices, etc. * f13--created http://fedoraproject.org/wiki/ReleaseEngineering/SOP From Matt_Domsch at dell.com Wed Jun 20 01:48:42 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 19 Jun 2007 20:48:42 -0500 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: References: Message-ID: <20070620014842.GA29856@auslistsprd01.us.dell.com> On Tue, Jun 19, 2007 at 03:40:59PM -0400, Anthony Bryan wrote: > >On Sat, Jun 09, 2007 at 07:51:20PM +0200, Ruben Kerkhof wrote: > > Have you had a chance to look over Ruben's additions? Any feedback? He > said he re-licensed it to line up w/ mirrormanager. Any ideas/comments > for features in Metalink that could be of use to Fedora? Yes, I took a quick look; I'll be able to do something with this, but not for the next 4 weeks, as I'm out of the office moving houses and on vacation, then catching up on real work. :-) If someone would care to add it in themselves using the publicly available mirrorlists as the initial list of mirrors for test purposes, I'll be happy to review patches when I return. mirrormanager is in a git archive at https://hosted.fedoraproject.org/projects/mirrormanager. It will then be easy to make that code use the mm database rather than a static list. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From poelstra at redhat.com Wed Jun 20 02:33:46 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 19 Jun 2007 19:33:46 -0700 Subject: FESCo elections In-Reply-To: <1182223698.2796.0.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> Message-ID: <4678920A.5010308@redhat.com> Brian Pepple said the following on 06/18/2007 08:28 PM Pacific Time: > For more information regarding the election, please refer to this: > http://fedoraproject.org/wiki/Extras/Policy/FESCoElections > > Thanks, > /B > >From the link above: "Candidates may be any member of the cvsextras group in the Fedora Accounts System" 1) What does "any member" of the cvsextras group mean? This sentence does not make sense. 2) With "Extras" gone, is this group still relevant? I do not maintain any packages, but participate in the Fedora. Can I still run? Thanks, John From a.badger at gmail.com Wed Jun 20 03:10:35 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Jun 2007 20:10:35 -0700 Subject: FESCo elections In-Reply-To: <4678920A.5010308@redhat.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> Message-ID: <1182309035.29855.57.camel@localhost.localdomain> On Tue, 2007-06-19 at 19:33 -0700, John Poelstra wrote: > Brian Pepple said the following on 06/18/2007 08:28 PM Pacific Time: > > > For more information regarding the election, please refer to this: > > http://fedoraproject.org/wiki/Extras/Policy/FESCoElections > > > > Thanks, > > /B > > > > >From the link above: > "Candidates may be any member of the cvsextras group in the Fedora Accounts System" > > 1) What does "any member" of the cvsextras group mean? This sentence does not make sense. The cvsextras group exists inside the Fedora Account System. It was originally for people who had access to the extras cvs repository, ie: a packager contributing to Extras. Now that Core and Extras are merged all the packagers from Core should be in cvsextras as well. > 2) With "Extras" gone, is this group still relevant? > There was talk about renaming it but that hasn't happened yet. This group should still include all the packagers contributing to Fedora. However, it doesn't include non-packagers. > I do not maintain any packages, but participate in the Fedora. Can I still run? > Not according to the policy. I think the policy deserves to be examined since FESCo is no longer strictly about packaging but about making all technical decisions WRT Fedora. I'm undecided whether it should be updated this close to the election. Does anyone else have thoughts on this? P.S. You _can_ run for the Board. The Board election is coming up before the FESCo election and there's currently only one candidate. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dyoung at mesd.k12.or.us Wed Jun 20 05:16:50 2007 From: dyoung at mesd.k12.or.us (Dan Young) Date: Tue, 19 Jun 2007 22:16:50 -0700 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> Message-ID: <994441ae0706192216q24f1bc8dndd68e3209a0b16c4@mail.gmail.com> On 6/19/07, n0dalus wrote: > In what way would it benefit a majority of users? I could be wrong, > but I suspect the majority of Fedora installations only have one > administrator, in which case, sudo actually ends up making things > _less_ secure (it provides another account by which root access can be > cracked). In a "1st user gets sudo" scenario, I'd lock the root account. It wouldn't be _another_ account to crack, it would be a different account. Plus, root accounts are known to be present. Usernames with sudo access would need to be guessed or discovered through other means. -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From pemboa at gmail.com Wed Jun 20 05:20:41 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 20 Jun 2007 00:20:41 -0500 Subject: user created at install added in sudoers ? In-Reply-To: <994441ae0706192216q24f1bc8dndd68e3209a0b16c4@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> <994441ae0706192216q24f1bc8dndd68e3209a0b16c4@mail.gmail.com> Message-ID: <16de708d0706192220u7079eb70q24a1462a0a3dd61a@mail.gmail.com> On 6/20/07, Dan Young wrote: > On 6/19/07, n0dalus wrote: > > In what way would it benefit a majority of users? I could be wrong, > > but I suspect the majority of Fedora installations only have one > > administrator, in which case, sudo actually ends up making things > > _less_ secure (it provides another account by which root access can be > > cracked). > > In a "1st user gets sudo" scenario, I'd lock the root account. It > wouldn't be _another_ account to crack, it would be a different > account. You can pry root from my cold, dead hands. > Plus, root accounts are known to be present. Usernames with sudo > access would need to be guessed or discovered through other means. > > -- > Dan Young > Multnomah ESD - Technology Services > 503-257-1562 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Fedora Core 6 and proud From kwade at redhat.com Wed Jun 20 05:37:10 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 19 Jun 2007 22:37:10 -0700 Subject: FESCo elections In-Reply-To: <1182309035.29855.57.camel@localhost.localdomain> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> Message-ID: <1182317830.21966.415.camel@erato.phig.org> On Tue, 2007-06-19 at 20:10 -0700, Toshio Kuratomi wrote: > On Tue, 2007-06-19 at 19:33 -0700, John Poelstra wrote: > > I do not maintain any packages, but participate in the Fedora. Can I still run? > > > Not according to the policy. I think the policy deserves to be examined > since FESCo is no longer strictly about packaging but about making all > technical decisions WRT Fedora. I'm undecided whether it should be > updated this close to the election. Does anyone else have thoughts on > this? It's not too close to the elections to change this detail in this direction. Too close to restrict the pool of contenders, but not too close to expand it. +1 to FESCo candidates being anyone with an FAS account. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ruben at rubenkerkhof.com Wed Jun 20 06:43:34 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Wed, 20 Jun 2007 08:43:34 +0200 Subject: Improving availability and guaranteeing integrity in ISO downloads In-Reply-To: <20070620014842.GA29856@auslistsprd01.us.dell.com> References: <20070620014842.GA29856@auslistsprd01.us.dell.com> Message-ID: <7C31157D-6A4C-46C6-8E02-3508651A6FA9@rubenkerkhof.com> Hi, On 20-jun-2007, at 3:48, Matt Domsch wrote: > If someone would care to add it in themselves using the publicly > available mirrorlists as the initial list of mirrors for test > purposes, I'll be happy to review patches when I return. > mirrormanager is in a git archive at > https://hosted.fedoraproject.org/projects/mirrormanager. It will then > be easy to make that code use the mm database rather than a static > list. Anthony was so nice to give me an xsd schema for the metalink format, so I'm now validating the file my script generates and fixing any obvious errors. I also want to add PGP support and torrent chunk support is nice to have either. I'll clone your git repo and see what I can come up with in the next 4 weeks. We can discuss it when you're back from vacation. Cheers, Ruben From dev at nigelj.com Wed Jun 20 07:03:56 2007 From: dev at nigelj.com (Nigel Jones) Date: Wed, 20 Jun 2007 19:03:56 +1200 Subject: FESCo elections In-Reply-To: <1182317830.21966.415.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> Message-ID: <4678D15C.6030108@nigelj.com> Karsten Wade wrote: > On Tue, 2007-06-19 at 20:10 -0700, Toshio Kuratomi wrote: >> On Tue, 2007-06-19 at 19:33 -0700, John Poelstra wrote: > >>> I do not maintain any packages, but participate in the Fedora. Can I still run? >>> >> Not according to the policy. I think the policy deserves to be examined >> since FESCo is no longer strictly about packaging but about making all >> technical decisions WRT Fedora. I'm undecided whether it should be >> updated this close to the election. Does anyone else have thoughts on >> this? > > It's not too close to the elections to change this detail in this > direction. Too close to restrict the pool of contenders, but not too > close to expand it. > > +1 to FESCo candidates being anyone with an FAS account. > Is it me, or has the purpose of FESCo got lost? My understanding, FESCo (Fedora Extras Steering Committee) is to steer issues WRT to the Fedora Distribution [1] (formally the Fedora Extras Distribution), it makes sense to only allow current packagers as *they* are the ones that or contributing to the distribution. FESCo has typically dealt with issues such as: * Patent issues * Package naming * Static library issues * Approving changes to packaging guidelines (already agreed to by the packaging committee) * Approval of new sponsors (for cvsextras) Have a look at http://fedoraproject.org/wiki/Development/Schedule Fedora Documentation has FDSCo (Fedora Documentation Steering Committee), which last I checked does not report to FESCo, I believe they report to the Board, like FESCo (?) So no, I'm not sure what advantage there would be to having non packagers in FESCo, ditto with having non documentation writers in FDSCo, by all means, attend the meetings, but the casting vote I'm not sure about. [1] - I'm describing the Fedora Distribution as the collection of rpms N.J. From n0dalus+redhat at gmail.com Wed Jun 20 08:15:02 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 20 Jun 2007 17:45:02 +0930 Subject: user created at install added in sudoers ? In-Reply-To: <994441ae0706192216q24f1bc8dndd68e3209a0b16c4@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> <994441ae0706192216q24f1bc8dndd68e3209a0b16c4@mail.gmail.com> Message-ID: <6280325c0706200115p6699c335p4474a949ed121349@mail.gmail.com> On 6/20/07, Dan Young wrote: > On 6/19/07, n0dalus wrote: > > In what way would it benefit a majority of users? I could be wrong, > > but I suspect the majority of Fedora installations only have one > > administrator, in which case, sudo actually ends up making things > > _less_ secure (it provides another account by which root access can be > > cracked). > > In a "1st user gets sudo" scenario, I'd lock the root account. It > wouldn't be _another_ account to crack, it would be a different > account. > If that's what you want, can I suggest you propose that as a firstboot option instead then? Currently the proposal seemed to be just "1st user gets sudo", and root is still available. The approach I personally use is to keep the root account enabled, disable root from logging in with ssh/gdm/kdm/xdm, and then use su - from my user account. The options proposed so far are: 1) Provide no option on install/firstboot. Keep the system as is, with nobody in sudoers and users use su - or login as root directly to get root access. 2) Provide the option to put the firstboot created user in sudoers, users use sudo, su - or direct root login to get root access. As I've pointed out earlier, this is not really that helpful. 3) Provide the option to put the firstboot created user in sudoers and disable the root login, users use sudo to get root access. This is the method used in Some Other (TM) distros. To throw a couple of other options into the mix: 4) Provide no option on install/firstboot, but disable root logins in ssh_config/etc by default (after firstboot has been run, so don't do this on an upgrade), users use su - to get root access. 5) Provide an option in firstboot to disable root logins in ssh_config/etc and users can use su - to get root access. Are there other possible options? For 4 and 5, would we want gdm/kdm/xdm root logins disabled? How about vt root logins? The reason for blocking ssh root access is fairly straightforward; it's the only practical method for cracking the root account. Blocking gdm/kdm/xdm is just to discourage users from logging into their desktops as root, which we should be doing anyway. You'd block vt root logins too if you wanted to completely ensure root can only be reached by su -. I'd personally vote for 1, but would also be happy with 4 or 5. n0dalus. From laroche at redhat.com Wed Jun 20 08:21:56 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 20 Jun 2007 10:21:56 +0200 Subject: FESCo elections In-Reply-To: <4678920A.5010308@redhat.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> Message-ID: <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> On Tue, Jun 19, 2007 at 07:33:46PM -0700, John Poelstra wrote: > Brian Pepple said the following on 06/18/2007 08:28 PM Pacific Time: > > >For more information regarding the election, please refer to this: > >http://fedoraproject.org/wiki/Extras/Policy/FESCoElections > > > >Thanks, > >/B > > > > >From the link above: > "Candidates may be any member of the cvsextras group in the Fedora Accounts > System" > > 1) What does "any member" of the cvsextras group mean? This sentence does > not make sense. > 2) With "Extras" gone, is this group still relevant? > > I do not maintain any packages, but participate in the Fedora. Can I still > run? Hello John, why not just apply for the group "cvsextras"? There shouldn't be a requirement there to own packages then. regards, Florian La Roche From snecklifter at gmail.com Wed Jun 20 08:53:21 2007 From: snecklifter at gmail.com (Chris Brown) Date: Wed, 20 Jun 2007 09:53:21 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> Message-ID: <364d303b0706200153u5b389b45if530237b2de0b39e@mail.gmail.com> On 20/06/07, n0dalus wrote: > > On 6/20/07, Chris Brown wrote: > > > > [...] In my opinion (and many > > others) this is A Good Thing(tm) and would be of benefit to the majority > of > > people. It would also result in a more secure Fedora which I think we > can > > all agree is a good thing. So lets get it debated (FESCo?) and hear some > > arguments against because so far yours appears to be the only one and it > > sucks. > > > > In what way would it benefit a majority of users? Please go back and read the thread for the arguments for doing this. I could be wrong, > but I suspect the majority of Fedora installations only have one > administrator, in which case, sudo actually ends up making things > _less_ secure (it provides another account by which root access can be > cracked). The majority of Fedora setups, including many ones with just > two or three administrators, would never have a need for revokable > root access (which is the only real advantage sudo gives). No, its not. It means newbies understand the concept of root better (and don't run everything as root) and, as I have already said, I consider it more secure as it allows me to temporarily escalate privs to run a program requiring root in the knowledge that I can forget about having to exit the root shell afterwards. Which is nice. I personally don't think it's an option that needs to be in the > installer, since in the majority of cases it is not even helpful. In > the other few cases, the person running the installation/firstboot > will setup (and hence know) the root password themselves, so there is > no need for a checkbox to add themselves to sudoers. Except for the reasons I have given above. Sudo is only really useful in multi-administrator environments, where > root access needs to be revokable. Again, I don't agree. For this case, it should be > presented as an option in system-config-users so second and subsequent > administrators can be set up, That idea I _do_ like. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From snecklifter at gmail.com Wed Jun 20 08:56:36 2007 From: snecklifter at gmail.com (Chris Brown) Date: Wed, 20 Jun 2007 09:56:36 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <467871C8.20308@fedoraproject.org> References: <4673037B.3030105@laposte.net> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> <467871C8.20308@fedoraproject.org> Message-ID: <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> On 20/06/07, Rahul Sundaram wrote: > > Chris Brown wrote: > > On 19/06/07, *Rahul Sundaram* > > wrote: > > > > Chris Brown wrote: > > > > > > > > That's a pretty lame argument. If I did that I'd still be running > > my BBC > > > Micro. > > > > I don't know what relationship there exists between what you run and > > what choices the installer exposes. If you going to argue you need > > to do > > so in more generic terms. > > > > > > ...and you in slightly less patronising ones. Wading in advising people > > to "pick one option and stick with it" smacks of narrow-mindedness and > > is an awful technical argument. > > Try writing documentation for all these options and then tell me it is > not a good technical argument. > So now because writing documentation is a hassle we shouldn't do it? Again, pretty poor argument but what the hell, I'm happy to write the docs if this gets implemented. Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickirelan at gmail.com Wed Jun 20 09:20:16 2007 From: nickirelan at gmail.com (Nick Irelan) Date: Wed, 20 Jun 2007 04:20:16 -0500 Subject: Driver Manager Message-ID: <7ff232d10706200220j7bcaa9d0w8bf9d7e7b7473dc0@mail.gmail.com> Hello, I would like to start a new open source project that will help manage drivers in Linux and/or other OSes. If anyone out there has expierence with drivers and would like to help please email me. Thanks Nick Irelan -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.azerty at laposte.net Wed Jun 20 09:25:48 2007 From: axel.azerty at laposte.net (Axel) Date: Wed, 20 Jun 2007 11:25:48 +0200 Subject: Driver Manager In-Reply-To: <7ff232d10706200220j7bcaa9d0w8bf9d7e7b7473dc0@mail.gmail.com> References: <7ff232d10706200220j7bcaa9d0w8bf9d7e7b7473dc0@mail.gmail.com> Message-ID: <4678F29C.9020608@laposte.net> Nick Irelan a ?crit : > Hello, > I would like to start a new open source project that will help manage > drivers in Linux and/or other OSes. If anyone out there has expierence > with drivers and would like to help please email me. > Thanks > Nick Irelan By "project", what do you mean ? software ? a website ? From buildsys at redhat.com Wed Jun 20 09:34:33 2007 From: buildsys at redhat.com (Build System) Date: Wed, 20 Jun 2007 05:34:33 -0400 Subject: rawhide report: 20070620 changes Message-ID: <200706200934.l5K9YX5t001853@porkchop.devel.redhat.com> New package tcptraceroute A traceroute implementation using TCP packets New package telepathy-glib GLib bindings for Telepathy New package testoob Advanced unit testing framework for Python Updated Packages: ClanLib-0.8.0-5.fc8 ------------------- * Tue Jun 19 2007 Matthias Saou 0.8.0-5 - Rebuild against SDL_gfx 2.0.16. SDL_Pango-0.1.2-5.fc8 --------------------- * Fri Sep 29 2006 Matthias Saou 0.1.2-5 - Update source URL. - Disable static lib building instead of excluding it from the files list. SDL_gfx-2.0.16-2.fc8 -------------------- * Tue Jun 19 2007 Matthias Saou 2.0.16-2 - Minor cleanups. * Mon May 07 2007 Matthias Saou 2.0.16-1 - Update to 2.0.16. - Remove no longer needed semicolon patch. - Add libXt-devel BR to make configure happy (seems unused, though). - Remove no longer needed autotools BR. advancecomp-1.15-7.fc8 ---------------------- * Thu Mar 29 2007 Matthias Saou 1.15-7 - Switch to using DESTDIR install method. autofs-1:5.0.2-2 ---------------- * Wed Jun 20 2007 Ian Kent - 5.0.2-2 - include krb5.h in lookup_ldap.h (some openssl doesn't implicitly include it). - correct initialization of local var in parse_server_string. bbkeys-0.9.0-7.fc8 ------------------ * Tue Jun 19 2007 Matthias Saou 0.9.0-7 - Remove old X build requires conditional. bind-31:9.5.0a5-1.fc8 --------------------- * Tue Jun 19 2007 Adam Tkac 31:9.5.0a5-1.fc8 - updated to latest upstream blackbox-0.70.1-7.fc8 --------------------- * Tue Jun 19 2007 Matthias Saou 0.70.1-7 - Switch to using the DESTDIR install method. - Remove old X build requirements conditionals. camE-1.9-9.fc8 -------------- * Wed Jun 20 2007 Matthias Saou 1.9-9 - Use the DESTDIR install method... not! So document it :-) control-center-1:2.19.4-3.fc8 ----------------------------- * Tue Jun 19 2007 Matthias Clasen - 2.19.4-3 - Fix a segfault in the background-setting code * Tue Jun 19 2007 Matthias Clasen - 2.19.4-2 - Fix up the new module handling in gnome-settings-daemon denyhosts-2.6-5.fc8 ------------------- * Tue Jun 19 2007 Jason L Tibbitts III - 2.6-5 - Apply yet another regex.py fix from Jonathan Underwood to fix bug 244943. digikam-0.9.2-1.fc8 ------------------- * Tue Jun 19 2007 Marcin Garski 0.9.2-1 - Update to version 0.9.2-final - Remove digikam-0.9.2-beta3-fix-exiv2-dep.patch, merged upstream * Wed Jun 06 2007 Marcin Garski 0.9.2-0.3.beta3 - Fix .desktop category * Wed Jun 06 2007 Marcin Garski 0.9.2-0.2.beta3 - Fix broken compilation caused by Exiv2 dependency epydoc-2.1-8.fc8 ---------------- * Tue Jun 19 2007 Matthias Saou 2.1-8 - Remove desktop file prefix and X-Fedora category. - Include patch to remove #! python from files only meant to be included. espeak-1.26-1.fc8 ----------------- * Tue Jun 19 2007 Francois Aucamp - 1.26-1 - Update to version 1.26 - Modified %prep to build against portaudio v19 evolution-sharp-0.13-1.fc8 -------------------------- * Tue Jun 19 2007 Matthew Barnes - 0.13-1.fc8 - Update to 0.13 fedora-release-7.89-2 --------------------- * Tue Jun 19 2007 Jesse Keating - 7.89-2 - Define the dist macros in this package since we define everyting else here * Wed May 30 2007 Jesse Keating - 7.89-1 - And we're back to rawhide. Re-enable devel repos * Thu May 24 2007 Jesse Keating - 7-3 - We have a name! - Require the newer release notes file-roller-2.19.3-1.fc8 ------------------------ * Tue Jun 19 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 gcompris-8.3.2-1.fc8 -------------------- * Tue Jun 19 2007 Hans de Goede 8.3.2-1 - New upstream release 8.3.2 - Drop upstreamed patches glyph-keeper-0.32-2.fc8 ----------------------- * Tue Jun 19 2007 Matthias Saou 0.32-2 - Rebuild against SDL_gfx 2.0.16. gnome-session-2.19.4-2.fc8 -------------------------- * Tue Jun 19 2007 Matthias Clasen - 2.19.4-2 - Fix a hang on login with a11y gpredict-0.8.0-2.fc8 -------------------- * Tue Jun 19 2007 Denis Leroy - 0.8.0-2 - Fixed desktop StartupNotify line * Tue Jun 19 2007 Denis Leroy - 0.8.0-1 - Update to 0.8.0 gstreamer-plugins-good-0.10.6-1.fc8 ----------------------------------- * Tue Jun 19 2007 - Bastien Nocera - 0.10.6-1 - Update to 0.10.6 - Remove outdated FLAC patch - Add new plugins gthumb-2.10.4-1.fc8 ------------------- * Tue Jun 19 2007 Matthias Clasen - 2.10.4-1 - Update to 2.10.4 gtk2-2.11.4-1.fc8 ----------------- * Tue Jun 19 2007 Matthias Clasen - 2.11.4-1 - Update to 2.11.4 * Sun Jun 17 2007 Matthias Clasen - 2.11.3-4 - Update versioned dependencies (#244602) * Sun Jun 17 2007 Matthias Clasen - 2.11.3-3 - Clean up directory ownership hercules-3.04.1-5.fc8 --------------------- * Tue Jun 19 2007 Matthias Saou 3.04.1-5 - Update included README-rpm (was README.fedora) to remove Fedora instructions since after the Core+Extras merge, Fedora isn't built for x390 (#234803). - Remove rpath at last (using sed on the libtool script method). kexec-tools-1.101-71.fc8 ------------------------ * Tue Jun 19 2007 Neil Horman - 1.101-71.fc8 - Fixed conflict in mkdumprd in use of /mnt (bz 222911) libbonobo-2.19.4-1.fc8 ---------------------- * Tue Jun 19 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 libbonoboui-2.19.4-1.fc8 ------------------------ * Tue Jun 19 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 libglade2-2.6.1-1.fc8 --------------------- * Tue Jun 19 2007 Matthias Clasen - 2.6.1-1 - Update to 2.6.1 libkdcraw-0.1.1-1.fc8 --------------------- linuxdoc-tools-0.9.21-9.fc8 --------------------------- * Tue Jun 19 2007 Ondrej Vasik 4.6.1a-47 - refresh contents of terminal when resized during time expensive I/O operations (#236502) * Tue Jun 12 2007 Jindrich Novy 4.6.1a-46 - update to new upstream CVS snapshot (2007-06-04-22) - don't print prompts multiple times when switching between mc and subshell * Mon Apr 16 2007 Jindrich Novy 4.6.1a-45 - fix segmentation fault while editing non-UTF8 files (#229383) metakit-2.4.9.7-1.fc8 --------------------- * Tue Jun 19 2007 Matthias Saou 2.4.9.7-1 - Update to 2.4.9.7. - Move tcl files to a sub-dir of %{_libdir} (#228177)... :-/ mod_security-2.1.1-1.fc8 ------------------------ * Tue Jun 19 2007 Michael Fleming 2.1.1-1 - New upstream release - Drop ASCIIZ rule (fixed upstream) - Re-enable protocol violation/anomalies rules now that REQUEST_FILENAME is fixed upstream. mugshot-1.1.45-1.fc8 -------------------- * Tue Jun 19 2007 Owen Taylor - 1.1.45-1 - 1.1.45 openlierox-0.57-0.4.beta2.fc8 ----------------------------- * Tue Jun 19 2007 Matthias Saou 0.57-0.4.beta2 - Rebuild against SDL_gfx 2.0.16. p7zip-4.47-1.fc8 ---------------- * Tue Jun 19 2007 Matthias Saou 4.47-1 - Update to 4.47. - Include now required patch to exclude removed Rar bits from makefiles. - Switch to using "make install" for installation... so patch and hack. - Use the asm makefile for x86_64, so build require yasm for it too. - Add ppc64 to the main %ifarch. - Remove no longer included Codecs and Formats dirs (7z.so replaces them?). - Remove our wrapper scripts, since the install script creates its own. perl-SDL-2.1.3-4.fc8 -------------------- * Tue Jun 19 2007 Matthias Saou 2.1.3-4 - Rebuild against SDL_gfx 2.0.16. php-5.2.3-3 ----------- * Tue Jun 19 2007 Joe Orton 5.2.3-3 - add mcrypt, mhash, tidy, mssql subpackages (Dmitry Butskoy) - enable dbase extension and package in -common php-pecl-mailparse-2.1.1-6.fc8 ------------------------------ * Tue Jun 19 2007 Matthias Saou 2.1.1-6 - Fix package requirements by adding build-time zend-abi version. - Clean up spec to conform to current PHP packaging rules. - No longer bundle part of mbstring (mbfl), at last! (makes spec F7+ specific) pidgin-2.0.2-3.fc8 ------------------ * Tue Jun 19 2007 Warren Togami - 2.0.2-3 - libpurple obsoletes and provides gaim This smoothens multilib the upgrade path. portaudio-19-1.fc8 ------------------ * Tue Jun 19 2007 Matthias Saou 19-1 - Update to "stable" v19_061121. - Switch virtual devel provide to a real sub-package. - Update spec to match build changes from custom Makefile to autotools. - Include new pkgconfig file and require pkgconfig from the devel package. - Add ldconfig calls now that we have a versionned shared library. - Rebuild against alsa-lib and jack-audio-connection-kit. - Build doxygen documentation and include it in the devel package. powermanga-0.80-4.fc8 --------------------- * Tue Jun 19 2007 Matthias Saou 0.80-4 - Move binary to _bindir and data to _datadir, removing "games" prefixes since the guidelines now say so. This should fix prelink's problems (#218280). - Include patch to acheive the above, move the man6 hack to there too. - Externalize the desktop file. - Move icon from pixmaps to 48x48 hicolor, add scriplets. redhat-rpm-config-9.0.0-1.fc8 ----------------------------- * Tue Jun 19 2007 Jeremy Katz - 9.0.0-1 - use stock find-lang.sh (#213041) - arm fixes (Lennert Buytenhek, #243523) - allow jar repacking to be disabled (#219731) - fix running dist.sh --fc (#223651) - hardlink identical .pyc and .pyo files to save space (Ville Skytt??) - fix TMPDIR usage (Matthew Miller, #235614) * Tue Jun 19 2007 Jeremy Katz - 8.1.0-1 - add modalias tags to kmod packages and other kmod changes (jcm) - recompress jars to avoid multilib conflicts (bkonrath) rpm-4.4.2-47.fc8 ---------------- * Tue Jun 19 2007 Panu Matilainen - 4.4.2-47 - spec / package (review) cleanups: - use find_lang instead of manually listing translations - remove useless rpm 3.x upgrade check from preinstall script - use Fedora recommended buildroot - don't include useless, ancient GPG keys - add rpm, db and file licenses to docs - use scriptlet dependency markers instead of PreReq - post scriptlet requires coreutils - main package doesn't require patch, rpm-build does - buildrequire doxygen once more to resurrect apidocs - remove useless/doubly packaged files from /usr/lib/rpm - fix bunch of file permissions * Tue May 01 2007 Paul Nasrat - 4.4.2-46 - Configurable policy for prefered ELF (#235757) * Mon Apr 23 2007 Paul Nasrat - 4.4.2-45 - Fix debugedit for relative paths (#232222) sqlite-3.4.0-1.fc8 ------------------ * Tue Jun 19 2007 Paul Nasrat - 3.4.0-1 - Update to 3.4.0 * Fri Jun 01 2007 Paul Nasrat - 3.3.17-2 - Enable load - Build fts1 and fts2 - Don't sync on dirs (#237427) * Tue May 29 2007 Paul Nasrat - 3.3.17-1 - Update to 3.3.17 synergy-1.3.1-3.fc8 ------------------- * Tue Jun 19 2007 Matthias Saou 1.3.1-3 - Change to using the DESTDIR install mathod. - Drop X build requires conditional. - Switch to using a downloads.sf.net source URL. system-config-language-1.2.2-1.fc8 ---------------------------------- * Tue Jun 19 2007 Lingning Zhang - 1.2.2 - modify the category value in system-config-language.spec. - fix bug243529. * Mon Jun 18 2007 Lingning Zhang - 1.2.1 - Fix bug237715, bug241744 and bug225949(patch from Stephanos Manos). tcpreplay-3.0.1-2.fc8 --------------------- * Fri May 04 2007 Bojan Smojver - 3.0.1-2 - static libraries not shipped in FC7 - fix libpcap.so detection * Thu May 03 2007 Bojan Smojver - 3.0.1-1 - Bump up to new release 3.0.1 - flowreplay doesn't compile, will enable when it does telepathy-gabble-0.5.12-2.fc8 ----------------------------- * Tue Jun 19 2007 Brian Pepple - 0.5.12-2 - Correct version check for loudmouth * Tue Jun 19 2007 Brian Pepple - 0.5.12-1 - Update to 0.5.12. - Add BR on telepathy-glib-devel telepathy-idle-0.1.1-1.fc8 -------------------------- thttpd-2.25b-13.fc8 ------------------- * Tue Jun 19 2007 Matthias Saou 2.25b-13 - Add missing requirements for the scriplets, they could cause the thttpd user to not be added when thttpd was installed from the F7 media (#234740). - Preserve timestamps for all the installed sources. - Init scripts are *not* config files. - Default service to disable. tig-0.8-1.fc8 ------------- * Tue Jun 19 2007 James Bowes - 0.8-1 - tig-0.8 wormux-0.7.9-4.fc8 ------------------ * Tue Jun 19 2007 Matthias Saou 0.7.9-4 - Rebuild against SDL_gfx 2.0.16. xblast-2.10.4-3.fc8 ------------------- xfsdump-2.2.45-2.fc8 -------------------- * Tue Jun 19 2007 Eric Sandeen - 2.2.45-2 - Remove readline-devel & libtermcap-devel BuildRequires xorg-x11-drv-ati-6.6.3-4.fc8 ---------------------------- * Tue Jun 19 2007 Adam Jackson 6.6.3-4 - radeon-6.6.3-renderaccel-buglet.patch: Fix OpenOffice font corruption when RenderAccel is disabled. (#244675) xorg-x11-drv-nv-2.1.0-1.fc8 --------------------------- * Tue Jun 19 2007 Adam Jackson 2.1.0-1 - xf86-video-nv 2.1.0. xvattr-1.3-12.fc8 ----------------- * Tue Jun 19 2007 Matthias Saou 1.3-12 - Switch to using DESTDIR install method. - Convert man page to UTF-8... not? yasm-0.6.1-1.fc8 ---------------- * Tue Jun 19 2007 Matthias Saou 0.6.1-1 - Update to 0.6.1. zziplib-0.13.49-2.fc8 --------------------- * Tue Jun 19 2007 Matthias Saou 0.13.49-2 - Disable static lib build instead of excluding it later. - Remove rpath on 64bit archs. - Switch to using DESTDIR install method. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 kipi-plugins - 0.1.4-0.1.beta1.fc8.i386 requires libkdcraw.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lcdproc - 0.5.2-1.fc8.i386 requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.i386 requires gecko-libs = 0:1.8.1.3 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.3 kipi-plugins - 0.1.4-0.1.beta1.fc8.i386 requires libkdcraw.so.0 kipi-plugins - 0.1.4-0.1.beta1.fc8.x86_64 requires libkdcraw.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lcdproc - 0.5.2-1.fc8.x86_64 requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 gtkmozembedmm - 1.4.2.cvs20060817-10.fc7.ppc requires gecko-libs = 0:1.8.1.3 kipi-plugins - 0.1.4-0.1.beta1.fc8.ppc requires libkdcraw.so.0 kipi-plugins - 0.1.4-0.1.beta1.fc8.ppc64 requires libkdcraw.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lcdproc - 0.5.2-1.fc8.ppc requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kipi-plugins - 0.1.4-0.1.beta1.fc8.ppc64 requires libkdcraw.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux lcdproc - 0.5.2-1.fc8.ppc64 requires perl(Geo::METAR) libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.9-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From pertusus at free.fr Wed Jun 20 10:16:42 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 Jun 2007 12:16:42 +0200 Subject: FESCo elections In-Reply-To: <4678D15C.6030108@nigelj.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> Message-ID: <20070620101642.GB3164@free.fr> On Wed, Jun 20, 2007 at 07:03:56PM +1200, Nigel Jones wrote: > My understanding, FESCo (Fedora Extras Steering Committee) is to steer > issues WRT to the Fedora Distribution [1] (formally the Fedora Extras > Distribution), it makes sense to only allow current packagers as *they* > are the ones that or contributing to the distribution. Maybe I am not following everything, but FESCo role is not that clear to me after the merge. Areas of steering may also include release process (for example the schedule), or not. Also previously FESCo had a role of representing the community, though I don't know if it is really a FESCo role, or if it is now a FAB role, for example. -- Pat From rjones at redhat.com Wed Jun 20 10:27:13 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 20 Jun 2007 11:27:13 +0100 Subject: OCaml Guidelines In-Reply-To: <1182278888.29855.44.camel@localhost.localdomain> References: <1182278888.29855.44.camel@localhost.localdomain> Message-ID: <46790101.5050407@redhat.com> Toshio Kuratomi wrote: > The guidelines created by our hardworking OCaml SIG have been approved > by the Packaging Committee and FESCo. Everyone who has been wondering > about the difference between a cmi, cmx, and cma can visit:: > http://fedoraproject.org/wiki/Packaging/OCaml > > for the official word on what they mean and how to package them. Thanks Toshio. For more on cmi, cmo, etc. see also: http://www.ocaml-tutorial.org/filenames I should add a link to the OCaml SIG ... done. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From ce at ceag.ch Wed Jun 20 10:37:03 2007 From: ce at ceag.ch (Carsten Emde) Date: Wed, 20 Jun 2007 12:37:03 +0200 Subject: gnome-session-2.19.4-1.fc8 hangs forever Message-ID: <4679034F.7090209@ceag.ch> This gnome-session version hangs forever. Quick hack attached. --cbe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gsm-at-startup.c.hangforever.patch URL: From n0dalus+redhat at gmail.com Wed Jun 20 11:11:51 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 20 Jun 2007 20:41:51 +0930 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706200153u5b389b45if530237b2de0b39e@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> <364d303b0706200153u5b389b45if530237b2de0b39e@mail.gmail.com> Message-ID: <6280325c0706200411v432c6113pc3da80498e8d9113@mail.gmail.com> On 6/20/07, Chris Brown wrote: > > > > In what way would it benefit a majority of users? > > Please go back and read the thread for the arguments for doing this. I've read them all. Most of the supposed benefits are not actually benefits exclusive to sudo, and the actual benefits of sudo only apply to a small minority. > > I could be wrong, > > but I suspect the majority of Fedora installations only have one > > administrator, in which case, sudo actually ends up making things > > _less_ secure (it provides another account by which root access can be > > cracked). The majority of Fedora setups, including many ones with just > > two or three administrators, would never have a need for revokable > > root access (which is the only real advantage sudo gives). > > No, its not. It means newbies understand the concept of root better (and > don't run everything as root) and, as I have already said, I consider it > more secure as it allows me to temporarily escalate privs to run a program > requiring root in the knowledge that I can forget about having to exit the > root shell afterwards. Which is nice. Stopping users running everything as root is a completely orthogonal issue. That is done by disallowing root logins at gdm/kdm/xdm, not using sudo. Sudo doesn't stop you from having a root shell. It's as simple as `sudo sh`, try it and see. Furthermore, you can already temporarily escalate privileges with 'su -c' as has been discussed in this thread. The benefits you have just listed are already part of Fedora by default, and sudo is not needed to get them. n0dalus. From jdieter at gmail.com Wed Jun 20 11:56:59 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 20 Jun 2007 14:56:59 +0300 Subject: Official presto repositories for Rawhide In-Reply-To: References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: <1182340619.9539.0.camel@jndwidescreen.lesbg.loc> On Mon, 2007-06-18 at 09:56 -0500, Rex Dieter wrote: > Jonathan Dieter wrote: > > > I would like to request the creation of presto repositories for Rawhide. > ... > > The presto repository creation tools probably need to be looked over, > > but I think it's time to start creating "official" deltarpms if we're > > going to make it into F8. > > Prereq: presto repository creation tools need to be submitted for review, > and imported into Fedora. > > -- Rex > It's now submitted for review. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244978. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed Jun 20 13:13:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 08:13:19 -0500 Subject: FESCo elections In-Reply-To: <20070620101642.GB3164@free.fr> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> Message-ID: <1182345199.14977.13.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 12:16 +0200, Patrice Dumas wrote: > On Wed, Jun 20, 2007 at 07:03:56PM +1200, Nigel Jones wrote: > > > My understanding, FESCo (Fedora Extras Steering Committee) is to steer > > issues WRT to the Fedora Distribution [1] (formally the Fedora Extras > > Distribution), it makes sense to only allow current packagers as *they* > > are the ones that or contributing to the distribution. > > Maybe I am not following everything, but FESCo role is not that clear to > me after the merge. Areas of steering may also include release process > (for example the schedule), or not. Also previously FESCo had a role of > representing the community, though I don't know if it is really a FESCo > role, or if it is now a FAB role, for example. First, there is no FAB. FAB stands for "fedora-advisory-board" and is simply a mailing list, not a formal committee. If you meant the Fedora Ambassadors Steering Committee, that's FAmSco. Yay for ambiguous acronyms! FESCo still has a responsibility of representing the community. That is why it is comprised of people from the community, which are elected by the community itself. josh From bpepple at fedoraproject.org Wed Jun 20 13:31:31 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 20 Jun 2007 09:31:31 -0400 Subject: FESCo elections In-Reply-To: <4678D15C.6030108@nigelj.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> Message-ID: <1182346291.2806.9.camel@kennedy> On Wed, 2007-06-20 at 19:03 +1200, Nigel Jones wrote: > Is it me, or has the purpose of FESCo got lost? > > My understanding, FESCo (Fedora Extras Steering Committee) is to steer > issues WRT to the Fedora Distribution [1] (formally the Fedora Extras > Distribution), it makes sense to only allow current packagers as *they* > are the ones that or contributing to the distribution. > > FESCo has typically dealt with issues such as: > * Patent issues > * Package naming > * Static library issues > * Approving changes to packaging guidelines (already agreed to by the > packaging committee) > * Approval of new sponsors (for cvsextras) > > Have a look at http://fedoraproject.org/wiki/Development/Schedule > > Fedora Documentation has FDSCo (Fedora Documentation Steering > Committee), which last I checked does not report to FESCo, I believe > they report to the Board, like FESCo (?) > > So no, I'm not sure what advantage there would be to having non > packagers in FESCo, ditto with having non documentation writers in > FDSCo, by all means, attend the meetings, but the casting vote I'm not > sure about. FESCo is taking on new responsibilities due to the merge of Core/Extras. Some of the responsibilities include overseeing: 1. Features 2. Theory of Packaging (Packaging Committee) 3. Practice of Packaging (Old FESCo responsibilities) 4. Release Engineering (rel-eng team) 5. QA For more information, please refer to: https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.html Later, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Wed Jun 20 13:43:24 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 20 Jun 2007 09:43:24 -0400 Subject: FESCo elections In-Reply-To: <1182317830.21966.415.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> Message-ID: <1182347004.2806.20.camel@kennedy> On Tue, 2007-06-19 at 22:37 -0700, Karsten Wade wrote: > On Tue, 2007-06-19 at 20:10 -0700, Toshio Kuratomi wrote: > > On Tue, 2007-06-19 at 19:33 -0700, John Poelstra wrote: > > > > I do not maintain any packages, but participate in the Fedora. Can I still run? > > > > > Not according to the policy. I think the policy deserves to be examined > > since FESCo is no longer strictly about packaging but about making all > > technical decisions WRT Fedora. I'm undecided whether it should be > > updated this close to the election. Does anyone else have thoughts on > > this? > > It's not too close to the elections to change this detail in this > direction. Too close to restrict the pool of contenders, but not too > close to expand it. > > +1 to FESCo candidates being anyone with an FAS account. +1 to allowing more folks be eligible for FESCo, though I'm not sure if anyone with a FAS account is the right criteria. Some of the things that FESCo will most likely be overseeing in the future are things like New Features (which John will be leading), QA, and Release Engineering. It makes sense we should make the folks involved with these aspects of the project also eligible to be part of FESCo. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonathan.underwood at gmail.com Wed Jun 20 13:44:52 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 20 Jun 2007 14:44:52 +0100 Subject: Driver Manager In-Reply-To: <7ff232d10706200220j7bcaa9d0w8bf9d7e7b7473dc0@mail.gmail.com> References: <7ff232d10706200220j7bcaa9d0w8bf9d7e7b7473dc0@mail.gmail.com> Message-ID: <645d17210706200644y3b79f272pef2097519d44ae93@mail.gmail.com> On 20/06/07, Nick Irelan wrote: > Hello, > I would like to start a new open source project that will help manage > drivers in Linux and/or other OSes. If anyone out there has expierence with > drivers and would like to help please email me. > Thanks > Nick Irelan What do you mean by "manage" exactly? I think it would help if you were clearer about your goals - that would make it easier for people to comment/offer to help. Cheers, Jonathan. From mclasen at redhat.com Wed Jun 20 13:45:50 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 20 Jun 2007 09:45:50 -0400 Subject: Driver Manager In-Reply-To: <645d17210706200644y3b79f272pef2097519d44ae93@mail.gmail.com> References: <7ff232d10706200220j7bcaa9d0w8bf9d7e7b7473dc0@mail.gmail.com> <645d17210706200644y3b79f272pef2097519d44ae93@mail.gmail.com> Message-ID: <1182347150.3517.3.camel@dhcp83-186.boston.redhat.com> On Wed, 2007-06-20 at 14:44 +0100, Jonathan Underwood wrote: > On 20/06/07, Nick Irelan wrote: > > Hello, > > I would like to start a new open source project that will help manage > > drivers in Linux and/or other OSes. If anyone out there has expierence with > > drivers and would like to help please email me. > > Thanks > > Nick Irelan > > What do you mean by "manage" exactly? I think it would help if you > were clearer about your goals - that would make it easier for people > to comment/offer to help. Also see http://fedoraproject.org/wiki/Releases/FeatureDriverBuddy for currently ongoing work in this area. The wiki page is unfortunately not very clear either... From j.w.r.degoede at hhs.nl Wed Jun 20 14:10:34 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Wed, 20 Jun 2007 16:10:34 +0200 Subject: Fedora Package Status of Jun 19, 2007 In-Reply-To: <20070620003459.5f9c7416@ludwig-alpha.unil.ch> References: <20070620003459.5f9c7416@ludwig-alpha.unil.ch> Message-ID: On Wed, 20 Jun 2007 00:34:59 +0200 Christian Iseli wrote: > Hi folks, > > Now that the BZ merge seems to be done, I have updated > the > PackageStatus page. There seems to be a problem > somewhere though: a > lot of ACCEPTed closed tickets seem to be missing. Dunno > yet whether > it's my script or bugzilla acting up (or maybe I just did > this too > early and the merge is not completed yet). I won't have > time right now, > but I'll go hunting ASAP. Feel free to post hints, too > :-) > > There are a ton of open bugs, too... > You seem to not taking releases updates into account, for example for F-7 your script complains tat blobAndConquer is in comps, but not in the repo, but it is in the repo, its in updates. Regards, Hans From pjones at redhat.com Wed Jun 20 14:16:06 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 20 Jun 2007 10:16:06 -0400 Subject: FESCo elections In-Reply-To: <1182347004.2806.20.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> Message-ID: <467936A6.2060402@redhat.com> Brian Pepple wrote: > On Tue, 2007-06-19 at 22:37 -0700, Karsten Wade wrote: >> On Tue, 2007-06-19 at 20:10 -0700, Toshio Kuratomi wrote: >>> On Tue, 2007-06-19 at 19:33 -0700, John Poelstra wrote: >>>> I do not maintain any packages, but participate in the Fedora. Can I still run? >>>> >>> Not according to the policy. I think the policy deserves to be examined >>> since FESCo is no longer strictly about packaging but about making all >>> technical decisions WRT Fedora. I'm undecided whether it should be >>> updated this close to the election. Does anyone else have thoughts on >>> this? >> It's not too close to the elections to change this detail in this >> direction. Too close to restrict the pool of contenders, but not too >> close to expand it. >> >> +1 to FESCo candidates being anyone with an FAS account. > > +1 to allowing more folks be eligible for FESCo, though I'm not sure if > anyone with a FAS account is the right criteria. I think it's a good enough criteria. If there's somebody involved that doesn't have an account and wants to be elected, getting an account isn't a very high bar. If there's somebody *not* involved who wants to be elected, getting an account isn't going to change the fact that none of us recognize them. Sure, it's arbitrary, but it's not terrible. -- Peter From Christian.Iseli at licr.org Wed Jun 20 14:25:51 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 20 Jun 2007 16:25:51 +0200 Subject: Fedora Package Status of Jun 19, 2007 In-Reply-To: References: <20070620003459.5f9c7416@ludwig-alpha.unil.ch> Message-ID: <20070620162551.2964b7f0@ludwig-alpha.unil.ch> On Wed, 20 Jun 2007 16:10:34 +0200, Goede, J.W.R. de wrote: > You seem to not taking releases updates into account, for > example for F-7 your script complains tat blobAndConquer is > in comps, but not in the repo, but it is in the repo, its > in updates. Good catch. I'll update the page shortly. I think I also found out why I was missing a lot of the accepted reviews (my bad, of course). Cheers, C From pjones at redhat.com Wed Jun 20 14:27:55 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 20 Jun 2007 10:27:55 -0400 Subject: Root filesystem encryption update In-Reply-To: References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <4677F20F.8050405@redhat.com> Message-ID: <4679396B.7070902@redhat.com> Thomas Swan wrote: > I think we might be putting the cart before the horse. I'm *sure* we're putting the cart before the horse -- that's what Jeremy and I have been getting at. It's possible to solve these problems, but there are other things that need to be done before we'll have a good solution. More on that below. > A user would be thawing from hibernation on a machine with an > *existing* installation. Therefore language, and keymaps would have > been chosen (during installation) prior to the hibernate operation. Yeah, we can definitely store something that's right /some/ of the time. Just be aware that there are lots of corner cases. As an example, I often suspend my laptop before driving to work in the morning. When it resumes, it's in a docking station and there's a different keyboard, with a somewhat different key map. It's not that getting a password from the user on resume is an intractable problem, but that there are steps to be taken before we can solve it in a way that maintains the level of quality and support expected of Fedora. We've got (some of) the filesystem technology to do this, and that's one piece. Another piece is getting video mode setting into the kernel so we can display the graphics required for non-European languages early on in a cleaner way than e.g. svgalib, without having to pull in all of X. There's work going forward on this. Point being, it's a complex feature, and a lot of the traffic on the list seems to ignore many aspects of why. -- Peter From katzj at redhat.com Wed Jun 20 14:30:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Jun 2007 10:30:33 -0400 Subject: FESCo elections In-Reply-To: <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> Message-ID: <1182349833.30259.4.camel@erebor.boston.redhat.com> On Wed, 2007-06-20 at 10:21 +0200, Florian La Roche wrote: > On Tue, Jun 19, 2007 at 07:33:46PM -0700, John Poelstra wrote: > > I do not maintain any packages, but participate in the Fedora. Can I still > > run? > > why not just apply for the group "cvsextras"? There shouldn't be a > requirement there to own packages then. How else would you get sponsored for membership in cvsextras? This is the group that gives access to the package CVS repository -- the _only_ way in is to submit a package and have it reviewed, approved and finding a sponsor Jeremy From jwboyer at jdub.homelinux.org Wed Jun 20 14:35:15 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 09:35:15 -0500 Subject: FESCo elections In-Reply-To: <1182349833.30259.4.camel@erebor.boston.redhat.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> Message-ID: <1182350116.14977.20.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 10:30 -0400, Jeremy Katz wrote: > On Wed, 2007-06-20 at 10:21 +0200, Florian La Roche wrote: > > On Tue, Jun 19, 2007 at 07:33:46PM -0700, John Poelstra wrote: > > > I do not maintain any packages, but participate in the Fedora. Can I still > > > run? > > > > why not just apply for the group "cvsextras"? There shouldn't be a > > requirement there to own packages then. > > How else would you get sponsored for membership in cvsextras? This is > the group that gives access to the package CVS repository -- the _only_ > way in is to submit a package and have it reviewed, approved and finding > a sponsor No it's not. Co-maintainers. josh From dyoung at mesd.k12.or.us Wed Jun 20 15:33:36 2007 From: dyoung at mesd.k12.or.us (Dan Young) Date: Wed, 20 Jun 2007 08:33:36 -0700 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706200115p6699c335p4474a949ed121349@mail.gmail.com> References: <4673037B.3030105@laposte.net> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> <994441ae0706192216q24f1bc8dndd68e3209a0b16c4@mail.gmail.com> <6280325c0706200115p6699c335p4474a949ed121349@mail.gmail.com> Message-ID: <994441ae0706200833p358d0f72t5cab876b43c964b1@mail.gmail.com> On 6/20/07, n0dalus wrote: > On 6/20/07, Dan Young wrote: > > On 6/19/07, n0dalus wrote: > > > In what way would it benefit a majority of users? I could be wrong, > > > but I suspect the majority of Fedora installations only have one > > > administrator, in which case, sudo actually ends up making things > > > _less_ secure (it provides another account by which root access can be > > > cracked). > > > > In a "1st user gets sudo" scenario, I'd lock the root account. It > > wouldn't be _another_ account to crack, it would be a different > > account. > > > > If that's what you want, can I suggest you propose that as a firstboot > option instead then? Currently the proposal seemed to be just "1st > user gets sudo", and root is still available. I don't care either way, frankly. It's unlikely that consensus can be reached on a change like this. The only reason Ubuntu could get away with it is that it was the default since the no-name-yet.com days. -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From bpepple at fedoraproject.org Wed Jun 20 16:21:31 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 20 Jun 2007 12:21:31 -0400 Subject: Plan for tomorrows (20070621) FESCO meeting Message-ID: <1182356491.3250.10.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- sponsor nominations -- Jochen Schmitt /topic FESCO-Meeting -- sponsor nominations -- Xavier Lamien /topic FESCO-Meeting -- sponsor nominations -- Dominik Mierzejewski /topic FESCO-Meeting -- OLPC -- include binary firmware for the Libertas usb8488 - http://people.freedesktop.org/~johnp/libertas-usb8388-firmware.spec /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-meeting -- Statically link libuu (uulib-static) into klibido -- tibbs -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at licr.org Wed Jun 20 16:21:43 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 20 Jun 2007 18:21:43 +0200 Subject: Fedora Package Status of Jun 20, 2007 Message-ID: <20070620182143.751a8cbf@ludwig-alpha.unil.ch> Hi folks, A bit of a brown paper bag case... so I updated that page again. It's a pain, because updating it is *dog* slow, and fails several times before the changes are actually uploaded. I have now tried to split out some parts of the page into a few sub-pages. I'm still trying to upload the sub-pages... The counts should now be correct, and the update repo is taken into account. Cheers, C ==== Fedora Package Status of Jun 20, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4596 packages - 7579 binary rpms in devel - 110 orphans - 44 packages not available in devel or release Axel dot Thimm at ATrpms dot net vtkdata Axel dot Thimm at ATrpms dot net vtk ajackson at redhat dot com xorg-x11-drv-vermilion andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue andreas at bawue dot net perl-NetAddr-IP arnd at arndb dot de dtc bdpepple at ameritech dot net galago-filesystem bdpepple at ameritech dot net gaim-galago bnocera at redhat dot com gnome-launch-box cgoorah at yahoo dot com dot au netgen cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu gaim-gaym dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask foolish at guezz dot net perl-Net-Packet foolish at guezz dot net perl-SQLite-Simple gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils icon at fedoraproject dot org mod_evasive jafo at tummy dot com python-mechanoid jafo at tummy dot com python-memcached jmp at safe dot ca clement johnp at redhat dot com GConf2-dbus jorton at redhat dot com libc-client jwboyer at jdub dot homelinux dot org gaim-meanwhile lxtnow at gmail dot com gshutdown mastahnke at gmail dot com epel-release mastahnke at gmail dot com php-magpierss maxime at maxca dot info pypar2 mpg at redhat dot com sugar-artwork mpg at redhat dot com xapian-core paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman rvokal at redhat dot com gaim-guifications splinux at fedoraproject dot org drapes vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp wjhns174 at hardakers dot net perl-Crypt-OpenSSL-DSA wjhns174 at hardakers dot net perl-Crypt-OpenSSL-PKCS10 wjhns174 at hardakers dot net perl-Digest-SHA yufanyufan at gmail dot com audacious-plugins-docklet - 2 packages not available in devel but present in release caolanm at redhat dot com hunspell-he jorton at redhat dot com newt-perl - 12 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=222191,232702,232703,242566,244523 eclipse bkonrath at redhat.com perl-Compress-Raw-Bzip2 steve at silug.org perl-IO-Compress-Bzip2 steve at silug.org cegui packages at amiga-hardware.com ddrescue splinux25 at gmail.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221084,221717,224458,226725,227091,231861,243006 dkms Matt_Domsch at dell.com agg caolanm at redhat.com libsilc wtogami at redhat.com netgen cgoorah at yahoo.com.au objectweb-anttask rafaels at redhat.com cyrus-imapd tjanouse at redhat.com apr jorton at redhat.com - 3 packages present in the development repo which have no owners entry audacious-docklet s390utils ws-commons-util - 19 orphaned packages, yet available in devel docbook-dtds docbook-simple docbook-slides docbook-style-dsssl docbook-style-xsl docbook-utils driftnet gnome-bluetooth gob2 libbtctl libedit linuxdoc-tools luks-tools openjade opensp pam_usb udftools xmltex xmlto FE-ACCEPT packages stats: - 2669 accepted, closed package reviews - 35 accepted, closed package reviews not in repo - 6 accepted, closed package reviews not in owners - 99 accepted, open package reviews older than 4 weeks; - 121 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 225 open tickets - 84 tickets with no activity in eight weeks - 23 tickets with no activity in four weeks - 18 closed tickets FE-NEW packages stats: - 982 open tickets - 766 tickets with no activity in eight weeks - 41 tickets with no activity in four weeks - 2 closed tickets FE-NEEDSPONSOR packages stats: - 50 open tickets - 4 tickets with no activity in eight weeks - 3 tickets with no activity in four weeks FE-LEGAL packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks OPEN-BUGS packages stats: - 7991 open tickets - 5103 tickets with no activity in eight weeks - 856 tickets with no activity in four weeks CVS stats: - 4609 packages with a devel directory - 12 packages with no owners entry hunspell-ar isorelax-0-0.1.release20050331.1jpp.1.src.rpm mrxvt mysql-administrator olpc-hardware-manager postgis reciteword subcommander sugar-presence-service svnkit tdma xapian-bindings - 199 packages were dropped from Fedora Maintainers stats: - 380 maintainers - 2 inactive maintainers with open bugs - 3 inactive maintainers Dropped Fedora packages: - 2 packages were dropped since Fedora 7 Comps.xml files stats: - 2376 packages in comps-f8 file - 999 packages missing from comps-f8 file - 31 packages in comps-f8 but not in repo - 2378 packages in comps-f7 file - 974 packages missing from comps-f7 file - 30 packages in comps-f7 but not in repo From thomas.swan at gmail.com Wed Jun 20 16:23:13 2007 From: thomas.swan at gmail.com (Thomas Swan) Date: Wed, 20 Jun 2007 11:23:13 -0500 Subject: Root filesystem encryption update In-Reply-To: <4679396B.7070902@redhat.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <4677F20F.8050405@redhat.com> <4679396B.7070902@redhat.com> Message-ID: On 6/20/07, Peter Jones wrote: > > I'm *sure* we're putting the cart before the horse -- that's what Jeremy > and I have been getting at. It's possible to solve these problems, but > there are other things that need to be done before we'll have a good > solution. More on that below. > > > A user would be thawing from hibernation on a machine with an > > *existing* installation. Therefore language, and keymaps would have > > been chosen (during installation) prior to the hibernate operation. > > Yeah, we can definitely store something that's right /some/ of the time. > Just be aware that there are lots of corner cases. As an example, I > often suspend my laptop before driving to work in the morning. When it > resumes, it's in a docking station and there's a different keyboard, > with a somewhat different key map. > > It's not that getting a password from the user on resume is an > intractable problem, but that there are steps to be taken before we can > solve it in a way that maintains the level of quality and support > expected of Fedora. We've got (some of) the filesystem technology to do > this, and that's one piece. Another piece is getting video mode setting > into the kernel so we can display the graphics required for non-European > languages early on in a cleaner way than e.g. svgalib, without having to > pull in all of X. There's work going forward on this. This was something I was something of which I was completely unaware. Point being, it's a complex feature, and a lot of the traffic on the > list seems to ignore many aspects of why. > Excellent points. I'm currently at an impasse with the anaconda screens; however, a small video and step-by-step mockup should be up shortly on my page. Is there anything I can do/explore to help move this for Fedora 8? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Wed Jun 20 16:28:42 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 11:28:42 -0500 Subject: Fedora Package Status of Jun 20, 2007 In-Reply-To: <20070620182143.751a8cbf@ludwig-alpha.unil.ch> References: <20070620182143.751a8cbf@ludwig-alpha.unil.ch> Message-ID: <1182356922.14977.44.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 18:21 +0200, Christian Iseli wrote: > jwboyer at jdub dot homelinux dot org gaim-meanwhile This is dead now. Part of pidgin josh From Christian.Iseli at licr.org Wed Jun 20 16:36:56 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 20 Jun 2007 18:36:56 +0200 Subject: Fedora Package Status of Jun 20, 2007 In-Reply-To: <1182356922.14977.44.camel@weaponx.rchland.ibm.com> References: <20070620182143.751a8cbf@ludwig-alpha.unil.ch> <1182356922.14977.44.camel@weaponx.rchland.ibm.com> Message-ID: <20070620183656.4d4a895d@ludwig-alpha.unil.ch> On Wed, 20 Jun 2007 11:28:42 -0500, Josh Boyer wrote: > On Wed, 2007-06-20 at 18:21 +0200, Christian Iseli wrote: > > > jwboyer at jdub dot homelinux dot org gaim-meanwhile > > This is dead now. Part of pidgin In this case, could you please put a dead.package file in the devel repo as outlined in http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife Thanks, C From jwboyer at jdub.homelinux.org Wed Jun 20 16:39:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 11:39:57 -0500 Subject: Fedora Package Status of Jun 20, 2007 In-Reply-To: <20070620183656.4d4a895d@ludwig-alpha.unil.ch> References: <20070620182143.751a8cbf@ludwig-alpha.unil.ch> <1182356922.14977.44.camel@weaponx.rchland.ibm.com> <20070620183656.4d4a895d@ludwig-alpha.unil.ch> Message-ID: <1182357597.14977.46.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 18:36 +0200, Christian Iseli wrote: > On Wed, 20 Jun 2007 11:28:42 -0500, Josh Boyer wrote: > > On Wed, 2007-06-20 at 18:21 +0200, Christian Iseli wrote: > > > > > jwboyer at jdub dot homelinux dot org gaim-meanwhile > > > > This is dead now. Part of pidgin > > In this case, could you please put a dead.package file in the devel > repo as outlined in > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife Oops. Now it's my turn for a brown paper bag. I thought I did that a while ago. josh From Christian.Iseli at licr.org Wed Jun 20 16:44:12 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 20 Jun 2007 18:44:12 +0200 Subject: Fedora Package Status of Jun 20, 2007 In-Reply-To: <1182357597.14977.46.camel@weaponx.rchland.ibm.com> References: <20070620182143.751a8cbf@ludwig-alpha.unil.ch> <1182356922.14977.44.camel@weaponx.rchland.ibm.com> <20070620183656.4d4a895d@ludwig-alpha.unil.ch> <1182357597.14977.46.camel@weaponx.rchland.ibm.com> Message-ID: <20070620184412.541b09a6@ludwig-alpha.unil.ch> On Wed, 20 Jun 2007 11:39:57 -0500, Josh Boyer wrote: > Oops. Now it's my turn for a brown paper bag. I thought I did that a > while ago. eh :-) welcome to the club... C From a.badger at gmail.com Wed Jun 20 17:00:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 Jun 2007 10:00:04 -0700 Subject: FESCo elections In-Reply-To: <467936A6.2060402@redhat.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <467936A6.2060402@redhat.com> Message-ID: <1182358804.8424.12.camel@localhost.localdomain> On Wed, 2007-06-20 at 10:16 -0400, Peter Jones wrote: > Brian Pepple wrote: > > On Tue, 2007-06-19 at 22:37 -0700, Karsten Wade wrote: > >> On Tue, 2007-06-19 at 20:10 -0700, Toshio Kuratomi wrote: > >>> On Tue, 2007-06-19 at 19:33 -0700, John Poelstra wrote: > >>>> I do not maintain any packages, but participate in the Fedora. Can I still run? > >>>> > >>> Not according to the policy. I think the policy deserves to be examined > >>> since FESCo is no longer strictly about packaging but about making all > >>> technical decisions WRT Fedora. I'm undecided whether it should be > >>> updated this close to the election. Does anyone else have thoughts on > >>> this? > >> It's not too close to the elections to change this detail in this > >> direction. Too close to restrict the pool of contenders, but not too > >> close to expand it. > >> > >> +1 to FESCo candidates being anyone with an FAS account. > > > > +1 to allowing more folks be eligible for FESCo, though I'm not sure if > > anyone with a FAS account is the right criteria. > > I think it's a good enough criteria. If there's somebody involved that > doesn't have an account and wants to be elected, getting an account > isn't a very high bar. If there's somebody *not* involved who wants to > be elected, getting an account isn't going to change the fact that none > of us recognize them. Sure, it's arbitrary, but it's not terrible. > One point -- currently, the eligible voters and the candidate pool coincide. I'm assuming that we are talking about keeping that aspect the same (rather than letting anyone with a CLA_done be a candidate while only cvsextras can vote.) When the policy was ratified by FESCo, this was a point that was debated and can be found in the Meeting Archives [1]_. With that in mind I think Brian Pepple's list of FESCo responsibilities [2]_ is a good starting place as it lists the areas of Fedora that FESCo has direct control over. Other areas FESCo may influence but they do not have responsibility for or control. Basically, you should be able to vote if you are under FESCo's authority. You should not be able to vote if you are not. [1]_: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060824 [2]_: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02136.html -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Jun 20 17:14:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jun 2007 09:14:00 -0800 Subject: FESCo elections In-Reply-To: <1182350116.14977.20.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> Message-ID: <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> On 6/20/07, Josh Boyer wrote: > No it's not. Co-maintainers. Do we have examples of co-maintainers who are themselves not a primary package maintainer who has gone through the package submission and sponsorship process? I'd love to know that such a precedent exists. -jef From jspaleta at gmail.com Wed Jun 20 17:15:59 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jun 2007 09:15:59 -0800 Subject: FESCo elections In-Reply-To: <1182347004.2806.20.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> Message-ID: <604aa7910706201015g1915064cr1bd6d0ec66c62626@mail.gmail.com> On 6/20/07, Brian Pepple wrote: > Some of the things that FESCo will most likely be overseeing in the > future are things like New Features (which John will be leading), QA, > and Release Engineering. It makes sense we should make the folks > involved with these aspects of the project also eligible to be part of > FESCo. Is this distinction currently academic? Is there anyone in release-eng or QA that aren't already in the cvsextras group? -jef From tmraz at redhat.com Wed Jun 20 17:17:33 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 20 Jun 2007 19:17:33 +0200 Subject: suggestions for admin-power users [was Re: user created at install added in sudoers ?] In-Reply-To: <20070619174637.GB29865@jadzia.bu.edu> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <364d303b0706190728p37f70aecxdd4aabd7ac4dc0d2@mail.gmail.com> <20070619174637.GB29865@jadzia.bu.edu> Message-ID: <1182359853.3280.15.camel@perun.kabelta.loc> On Tue, 2007-06-19 at 13:46 -0400, Matthew Miller wrote: > 5) Can we pretty-please enable pam_passwdqc for all users, even root? What's wrong with pam_cracklib apart from slightly different configuration options? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From ruben at rubenkerkhof.com Wed Jun 20 17:25:34 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Wed, 20 Jun 2007 19:25:34 +0200 Subject: rpms/rpm/devel rpm.spec,1.230,1.231 In-Reply-To: <200706190809.l5J89iQ8020843@cvs-int.fedora.redhat.com> References: <200706190809.l5J89iQ8020843@cvs-int.fedora.redhat.com> Message-ID: On 19-jun-2007, at 10:09, Panu Matilainen (pmatilai) wrote: > -Requires: patch > 2.5 > -Prereq: shadow-utils > +Requires(pre): shadow-utils > +Requires(pre): shadow-utils > +Requires(postun): shadow-utils shadow-utils is required twice here Ruben From bpepple at fedoraproject.org Wed Jun 20 17:32:30 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 20 Jun 2007 13:32:30 -0400 Subject: FESCo elections In-Reply-To: <1182358804.8424.12.camel@localhost.localdomain> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <467936A6.2060402@redhat.com> <1182358804.8424.12.camel@localhost.localdomain> Message-ID: <1182360750.3250.16.camel@kennedy> On Wed, 2007-06-20 at 10:00 -0700, Toshio Kuratomi wrote: > > Basically, you should be able to vote if you are under FESCo's > authority. You should not be able to vote if you are not. Agreed. So, we need to identify the people in QA, rel-eng, and features groups, that aren't currently in the cvsextras, and modify our election software to give them the necessary permissions to vote. Right? /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Wed Jun 20 17:35:55 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 20 Jun 2007 13:35:55 -0400 Subject: FESCo elections In-Reply-To: <604aa7910706201015g1915064cr1bd6d0ec66c62626@mail.gmail.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <604aa7910706201015g1915064cr1bd6d0ec66c62626@mail.gmail.com> Message-ID: <1182360955.3250.22.camel@kennedy> On Wed, 2007-06-20 at 09:15 -0800, Jeff Spaleta wrote: > On 6/20/07, Brian Pepple wrote: > > Some of the things that FESCo will most likely be overseeing in the > > future are things like New Features (which John will be leading), QA, > > and Release Engineering. It makes sense we should make the folks > > involved with these aspects of the project also eligible to be part of > > FESCo. > > Is this distinction currently academic? Is there anyone in release-eng > or QA that aren't already in the cvsextras group? I believe John Poelestra and Will Woods off the top of my head. There may be more, since I'm not aware of everyone on those groups. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Wed Jun 20 17:37:54 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 20 Jun 2007 13:37:54 -0400 Subject: FESCo elections In-Reply-To: <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> Message-ID: <1182361074.3250.26.camel@kennedy> On Wed, 2007-06-20 at 09:14 -0800, Jeff Spaleta wrote: > On 6/20/07, Josh Boyer wrote: > > No it's not. Co-maintainers. > > Do we have examples of co-maintainers who are themselves not a primary > package maintainer who has gone through the package submission and > sponsorship process? I'd love to know that such a precedent exists. This is something we've talked about doing, but I'm not aware of it being actually done yet. This was one of the reasons that acl's were implemented, so we could make it easier for new folks to join and limit the amount of damage they could potentially cause. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Jun 20 17:43:23 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 20 Jun 2007 10:43:23 -0700 Subject: FESCo elections In-Reply-To: <1182360750.3250.16.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <467936A6.2060402@redhat.com> <1182358804.8424.12.camel@localhost.localdomain> <1182360750.3250.16.camel@kennedy> Message-ID: <1182361403.8424.24.camel@localhost.localdomain> On Wed, 2007-06-20 at 13:32 -0400, Brian Pepple wrote: > On Wed, 2007-06-20 at 10:00 -0700, Toshio Kuratomi wrote: > > > > Basically, you should be able to vote if you are under FESCo's > > authority. You should not be able to vote if you are not. > > Agreed. So, we need to identify the people in QA, rel-eng, and features > groups, that aren't currently in the cvsextras, and modify our election > software to give them the necessary permissions to vote. Right? > Basically yes. If we just identify groups for these areas we can add those easily enough. I see these groups in the account system which might be relevant: releng securit_respons qa-admin I don't think this is going to adequately cover everyone, though. f13, does releng include all the release engineers that should have voting privileges? wwoods, poelcat do we need to add a tracker group to the Account System for QA and features? Should the security response team fall under QA or have its own group? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Jun 20 17:54:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Jun 2007 13:54:53 -0400 Subject: FESCo elections In-Reply-To: <1182361403.8424.24.camel@localhost.localdomain> References: <1182223698.2796.0.camel@kennedy> <1182360750.3250.16.camel@kennedy> <1182361403.8424.24.camel@localhost.localdomain> Message-ID: <200706201354.54175.jkeating@redhat.com> On Wednesday 20 June 2007 13:43:23 Toshio Kuratomi wrote: > I see these groups in the account system which might be relevant: > ? releng I'm not entirely sure what this group is used for. I have a gitreleng group that I manage for write access to the releng git module. I forget what this 'releng' group is for. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Jun 20 18:04:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Jun 2007 23:34:58 +0530 Subject: user created at install added in sudoers ? In-Reply-To: <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> References: <4673037B.3030105@laposte.net> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> <467871C8.20308@fedoraproject.org> <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> Message-ID: <46796C4A.9030209@fedoraproject.org> Chris Brown wrote: > > > So now because writing documentation is a hassle we shouldn't do it? > Again, pretty poor argument but what the hell, I'm happy to write the > docs if this gets implemented. Documentation mentions su -c "command" all over the place. You have to consider whether you want to mention sudo or su or both if this is made a option. Dismissing concerns as poor without being involved is pretty easy. Documentation is far from the only concern with adding more options. Rahul From andy at smile.org.ua Wed Jun 20 18:07:40 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Wed, 20 Jun 2007 21:07:40 +0300 Subject: Questions regarding my man/info summer project In-Reply-To: <1182294471.6878.11.camel@core2.lynema.com> References: <200706121533.50219.vpivaini@cs.helsinki.fi> <4677DC96.3000301@redhat.com> <1182294471.6878.11.camel@core2.lynema.com> Message-ID: <20070620180740.GB3255@serv.smile.org.ua> Hi Tom Lynema! On Tue, Jun 19, 2007 at 06:07:51PM -0500, Tom Lynema wrote next: > Oddly enough, I just started working on a site with similar > requirements. The bash command I used to convert the man pages to > WikiMedia markup looked something like this: > for i in `ls /usr/share/man/man3/*.bz2` ; do bunzip2 -c $i | man2html > | html2wiki --dialect MediaWiki --encoding iso-8859-1 > --base-uri http://wikux.org --wiki-uri http://wikux.org/ > > /home/lyz/Programming/Web/Wikux.org/man3bz2/$i.wiki ; done > > As you can see, the main tools used were man2html and html2wiki. > > I never considered going the other way around, but did keep the markup > results handy so they could be diffed to check for updated pages. FYI: The wiki2man project is developing on the http://wiki2man.sourceforge.net/ P.S. I'm maintaing the man-pages-uk package that core was created by the wiki2man script. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From karsten at redhat.com Wed Jun 20 20:24:07 2007 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 20 Jun 2007 22:24:07 +0200 Subject: Root filesystem encryption update In-Reply-To: <4679396B.7070902@redhat.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <4677F20F.8050405@redhat.com> <4679396B.7070902@redhat.com> Message-ID: <46798CE7.6030701@redhat.com> Peter Jones schrieb: > Thomas Swan wrote: > >> I think we might be putting the cart before the horse. > > I'm *sure* we're putting the cart before the horse -- that's what Jeremy > and I have been getting at. It's possible to solve these problems, but > there are other things that need to be done before we'll have a good > solution. More on that below. > >> A user would be thawing from hibernation on a machine with an >> *existing* installation. Therefore language, and keymaps would have >> been chosen (during installation) prior to the hibernate operation. > > Yeah, we can definitely store something that's right /some/ of the time. > Just be aware that there are lots of corner cases. As an example, I > often suspend my laptop before driving to work in the morning. When it > resumes, it's in a docking station and there's a different keyboard, > with a somewhat different key map. > > It's not that getting a password from the user on resume is an > intractable problem, but that there are steps to be taken before we can > solve it in a way that maintains the level of quality and support > expected of Fedora. We've got (some of) the filesystem technology to do > this, and that's one piece. Another piece is getting video mode setting > into the kernel so we can display the graphics required for non-European > languages early on in a cleaner way than e.g. svgalib, without having to > pull in all of X. There's work going forward on this. > > Point being, it's a complex feature, and a lot of the traffic on the > list seems to ignore many aspects of why. > I agree that getting encryption support into the initrd is just one of many pieces, but it is a first step that can be done now without having to wait for the kernel side even if it means that some users can't use root FS encryption in their native language at the moment. But it gives us some time to find bugs and fix them before we put all the pieces together. Karsten From davej at redhat.com Wed Jun 20 18:40:20 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 14:40:20 -0400 Subject: 586 kernels. Message-ID: <20070620184020.GH23569@redhat.com> A day or so ago, I flipped the switch and killed off the 586 specific kernel, by making the 686 kernel bootable on older machines. Turns out it isn't that easy however. Rpm will refuse to install the 686 kernel a 586, because it checks the arch.. sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm Preparing... ########################################### [100%] package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture (Oddly, the 586 kernel uname is reporting itself as 686 already, which I don't quite understand.. Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 i686 i386 GNU/Linux) Anyway.. To 'solve' this, I think I'm going to have to make the 686 kernel package an 'i386' package. Does anyone see anything flawed with this approach? (Modulo problems with yum doing exactarch matches and upgrades being more of a nightmare than usual). Dave -- http://www.codemonkey.org.uk From skvidal at linux.duke.edu Wed Jun 20 18:44:54 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 14:44:54 -0400 Subject: 586 kernels. In-Reply-To: <20070620184020.GH23569@redhat.com> References: <20070620184020.GH23569@redhat.com> Message-ID: <1182365094.4102.17.camel@hodge> On Wed, 2007-06-20 at 14:40 -0400, Dave Jones wrote: > A day or so ago, I flipped the switch and killed off the 586 specific > kernel, by making the 686 kernel bootable on older machines. > Turns out it isn't that easy however. > Rpm will refuse to install the 686 kernel a 586, because it checks > the arch.. > > sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm > Preparing... ########################################### [100%] > package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture > > > (Oddly, the 586 kernel uname is reporting itself as 686 already, > which I don't quite understand.. > Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 i686 i386 GNU/Linux) > > Anyway.. To 'solve' this, I think I'm going to have to make the 686 > kernel package an 'i386' package. > > Does anyone see anything flawed with this approach? > > (Modulo problems with yum doing exactarch matches and upgrades being > more of a nightmare than usual). so, umm we're going to have users 'ugprading' from kernel.i586 to kernel.i386? Is that right? -sv From jkeating at redhat.com Wed Jun 20 18:46:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Jun 2007 14:46:04 -0400 Subject: 586 kernels. In-Reply-To: <1182365094.4102.17.camel@hodge> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> Message-ID: <200706201446.05150.jkeating@redhat.com> On Wednesday 20 June 2007 14:44:54 seth vidal wrote: > so, umm > we're going to have users 'ugprading' from kernel.i586 to kernel.i386? > Is that right? They'd be going from i686 to i386 too it would seem. My brain just screams that this is confusing, but I'm not coming up with any hard problems yet. Can you do up a scratch build for us to play with Dave? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Wed Jun 20 18:48:50 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 14:48:50 -0400 Subject: 586 kernels. In-Reply-To: <200706201446.05150.jkeating@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> Message-ID: <1182365330.4102.19.camel@hodge> On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote: > On Wednesday 20 June 2007 14:44:54 seth vidal wrote: > > so, umm > > we're going to have users 'ugprading' from kernel.i586 to kernel.i386? > > Is that right? > > They'd be going from i686 to i386 too it would seem. > > My brain just screams that this is confusing, but I'm not coming up with any > hard problems yet. Can you do up a scratch build for us to play with Dave? > just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and let's not even start thinking about what this will mean for kernel modules. -sv From jwboyer at jdub.homelinux.org Wed Jun 20 18:56:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 13:56:17 -0500 Subject: FESCo elections In-Reply-To: <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> Message-ID: <1182365777.14977.75.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 09:14 -0800, Jeff Spaleta wrote: > On 6/20/07, Josh Boyer wrote: > > No it's not. Co-maintainers. > > Do we have examples of co-maintainers who are themselves not a primary > package maintainer who has gone through the package submission and > sponsorship process? I'd love to know that such a precedent exists. Not that I know of. But we also don't have current, codified rules on what criteria a sponsor has to use before sponsoring someone. There is technically nothing preventing it from happening now. Discussion on such criteria might be warranted. josh From jwboyer at jdub.homelinux.org Wed Jun 20 19:02:09 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 14:02:09 -0500 Subject: FESCo elections In-Reply-To: <1182360955.3250.22.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <604aa7910706201015g1915064cr1bd6d0ec66c62626@mail.gmail.com> <1182360955.3250.22.camel@kennedy> Message-ID: <1182366129.14977.78.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 13:35 -0400, Brian Pepple wrote: > On Wed, 2007-06-20 at 09:15 -0800, Jeff Spaleta wrote: > > On 6/20/07, Brian Pepple wrote: > > > Some of the things that FESCo will most likely be overseeing in the > > > future are things like New Features (which John will be leading), QA, > > > and Release Engineering. It makes sense we should make the folks > > > involved with these aspects of the project also eligible to be part of > > > FESCo. > > > > Is this distinction currently academic? Is there anyone in release-eng > > or QA that aren't already in the cvsextras group? > > I believe John Poelestra and Will Woods off the top of my head. There > may be more, since I'm not aware of everyone on those groups. John and Will are in cvsextras. josh From davej at redhat.com Wed Jun 20 19:10:35 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 15:10:35 -0400 Subject: 586 kernels. In-Reply-To: <1182365330.4102.19.camel@hodge> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> Message-ID: <20070620191035.GJ23569@redhat.com> On Wed, Jun 20, 2007 at 02:48:50PM -0400, seth vidal wrote: > On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote: > > On Wednesday 20 June 2007 14:44:54 seth vidal wrote: > > > so, umm > > > we're going to have users 'ugprading' from kernel.i586 to kernel.i386? > > > Is that right? > > > > They'd be going from i686 to i386 too it would seem. > > > > My brain just screams that this is confusing, but I'm not coming up with any > > hard problems yet. Can you do up a scratch build for us to play with Dave? > > > > just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and > let's not even start thinking about what this will mean for kernel > modules. Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin). Dave -- http://www.codemonkey.org.uk From jspaleta at gmail.com Wed Jun 20 19:13:07 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jun 2007 11:13:07 -0800 Subject: FESCo elections In-Reply-To: <1182365777.14977.75.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> Message-ID: <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> On 6/20/07, Josh Boyer wrote: > But we also don't have current, codified rules on what criteria a > sponsor has to use before sponsoring someone. There is technically > nothing preventing it from happening now. Discussion on such criteria > might be warranted. Right, technically nothing preventing it... but we also only have concrete guidance/process on a path to sponsorship through the package submission and review process. If someone was going to attempt to ask for sponsorship without submitting a new package...where do they start? -jef From pertusus at free.fr Wed Jun 20 19:11:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 20 Jun 2007 21:11:45 +0200 Subject: FESCo elections In-Reply-To: <1182345199.14977.13.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> Message-ID: <20070620191144.GA3929@free.fr> On Wed, Jun 20, 2007 at 08:13:19AM -0500, Josh Boyer wrote: > > First, there is no FAB. FAB stands for "fedora-advisory-board" and is > simply a mailing list, not a formal committee. If you meant the Fedora > Ambassadors Steering Committee, that's FAmSco. Yay for ambiguous > acronyms! I meant FPB. > FESCo still has a responsibility of representing the community. That is > why it is comprised of people from the community, which are elected by > the community itself. Lately FESCo seems more to be an engineering body. It doesn't means that it cannot be elected, but I am not convinced that it really represents the community, since it seems that representativeness is done in FPB. Although more things are under the responsibility of FESCo it seems to me that less is under FESCo control. (According to the long thread on f-a-b). -- Pat From bpepple at fedoraproject.org Wed Jun 20 19:14:32 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 20 Jun 2007 15:14:32 -0400 Subject: FESCo elections In-Reply-To: <1182366129.14977.78.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <604aa7910706201015g1915064cr1bd6d0ec66c62626@mail.gmail.com> <1182360955.3250.22.camel@kennedy> <1182366129.14977.78.camel@weaponx.rchland.ibm.com> Message-ID: <1182366872.3250.28.camel@kennedy> On Wed, 2007-06-20 at 14:02 -0500, Josh Boyer wrote: > On Wed, 2007-06-20 at 13:35 -0400, Brian Pepple wrote: > > On Wed, 2007-06-20 at 09:15 -0800, Jeff Spaleta wrote: > > > On 6/20/07, Brian Pepple wrote: > > > > Some of the things that FESCo will most likely be overseeing in the > > > > future are things like New Features (which John will be leading), QA, > > > > and Release Engineering. It makes sense we should make the folks > > > > involved with these aspects of the project also eligible to be part of > > > > FESCo. > > > > > > Is this distinction currently academic? Is there anyone in release-eng > > > or QA that aren't already in the cvsextras group? > > > > I believe John Poelestra and Will Woods off the top of my head. There > > may be more, since I'm not aware of everyone on those groups. > > John and Will are in cvsextras. Didn't John mention earlier in this thread that he wasn't in cvsextras? /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Wed Jun 20 19:21:08 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 15:21:08 -0400 Subject: 586 kernels. In-Reply-To: <20070620191035.GJ23569@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> Message-ID: <1182367268.4102.23.camel@hodge> On Wed, 2007-06-20 at 15:10 -0400, Dave Jones wrote: > On Wed, Jun 20, 2007 at 02:48:50PM -0400, seth vidal wrote: > > On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote: > > > On Wednesday 20 June 2007 14:44:54 seth vidal wrote: > > > > so, umm > > > > we're going to have users 'ugprading' from kernel.i586 to kernel.i386? > > > > Is that right? > > > > > > They'd be going from i686 to i386 too it would seem. > > > > > > My brain just screams that this is confusing, but I'm not coming up with any > > > hard problems yet. Can you do up a scratch build for us to play with Dave? > > > > > > > just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and > > let's not even start thinking about what this will mean for kernel > > modules. > > Yeah. The alternative is that I un-kill 586, and we continue shipping > that forever. (Or we just tell those 38 586 users to go make their > own spin). according to what jesse just said we're also talking about it for all of our i686 kernel users, too. Or was that mis-said? -sv From jima at beer.tclug.org Wed Jun 20 19:22:04 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 20 Jun 2007 14:22:04 -0500 (CDT) Subject: 586 kernels. In-Reply-To: <20070620191035.GJ23569@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> Message-ID: On Wed, 20 Jun 2007, Dave Jones wrote: > Yeah. The alternative is that I un-kill 586, and we continue shipping > that forever. (Or we just tell those 38 586 users to go make their > own spin). Make that 36, at most. At least two of those are me, and I for one can live with that. Jima From tibbs at math.uh.edu Wed Jun 20 19:25:42 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Jun 2007 14:25:42 -0500 Subject: FESCo elections In-Reply-To: <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> Message-ID: >>>>> "JS" == Jeff Spaleta writes: JS> If someone was going to attempt to ask for sponsorship without JS> submitting a new package...where do they start? Apply for cvsextras membership in the account system and find someone to sponsor them through whatever channels they wish. - J< From jwboyer at jdub.homelinux.org Wed Jun 20 19:33:18 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 14:33:18 -0500 Subject: FESCo elections In-Reply-To: <20070620191144.GA3929@free.fr> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> Message-ID: <1182367998.14977.81.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 21:11 +0200, Patrice Dumas wrote: > On Wed, Jun 20, 2007 at 08:13:19AM -0500, Josh Boyer wrote: > > > > First, there is no FAB. FAB stands for "fedora-advisory-board" and is > > simply a mailing list, not a formal committee. If you meant the Fedora > > Ambassadors Steering Committee, that's FAmSco. Yay for ambiguous > > acronyms! > > I meant FPB. > > > FESCo still has a responsibility of representing the community. That is > > why it is comprised of people from the community, which are elected by > > the community itself. > > Lately FESCo seems more to be an engineering body. It doesn't means that > it cannot be elected, but I am not convinced that it really represents > the community, since it seems that representativeness is done in FPB. > Although more things are under the responsibility of FESCo it seems to > me that less is under FESCo control. > (According to the long thread on f-a-b). The FPB also has community elected seats. I'm not sure what from the community you want to be represented, so without further examples I can't really say which board or committee should handle that. josh From jwboyer at jdub.homelinux.org Wed Jun 20 19:34:28 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 14:34:28 -0500 Subject: FESCo elections In-Reply-To: <1182366872.3250.28.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <604aa7910706201015g1915064cr1bd6d0ec66c62626@mail.gmail.com> <1182360955.3250.22.camel@kennedy> <1182366129.14977.78.camel@weaponx.rchland.ibm.com> <1182366872.3250.28.camel@kennedy> Message-ID: <1182368068.14977.84.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 15:14 -0400, Brian Pepple wrote: > On Wed, 2007-06-20 at 14:02 -0500, Josh Boyer wrote: > > On Wed, 2007-06-20 at 13:35 -0400, Brian Pepple wrote: > > > On Wed, 2007-06-20 at 09:15 -0800, Jeff Spaleta wrote: > > > > On 6/20/07, Brian Pepple wrote: > > > > > Some of the things that FESCo will most likely be overseeing in the > > > > > future are things like New Features (which John will be leading), QA, > > > > > and Release Engineering. It makes sense we should make the folks > > > > > involved with these aspects of the project also eligible to be part of > > > > > FESCo. > > > > > > > > Is this distinction currently academic? Is there anyone in release-eng > > > > or QA that aren't already in the cvsextras group? > > > > > > I believe John Poelestra and Will Woods off the top of my head. There > > > may be more, since I'm not aware of everyone on those groups. > > > > John and Will are in cvsextras. > > Didn't John mention earlier in this thread that he wasn't in cvsextras? When he said that, he wasn't. He is now. josh From davej at redhat.com Wed Jun 20 19:38:07 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 15:38:07 -0400 Subject: 586 kernels. In-Reply-To: <1182367268.4102.23.camel@hodge> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <1182367268.4102.23.camel@hodge> Message-ID: <20070620193807.GB5727@redhat.com> On Wed, Jun 20, 2007 at 03:21:08PM -0400, seth vidal wrote: > On Wed, 2007-06-20 at 15:10 -0400, Dave Jones wrote: > > On Wed, Jun 20, 2007 at 02:48:50PM -0400, seth vidal wrote: > > > On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote: > > > > On Wednesday 20 June 2007 14:44:54 seth vidal wrote: > > > > > so, umm > > > > > we're going to have users 'ugprading' from kernel.i586 to kernel.i386? > > > > > Is that right? > > > > > > > > They'd be going from i686 to i386 too it would seem. > > > > > > > > My brain just screams that this is confusing, but I'm not coming up with any > > > > hard problems yet. Can you do up a scratch build for us to play with Dave? > > > > > > > > > > just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and > > > let's not even start thinking about what this will mean for kernel > > > modules. > > > > Yeah. The alternative is that I un-kill 586, and we continue shipping > > that forever. (Or we just tell those 38 586 users to go make their > > own spin). > > according to what jesse just said we're also talking about it for all of > our i686 kernel users, too. Or was that mis-said? Yes. because rpm won't install a 686 package on a 586. Whereas i386 will install everywhere obviously Dave -- http://www.codemonkey.org.uk From mattdm at mattdm.org Wed Jun 20 19:40:28 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jun 2007 15:40:28 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <46796C4A.9030209@fedoraproject.org> References: <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> <467871C8.20308@fedoraproject.org> <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> <46796C4A.9030209@fedoraproject.org> Message-ID: <20070620194028.GA5240@jadzia.bu.edu> On Wed, Jun 20, 2007 at 11:34:58PM +0530, Rahul Sundaram wrote: > Documentation mentions su -c "command" all over the place. You have to > consider whether you want to mention sudo or su or both if this is made > a option. Dismissing concerns as poor without being involved is pretty > easy. Documentation is far from the only concern with adding more options. We could easily set up the sudoers file like this: a) for wheel-group members, auth-as-self. b) for non-wheel-group-members, sudo prompts for the *root* password. Then, 'su -c "command"' could be replaced with "sudo command" in the documentation and would be correct in both cases. And since sudo has several advantages over 'su -c', this is a win-win. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Jun 20 19:46:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jun 2007 15:46:48 -0400 Subject: suggestions for admin-power users [was Re: user created at install added in sudoers ?] In-Reply-To: <1182359853.3280.15.camel@perun.kabelta.loc> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <364d303b0706190728p37f70aecxdd4aabd7ac4dc0d2@mail.gmail.com> <20070619174637.GB29865@jadzia.bu.edu> <1182359853.3280.15.camel@perun.kabelta.loc> Message-ID: <20070620194648.GB5240@jadzia.bu.edu> On Wed, Jun 20, 2007 at 07:17:33PM +0200, Tomas Mraz wrote: > > 5) Can we pretty-please enable pam_passwdqc for all users, even root? > What's wrong with pam_cracklib apart from slightly different > configuration options? passwdqc has more and stronger options. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Jun 20 19:48:33 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jun 2007 15:48:33 -0400 Subject: 586 kernels. In-Reply-To: <20070620191035.GJ23569@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> Message-ID: <20070620194833.GC5240@jadzia.bu.edu> On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote: > Yeah. The alternative is that I un-kill 586, and we continue shipping > that forever. (Or we just tell those 38 586 users to go make their > own spin). Will they need their own spin, or just need to do a reinstall rather than an upgrade? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Wed Jun 20 20:01:23 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 16:01:23 -0400 Subject: 586 kernels. In-Reply-To: <20070620194833.GC5240@jadzia.bu.edu> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> Message-ID: <20070620200123.GA15798@redhat.com> On Wed, Jun 20, 2007 at 03:48:33PM -0400, Matthew Miller wrote: > On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote: > > Yeah. The alternative is that I un-kill 586, and we continue shipping > > that forever. (Or we just tell those 38 586 users to go make their > > own spin). > > Will they need their own spin, or just need to do a reinstall rather than an > upgrade? If we stop building the kernel for them they'll need their own spin. Dave -- http://www.codemonkey.org.uk From notting at redhat.com Wed Jun 20 20:03:21 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Jun 2007 16:03:21 -0400 Subject: 586 kernels. In-Reply-To: <20070620191035.GJ23569@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> Message-ID: <20070620200321.GC16171@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > Yeah. The alternative is that I un-kill 586, and we continue shipping > that forever. (Or we just tell those 38 586 users to go make their > own spin). Patch RPM. :P Bill From davej at redhat.com Wed Jun 20 20:14:49 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 16:14:49 -0400 Subject: 586 kernels. In-Reply-To: <20070620200321.GC16171@nostromo.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620200321.GC16171@nostromo.devel.redhat.com> Message-ID: <20070620201449.GA20538@redhat.com> On Wed, Jun 20, 2007 at 04:03:21PM -0400, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > Yeah. The alternative is that I un-kill 586, and we continue shipping > > that forever. (Or we just tell those 38 586 users to go make their > > own spin). > > Patch RPM. :P Oh yeah, that's always a good idea ;-) Since my last foray into the rpm source, I have even more respect for pnasrat. I'd drink a lot more if I were in his position. Dave -- http://www.codemonkey.org.uk From ben.lewis at benl.co.uk Wed Jun 20 20:37:20 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Wed, 20 Jun 2007 21:37:20 +0100 Subject: 586 kernels. In-Reply-To: <20070620194833.GC5240@jadzia.bu.edu> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> Message-ID: <46799000.6090807@benl.co.uk> Matthew Miller wrote: > On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote: > >> Yeah. The alternative is that I un-kill 586, and we continue shipping >> that forever. (Or we just tell those 38 586 users to go make their >> own spin). >> > > Will they need their own spin, or just need to do a reinstall rather than an > upgrade? > I have K6's as servers. Re-installs or re-spins are not really an option for me. And make that 37 users :P -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Wed Jun 20 20:49:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Jun 2007 16:49:52 -0400 Subject: Root filesystem encryption update In-Reply-To: <46798CE7.6030701@redhat.com> References: <20070618151203.GA3999@wolff.to> <1182185731.4576.4.camel@aglarond.local> <20070618190733.GA31493@wolff.to> <1182199915.16956.38.camel@erebor.boston.redhat.com> <20070618215035.GA11450@wolff.to> <4677F20F.8050405@redhat.com> <4679396B.7070902@redhat.com> <46798CE7.6030701@redhat.com> Message-ID: <20070620204952.GA27808@nostromo.devel.redhat.com> Karsten Hopp (karsten at redhat.com) said: > But it gives us some time to find bugs and fix them before we put all the > pieces together. But before we try and solve some of these issues, we don't even know if the pieces you have are the pieces you'll need later. I know the perfect is the enemy of the good, but: - All new code adds complexity. - All new code adds bugs. - All new code adds maintenance load. - All new features need supported. Especially when you're talking about the root filesystem. Good engineering is always about adding code for the right 'why', not just 'why not'. Bill From ville.skytta at iki.fi Wed Jun 20 21:00:00 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 21 Jun 2007 00:00:00 +0300 Subject: 586 kernels. In-Reply-To: <20070620193807.GB5727@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182367268.4102.23.camel@hodge> <20070620193807.GB5727@redhat.com> Message-ID: <200706210000.00303.ville.skytta@iki.fi> On Wednesday 20 June 2007, Dave Jones wrote: > On Wed, Jun 20, 2007 at 03:21:08PM -0400, seth vidal wrote: > > > according to what jesse just said we're also talking about it for all of > > our i686 kernel users, too. Or was that mis-said? > > Yes. because rpm won't install a 686 package on a 586. > Whereas i386 will install everywhere obviously I suppose making it i586 instead of i386 would be slightly less painful. From alan at redhat.com Wed Jun 20 21:54:45 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Jun 2007 17:54:45 -0400 Subject: 586 kernels. In-Reply-To: <20070620184020.GH23569@redhat.com> References: <20070620184020.GH23569@redhat.com> Message-ID: <20070620215445.GE26632@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 02:40:20PM -0400, Dave Jones wrote: > Rpm will refuse to install the 686 kernel a 586, because it checks > the arch.. RPM understands that cmov is required for '686' - that is it has hacks built in to compensate for the compiler bug at the heart of this stuff. > Anyway.. To 'solve' this, I think I'm going to have to make the 686 > kernel package an 'i386' package. > > Does anyone see anything flawed with this approach? It's not a 386 package - its a 586 package if its 686 without cmov, or for Fedora 8 if we've fixed the compiler bug we can remove the rpm hack... From alan at redhat.com Wed Jun 20 21:56:59 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Jun 2007 17:56:59 -0400 Subject: 586 kernels. In-Reply-To: <20070620191035.GJ23569@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> Message-ID: <20070620215659.GF26632@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote: > Yeah. The alternative is that I un-kill 586, and we continue shipping > that forever. (Or we just tell those 38 586 users to go make their > own spin). For FC7 I don't see an easy answer - Fix the 586 kernel to be built 686 -cmov and push it as 586 for testing and verification. For FC8 remove the RPM hack ship real 686 binaries (not GCC '686 and a bit' binaries) and we'll rock. From alan at redhat.com Wed Jun 20 22:00:32 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Jun 2007 18:00:32 -0400 Subject: 586 kernels. In-Reply-To: <20070620200123.GA15798@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> <20070620200123.GA15798@redhat.com> Message-ID: <20070620220032.GG26632@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote: > > Will they need their own spin, or just need to do a reinstall rather than an > > upgrade? > > If we stop building the kernel for them they'll need their own spin. Dunno about the other 586 users but I'd probably just change distro at that point, and since its easier to keep all boxes on one distro probably move the lot over, except for the RHEL devel boxes. Alan From n0dalus+redhat at gmail.com Wed Jun 20 22:05:24 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 21 Jun 2007 07:35:24 +0930 Subject: user created at install added in sudoers ? In-Reply-To: <20070620194028.GA5240@jadzia.bu.edu> References: <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> <467871C8.20308@fedoraproject.org> <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> <46796C4A.9030209@fedoraproject.org> <20070620194028.GA5240@jadzia.bu.edu> Message-ID: <6280325c0706201505h295de44dlee984cab682cf2dc@mail.gmail.com> On 6/21/07, Matthew Miller wrote: > > We could easily set up the sudoers file like this: > > a) for wheel-group members, auth-as-self. > b) for non-wheel-group-members, sudo prompts for the *root* password. I'm not sure this is possible to do with sudoers. Please post the lines you would expect to see in the file. I think that kind of behaviour would require patching sudo, and would be inconsistent with the sudo documentation found anywhere on the internet. > Then, 'su -c "command"' could be replaced with "sudo command" in the > documentation and would be correct in both cases. And since sudo has several > advantages over 'su -c', this is a win-win. I'm fairly sure users who add themselves to sudoers know to replace "su -c" with "sudo" when they read documentation, so this doesn't really seem like an issue. n0dalus. From alan at redhat.com Wed Jun 20 22:05:44 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Jun 2007 18:05:44 -0400 Subject: 586 kernels. In-Reply-To: <20070620200321.GC16171@nostromo.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620200321.GC16171@nostromo.devel.redhat.com> Message-ID: <20070620220544.GH26632@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 04:03:21PM -0400, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > Yeah. The alternative is that I un-kill 586, and we continue shipping > > that forever. (Or we just tell those 38 586 users to go make their > > own spin). > > Patch RPM. :P The history might be good here actually as I guess Bill is one of the few folks at Red Hat long enough to remember it gcc produced "686" code that wasn't in fact 686 machine architecture compliant The gcc team denied this until I quoted them pages from the Intel doc (ok obscure pages but they are there) It was decided by the gcc folks that it was better to keep gcc 686 including cmov and tell people to use 586 otherwise (there were good performance reasons on original PPro when the decision was made but not by PIV) A hack was put into rpm to say 686 is "686 + cmov" It was agreed that rpm needed fixing properly anyway for architecture - notably that architectures should become dependancies anyway as should cpu flags. That somehow never happened (The reasoning being that a PC would intrinsically supply "686" "686_cmov" etc while a PPC would not, but qemu on ppc could provide "686" and allow 686 binaries to be installed and stuff. It's actually not as bright as it sounds when you think about multiarch, in fact in some ways we should probably be glad it didn't happen ;) ) Anyway fix gcc and you can fix rpm and you get back to the world as intended From ben.lewis at benl.co.uk Wed Jun 20 22:09:25 2007 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Wed, 20 Jun 2007 23:09:25 +0100 Subject: 586 kernels. In-Reply-To: <20070620220032.GG26632@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> <20070620200123.GA15798@redhat.com> <20070620220032.GG26632@devserv.devel.redhat.com> Message-ID: <4679A595.3060002@benl.co.uk> Alan Cox wrote: > On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote: > >> > Will they need their own spin, or just need to do a reinstall rather than an >> > upgrade? >> >> If we stop building the kernel for them they'll need their own spin. >> > > Dunno about the other 586 users but I'd probably just change distro at > that point, and since its easier to keep all boxes on one distro probably > move the lot over, except for the RHEL devel boxes. > > Alan > > Sadly, thats probably what I'd do too. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben.lewis.vcf Type: text/x-vcard Size: 144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Wed Jun 20 22:22:57 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 18:22:57 -0400 Subject: 586 kernels. In-Reply-To: <20070620220032.GG26632@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> <20070620200123.GA15798@redhat.com> <20070620220032.GG26632@devserv.devel.redhat.com> Message-ID: <20070620222257.GA10011@redhat.com> On Wed, Jun 20, 2007 at 06:00:32PM -0400, Alan Cox wrote: > On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote: > > > Will they need their own spin, or just need to do a reinstall rather than an > > > upgrade? > > > > If we stop building the kernel for them they'll need their own spin. > > Dunno about the other 586 users but I'd probably just change distro at > that point For the sake of 30 or so users, that may be the better option. > and since its easier to keep all boxes on one distro probably > move the lot over, except for the RHEL devel boxes. As entertaining as it is to watch you throw teddies every time something like this comes up, it doesn't really help the situation. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jun 20 22:26:20 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Jun 2007 18:26:20 -0400 Subject: 586 kernels. In-Reply-To: <20070620215659.GF26632@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620215659.GF26632@devserv.devel.redhat.com> Message-ID: <20070620222620.GB10011@redhat.com> On Wed, Jun 20, 2007 at 05:56:59PM -0400, Alan Cox wrote: > On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote: > > Yeah. The alternative is that I un-kill 586, and we continue shipping > > that forever. (Or we just tell those 38 586 users to go make their > > own spin). > > For FC7 I don't see an easy answer F7 is irrelevant. Given it's already released, it's too late for any change of this nature. > - Fix the 586 kernel to be built 686 -cmov > and push it as 586 for testing and verification. That's what the current 686 kernel is in rawhide. > For FC8 remove the RPM hack > ship real 686 binaries (not GCC '686 and a bit' binaries) and we'll rock. I'd rather we fixed this without introducing hacks we know we're going to have to later remove. Dave -- http://www.codemonkey.org.uk From mike at miketc.com Wed Jun 20 22:43:11 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 20 Jun 2007 17:43:11 -0500 Subject: 586 kernels. In-Reply-To: <20070620184020.GH23569@redhat.com> References: <20070620184020.GH23569@redhat.com> Message-ID: <1182379391.3284.5.camel@scrappy.miketc.com> On Wed, 2007-06-20 at 14:40 -0400, Dave Jones wrote: > A day or so ago, I flipped the switch and killed off the 586 specific > kernel, by making the 686 kernel bootable on older machines. > Turns out it isn't that easy however. > Rpm will refuse to install the 686 kernel a 586, because it checks > the arch.. > > sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm > Preparing... ########################################### [100%] > package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture Since the other kernels have their specific names in them, such as ppc, x86-64, ppc64, etc., why can't you use a name for ix86 systems instead of x86? Heck, why not just x86? Will rpm upgrade/install with that over 586, 686, etc? kernel-2.6.21-1.3228.fc8.intel.rpm kernel-2.6.21-1.3228.fc8.x86.rpm kernel-2.6.21-1.3228.fc8.rpm (leave off the name all together for x86 boxes) Anything other than intel boxes would have the name, like ppc, x86_64, s390, etc.. Would rpm/yum work with anything of that nature? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From katzj at redhat.com Wed Jun 20 22:43:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Jun 2007 18:43:51 -0400 Subject: 586 kernels. In-Reply-To: <1182379391.3284.5.camel@scrappy.miketc.com> References: <20070620184020.GH23569@redhat.com> <1182379391.3284.5.camel@scrappy.miketc.com> Message-ID: <1182379431.2817.2.camel@aglarond.local> On Wed, 2007-06-20 at 17:43 -0500, Mike Chambers wrote: > Since the other kernels have their specific names in them, such as ppc, > x86-64, ppc64, etc., why can't you use a name for ix86 systems instead > of x86? Heck, why not just x86? Will rpm upgrade/install with that > over 586, 686, etc? We'd have to add the new arch to rpm, yum, etc so that it would be known and where it falls in the ordering, etc Jeremy From mike at miketc.com Wed Jun 20 22:48:02 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 20 Jun 2007 17:48:02 -0500 Subject: 586 kernels. In-Reply-To: <1182379431.2817.2.camel@aglarond.local> References: <20070620184020.GH23569@redhat.com> <1182379391.3284.5.camel@scrappy.miketc.com> <1182379431.2817.2.camel@aglarond.local> Message-ID: <1182379682.3284.8.camel@scrappy.miketc.com> On Wed, 2007-06-20 at 18:43 -0400, Jeremy Katz wrote: > On Wed, 2007-06-20 at 17:43 -0500, Mike Chambers wrote: > > Since the other kernels have their specific names in them, such as ppc, > > x86-64, ppc64, etc., why can't you use a name for ix86 systems instead > > of x86? Heck, why not just x86? Will rpm upgrade/install with that > > over 586, 686, etc? > > We'd have to add the new arch to rpm, yum, etc so that it would be known > and where it falls in the ordering, etc How hard would that be, for it to work with Fedora (if that is an option to use), and to be used on other distros, and still work with their system, if they use the current methods? And if it's not that hard to implement, is that something worth using then? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From notting at redhat.com Wed Jun 20 22:51:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Jun 2007 18:51:35 -0400 Subject: 586 kernels. In-Reply-To: <1182379682.3284.8.camel@scrappy.miketc.com> References: <20070620184020.GH23569@redhat.com> <1182379391.3284.5.camel@scrappy.miketc.com> <1182379431.2817.2.camel@aglarond.local> <1182379682.3284.8.camel@scrappy.miketc.com> Message-ID: <20070620225135.GA5265@nostromo.devel.redhat.com> Mike Chambers (mike at miketc.com) said: > How hard would that be, for it to work with Fedora (if that is an option > to use), and to be used on other distros, and still work with their > system, if they use the current methods? > > And if it's not that hard to implement, is that something worth using > then? It's something that would need carried forward eternally for this one-time change. Bill From mattdm at mattdm.org Thu Jun 21 00:26:04 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jun 2007 20:26:04 -0400 Subject: 586 kernels. In-Reply-To: <20070620200123.GA15798@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> <20070620200123.GA15798@redhat.com> Message-ID: <20070621002604.GA1529@jadzia.bu.edu> On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote: > > > Yeah. The alternative is that I un-kill 586, and we continue shipping > > > that forever. (Or we just tell those 38 586 users to go make their > > > own spin). > > Will they need their own spin, or just need to do a reinstall rather than an > > upgrade? > If we stop building the kernel for them they'll need their own spin. But the 686 kernel would be bootable, right? And once you're running that kernel, how does RPM even know to cause trouble? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jun 21 00:28:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jun 2007 20:28:02 -0400 Subject: 586 kernels. In-Reply-To: <20070621002604.GA1529@jadzia.bu.edu> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> <20070620200123.GA15798@redhat.com> <20070621002604.GA1529@jadzia.bu.edu> Message-ID: <20070621002802.GB1529@jadzia.bu.edu> On Wed, Jun 20, 2007 at 08:26:04PM -0400, Matthew Miller wrote: > But the 686 kernel would be bootable, right? And once you're running that > kernel, how does RPM even know to cause trouble? Ah, never mind. I saw Alan's post. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From zaitcev at redhat.com Thu Jun 21 00:42:24 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 20 Jun 2007 17:42:24 -0700 Subject: 586 kernels. In-Reply-To: <20070620191035.GJ23569@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> Message-ID: <20070620174224.65b9c8f6.zaitcev@redhat.com> On Wed, 20 Jun 2007 15:10:35 -0400, Dave Jones wrote: > Yeah. The alternative is that I un-kill 586, and we continue shipping > that forever. (Or we just tell those 38 586 users to go make their > own spin). I'm thinking about getting a new box anyway (it's an old not-quite-C3 with some odd Biblean-sounding codename, chugging along at 800MHz). With less than 40 users, it's just not worth it. I'm surprised though, I thought VIA was more popular than that. -- Pete From mattdm at mattdm.org Thu Jun 21 02:03:25 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Jun 2007 22:03:25 -0400 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706201505h295de44dlee984cab682cf2dc@mail.gmail.com> References: <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> <467871C8.20308@fedoraproject.org> <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> <46796C4A.9030209@fedoraproject.org> <20070620194028.GA5240@jadzia.bu.edu> <6280325c0706201505h295de44dlee984cab682cf2dc@mail.gmail.com> Message-ID: <20070621020325.GC1529@jadzia.bu.edu> On Thu, Jun 21, 2007 at 07:35:24AM +0930, n0dalus wrote: > >We could easily set up the sudoers file like this: > > a) for wheel-group members, auth-as-self. > > b) for non-wheel-group-members, sudo prompts for the *root* password. > I'm not sure this is possible to do with sudoers. Please post the Sure it is. Why would I have suggested it otherwise? > lines you would expect to see in the file. I think that kind of > behaviour would require patching sudo, and would be inconsistent with > the sudo documentation found anywhere on the internet. What, the man page isn't on the internet? :) You just need to do this: Defaults:ALL,!%wheel rootpw and optionally Defaults passprompt="Root password:" Defaults:%wheel passprompt="Your password:" and then ALL ALL=(ALL) ALL That last line is a bit scary but is as safe as allowing anyone to run the su command, assuming nothing screws with the Defaults line. There'd be other ways to accomplish the same goal with a little more complexity in return for a more fail-safe feeling, but you get the idea. It *is* unfortunate that there isn't a ROOTPW or ROOTPASSWD "tag" (in sudo terminology) to match the existing NOPASSWD. (And a TARGETPW, while we're at it) That'd be a slightly nicer way to do this. The upstream author might accept a patch to add that, actually. That way, you could do: ALL ALL=(ALL) ROOTPW: ALL wheel ALL=(ALL) instead of the split between the defaults line and "ALL ALL=(ALL) ALL". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From n0dalus+redhat at gmail.com Thu Jun 21 03:05:07 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 21 Jun 2007 12:35:07 +0930 Subject: user created at install added in sudoers ? In-Reply-To: <20070621020325.GC1529@jadzia.bu.edu> References: <1182276012.20455.1.camel@moogle> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> <467871C8.20308@fedoraproject.org> <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> <46796C4A.9030209@fedoraproject.org> <20070620194028.GA5240@jadzia.bu.edu> <6280325c0706201505h295de44dlee984cab682cf2dc@mail.gmail.com> <20070621020325.GC1529@jadzia.bu.edu> Message-ID: <6280325c0706202005x79572877g11fbc943e2d46250@mail.gmail.com> On 6/21/07, Matthew Miller wrote: > On Thu, Jun 21, 2007 at 07:35:24AM +0930, n0dalus wrote: > > >We could easily set up the sudoers file like this: > > > a) for wheel-group members, auth-as-self. > > > b) for non-wheel-group-members, sudo prompts for the *root* password. > > I'm not sure this is possible to do with sudoers. Please post the > > Sure it is. Why would I have suggested it otherwise? Good to know. I looked at the man page but missed that bit of it. I think the proposed change to sudoers is a good one. Thanks for outlining the config file you would use. n0dalus. From pmatilai at laiskiainen.org Thu Jun 21 04:53:31 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 21 Jun 2007 07:53:31 +0300 (EEST) Subject: 586 kernels. In-Reply-To: <20070620201449.GA20538@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620200321.GC16171@nostromo.devel.redhat.com> <20070620201449.GA20538@redhat.com> Message-ID: On Wed, 20 Jun 2007, Dave Jones wrote: > On Wed, Jun 20, 2007 at 04:03:21PM -0400, Bill Nottingham wrote: > > Dave Jones (davej at redhat.com) said: > > > Yeah. The alternative is that I un-kill 586, and we continue shipping > > > that forever. (Or we just tell those 38 586 users to go make their > > > own spin). > > > > Patch RPM. :P > > Oh yeah, that's always a good idea ;-) We could always encode /proc/cpuinfo + compiler flags used into dependencies and... :) > Since my last foray into the rpm source, I have even more respect > for pnasrat. I'd drink a lot more if I were in his position. Hehe, can I quote you on that (I work on RPM these days with Paul) ;) Oh and btw, RPM 4.4.2.1 will support %patch -F too. - Panu - From pertusus at free.fr Thu Jun 21 07:35:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 21 Jun 2007 09:35:28 +0200 Subject: FESCo elections In-Reply-To: <1182367998.14977.81.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> Message-ID: <20070621073528.GA3140@free.fr> On Wed, Jun 20, 2007 at 02:33:18PM -0500, Josh Boyer wrote: > > The FPB also has community elected seats. Indeed, and I think it is more here that political representation is. Strangely, although I am on many fedora lists I didn't see anything about this election (then I googled and saw the pages on the wiki). On which list was it announced? > I'm not sure what from the community you want to be represented, so > without further examples I can't really say which board or committee > should handle that. In fact after a bit of thinking I am not sure that FESCo had more political control before (contrary to what I said above). What has changed (temporarily) is that FESCo lost a part of the engineering control during the merge, with rel-eng becoming more important. But if I recall well FESCo never had a political role, except for very minor decisions. I wanted FESCo to have a political role, but it is not reality, even the FESCo role about, say, static libs is technical and not political. So FESCo doesn't really represent the community, because it doesn't really have a political role, but having the technical leaders elected nevertheless means that the community is represented in the technical decision body. -- Pat From kevin.kofler at chello.at Thu Jun 21 08:13:29 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Jun 2007 08:13:29 +0000 (UTC) Subject: [OT] Thanks Panu! (was: Re: 586 kernels.) References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620200321.GC16171@nostromo.devel.redhat.com> <20070620201449.GA20538@redhat.com> Message-ID: Panu Matilainen laiskiainen.org> writes: > > Since my last foray into the rpm source, I have even more respect > > for pnasrat. I'd drink a lot more if I were in his position. > > Hehe, can I quote you on that (I work on RPM these days with Paul) ;) I've noticed. As a long-time apt-rpm user, I think it's great to have you working on RPM itself. You managed to resurrect apt-rpm at a time where people were giving up on it and implement the 2 most-requested features (multilib and repomd support), the latter also making the issue of repos dropping support for it irrelevant. :-) And now you and Paul are resurrecting the RPM upstream project and cleaning up the huge mountain of bitrot which had formed, and I've noticed you're also working on fixing longstanding annoying bugs like "provides as obsoletes" (already fixed for 4.4.2.1) and "uninstalling multilib package erases files" (fix under discussion). I'd really like to thank you for picking up that thankless job and also for all the work you're doing on the apt-rpm project (looking forward to a stable release with sqlite repomd support), you really deserve those thanks! Kevin Kofler From rms at 1407.org Thu Jun 21 09:34:05 2007 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Thu, 21 Jun 2007 10:34:05 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706200411v432c6113pc3da80498e8d9113@mail.gmail.com> References: <4673037B.3030105@laposte.net> <364d303b0706190721p7763ca43oc19db048a52d84e4@mail.gmail.com> <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <6280325c0706191709m38621cc3pd1e2a84063405700@mail.gmail.com> <364d303b0706200153u5b389b45if530237b2de0b39e@mail.gmail.com> <6280325c0706200411v432c6113pc3da80498e8d9113@mail.gmail.com> Message-ID: <1182418445.2956.32.camel@localhost6.localdomain6> Qua, 2007-06-20 ?s 20:41 +0930, n0dalus escreveu: > The benefits you have just listed are already part of Fedora by > default, and sudo is not needed to get them. Supose: sudo yum update vs su -c "yum update" * Which is more user friendly? * Which is faster to type? * Does su register the command as well as sudo does? At least with higher security environments sudo is highly preferred since you can at least establish a rule that different administrators don't know the root password and yet they can give authenticated and registered commands. If admin user A does "sudo sh" and that is found out in the logs preserved off-band, he can be punished. Of course you could do even more strict restrictions, but that's beyond the point. I'm actually more concerned that in either su or sudo you now have nice GUIs that could be easily faked by some trojan-horse. Rui P'tang! Today is Boomtime, the 26th day of Confusion in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From k.georgiou at imperial.ac.uk Thu Jun 21 09:58:23 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Thu, 21 Jun 2007 10:58:23 +0100 Subject: user created at install added in sudoers ? In-Reply-To: <6280325c0706182153rcd68487u5d3c2dd94ade7bba@mail.gmail.com> References: <4673037B.3030105@laposte.net> <46731409.8060701@gnat.ca> <20070616011257.051622a4@cluestix.noc.ams-ix.net> <6280325c0706182153rcd68487u5d3c2dd94ade7bba@mail.gmail.com> Message-ID: <20070621095823.GB21905@imperial.ac.uk> On Tue, Jun 19, 2007 at 02:23:18PM +0930, n0dalus wrote: > A better way of giving users this kind of access is to allow the > password to go from user -> root to be set to a different password > than their usual login password (which would be essentially the same > as having a second user). This could be implemented with a pam module, > so users trying to sudo are not asked for their own password but a > second password they set (and any dialogue would be clearly labelled > to make clear which password was being asked for). This could then be > integrated into consolehelper. My prefered way to do this is with user/root kerberos principals with strong complexity requirements for the password and the requirement to change it every few months. Hardly something to use in a desktop or a laptop though. Kostas From buildsys at redhat.com Thu Jun 21 10:23:03 2007 From: buildsys at redhat.com (Build System) Date: Thu, 21 Jun 2007 06:23:03 -0400 Subject: rawhide report: 20070621 changes Message-ID: <200706211023.l5LAN3Mu006730@porkchop.devel.redhat.com> New package adminutil Utility library for directory server administration New package hunspell-ar Arabic hunspell dictionaries New package libmatchbox Libraries for the Matchbox Desktop New package perl-CGI-FormBuilder Easily generate and process stateful forms New package perl-Crypt-OpenSSL-PKCS10 Perl interface to OpenSSL for PKCS10 New package perl-Geo-METAR Perl module for accessing aviation weather information New package pypar2 PyPar2 is a graphical frontend for the Linux par2 command line New package reciteword Recite Word Easily New package schroedinger Portable libraries for the high quality Dirac video codec New package subcommander Graphical UI for subversion New package svnkit Pure Java Subversion client library Updated Packages: cdrkit-1.1.6-1.fc8 ------------------ * Wed Jun 20 2007 Harald Hoyer - 1.1.6-1 - version 1.1.6 - added readcd symlink cracklib-2.8.9-11 ----------------- * Wed Jun 20 2007 Nalin Dahyabhai - 2.8.9-11 - improve reports of out-of-memory exceptions so that they don't include a bogus filename - improve reports of file-missing exceptions from the python module so that they give the right filename (#225858) csmash-0.6.6-15.fc8 ------------------- * Wed Jun 20 2007 Matthias Saou 0.6.6-15 - Switch to use DESTDIR install method. - Run autoreconf since gcc gets passed "NONE" otherwise and configure fails. - Add all searched libX* build requirements. - Include a home made table tennis racket icon, in hicolor with scriplets. - Split out the desktop file as its own source. - Include patch to move data from datadir/games/ to datadir/. dbmail-2.2.5-3.fc8 ------------------ * Wed Jun 20 2007 Bernard Johnson 2.2.5-3 - assign uid from package user registry dhcp-12:3.0.5-37.fc8 -------------------- * Wed Jun 20 2007 David Cantrell - 12:3.0.5-37 - For init script functions, echo new line after OK or FAIL msg (#244956) * Fri Jun 15 2007 David Cantrell - 12:3.0.5-36 - BOOTP_BROADCAST_ALWAYS is not the same as ATSFP, fixed - Added anycast mac support to dhclient for OLPC * Tue May 22 2007 David Cantrell - 12:3.0.5-35 - Disable -fvisibility=hidden for now as it breaks dhcpv4_client() from the shared library (#240804) docbook-dtds-1.0-31 ------------------- * Wed Jun 20 2007 Ondrej Vasik - 1.0.31 - .cat files touched and ghosted to be owned by package - (bug #193475) e2fsprogs-1.39-13.fc8 --------------------- * Wed Jun 20 2007 Eric Sandeen 1.39-13 - add dist tag to release field * Wed Jun 20 2007 Eric Sandeen 1.39-12 - add LUKS support to libblkid eclipse-1:3.2.2-15.fc7 ---------------------- * Wed Jun 20 2007 Ben Konrath 3.2.2-15 - Add Java-1.7.profile to org.eclipse.osgi for IcedTea. * Thu May 17 2007 Ben Konrath 3.2.2-14 - BR/R tomcat5 >= 5.5.23. - Fix broken symlinks for tomcat5 5.5.23. * Tue May 15 2007 Ben Konrath 3.2.2-13 - Another bug fix for launch-addplatformtotildeeclipse.patch. - Add BR/B tomcat >= 5.5.20 instead of just = 5.5.20. - Resolves: #240025. eclipse-subclipse-1.2.2-2.fc8 ----------------------------- * Wed Jun 20 2007 Robert Marcano 1.2.2-2 - Update to upstream 1.2.2 - Dependency changed from javasvn to svnkit - Patch to support EPEL5 sent by Rob Myers fedora-usermgmt-0.10-1.fc8 -------------------------- * Wed Jun 20 2007 Enrico Scholz - 0.10-1 - added basic checks that CLI is used correctly fillets-ng-0.7.4-1.fc8 ---------------------- * Wed Jun 20 2007 Matthias Saou 0.7.4-1 - Update to 0.7.4. - Switch to using downloads.sf.net source URL. - Switch to using the DESTDIR install method. - Remove the fedora desktop file prefix. - Remove all patches, no longer required, don't autoreconf anymore either. - Force datadir to be the new location of our fillets-ng-data package's files. fillets-ng-data-0.7.4-1 ----------------------- * Wed Jun 20 2007 Matthias Saou 0.7.4-1 - Update to 0.7.4. - Move all files from datadir/games/ to datadir/. - Switch to use downloads.sf.net source URL. gdb-6.6-16.fc8 -------------- * Wed Jun 20 2007 Jan Kratochvil - 6.6-16 - Fix attaching a stopped process on expected + upstream kernels (BZ 233852). - Fix attaching during a pending signal being delivered. gmpc-0.14.0-2.fc8 ----------------- * Wed Jun 20 2007 Adrian Reber - 0.14.0-2 - applied patch to fix album play order from David Woodhouse gscan2pdf-0.9.12-1.fc8 ---------------------- * Tue Jun 19 2007 Bernard Johnson - 0.9.12-1 - v 0.9.12 gtkhtml38-3.12.3-5.fc8 ---------------------- * Wed Jun 20 2007 Bill Nottingham - 3.12.3-5 - add patch for setting font when printing (#239205, ) gtkmozembedmm-1.4.2.cvs20060817-11.fc7.1 ---------------------------------------- * Wed Jun 06 2007 Ha??kel Gu??mar - 1.4.2.cvs20060817-11 - rebuilt against gecko-libs 1.8.1.4 hotwire-0.567-1.fc8 ------------------- * Wed Jun 20 2007 Colin Walters - 0.567-1 - update - R dbus-python kdebase-6:3.5.7-4.fc8 --------------------- * Wed Jun 20 2007 Rex Dieter - 6:3.5.7-4 - -devel: Requires: %name... - portability++ kdelibs-6:3.5.7-8.fc8 --------------------- * Wed Jun 20 2007 Rex Dieter - 6:3.5.7-8 - rework previously botched openssl patch * Wed Jun 20 2007 Rex Dieter - 6:3.5.7-7 - -devel: Provides: kdelibs3-devel = ... - openssl patch update (portability) - drop deprecated ssl-krb5 patch * Sat Jun 16 2007 Rex Dieter - 6:3.5.7-6 - Provides: kdelibs3 = %version-%release kernel-2.6.21-1.3230.fc8 ------------------------ * Wed Jun 20 2007 Dave Jones - 2.6.22-rc5-git4. * Tue Jun 19 2007 Chuck Ebbert - enable sound system debugging in -debug kernels kipi-plugins-0.1.4-0.5.beta2.fc8 -------------------------------- * Wed Jun 20 2007 Rex Dieter 0.1.4-0.5.beta3 - LIB_KIO.patch * Wed Jun 20 2007 Rex Dieter 0.1.4-0.4.beta2 - --disable-final * Tue Jun 19 2007 Rex Dieter 0.1.4-0.3.beta2 - BR: libkdcraw-devel >= 0.1.1 man-pages-2.55-2.fc8 -------------------- * Mon Jun 11 2007 Stepan Kasal - 2.55-2 - Add man-suid-bins.tar.bz2 and uuname.1 to document suid binaries (submitted through bug #196352). - Add man-pages-2.51-sched_setaffinity.patch, fixing the prototypes. - Remove sccs-related man pages. - Add man-pages-2.55-syscalls-2.6.9.patch, updating syscalls.2 to kernel version 2.6.9. - Add man-pages-2.55-clone2.patch; s/clone2/__&/, clone2 is not exported. - Add man-pages-2.55-signal.patch; SIGRTMIN is not constant. * Mon Jun 11 2007 Ivana Varekova - 2.55-1 - update to 2.55 * Mon Jun 04 2007 Stepan Kasal - 2.51-4 - Simplify the build and install phases; pages are now recoded during the install. - Move the "rm" commands from build to prep. - Add man-pages-2.51-epoll_pwait.patch to fix a circular link. mc-1:4.6.1a-48.20070604cvs.fc8 ------------------------------ * Wed Jun 20 2007 Jindrich Novy 4.6.1a-48 - fix displaying of prompt in subshell (#244025) * Tue Jun 19 2007 Jindrich Novy 4.6.1a-47 - refresh contents of terminal when resized during time expensive I/O operations (#236502) * Tue Jun 12 2007 Jindrich Novy 4.6.1a-46 - update to new upstream CVS snapshot (2007-06-04-22) - don't print prompts multiple times when switching between mc and subshell mock-0.7.2-1.fc8 ---------------- mod_auth_mysql-1:3.0.0-4 ------------------------ * Wed Jun 20 2007 Joe Orton 1:3.0.0-4 - tweak %summary, use standard BuildRoot * Wed Jul 12 2006 Jesse Keating - 1:3.0.0-3.1 - rebuild * Tue Feb 28 2006 Joe Orton 1:3.0.0-3 - fix to disable auth by default again (regression since FC4) mod_auth_pgsql-2.0.3-4 ---------------------- * Wed Jun 20 2007 Joe Orton 2.0.3-4 - convert %changelog file to UTF-8; use standard BuildRoot; tweak %summary and %description netpbm-10.35-13.fc8 ------------------- * Wed Jun 20 2007 Jindrich Novy 10.35-13 - package map files needed by pnmtopalm (#244983) nexuiz-2.3-1.fc8 ---------------- * Tue Jun 19 2007 Jon Ciesla - 2.3-1 - Updated to 2.3 nexuiz-data-2.3-1 ----------------- * Tue Jun 19 2007 Jon Ciesla - 2.3-1 - Updated to 2.3 openssh-4.5p1-7.fc8 ------------------- * Wed Jun 20 2007 Tomas Mraz - 4.5p1-7 - experimental NSS keys support - correctly setup context when empty level requested (#234951) pax-3.4-2 --------- * Wed Jun 20 2007 Radek Brich - 3.4-2 - applied patch for #239000 (pax fails creation of ustar if an absolute name is exactly 100 characters long) perl-4:5.8.8-19.fc8 ------------------- * Fri Jun 01 2007 Robin Norwood - 4:5.8.8-19 - Remove artificial Requires from perl-devel * Wed May 16 2007 Robin Norwood - 4:5.8.8-18 - Have perl-devel Require the other development/build related modules for simplicity. * Fri May 04 2007 Robin Norwood - 4:5.8.8-17 - Includes patch from Ralf Corsepius to split out some more perl modules. - Further split out development related perl modules. - Remove Requires: perl-devel from perl - Move libperl.so -> perl-libs - Patch39 to disable test_hosts in Net::Config perl-Digest-SHA-5.44-5.fc8 -------------------------- * Fri Jun 01 2007 Wes Hardaker - 5.44-5 - fix changelog * Thu May 31 2007 Wes Hardaker - 5.44-4 - fix description clause to remove hyphenation - pass optimization flags to Makefile.PL - Reverse terms in license to match perl rpm exactly * Mon May 14 2007 Wes Hardaker - 5.44-3 - BuildRequire a slew of modules needed for testing/building postgresql-8.2.4-2.fc8 ---------------------- * Wed Jun 20 2007 Tom Lane 8.2.4-2 - Fix oversight in postgresql-test makefile: pg_regress isn't a shell script anymore. Per upstream bug 3398. * Tue Apr 24 2007 Tom Lane 8.2.4-1 - Update to PostgreSQL 8.2.4 for CVE-2007-2138, data loss bugs Resolves: #237682 * Wed Feb 14 2007 Karsten Hopp 8.2.3-2 - rebuild with tcl-8.4 pungi-0.3.8-1.fc8 ----------------- * Wed Jun 20 2007 Jesse Keating - 0.3.8-1 - Only grab the newest of deps. - Don't use flavor for a log file if no flavor set (Trac #48) - Point to the right manifest file in pungi.conf - Add a install target to make (Trac #37) - Enable the source repo in yum configs (Trac #47) - Use universal newlines in getting process output (Trac #44) - Fix logging of broken deps (Trac #39) qhull-2003.1-7.fc8 ------------------ * Wed Jun 20 2007 Ralf Cors??pius - 2003.1-7 - Remove *.la. revisor-2.0.3.10-1.fc8 ---------------------- * Sun Jun 17 2007 Jonathan Steffan 2.0.3.10-1 - Final round of fixes for 2.0.3.x - Added requirement for fedora-release >= 7 ruby-1.8.6.36-2.fc8 ------------------- * Fri Jul 20 2007 Akira TAGOH - 1.8.6.36-2 - New upstream release. - Fix Etc::getgrgid to get the correct gid as requested. (#236647) * Wed Mar 28 2007 Akira TAGOH - 1.8.6-2 - Fix search path breakage. (#234029) * Thu Mar 15 2007 Akira TAGOH - 1.8.6-1 - New upstream release. - clean up a spec file. scite-1.74-1.fc8 ---------------- * Wed Jun 20 2007 Jorge Torres 1.74-1 - Upgrade to 1.74. - Default to UTF-8 encoding (fixes bug #240558). - Remove iconv workaround for desktop file encoding. tcptraceroute-1.5-0.2.beta7.fc8 ------------------------------- tin-1.8.3-1.fc8 --------------- * Wed Jun 20 2007 Adrian Reber - 1.8.3-1 - updated to 1.8.3 - removed desktop file (bz #241463) tmda-1.1.11-4.fc8 ----------------- * Wed Jun 20 2007 Bernard Johnson 1.1.11-4 - assign package uid * Fri Apr 06 2007 Bernard Johnson 1.1.11-3 - remove versioned python dependencies, no supported python is unsupported - if compiling for EL-4, compile python since there is no brp-python-bytecompile * Thu Mar 01 2007 Bernard Johnson 1.1.11-2 - fix source0 line xcdroast-0.98a15-14.fc8 ----------------------- * Wed Jun 20 2007 Harald Hoyer - 0.98a15-13.1 - added cdrkit compat patches xorg-x11-drv-ark-0.6.0-5.fc8 ---------------------------- * Wed Jun 20 2007 Adam Jackson 0.6.0-5 - Fix ark.xinf. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From jwboyer at jdub.homelinux.org Thu Jun 21 11:10:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Jun 2007 06:10:39 -0500 Subject: FESCo elections In-Reply-To: <20070621073528.GA3140@free.fr> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> <20070621073528.GA3140@free.fr> Message-ID: <1182424239.3865.17.camel@vader.jdub.homelinux.org> On Thu, 2007-06-21 at 09:35 +0200, Patrice Dumas wrote: > On Wed, Jun 20, 2007 at 02:33:18PM -0500, Josh Boyer wrote: > > > > The FPB also has community elected seats. > > Indeed, and I think it is more here that political representation is. > Strangely, although I am on many fedora lists I didn't see anything > about this election (then I googled and saw the pages on the wiki). > On which list was it announced? fedora-list and fedora-announce-list > > I'm not sure what from the community you want to be represented, so > > without further examples I can't really say which board or committee > > should handle that. > > In fact after a bit of thinking I am not sure that FESCo had more > political control before (contrary to what I said above). What has > changed (temporarily) is that FESCo lost a part of the engineering > control during the merge, with rel-eng becoming more important. But if I Erm, not really. FESCo never did release engineering in the Extras world. There was no loss since it was never done before. > recall well FESCo never had a political role, except for very minor > decisions. I wanted FESCo to have a political role, but it is not > reality, even the FESCo role about, say, static libs is technical and > not political. > > So FESCo doesn't really represent the community, because it doesn't > really have a political role, but having the technical leaders elected > nevertheless means that the community is represented in the technical > decision body. Yes, it represents the community in technical matters at the least. But you still didn't give me an example of something you feel is "political" in nature, so I have no idea if FESCo would be involved in those things or not. josh From alan at redhat.com Thu Jun 21 11:34:43 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 07:34:43 -0400 Subject: 586 kernels. In-Reply-To: <20070620222257.GA10011@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620194833.GC5240@jadzia.bu.edu> <20070620200123.GA15798@redhat.com> <20070620220032.GG26632@devserv.devel.redhat.com> <20070620222257.GA10011@redhat.com> Message-ID: <20070621113443.GA15961@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 06:22:57PM -0400, Dave Jones wrote: > > and since its easier to keep all boxes on one distro probably > > move the lot over, except for the RHEL devel boxes. > > As entertaining as it is to watch you throw teddies every time > something like this comes up, it doesn't really help the situation. Maybe you are the one who should stop throwing fits since you seem to be doing the name calling. I'm being practical and serious. Maintaining two sets of boxes on two distros is a complete and utter pain. Alan From alan at redhat.com Thu Jun 21 11:35:51 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 07:35:51 -0400 Subject: 586 kernels. In-Reply-To: <20070620222620.GB10011@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620215659.GF26632@devserv.devel.redhat.com> <20070620222620.GB10011@redhat.com> Message-ID: <20070621113551.GB15961@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 06:26:20PM -0400, Dave Jones wrote: > > For FC8 remove the RPM hack > > ship real 686 binaries (not GCC '686 and a bit' binaries) and we'll rock. > > I'd rather we fixed this without introducing hacks we know we're > going to have to later remove. You are removing an ugly hack not adding one if FC8 removes the rpm cmov ugly From alan at redhat.com Thu Jun 21 11:42:55 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 07:42:55 -0400 Subject: 586 kernels. In-Reply-To: <20070620174224.65b9c8f6.zaitcev@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> Message-ID: <20070621114255.GD15961@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote: > I'm thinking about getting a new box anyway (it's an old not-quite-C3 > with some odd Biblean-sounding codename, chugging along at 800MHz). > With less than 40 users, it's just not worth it. I'm surprised though, > I thought VIA was more popular than that. It is a good deal more popular than that (although the 686 compatible but not gcc 686 compatible ones are the older ones generally) Unless Dave can publish data sets and a methodology for his count (and given even the big marketing companies can't do it I want to see this) we should assume he made up a number to justify killing it cos he finds it a hassle to maintain. Alan From rc040203 at freenet.de Thu Jun 21 11:47:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Jun 2007 13:47:46 +0200 Subject: FESCo elections In-Reply-To: <1182424239.3865.17.camel@vader.jdub.homelinux.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> <20070621073528.GA3140@free.fr> <1182424239.3865.17.camel@vader.jdub.homelinux.org> Message-ID: <1182426466.6710.34.camel@mccallum.corsepiu.local> On Thu, 2007-06-21 at 06:10 -0500, Josh Boyer wrote: > On Thu, 2007-06-21 at 09:35 +0200, Patrice Dumas wrote: > > On Wed, Jun 20, 2007 at 02:33:18PM -0500, Josh Boyer wrote: > > So FESCo doesn't really represent the community, because it doesn't > > really have a political role, but having the technical leaders elected > > nevertheless means that the community is represented in the technical > > decision body. > > Yes, it represents the community in technical matters at the least. IMO, an elected organ is a bad choice to provide leadership on technical matters, because one can not expect an elected member of an organ to be technically competent. The domain of "elected organs" is "strategic and political decisions", not details. > But > you still didn't give me an example of something you feel is "political" > in nature, so I have no idea if FESCo would be involved in those things > or not. Some random examples: * Pat's static libs issue: This is not a mere technical issue, it's a distribution policy issue. * Decisions on "matter of taste", e.g. decisions on when to exclude a package because of its contents (E.g. US folks tend to get nervous about matters of "depiction of nudity", Europeans tend to get nervous "glorification of violence" (games!), members of non-Western cultures might find other topics offensive). * Decisions on "freedom of software". E.g. when to allow non-free software and when not (c.f. the non-free firmware case). * Decisions on when and how to enforce the "rules of the game". ... Ralf From dr.diesel at gmail.com Thu Jun 21 11:50:23 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 21 Jun 2007 06:50:23 -0500 Subject: 586 kernels. In-Reply-To: <20070621114255.GD15961@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> Message-ID: <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> On 6/21/07, Alan Cox wrote: > On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote: > > I'm thinking about getting a new box anyway (it's an old not-quite-C3 > > with some odd Biblean-sounding codename, chugging along at 800MHz). > > With less than 40 users, it's just not worth it. I'm surprised though, > > I thought VIA was more popular than that. > > It is a good deal more popular than that (although the 686 compatible but > not gcc 686 compatible ones are the older ones generally) > > Unless Dave can publish data sets and a methodology for his count (and given > even the big marketing companies can't do it I want to see this) we should > assume he made up a number to justify killing it cos he finds it a hassle > to maintain. > > Alan > The 38 comes from Smolt: http://smolt.fedoraproject.org/stats Did someone say it isn't always detected correctly? -- On Tap: HopZilla and a Belgian Tripel Fermentating: Imperial English Pale Ale Next: Brutal Blackend Bitter From alan at redhat.com Thu Jun 21 12:00:42 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 08:00:42 -0400 Subject: 586 kernels. In-Reply-To: <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> Message-ID: <20070621120042.GA17306@devserv.devel.redhat.com> On Thu, Jun 21, 2007 at 06:50:23AM -0500, Dr. Diesel wrote: > The 38 comes from Smolt: > > http://smolt.fedoraproject.org/stats > > Did someone say it isn't always detected correctly? Smolt is currently only counting a subset of FC7 users. Lots of us are still using FC6 and the data should be skewed towards bigger/new boxes for early adopter patterns - still useful data for arguing the 586 kernel is relatively low userbase. From dr.diesel at gmail.com Thu Jun 21 12:10:43 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 21 Jun 2007 07:10:43 -0500 Subject: 586 kernels. In-Reply-To: <20070621120042.GA17306@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <20070621120042.GA17306@devserv.devel.redhat.com> Message-ID: <2a28d2ab0706210510u53d9e18am43eba1ce2f8257da@mail.gmail.com> On 6/21/07, Alan Cox wrote: > On Thu, Jun 21, 2007 at 06:50:23AM -0500, Dr. Diesel wrote: > > The 38 comes from Smolt: > > > > http://smolt.fedoraproject.org/stats > > > > Did someone say it isn't always detected correctly? > > Smolt is currently only counting a subset of FC7 users. Lots of us are > still using FC6 and the data should be skewed towards bigger/new boxes for > early adopter patterns - still useful data for arguing the 586 kernel is > relatively low userbase. > I really hate to screw people, but you guys have enough work already! Do we really need Fedora 10 to be able to run on a i586? -- On Tap: HopZilla and a Belgian Tripel Fermentating: Imperial English Pale Ale Next: Brutal Blackend Bitter From jwboyer at jdub.homelinux.org Thu Jun 21 12:32:31 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Jun 2007 07:32:31 -0500 Subject: 586 kernels. In-Reply-To: <2a28d2ab0706210510u53d9e18am43eba1ce2f8257da@mail.gmail.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <20070621120042.GA17306@devserv.devel.redhat.com> <2a28d2ab0706210510u53d9e18am43eba1ce2f8257da@mail.gmail.com> Message-ID: <1182429151.7546.10.camel@weaponx.rchland.ibm.com> On Thu, 2007-06-21 at 07:10 -0500, Dr. Diesel wrote: > On 6/21/07, Alan Cox wrote: > > On Thu, Jun 21, 2007 at 06:50:23AM -0500, Dr. Diesel wrote: > > > The 38 comes from Smolt: > > > > > > http://smolt.fedoraproject.org/stats > > > > > > Did someone say it isn't always detected correctly? > > > > Smolt is currently only counting a subset of FC7 users. Lots of us are > > still using FC6 and the data should be skewed towards bigger/new boxes for > > early adopter patterns - still useful data for arguing the 586 kernel is > > relatively low userbase. > > > > I really hate to screw people, but you guys have enough work already! > Do we really need Fedora 10 to be able to run on a i586? Why not? We're talking about getting Fedora running on ARM and SPARC and Alpha. Make i586 a secondary arch :) josh From j.w.r.degoede at hhs.nl Thu Jun 21 12:55:04 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Thu, 21 Jun 2007 14:55:04 +0200 Subject: 586 kernels. In-Reply-To: <1182429151.7546.10.camel@weaponx.rchland.ibm.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <20070621120042.GA17306@devserv.devel.redhat.com> <2a28d2ab0706210510u53d9e18am43eba1ce2f8257da@mail.gmail.com> <1182429151.7546.10.camel@weaponx.rchland.ibm.com> Message-ID: On Thu, 21 Jun 2007 07:32:31 -0500 > > Why not? We're talking about getting Fedora running on > ARM and SPARC > and Alpha. Make i586 a secondary arch :) > Lets not do that, I know quite a few people running Fedora on epia's including older ones and I would hate to see Fedor not supporthing those machines anymore. Note I do not have any such a machine left myself. I think this discussion has been blown both off-topic and out of proportion. Dave wants to kill of the i585 kernel and still keep supporting i586, which I think is a great idea, ideally we would have / need only one kernel per arch. However we have this purely technical problem where for current i586 users rpm will not install the i686 kernels even though it can run on i586. Despites rpm's buggy, but documented / relied upon, behaviour of finding an i686 without cmov not an i686 (lets keep that out of the discusuion for now). I find this perfectly logical behaviour of rpm. Think about it i686 means only runs on i686 and better, so dave's proposed solution of naming it i586 is technically correct. This does mean however that rawhide i686 users (quite a lot of them) will have to manually install the first kernel update which is called .i586 using rpm -i should work just fine in this case. If we document and announce this I don't see a problem. As for normal updates, I'm sure anaconda can be thought to fix this. People doing (unssupported) yum updates should once again fix this manually, which again we need to document. Regards, Hans From jwboyer at jdub.homelinux.org Thu Jun 21 12:56:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Jun 2007 07:56:12 -0500 Subject: FESCo elections In-Reply-To: <1182426466.6710.34.camel@mccallum.corsepiu.local> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> <20070621073528.GA3140@free.fr> <1182424239.3865.17.camel@vader.jdub.homelinux.org> <1182426466.6710.34.camel@mccallum.corsepiu.local> Message-ID: <1182430572.8010.13.camel@weaponx.rchland.ibm.com> On Thu, 2007-06-21 at 13:47 +0200, Ralf Corsepius wrote: > On Thu, 2007-06-21 at 06:10 -0500, Josh Boyer wrote: > > On Thu, 2007-06-21 at 09:35 +0200, Patrice Dumas wrote: > > > On Wed, Jun 20, 2007 at 02:33:18PM -0500, Josh Boyer wrote: > > > > So FESCo doesn't really represent the community, because it doesn't > > > really have a political role, but having the technical leaders elected > > > nevertheless means that the community is represented in the technical > > > decision body. > > > > Yes, it represents the community in technical matters at the least. > > IMO, an elected organ is a bad choice to provide leadership on technical > matters, because one can not expect an elected member of an organ to be > technically competent. The domain of "elected organs" is "strategic and > political decisions", not details. Personally, I think that depends on the pool of candidates that are allowed for such and election. > > But > > you still didn't give me an example of something you feel is "political" > > in nature, so I have no idea if FESCo would be involved in those things > > or not. > > Some random examples: > > * Pat's static libs issue: This is not a mere technical issue, it's a > distribution policy issue. This is being handled at the FESCo level. There have been a fairly low number of cases to my knowledge. However, if a higher level decree of whether static libs are allowable or not is required, it can always be brought to the Board. > * Decisions on "matter of taste", e.g. decisions on when to exclude a > package because of its contents (E.g. US folks tend to get nervous about > matters of "depiction of nudity", Europeans tend to get nervous > "glorification of violence" (games!), members of non-Western cultures > might find other topics offensive). To my knowledge, we've never excluded a package based on content unless that content was non-free. > * Decisions on "freedom of software". E.g. when to allow non-free > software and when not (c.f. the non-free firmware case). Sure, but that is a higher level issue to be handled by the Board. For example, it was not a specific debate about whether "firmware for the frobbitz device" is to be allowed. It was a decision at a higher level of including firmware in general. And it very much involved legal-ish discussion, which is sort of a flag that it needs to head up to the Board. > * Decisions on when and how to enforce the "rules of the game". You mean adherence to guidelines? Yes, FESCo will do this. I used an analogy on IRC the other day that might sum up some of the Board/FESCo interaction. It's not complete, but it paints a fairly decent picture of how things should work. The Board decides the higher level direction of Fedora, and FESCo takes that and implements it. If the Board were to say "Fedora should be on cell phones", FESCo would then oversee the adaptations and implementation of that idea. josh From jwboyer at jdub.homelinux.org Thu Jun 21 12:58:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Jun 2007 07:58:36 -0500 Subject: 586 kernels. In-Reply-To: References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <20070621120042.GA17306@devserv.devel.redhat.com> <2a28d2ab0706210510u53d9e18am43eba1ce2f8257da@mail.gmail.com> <1182429151.7546.10.camel@weaponx.rchland.ibm.com> Message-ID: <1182430716.8010.16.camel@weaponx.rchland.ibm.com> On Thu, 2007-06-21 at 14:55 +0200, Goede, J.W.R. de wrote: > On Thu, 21 Jun 2007 07:32:31 -0500 > > > > Why not? We're talking about getting Fedora running on > > ARM and SPARC > > and Alpha. Make i586 a secondary arch :) > > > > Lets not do that, I know quite a few people running Fedora > on epia's including older ones and I would hate to see > Fedor not supporthing those machines anymore. Note I do not > have any such a machine left myself. > > I think this discussion has been blown both off-topic and > out of proportion. My "suggestion" was merely a joke. I should have used a bigger smiley. Or just kept quiet. josh From rc040203 at freenet.de Thu Jun 21 13:17:01 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Jun 2007 15:17:01 +0200 Subject: FESCo elections In-Reply-To: <1182430572.8010.13.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> <20070621073528.GA3140@free.fr> <1182424239.3865.17.camel@vader.jdub.homelinux.org> <1182426466.6710.34.camel@mccallum.corsepiu.local> <1182430572.8010.13.camel@weaponx.rchland.ibm.com> Message-ID: <1182431822.6710.63.camel@mccallum.corsepiu.local> On Thu, 2007-06-21 at 07:56 -0500, Josh Boyer wrote: > On Thu, 2007-06-21 at 13:47 +0200, Ralf Corsepius wrote: > > On Thu, 2007-06-21 at 06:10 -0500, Josh Boyer wrote: > > > On Thu, 2007-06-21 at 09:35 +0200, Patrice Dumas wrote: > > > > On Wed, Jun 20, 2007 at 02:33:18PM -0500, Josh Boyer wrote: > > > > > > So FESCo doesn't really represent the community, because it doesn't > > > > really have a political role, but having the technical leaders elected > > > > nevertheless means that the community is represented in the technical > > > > decision body. > > > > > > Yes, it represents the community in technical matters at the least. > > > > IMO, an elected organ is a bad choice to provide leadership on technical > > matters, because one can not expect an elected member of an organ to be > > technically competent. The domain of "elected organs" is "strategic and > > political decisions", not details. > > Personally, I think that depends on the pool of candidates that are > allowed for such and election. > > > > But > > > you still didn't give me an example of something you feel is "political" > > > in nature, so I have no idea if FESCo would be involved in those things > > > or not. > > > > Some random examples: > > * Decisions on "matter of taste", e.g. decisions on when to exclude a > > package because of its contents (E.g. US folks tend to get nervous about > > matters of "depiction of nudity", Europeans tend to get nervous > > "glorification of violence" (games!), members of non-Western cultures > > might find other topics offensive). > > To my knowledge, we've never excluded a package based on content unless > that content was non-free. We've already had the X-screensaver case :-) More severe cases are only a matter of time. > > * Decisions on "freedom of software". E.g. when to allow non-free > > software and when not (c.f. the non-free firmware case). > > Sure, but that is a higher level issue to be handled by the Board. For > example, it was not a specific debate about whether "firmware for the > frobbitz device" is to be allowed. It was a decision at a higher level > of including firmware in general. And it very much involved legal-ish > discussion, which is sort of a flag that it needs to head up to the > Board. My view is different: Such decisions are mere political. FESCo had not been empowered to draw such decisions and not been equipped with the powers to clean up detail. > > * Decisions on when and how to enforce the "rules of the game". > > You mean adherence to guidelines? That's one point. Other ones would be submission/review policies, upgrade/update policies, AWOL handling, EOL'ing packages, Wiki, setting up deadlines, etc. > Yes, FESCo will do this. > > I used an analogy on IRC the other day that might sum up some of the > Board/FESCo interaction. It's not complete, but it paints a fairly > decent picture of how things should work. The Board decides the higher > level direction of Fedora, and FESCo takes that and implements it. If > the Board were to say "Fedora should be on cell phones", FESCo would > then oversee the adaptations and implementation of that idea. My analogy: The board is the government and FESCo is its administration. Do you see much sense a in a government having an elected Tax Administration? - I don't. Ralf From pertusus at free.fr Thu Jun 21 13:24:31 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 21 Jun 2007 15:24:31 +0200 Subject: FESCo elections In-Reply-To: <1182431822.6710.63.camel@mccallum.corsepiu.local> References: <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> <20070621073528.GA3140@free.fr> <1182424239.3865.17.camel@vader.jdub.homelinux.org> <1182426466.6710.34.camel@mccallum.corsepiu.local> <1182430572.8010.13.camel@weaponx.rchland.ibm.com> <1182431822.6710.63.camel@mccallum.corsepiu.local> Message-ID: <20070621132431.GA6618@free.fr> On Thu, Jun 21, 2007 at 03:17:01PM +0200, Ralf Corsepius wrote: > My analogy: The board is the government and FESCo is its > administration. That analogy seems right to me, FESCo is more than an engineering body, but doesn't take the really important decisions. > Do you see much sense a in a government having an elected Tax > Administration? - I don't. It may make sense. If the information regarding the suitability of the potential administrators is spread over the community, like it is the case in fedora where some information is gained through inter-personal relations in reviews or in private. Maybe it could be part appointed by FPB, part elected to gather advice from the community. However it should be clear that it isn't a representativeness issue, but a mere choice issue. There are countries where some people of the administration are elected (I think it is the case in the US). -- Pat From paul at all-the-johnsons.co.uk Thu Jun 21 13:37:36 2007 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 21 Jun 2007 13:37:36 +0000 Subject: Is this laptop supported by F7 or rawhide properly? Message-ID: <20070621133736.M40808@all-the-johnsons.co.uk> Hi, My old laptop has met it's proverbial maker and decided to die painfully, so it's time to replace it. Could anyone tell me if the following machine is supported properly (including the wlan) by either F7 or inside of rawhide? http://www.ebuyer.com/UK/product/123116/rb/0 Thanks TTFN Paul -- Get your free @ukpost.com account now http://www.ukpost.com/ From alan at redhat.com Thu Jun 21 13:55:19 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 09:55:19 -0400 Subject: Is this laptop supported by F7 or rawhide properly? In-Reply-To: <20070621133736.M40808@all-the-johnsons.co.uk> References: <20070621133736.M40808@all-the-johnsons.co.uk> Message-ID: <20070621135519.GA22406@devserv.devel.redhat.com> On Thu, Jun 21, 2007 at 01:37:36PM +0000, Paul F. Johnson wrote: > Could anyone tell me if the following machine is supported properly (including > the wlan) by either F7 or inside of rawhide? > > http://www.ebuyer.com/UK/product/123116/rb/0 ATI graphics so almost certainly not. Wireless is some branded Acer thing so can't tell so assume not. BTW acer notebooks are often found on morgancomputers.co.uk cheaper than ebuyer and they are from my experience a better vendor ... A good bet is to look for systems with Intel video/wireless - eg stuff with centrino branding. From katzj at redhat.com Thu Jun 21 13:55:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 21 Jun 2007 09:55:09 -0400 Subject: FESCo elections In-Reply-To: <1182430572.8010.13.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> <20070621073528.GA3140@free.fr> <1182424239.3865.17.camel@vader.jdub.homelinux.org> <1182426466.6710.34.camel@mccallum.corsepiu.local> <1182430572.8010.13.camel@weaponx.rchland.ibm.com> Message-ID: <1182434109.7099.2.camel@aglarond.local> On Thu, 2007-06-21 at 07:56 -0500, Josh Boyer wrote: > On Thu, 2007-06-21 at 13:47 +0200, Ralf Corsepius wrote: > > * Pat's static libs issue: This is not a mere technical issue, it's a > > distribution policy issue. > > This is being handled at the FESCo level. There have been a fairly low > number of cases to my knowledge. However, if a higher level decree of > whether static libs are allowable or not is required, it can always be > brought to the Board. Note that there is a pretty conscious effort while laying out responsibilities that technical details around things like static libs are _not_ the type of things the Board wants to be concerned with Jeremy From ncorrare at fedoraproject.org Thu Jun 21 13:59:42 2007 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Thu, 21 Jun 2007 10:59:42 -0300 Subject: Is this laptop supported by F7 or rawhide properly? In-Reply-To: <20070621135519.GA22406@devserv.devel.redhat.com> References: <20070621133736.M40808@all-the-johnsons.co.uk> <20070621135519.GA22406@devserv.devel.redhat.com> Message-ID: <467A844E.6030601@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 /sbin/lspci would be usefull... most probably the wireless uses a Broadcom chip, not that well supported, but works well with ndiswrapper Alan Cox wrote: > On Thu, Jun 21, 2007 at 01:37:36PM +0000, Paul F. Johnson wrote: >> Could anyone tell me if the following machine is supported properly (including >> the wlan) by either F7 or inside of rawhide? >> >> http://www.ebuyer.com/UK/product/123116/rb/0 > > ATI graphics so almost certainly not. Wireless is some branded Acer thing > so can't tell so assume not. > > BTW acer notebooks are often found on morgancomputers.co.uk cheaper than > ebuyer and they are from my experience a better vendor ... > > A good bet is to look for systems with Intel video/wireless - eg stuff with > centrino branding. > - -- - - -- Nicolas A. Corrarello Fedora Ambassador Argentina c: +54 (911) 5182-2245 e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: fedoraproject.org/wiki/NicolasCorrarello/ GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGeoRO4UWy+d/Ik+4RAtqFAKDCApUyInR7ig0H8ggPgCTrAL+3KACeJA5w lIuOsMAF6dWV3AmundT6GW0= =0QAc -----END PGP SIGNATURE----- From jwboyer at jdub.homelinux.org Thu Jun 21 14:04:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Jun 2007 09:04:59 -0500 Subject: Is this laptop supported by F7 or rawhide properly? In-Reply-To: <467A844E.6030601@fedoraproject.org> References: <20070621133736.M40808@all-the-johnsons.co.uk> <20070621135519.GA22406@devserv.devel.redhat.com> <467A844E.6030601@fedoraproject.org> Message-ID: <1182434699.8010.17.camel@weaponx.rchland.ibm.com> On Thu, 2007-06-21 at 10:59 -0300, Nicolas Antonio Corrarello wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > /sbin/lspci would be usefull... most probably the wireless uses a > Broadcom chip, not that well supported, but works well with ndiswrapper That's a bit hard for him to get, given that he hasn't bought it yet... josh From dwmw2 at infradead.org Thu Jun 21 14:06:11 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 21 Jun 2007 22:06:11 +0800 Subject: 586 kernels. In-Reply-To: <1182430716.8010.16.camel@weaponx.rchland.ibm.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <20070621120042.GA17306@devserv.devel.redhat.com> <2a28d2ab0706210510u53d9e18am43eba1ce2f8257da@mail.gmail.com> <1182429151.7546.10.camel@weaponx.rchland.ibm.com> <1182430716.8010.16.camel@weaponx.rchland.ibm.com> Message-ID: <1182434771.2782.31.camel@shinybook.infradead.org> On Thu, 2007-06-21 at 07:58 -0500, Josh Boyer wrote: > On Thu, 2007-06-21 at 14:55 +0200, Goede, J.W.R. de wrote: > > On Thu, 21 Jun 2007 07:32:31 -0500 > > > > > > Why not? We're talking about getting Fedora running on > > > ARM and SPARC > > > and Alpha. Make i586 a secondary arch :) > > > > > > > Lets not do that, I know quite a few people running Fedora > > on epia's including older ones and I would hate to see > > Fedor not supporthing those machines anymore. Note I do not > > have any such a machine left myself. > > > > I think this discussion has been blown both off-topic and > > out of proportion. > > My "suggestion" was merely a joke. I should have used a bigger smiley. > Or just kept quiet. It's interesting to see the perception though. The response doesn't seem to match your suggestion. -- dwmw2 From dwmw2 at infradead.org Thu Jun 21 14:13:34 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 21 Jun 2007 22:13:34 +0800 Subject: Is this laptop supported by F7 or rawhide properly? In-Reply-To: <467A844E.6030601@fedoraproject.org> References: <20070621133736.M40808@all-the-johnsons.co.uk> <20070621135519.GA22406@devserv.devel.redhat.com> <467A844E.6030601@fedoraproject.org> Message-ID: <1182435214.2782.34.camel@shinybook.infradead.org> On Thu, 2007-06-21 at 10:59 -0300, Nicolas Antonio Corrarello wrote: > /sbin/lspci would be usefull... most probably the wireless uses a > Broadcom chip, not that well supported, but works well with > ndiswrapper Don't top-post. Actually I think we have the TX power calibration issues with bcm43xx mostly sorted out now. Once we get that code into our kernel it should mean a lot more people can ditch ndiswrapper. Would be nice to see it in rawhide some time soon, perhaps? -- dwmw2 From j.w.r.degoede at hhs.nl Thu Jun 21 15:40:20 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Thu, 21 Jun 2007 17:40:20 +0200 Subject: Fedora 8 internet keys support detailed plan + patches Message-ID: Hi all, Attached (webmail interface sucks) is a long and detailed description about current problems with internet / east access keys, a proposed solution and description of some patches I'm working on. Please read this (long) and respond as I really would like to see this get included into F-8. Regards, Hans p.s. I forget to tell in the attached text that work is being done with HAL, to automatically call setkeycodes for laptops based on the DMI info of the laptop motherboard, as this is a case where we can actually identify the keyboard manufacturer and model of a ps/2 keyboard. This means that for the example non microsoft compatible keyboard used in the attachment things will work out of the box without needing any end user configuration. For older / rare non microsoft standalone keyboards manual configuration will still be needed though. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keyb-mail.txt URL: From davej at redhat.com Thu Jun 21 16:31:06 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 21 Jun 2007 12:31:06 -0400 Subject: 586 kernels. In-Reply-To: <20070621114255.GD15961@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> Message-ID: <20070621163106.GD29060@redhat.com> On Thu, Jun 21, 2007 at 07:42:55AM -0400, Alan Cox wrote: > Unless Dave can publish data sets and a methodology for his count (and given > even the big marketing companies can't do it I want to see this) we should > assume he made up a number to justify killing it cos he finds it a hassle > to maintain. http://smolt.fedoraproject.org Dave -- http://www.codemonkey.org.uk From jspaleta at gmail.com Thu Jun 21 16:39:47 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 21 Jun 2007 08:39:47 -0800 Subject: 586 kernels. In-Reply-To: <20070621163106.GD29060@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> Message-ID: <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> On 6/21/07, Dave Jones wrote: > http://smolt.fedoraproject.org we have to be somewhat careful with regard to interpreting smolt stats for fine-grained decision making, especially since f7 is the first release with it available by default. On a more personal note, I've been using 586 fc6 installs locally to help me prep LTSP packages for submission to fedora. If you don't mind, I'm going to ping you offlist before I'm ready to submit to make sure I know if 586 is going to be dropped or not to make sure the packages I finally submit have the necessary default script logic for whatever fedora ships. -jef From alan at redhat.com Thu Jun 21 18:39:55 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 14:39:55 -0400 Subject: 586 kernels. In-Reply-To: <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> Message-ID: <20070621183955.GA5301@devserv.devel.redhat.com> On Thu, Jun 21, 2007 at 08:39:47AM -0800, Jeff Spaleta wrote: > mind, I'm going to ping you offlist before I'm ready to submit to make > sure I know if 586 is going to be dropped or not to make sure the > packages I finally submit have the necessary default script logic for > whatever fedora ships. That surely is something for the Fedora Board to decide ? From abo at kth.se Thu Jun 21 18:53:27 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 21 Jun 2007 20:53:27 +0200 Subject: 586 kernels. In-Reply-To: <20070620184020.GH23569@redhat.com> References: <20070620184020.GH23569@redhat.com> Message-ID: <1182452007.2109.202.camel@home.alexander.bostrom.net> ons 2007-06-20 klockan 14:40 -0400 skrev Dave Jones: > Anyway.. To 'solve' this, I think I'm going to have to make the 686 > kernel package an 'i386' package. Wouldn't it be more correct to call it i586? Many FC6 users are on i586 kernels anyway so a yum upgrade would actually do the right thing in this case. :) /abo From jspaleta at gmail.com Thu Jun 21 19:16:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 21 Jun 2007 11:16:00 -0800 Subject: 586 kernels. In-Reply-To: <20070621183955.GA5301@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> <20070621183955.GA5301@devserv.devel.redhat.com> Message-ID: <604aa7910706211216k7136374bvbba38c2b5dd3b752@mail.gmail.com> On 6/21/07, Alan Cox wrote: > On Thu, Jun 21, 2007 at 08:39:47AM -0800, Jeff Spaleta wrote: > > mind, I'm going to ping you offlist before I'm ready to submit to make > > sure I know if 586 is going to be dropped or not to make sure the > > packages I finally submit have the necessary default script logic for > > whatever fedora ships. > > That surely is something for the Fedora Board to decide ? decide what? who I talk to for confirmation if a decision is made for F8? Since the bits that dave twiddles is directly affected by whomever makes the decision with regard to publishing a 586 kernel or not.. it seems best to me to confirm with him concerning the fallout of the decision making process.. since i am relying on his bits for my bits. -jef"it would be best to consider having to talk to me later a fit punishment to dave for starting this thread"spaleta From jdieter at gmail.com Thu Jun 21 19:22:36 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 21 Jun 2007 22:22:36 +0300 Subject: Official presto repositories for Rawhide In-Reply-To: References: <1182177111.4303.10.camel@jndwidescreen.lesbg.loc> Message-ID: <1182453756.9539.8.camel@jndwidescreen.lesbg.loc> On Mon, 2007-06-18 at 09:56 -0500, Rex Dieter wrote: > Jonathan Dieter wrote: > > > I would like to request the creation of presto repositories for Rawhide. > ... > > The presto repository creation tools probably need to be looked over, > > but I think it's time to start creating "official" deltarpms if we're > > going to make it into F8. > > Prereq: presto repository creation tools need to be submitted for review, > and imported into Fedora. Presto-utils should be showing up in F8 within a day or two. What needs to happen next? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Thu Jun 21 19:41:59 2007 From: buildsys at redhat.com (Build System) Date: Thu, 21 Jun 2007 15:41:59 -0400 Subject: rawhide report: 20070621 changes Message-ID: <200706211941.l5LJfxUY031163@porkchop.devel.redhat.com> New package grig A Ham Radio Control graphical user interface New package presto-utils Tools for creating presto repositories Updated Packages: amanda-2.5.2p1-1.fc8 -------------------- * Thu Jun 21 2007 Radek Brich 2.5.2.p1-1 - New upstream version. - Client rpm now installs amanda-client.conf. - Removed obsolete patches -bug18322 and -rsh. - Clean up spec file (non-utf8 error and some warnings from rpmlint). * Mon Feb 19 2007 Jay Fenlason 2.5.1p3-1.fc8 - Upgrade to new upstream release, now that 2.5.1 is somewhat stable. - Note that this requires changing the xinetd configuration and amanda.conf because of the new authentication mechanism. - -server subpackage does not require xinetd. - -server scriptlets do not need to reload xinetd. * Mon Sep 25 2006 Jay Fenlason 2.5.0p2-4 - Include my -dump_size patch to close bz#206129: Dump output size determined incorrectly - Clean up the spec file, following some suggestions in bz#185659: amanda 2.5.0 - Use a tarball without the problematic contrib/sst directory. - Include my new_gnutar (based on a patch by Orion Poplawski ) to work around changed incremental file format in newer (>1.15.1) versions of gnutar. - include my -wildcards patch to turn on wildcards with new versions of tar. charis-fonts-4.100-2.fc8 ------------------------ * Thu Jun 21 2007 Nicolas Mailhot ??? 4.100-2 ??? Fix URL (bug #245101) control-center-1:2.19.4-4.fc8 ----------------------------- * Thu Jun 21 2007 Matthias Clasen - 2.19.4-4 - Fix starting of screensavers dvd+rw-tools-7.0-4.fc8 ---------------------- * Thu Jun 21 2007 Harald Hoyer - 7.0-4 - fixed exit status (#243036) - Allow session to cross 4GB boundary regardless of medium type. Add a -F option (used instead of -M or -Z), which displays next_session offset and capacity. (#237967) * Tue Feb 27 2007 Harald Hoyer - 7.0-3 - fixed specfile issues (#209985) * Thu Dec 14 2006 Harald Hoyer - 7.0-0.4 - set pthread stack size according to limit (#215818) gdb-6.6-17.fc8 -------------- * Thu Jun 21 2007 Jan Kratochvil - 6.6-17 - Support for stepping over PPC atomic instruction sequences (BZ 237572). - `set scheduler-locking step' is no longer enforced but it is now default. geomview-1.9.3-1.fc8 -------------------- * Thu Jun 21 2007 Rex Dieter 1.9.3-1 - geomview-1.9.3 gtk2-engines-2.11.2-2.fc8 ------------------------- * Thu Jun 21 2007 Matthias Clasen - 2.11.2-2 - Make the new tooltip api yellow, too kdebase-6:3.5.7-5.fc8 --------------------- * Wed Jun 20 2007 Rex Dieter - 6:3.5.7-5 - Provides: kdebase3(-devel) libmusicbrainz-2.1.5-1.fc8 -------------------------- * Thu Jun 21 2007 - Bastien Nocera - 2.1.5-1 - Update to 2.1.5 ntp-4.2.4p2-1.fc8 ----------------- * Thu Jun 21 2007 Miroslav Lichvar 4.2.4p2-1 - update to 4.2.4p2 opensp-1.5.2-5.fc8 ------------------ * Thu Jun 21 2007 Ondrej Vasik 1.5.2-5 - fixed SIGSEGV (bug #245104) pcmciautils-014-9.fc8 --------------------- * Thu Jun 21 2007 Harald Hoyer - 014-9 - fixed modprobe udev rule python-2.5.1-2.fc8 ------------------ * Thu Jun 21 2007 Jeremy Katz - 2.5.1-2 - rebuild to take advantage of hardlinking between identical pyc/pyo files * Thu May 31 2007 Jeremy Katz - 2.5.1-1 - update to python 2.5.1 * Mon Mar 19 2007 Jeremy Katz - 2.5.3-12 - fix alpha build (#231961) python-genshi-0.4.2-1.fc8 ------------------------- * Thu Jun 21 2007 Jeffrey C. Ollie - 0.4.2-1 - Update to 0.4.2 scim-1.4.6-5.fc8 ---------------- * Thu Jun 21 2007 Jens Petersen - 1.4.6-5 - add scim-lang-* meta packages to aid yum package group handling of scim core packages so they no longer need to be installed by default * Tue Jun 05 2007 Jens Petersen - 1.4.6-4 - drop scim_panel_gtk-settle-toolbar-after-drag.patch since it interferes with user toolbar placement (reported by Ryo Dairiki, #242610) * Wed May 30 2007 Jens Petersen - 1.4.6-3 - save the hotkey for lang in initial-locale-hotkey-186861.patch again scummvm-0.10.0-1.fc8 -------------------- * Thu Jun 21 2007 Matthias Saou 0.10.0-1 - Update to 0.10.0, since Hans is away for a few days ;-) - Install icons the same way as the theme, and preserve timestamps. - Use a downloads.sf.net source URL. - Remove two no longer needed patches (gcc41 and new-flac). smartmontools-1:5.37-4.fc8 -------------------------- * Thu Jun 21 2007 Tomas Smetana - 1:5.37-4 - fix #241389 - smartd-conf.py pulls in a big dependency chain, so build a separate config package xchat-1:2.8.2-11.fc8 -------------------- * Thu Jun 21 2007 Kevin Kofler - 1:2.8.2-11 - add missing BR desktop-file-utils * Thu Jun 21 2007 Kevin Kofler - 1:2.8.2-10 - remove Application; and X-Red-Hat-Extras; categories from .desktop file (merge review #226551) - install the .desktop file properly (merge review #226551) Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From nicolas.mailhot at laposte.net Thu Jun 21 19:42:00 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 21 Jun 2007 21:42:00 +0200 Subject: Fedora 8 internet keys support detailed plan + patches In-Reply-To: References: Message-ID: <1182454920.32315.59.camel@rousalka.dyndns.org> Hi Hans, Since I've been looking at the same stuff, and noticed your post on LKML, I was wondering when you were going to bring the problem Fedora-side. Here are my thoughts on the subject: 1. as mouse handling showed we're really better of with the kernel faking a single kind of device rather than exposing all the device quirks to userspace. Therefore input work should progress from the kernel upwards and not the current multi-layer approach where efforts somehow never meet in the middle 2. what should be emulated is a microsoft usb keyboard as they're the best specified and competition is forcing manufacturers to target them anyway 3. however right now the kernel is not able to handle latest microsoft usb keyboards (google for hid bus on usb-devel). So first effort (getting target keyboard to work flawlessly to have a reference) is there. 4. Once that's fixed the only sane thing to target is evdev. It's been progressing quickly lately so putting efforts anywhere else is insane. Checking keyboard maps and app keybindings is a lot of work, it would be insane to do it for a temporary solution. (everyone interested in testing should be careful to restart his system after reconfiguring X as you can get weird effects otherwise). 5. the X internal keycodes are limited to 256 values, so you can't just assume a monster keyboard with every possible extended key. More work here. 6. in an extended keys words some actions can be triggered both by an extended key and ctrl+foo combos so apps need to learn to bind several keybindings to a single action 7. manufacturers are often quite creative in the extended key sets they propose so users need to be able to remap them (optionaly, as some users will take what's printed on keys over anything else, even if what's printed is totally useless) 8. lots of usb gadgets have extended keys nowadays, not just keyboards so the remapping & keybindings apps need to learn to be less keyboard-oriented someday 9. laptops are not the only ones with extended keys, and dmi is a laptop-specific solution That's a lot of stuff to fix, and it won't happen overnight, so a short-term target should probably be to choose a reference keyboard, enable evdev and try to have all our test hardware behave as well as it in this mode (well ? perfect as we're not there yet unfortunately) -- 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 naheemzaffar at gmail.com Thu Jun 21 19:53:33 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 21 Jun 2007 20:53:33 +0100 Subject: 586 kernels. In-Reply-To: <604aa7910706211216k7136374bvbba38c2b5dd3b752@mail.gmail.com> References: <20070620184020.GH23569@redhat.com> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> <20070621183955.GA5301@devserv.devel.redhat.com> <604aa7910706211216k7136374bvbba38c2b5dd3b752@mail.gmail.com> Message-ID: <3adc77210706211253l77a4c829yfd11806c2f4948e4@mail.gmail.com> Am I right in thinking the the i586 and the i686 kernels will be absolutely identical? feature for feature AND bug for bug? Why not have both? Possibly have i686 for upgrades/updates only and i586 for new installs? with a message in the release notes/docs/major announcements that by Fn+1 i686 kernel will be removed/merged? (but use different words so as not to get people kicking up a fuss...) From alan at redhat.com Thu Jun 21 21:09:58 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 17:09:58 -0400 Subject: 586 kernels. In-Reply-To: <604aa7910706211216k7136374bvbba38c2b5dd3b752@mail.gmail.com> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> <20070621183955.GA5301@devserv.devel.redhat.com> <604aa7910706211216k7136374bvbba38c2b5dd3b752@mail.gmail.com> Message-ID: <20070621210958.GD5301@devserv.devel.redhat.com> On Thu, Jun 21, 2007 at 11:16:00AM -0800, Jeff Spaleta wrote: > >That surely is something for the Fedora Board to decide ? > > decide what? who I talk to for confirmation if a decision is made for > F8? Since the bits that dave twiddles is directly affected by Whether FC8 should have support for older processors or not. This isn't just the kernel but several other packages - glibc, openssl that would want to either be fixed along with rpm or converted to 686 only. It also I believe has fallout for OLPC ? From alan at redhat.com Thu Jun 21 21:15:07 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 21 Jun 2007 17:15:07 -0400 Subject: 586 kernels. In-Reply-To: <20070621163106.GD29060@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> Message-ID: <20070621211507.GH5301@devserv.devel.redhat.com> On Thu, Jun 21, 2007 at 12:31:06PM -0400, Dave Jones wrote: > > even the big marketing companies can't do it I want to see this) we should > > assume he made up a number to justify killing it cos he finds it a hassle > > to maintain. > > http://smolt.fedoraproject.org Yes Dave. Statistical methodology ? From bojan at rexursive.com Thu Jun 21 21:37:27 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 22 Jun 2007 07:37:27 +1000 Subject: Fedora systems for maintainers Message-ID: <1182461847.2937.18.camel@shrek.rexursive.com> Are there any systems withing Fedora project infrastructure that package maintainers can log into (i.e. get a shell, VNC etc.)? It may be useful to have such things for times when maintainers want to play with, build locally or test packages on Fedora versions (including development) that they currently don't have installed on their local systems or their local systems are not in best shape. The reason I'm asking is this bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240395 -- Bojan From jwboyer at jdub.homelinux.org Thu Jun 21 22:05:40 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Jun 2007 17:05:40 -0500 Subject: Fedora systems for maintainers In-Reply-To: <1182461847.2937.18.camel@shrek.rexursive.com> References: <1182461847.2937.18.camel@shrek.rexursive.com> Message-ID: <1182463540.3865.22.camel@vader.jdub.homelinux.org> On Fri, 2007-06-22 at 07:37 +1000, Bojan Smojver wrote: > Are there any systems withing Fedora project infrastructure that package > maintainers can log into (i.e. get a shell, VNC etc.)? It may be useful > to have such things for times when maintainers want to play with, build > locally or test packages on Fedora versions (including development) that > they currently don't have installed on their local systems or their > local systems are not in best shape. Nothing official at this point. Though there are several people who will create accounts on various machines if you ask. E.g. David Woodhouse has been know to give accounts on ppc/ppc64 machines for maintainers to work through build issues. At the moment, best thing to do is ask here or -devel. Perhaps eventually we can have some KVM instances setup with various releases of Fedora installed. josh From j.w.r.degoede at hhs.nl Thu Jun 21 22:16:42 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Fri, 22 Jun 2007 00:16:42 +0200 Subject: Fedora 8 internet keys support detailed plan + patches In-Reply-To: <1182454920.32315.59.camel@rousalka.dyndns.org> References: <1182454920.32315.59.camel@rousalka.dyndns.org> Message-ID: On Thu, 21 Jun 2007 21:42:00 +0200 Nicolas Mailhot wrote: > Hi Hans, > > Since I've been looking at the same stuff, and noticed > your post on > LKML, I was wondering when you were going to bring the > problem > Fedora-side. Here are my thoughts on the subject: > Thanks for sharing your thoughts with us, but I get the feeling you didn't look any further at my plan / proposal howto handle his for F-8, can you please provide some direct feedback on my proposal? Thanks! > 1. as mouse handling showed we're really better of with > the kernel > faking a single kind of device rather than exposing all > the device > quirks to userspace. Therefore input work should progress > from the > kernel upwards and not the current multi-layer approach > where efforts > somehow never meet in the middle > Agreed, the kernel should emulate a virtual ps/2 keyboard which always looks the same (with regards to scancodes) independend of the real keyboard. In the case of userspace using evdev then there is nothing to emulate though, as the kernel then directly exports all features of the hardware as it sees them. > 2. what should be emulated is a microsoft usb keyboard as > they're the > best specified and competition is forcing manufacturers > to target them > anyway > ?? I don't understand we do not "emulate" USB devices, the kernel emulates a ps/2 keyboard, because some (most) apps expect there to be a ps/2 keyboard, even though in reality a USB keyboard might be present. When the app uses the input devices instead of looking for a ps/2 keyboard, then there is no emulating, the apps directly gets all the event from the input device as the kernel sees them. Under certain circumstances the kernel may need configuration or bugfixing to properly see the event (for example to properly match ps/2 scancodes to its internal keycodes) but that is not emulating! Or are you talking about emulating a microsoft multimedia keys having ps/2 keyboard, in that case I gully agree, and so thus upstream as that is what they are already doing. > 3. however right now the kernel is not able to handle > latest microsoft > usb keyboards (google for hid bus on usb-devel). So first > effort > (getting target keyboard to work flawlessly to have a > reference) is > there. > There is no such thing as a target keyboard. With USB keyboards the hid standard clearly defines id's for every keys (see the hut 1.24 document) and the kernel maps these ID's to keycodes accordind to the hut standard. Microsofts keyboards are not relevant here the kernel follows the standard as it should, and since microsoft helps in writing this standard, I assume microsoft keyboards will implement it. > 4. Once that's fixed the only sane thing to target is > evdev. It's been > progressing quickly lately so putting efforts anywhere > else is insane. > Checking keyboard maps and app keybindings is a lot of > work, it would be > insane to do it for a temporary solution. > (everyone interested in testing should be careful to > restart his system > after reconfiguring X as you can get weird effects > otherwise). > Fedora currently is using the Xorg keyboard driver, not evdev. Since AFAIK there are no plans to change that for F-8 and I want to see this fixed before F-8, I don't think that switching to evdev is a good idea, too much work, too much chances for regressions, little short term gain. Internet keys can be made to work easily with the current xorg setup, with minimal chances and little work. So unless the xorg maintainer already wants to switch to evdev for F-8, this will not be needed for proper internet keys operation. > 5. the X internal keycodes are limited to 256 values, so > you can't just > assume a monster keyboard with every possible extended > key. More work > here. > AFAIK, no there not, they are sequences of 4 ASCII characters, so plenty of room. > 6. in an extended keys words some actions can be > triggered both by an > extended key and ctrl+foo combos so apps need to learn to > bind several > keybindings to a single action > Yes, no matter how e get X to send the correct X-keysyms for internet keys, we still need to fix the apps. So lets take a minimal effort approach to getting X to send the correct jeysyms and then focus on fixing the apps. > 7. manufacturers are often quite creative in the extended > key sets they > propose so users need to be able to remap them > (optionaly, as some users > will take what's printed on keys over anything else, even > if what's > printed is totally useless) > ??? I don;t understand if the key comes with a finding glass icon, and X sends XF86Search as keysym, then all is well, if the user wants to binf this keysym to something other then search, thats fine, just like the user can make the 'a' key always launch an xterm when pressed. IOW, what does this have todo with anything? > 8. lots of usb gadgets have extended keys nowadays, not > just keyboards > so the remapping & keybindings apps need to learn to be > less > keyboard-oriented someday > Thats a far, far away future, when X will support plug and play of input devices and thus actually will be able to differentiate between the laptop keyboard and the just pluged in usb keyboard. As long as X cannot differentiate between these, there is nothing we can do to make the apps see the difference. > 9. laptops are not the only ones with extended keys, and > dmi is a > laptop-specific solution > I agree, actually isn't that exactly what I wrote?? > That's a lot of stuff to fix, and it won't happen > overnight, so a > short-term target should probably be to choose a > reference keyboard, > enable evdev and try to have all our test hardware behave > as well as it > in this mode (well ? perfect as we're not there yet > unfortunately) > Why enable evdev? Thats lots of work + many potential problems without much gain, Please read my proposal, which is meant as a solution which can be implemented in a short time, with a small it of (nearly finished) work on the xkb side, and most work on configuring apps, which is work which we can reuse if we decide to evdev, or input system X later. Regards, Hans > -- > Nicolas Mailhot From tonynelson at georgeanelson.com Thu Jun 21 23:27:29 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Thu, 21 Jun 2007 19:27:29 -0400 Subject: 586 kernels. In-Reply-To: <20070621210958.GD5301@devserv.devel.redhat.com> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> <20070621183955.GA5301@devserv.devel.redhat.com> <604aa7910706211216k7136374bvbba38c2b5dd3b752@mail.gmail.com> <20070621210958.GD5301@devserv.devel.redhat.com> Message-ID: At 5:09 PM -0400 6/21/07, Alan Cox wrote: >On Thu, Jun 21, 2007 at 11:16:00AM -0800, Jeff Spaleta wrote: >> >That surely is something for the Fedora Board to decide ? >> >> decide what? who I talk to for confirmation if a decision is made for >> F8? Since the bits that dave twiddles is directly affected by > >Whether FC8 should have support for older processors or not. This isn't >just the kernel but several other packages - glibc, openssl that would >want to either be fixed along with rpm or converted to 686 only. > >It also I believe has fallout for OLPC ? Dave Jones proposes shipping a single kernel that works with all 686 machines, both the ones Fedora calls 686 and the ones Fedora calls 586, rather than having two separate kernels. There is an issue with a hack in RPM that makes shipping a single kernel a bit annoying, and he asked what to do about it. Jeff Spaleta asked Dave Jones to keep him posted, as Jeff needs to make packaging decisions based on what Dave eventually calls the kernel. >From Dave's original post: At 2:40 PM -0400 6/20/07, Dave Jones wrote: >A day or so ago, I flipped the switch and killed off the 586 specific >kernel, by making the 686 kernel bootable on older machines. ... >From Jeff's request: At 8:39 AM -0800 6/21/07, Jeff Spaleta wrote: ... >On a more personal note, I've been using 586 fc6 installs locally to >help me prep LTSP packages for submission to fedora. If you don't >mind, I'm going to ping you offlist before I'm ready to submit to make >sure I know if 586 is going to be dropped or not to make sure the >packages I finally submit have the necessary default script logic for >whatever fedora ships. Note that Jeff expects that the kernel will work for LTSP. If you have machines that require a 586 kernel you should ask Dave for one of his new kernels and see if it works on them. If it doesn't work because of how it was compiled, you should tell him. Currently you are panicking without any evidence that you will have any issue at all. -- ____________________________________________________________________ TonyN.:' ' From mmahut at fedoraproject.org Thu Jun 21 23:44:43 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Fri, 22 Jun 2007 01:44:43 +0200 Subject: buggbot is broken Message-ID: <467B0D6B.4070809@fedoraproject.org> Hey guys, Buggbot on #fedorabot seems to be broken. Who take care of that? -- Marek Mahut Tel.: +420-532-294-666 Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From dwmw2 at infradead.org Fri Jun 22 00:58:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 22 Jun 2007 08:58:09 +0800 Subject: 586 kernels. In-Reply-To: <20070621210958.GD5301@devserv.devel.redhat.com> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> <20070621183955.GA5301@devserv.devel.redhat.com> <604aa7910706211216k7136374bvbba38c2b5dd3b752@mail.gmail.com> <20070621210958.GD5301@devserv.devel.redhat.com> Message-ID: <1182473889.10524.17.camel@shinybook.infradead.org> On Thu, 2007-06-21 at 17:09 -0400, Alan Cox wrote: > On Thu, Jun 21, 2007 at 11:16:00AM -0800, Jeff Spaleta wrote: > > >That surely is something for the Fedora Board to decide ? > > > > decide what? who I talk to for confirmation if a decision is made for > > F8? Since the bits that dave twiddles is directly affected by > > Whether FC8 should have support for older processors or not. This isn't > just the kernel but several other packages - glibc, openssl that would > want to either be fixed along with rpm or converted to 686 only. What is it that we stand to gain from dropping i586, again? I appreciate that it seems to have an order of magnitude fewer users than PowerPC, but why do we actually need to drop it? > It also I believe has fallout for OLPC ? OLPC builds its own kernels. -- dwmw2 From jkeating at redhat.com Fri Jun 22 01:07:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Jun 2007 21:07:15 -0400 Subject: 586 kernels. In-Reply-To: <1182473889.10524.17.camel@shinybook.infradead.org> References: <1182365094.4102.17.camel@hodge> <20070621210958.GD5301@devserv.devel.redhat.com> <1182473889.10524.17.camel@shinybook.infradead.org> Message-ID: <200706212107.15957.jkeating@redhat.com> On Thursday 21 June 2007 20:58:09 David Woodhouse wrote: > What is it that we stand to gain from dropping i586, again? I appreciate > that it seems to have an order of magnitude fewer users than PowerPC, > but why do we actually need to drop it? I don't think we're really planning on doing that. Dave is trying to find a way to build a single kernel that will work for /both/ i586 and i686. It sounds like he has one already, but he's running into rpm issues given that it's named i686. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Fri Jun 22 02:18:20 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 21 Jun 2007 21:18:20 -0500 Subject: 586 kernels. In-Reply-To: <20070620184020.GH23569@redhat.com> References: <20070620184020.GH23569@redhat.com> Message-ID: <200706212118.25699.dennis@ausil.us> Once upon a time Wednesday 20 June 2007, Dave Jones wrote: > A day or so ago, I flipped the switch and killed off the 586 specific > kernel, by making the 686 kernel bootable on older machines. > Turns out it isn't that easy however. > Rpm will refuse to install the 686 kernel a 586, because it checks > the arch.. > > sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm > Preparing... ########################################### > [100%] package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture > > > (Oddly, the 586 kernel uname is reporting itself as 686 already, > which I don't quite understand.. > Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 > i686 i386 GNU/Linux) > > Anyway.. To 'solve' this, I think I'm going to have to make the 686 > kernel package an 'i386' package. > > Does anyone see anything flawed with this approach? > > (Modulo problems with yum doing exactarch matches and upgrades being > more of a nightmare than usual). I dont particularly care what the kernel is called but im looking at buying a system from http://www.soekris.com/ to use as wireless access point / firewall / router . its a 586 class cpu so i would really like to have fedora working on it. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri Jun 22 08:53:15 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 22 Jun 2007 04:53:15 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-22 Message-ID: <20070622085315.67C37152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 30 NEW adminutil-1.1.1-3.fc6 : Utility library for directory server administration crystal-clear-20050622-5.fc6 dbmail-2.2.5-3.fc6 denyhosts-2.6-5.fc6 eclipse-subclipse-1.2.2-2.fc6 emacs-vm-8.0.0.453-1.fc6 fail2ban-0.8.0-9.fc6 fedora-usermgmt-0.10-1.fc6 fwbackups-1.43.0-0.1.rc3.fc6 geomview-1.9.3-1.fc6 NEW grig-0.7.2-1.fc6 : A Ham Radio Control graphical user interface gscan2pdf-0.9.12-1.fc6 kaffeine-0.8.4-1.fc6 kanatest-0.4.2-2.fc6 magic-7.4.35-2.fc6 NEW mecab-java-0.96-2.fc6 : Java binding for MeCab pcb-0.20070208-2.fc6 (!) perl-Crypt-OpenSSL-Bignum-0.03-3.fc6 : INVALID rebuild, not published! NEW perl-Crypt-OpenSSL-RSA-0.25-1.fc6 : Perl interface to OpenSSL for RSA NEW perl-Digest-SHA-5.44-5.fc6 : Perl extension for SHA-1/224/256/384/512 NEW perl-Geo-METAR-1.14-2.fc6 : Perl module for accessing aviation weather information php-extras-5.1.6-4.fc6 puppet-0.23.0-1.fc6 NEW pypar2-1.4-1.fc6 : PyPar2 is a graphical frontend for the Linux par2 command line NEW reciteword-0.8.3-3.fc6 : Recite Word Easily NEW svnkit-1.1.2-2.fc6 : Pure Java Subversion client library tcptraceroute-1.5-0.2.beta7.fc6 texmaker-1.6-2.fc6 tmda-1.1.11-4.fc6 NEW xfce4-volstatus-icon-0.1.0-1.fc6 : System tray icon to easily eject removable devices Packages built and released for Fedora Extras 5: 23 crystal-clear-20050622-5.fc5 dbmail-2.2.5-3.fc5 denyhosts-2.6-5.fc5 em8300-kmod-0.16.1-0.2.6.20_1.2320.fc5.2 fail2ban-0.8.0-9.fc5 fedora-usermgmt-0.8-4.fc5 fwbackups-1.43.0-0.1.rc3.fc5 geomview-1.9.3-1.fc5 gpredict-0.8.0-1.fc5 gscan2pdf-0.9.12-1.fc5 kaffeine-0.8.4-1.fc5 kanatest-0.4.2-2.fc5 koffice-1.6.3-6.fc5.1 maxima-5.12.0-3.fc5 mozldap-6.0.4-1.fc5 pcb-0.20070208-2.fc5 perl-Mozilla-LDAP-1.5.1-1.fc5 puppet-0.23.0-1.fc5 NEW PyKDE-3.16.0-5.fc5 : Python bindings for KDE NEW pypar2-1.4-1.fc5 : PyPar2 is a graphical frontend for the Linux par2 command line sbcl-1.0.6-1.fc5 texmaker-1.6-2.fc5 tmda-1.1.11-4.fc5 Changes in Fedora Extras 6: adminutil-1.1.1-3.fc6 --------------------- * Wed May 23 2007 Rich Megginson - 1.1.1-3 - more fedora review stuff - use macros consistently - make sure install preserves timestamps - use lgpl instead of gpl for acclanglist.c - fix undefined weak symbols in libadmsslutil crystal-clear-20050622-5.fc6 ---------------------------- * Thu Jun 21 2007 Chitlesh Goorah 20050622-5 - fixed url: # 245106 dbmail-2.2.5-3.fc6 ------------------ * Wed Jun 20 2007 Bernard Johnson 2.2.5-3 - assign uid from package user registry denyhosts-2.6-5.fc6 ------------------- * Tue Jun 19 2007 Jason L Tibbitts III - 2.6-5 - Apply yet another regex.py fix from Jonathan Underwood to fix bug 244943. eclipse-subclipse-1.2.2-2.fc6 ----------------------------- * Wed Jun 20 2007 Robert Marcano 1.2.2-2 - Update to upstream 1.2.2 - Dependency changed from javasvn to svnkit - Patch to support EPEL5 sent by Rob Myers emacs-vm-8.0.0.453-1.fc6 ------------------------ * Tue Jun 19 2007 Jonathan G. Underwood - 8.0.0.453-1 - Update to version 8.0.0 devo 453 which removes the need for thr vmrf patch - No longer need to bundle vcard stuff as that is included upstream - Spec file cleanups - No longer use separate pixmaps * Sun Mar 18 2007 Jonathan G. Underwood - 7.19.%{vmrfversion}-9 - Bump release to fix problem with CVS sources file * Sun Mar 18 2007 Jonathan G. Underwood - 7.19.devo282-8 - Redefine version to include vmrf patch version (devo282) - Remove pointless %{pkg} macro - Add new pixmaps with better sizing (still ugly though) - Renamed the vmrf patch to include the version fail2ban-0.8.0-9.fc6 -------------------- * Thu Jun 21 2007 Axel Thimm - 0.8.0-9 - Fix remote log injection (no CVE assignment yet). fedora-usermgmt-0.10-1.fc6 -------------------------- * Wed Jun 20 2007 Enrico Scholz - 0.10-1 - added basic checks that CLI is used correctly fwbackups-1.43.0-0.1.rc3.fc6 ---------------------------- * Wed Jun 20 2007 Stewart Adam 1.43.0-0.1.rc3 - Update to 1.43.0 rc3 (see CHANGELOG file for details on version changes) geomview-1.9.3-1.fc6 -------------------- * Thu Jun 21 2007 Rex Dieter 1.9.3-1 - geomview-1.9.3 * Sat Jun 16 2007 Rex Dieter 1.9.2-1 - geomview-1.9.2 * Wed Jun 06 2007 Rex Dieter 1.9.1-1 - geomview-1.9.1 - omit orrery/maniview, can now be packaged separately. grig-0.7.2-1.fc6 ---------------- * Fri Dec 29 2006 Denis Leroy - 0.7.2-1 - First version gscan2pdf-0.9.12-1.fc6 ---------------------- * Tue Jun 19 2007 Bernard Johnson - 0.9.12-1 - v 0.9.12 kaffeine-0.8.4-1.fc6 -------------------- * Fri Jun 08 2007 Rex Dieter 0.8.4-1 - kaffeine-0.8.4 (#243823) * Thu Jan 18 2007 Rex Dieter 0.8.3-4 - disable gst08 support (for now), it's been orphaned * Wed Nov 29 2006 Rex Dieter 0.8.3-3 - less globbing in %files * Wed Nov 29 2006 Rex Dieter 0.8.3-2 - include libkaffeinepart.so in main pkg, not -devel (bug #217835) kanatest-0.4.2-2.fc6 -------------------- * Thu Jun 21 2007 Robert Marcano - 0.4.2-2 - Update to upstream release 0.4.2 - Bug 245177 - URL changed - Bug 245177 magic-7.4.35-2.fc6 ------------------ * Thu Jun 21 2007 Chitlesh Goorah - 7.4.35-2 - fix desktop file #241443 mecab-java-0.96-2.fc6 --------------------- * Sun Jun 17 2007 Mamoru Tasaka - 0.96-2 - Nuke test for now * Fri Jun 15 2007 Mamoru Tasaka - 0.96-1 - 0.96 pcb-0.20070208-2.fc6 -------------------- * Thu Jun 21 2007 Chitlesh Goorah - 0.20070208-2 - fixed docdir * Fri Feb 09 2007 Chitlesh Goorah - 0.20070208-1 - New upstream release - 20070208 perl-Crypt-OpenSSL-Bignum-0.03-3.fc6 ------------------------------------ * Mon May 14 2007 Wes Hardaker - 0.03-3 - BuildRequire perl(ExtUtils::MakeMaker) perl(Test) perl-Crypt-OpenSSL-RSA-0.25-1.fc6 --------------------------------- * Thu May 31 2007 Wes Hardaker - 0.25-1 - head to upstream 0.25 - doc the new LICENSE file perl-Digest-SHA-5.44-5.fc6 -------------------------- * Fri Jun 01 2007 Wes Hardaker - 5.44-5 - fix changelog * Thu May 31 2007 Wes Hardaker - 5.44-4 - fix description clause to remove hyphenation - pass optimization flags to Makefile.PL - Reverse terms in license to match perl rpm exactly perl-Geo-METAR-1.14-2.fc6 ------------------------- * Wed Jun 06 2007 kwizart < kwizart at gmail.com > - 1.14-2 - Add BR perl(ExtUtils::MakeMaker) * Tue Jun 05 2007 kwizart < kwizart at gmail.com > - 1.14-1 - Initial Fedora package php-extras-5.1.6-4.fc6 ---------------------- * Wed Jun 20 2007 Dmitry Butskoy - 5.1.6-4 - add patch for mssql (#244736), a backport of some php-5.2 changes puppet-0.23.0-1.fc6 ------------------- * Wed Jun 20 2007 David Lutterkort - 0.23.0-1 - Install one puppet.conf instead of old config files, keep old configs around to ease update - Use plain shell commands in install instead of macros pypar2-1.4-1.fc6 ---------------- * Tue Apr 24 2007 Maxime Carron - 1.4-1 - approve Chitlesh's proposal reciteword-0.8.3-3.fc6 ---------------------- * Wed Jun 20 2007 Hu Zheng - 0.8.3-3 - Fix x86_64 compile error. * Fri Jun 15 2007 Hu Zheng - 0.8.3-2 - Small fixes according to Parag AN's suggestion. * Thu Jun 07 2007 Hu Zheng - 0.8.3-1 - Initial build for Fedora svnkit-1.1.2-2.fc6 ------------------ * Mon Jun 18 2007 Robert Marcano 1.1.2-2 - Package review fixes tcptraceroute-1.5-0.2.beta7.fc6 ------------------------------- * Wed Jun 20 2007 Sindre Pedersen Bj?rdal - 1.5-0.2.beta7 - Fix typo to really remove duplicate doc files texmaker-1.6-2.fc6 ------------------ * Thu Jun 21 2007 Deji Akingunola - 1:1.6-2.fc6 - Change default dvi viewer back to xdvi, and require tetex-xdvi for it * Thu Jun 21 2007 Deji Akingunola - 1:1.6-1.fc6 - New Release tmda-1.1.11-4.fc6 ----------------- * Wed Jun 20 2007 Bernard Johnson 1.1.11-4 - assign package uid * Fri Apr 06 2007 Bernard Johnson 1.1.11-3 - remove versioned python dependencies, no supported python is unsupported - if compiling for EL-4, compile python since there is no brp-python-bytecompile * Thu Mar 01 2007 Bernard Johnson 1.1.11-2 - fix source0 line xfce4-volstatus-icon-0.1.0-1.fc6 -------------------------------- * Mon Jun 11 2007 Christoph Wickert - 0.1.0-1 - Initial package. Changes in Fedora Extras 5: crystal-clear-20050622-5.fc5 ---------------------------- * Thu Jun 21 2007 Chitlesh Goorah 20050622-5 - fixed url: # 245106 dbmail-2.2.5-3.fc5 ------------------ * Wed Jun 20 2007 Bernard Johnson 2.2.5-3 - assign uid from package user registry denyhosts-2.6-5.fc5 ------------------- * Tue Jun 19 2007 Jason L Tibbitts III - 2.6-5 - Apply yet another regex.py fix from Jonathan Underwood to fix bug 244943. em8300-kmod-0.16.1-0.2.6.20_1.2320.fc5.2 ---------------------------------------- * Thu Jun 21 2007 Ville Skytt? - Rebuild for kernel 2.6.20-1.2320.fc5. fail2ban-0.8.0-9.fc5 -------------------- * Thu Jun 21 2007 Axel Thimm - 0.8.0-9 - Fix remote log injection (no CVE assignment yet). fedora-usermgmt-0.8-4.fc5 ------------------------- * Wed Jun 20 2007 Enrico Scholz - 0.8-4 - added basic checks that CLI is used correctly * Thu Mar 08 2007 Enrico Scholz - 0.8-3 - fixed and updated the documentation; especially, added the '-r' option to the fedora-useradd example and mentioned the wiki page. fwbackups-1.43.0-0.1.rc3.fc5 ---------------------------- * Wed Jun 20 2007 Stewart Adam 1.43.0-0.1.rc3 - Update to 1.43.0 rc3 (see CHANGELOG file for details on version changes) geomview-1.9.3-1.fc5 -------------------- * Thu Jun 21 2007 Rex Dieter 1.9.3-1 - geomview-1.9.3 * Sat Jun 16 2007 Rex Dieter 1.9.2-1 - geomview-1.9.2 * Wed Jun 06 2007 Rex Dieter 1.9.1-1 - geomview-1.9.1 - omit orrery/maniview, can now be packaged separately. gpredict-0.8.0-1.fc5 -------------------- * Tue Jun 19 2007 Denis Leroy - 0.8.0-1 - Update to 0.8.0 - Fixed desktop file StartupNotify gscan2pdf-0.9.12-1.fc5 ---------------------- * Tue Jun 19 2007 Bernard Johnson - 0.9.12-1 - v 0.9.12 kaffeine-0.8.4-1.fc5 -------------------- * Fri Jun 08 2007 Rex Dieter 0.8.4-1 - kaffeine-0.8.4 (#243823) * Thu Jan 18 2007 Rex Dieter 0.8.3-4 - disable gst08 support (for now), it's been orphaned * Wed Nov 29 2006 Rex Dieter 0.8.3-3 - less globbing in %files * Wed Nov 29 2006 Rex Dieter 0.8.3-2 - include libkaffeinepart.so in main pkg, not -devel (bug #217835) kanatest-0.4.2-2.fc5 -------------------- * Thu Jun 21 2007 Robert Marcano - 0.4.2-2 - Update to upstream release 0.4.2 - Bug 245177 - URL changed - Bug 245177 * Mon Aug 28 2006 Robert Marcano - 0.3.6-6 - Rebuild * Fri Jul 28 2006 Robert Marcano - 0.3.6-5 - Fix build in mock (bug #200076) koffice-1.6.3-6.fc5.1 --------------------- * Thu Jun 21 2007 Rex Dieter 1.6.2-6 - use simpler NoDisplay=True hack (workaround #245190) - disable (kross)ruby on rawhide (for now) * Wed Jun 20 2007 Rex Dieter 1.6.2-5 - mark applnk/.hidden/*.desktop NoDisplay=True instead (#245061) * Fri Jun 15 2007 Rex Dieter 1.6.2-3 - (really) require version of kdelibs used to build against (#244091) * Fri Jun 15 2007 Rex Dieter 1.6.2-2 - Require version of kdelibs used to build against (#244091) - -suite: use versioned Requires * Fri Jun 01 2007 Rex Dieter 1.6.3-1 - koffice-1.6.3 maxima-5.12.0-3.fc5 ------------------- * Tue May 29 2007 Rex Dieter 5.12.0-3 - ExclusiveArch: %ix86 -> i386 (for koji) * Tue May 29 2007 Rex Dieter 5.12.0-2 - respin for sbcl-1.0.6 * Thu May 03 2007 Rex Dieter 5.12.0-1 - maxima-5.12.0 * Mon Apr 30 2007 Rex Dieter 5.11.99-0.4.rc3 - maxima-5.11.99rc3 * Sun Apr 29 2007 Rex Dieter 5.11.99-0.3.rc2 - fix sbcl/ppc build (#238376) * Sun Apr 29 2007 Rex Dieter 5.11.99-0.1.rc2 - maxima-5.11.99rc2 mozldap-6.0.4-1.fc5 ------------------- * Wed Jun 20 2007 Rich Megginson - 6.0.4-1 - bump version to 6.0.4 - this version has some memory leak - fixes for SASL related code, fixes for control handling with - referral chasing, and packaging improvements - use -p when installing include files to preserve timestamps * Thu May 24 2007 Rich Megginson - 6.0.3-3 - We only need cyrus-sasl-devel as a BuildRequires in the main package * Mon May 21 2007 Rich Megginson - 6.0.3-2 - added cyrus-sasl-devel and pkgconfig to devel package Requires * Tue Mar 13 2007 Rich Megginson - 6.0.3-1 - bumped version to 6.0.3 - minor build fixes for some platforms pcb-0.20070208-2.fc5 -------------------- * Thu Jun 21 2007 Chitlesh Goorah - 0.20070208-2 - fixed docdir * Fri Feb 09 2007 Chitlesh Goorah - 0.20070208-1 - New upstream release - 20070208 perl-Mozilla-LDAP-1.5.1-1.fc5 ----------------------------- * Wed Jun 20 2007 Rich Megginson - 1.5.1-1 - all files have been GPL/LGPL/MPL tri-licensed puppet-0.23.0-1.fc5 ------------------- * Wed Jun 20 2007 David Lutterkort - 0.23.0-1 - Install one puppet.conf instead of old config files, keep old configs around to ease update - Use plain shell commands in install instead of macros PyKDE-3.16.0-5.fc5 ------------------ * Thu Nov 09 2006 Rex Dieter 3.16.0-5 - kmimetype patch - devel: Requires: sip-devel pypar2-1.4-1.fc5 ---------------- * Tue Apr 24 2007 Maxime Carron - 1.4-1 - approve Chitlesh's proposal sbcl-1.0.6-1.fc5 ---------------- * Tue May 29 2007 Rex Dieter 1.0.6-1 - sbcl-1.0.6 * Sun Apr 29 2007 Rex Dieter 1.0.5-1 - sbcl-1.0.5 * Mon Apr 09 2007 Rex Dieter 1.0.4-2 - re-enable threading support (#235644) * Mon Mar 26 2007 Rex Dieter 1.0.4-1 - sbcl-1.0.4 * Wed Feb 28 2007 Rex Dieter 1.0.3-1 - sbcl-1.0.3 texmaker-1.6-2.fc5 ------------------ * Thu Jun 21 2007 Deji Akingunola - 1:1.6-2.fc5 - Change default dvi viewer back to xdvi, and require tetex-xdvi for it * Thu Jun 21 2007 Deji Akingunola - 1:1.6-1.fc5 - New Release tmda-1.1.11-4.fc5 ----------------- * Wed Jun 20 2007 Bernard Johnson 1.1.11-4 - assign package uid * Fri Apr 06 2007 Bernard Johnson 1.1.11-3 - remove versioned python dependencies, no supported python is unsupported - if compiling for EL-4, compile python since there is no brp-python-bytecompile * Thu Mar 01 2007 Bernard Johnson 1.1.11-2 - fix source0 line For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at redhat.com Fri Jun 22 09:40:57 2007 From: buildsys at redhat.com (Build System) Date: Fri, 22 Jun 2007 05:40:57 -0400 Subject: rawhide report: 20070622 changes Message-ID: <200706220940.l5M9evt2009742@porkchop.devel.redhat.com> New package grig A Ham Radio Control graphical user interface New package matchbox-window-manager Window manager for the Matchbox Desktop New package mecab-java Java binding for MeCab New package presto-utils Tools for creating presto repositories New package pybackpack User oriented backup and restore application Updated Packages: Inventor-2.1.5-28.fc8 --------------------- * Thu Jun 21 2007 Ralf Cors??pius - 2.1.5-28 - ExcludeArch: ppc64 (BZ: 245192). * Thu Jun 21 2007 Ralf Cors??pius - 2.1.5-27 - Add *-27.patch. - Remove _ia64 grep (Incorporated into *-27.diff). - Add powerpc64 hack. NetworkManager-1:0.6.5-6.1.fc8 ------------------------------ * Thu Jun 21 2007 Dan Williams 1:0.6.5-6 - Update to stable branch snapshot: - More fixes for ethernet link detection (gnome #354565, rh #194124) - Support for HAL-detected rfkill switches * Sun Jun 10 2007 Dan Williams 1:0.6.5-5 - Fix applet crash on 64-bit platforms when choosing "Connect to other wireless network..." (gnome.org #435036) - Add debug output for ethernet device link changes * Thu Jun 07 2007 Dan Williams 1:0.6.5-4 - Fix ethernet link detection (gnome #354565, rh #194124) - Fix perpetual credentials request with private key passwords in the applet - Sleep a bit before activating wireless cards to work around driver bugs OpenSceneGraph-1.2-4.fc8 ------------------------ * Thu Jun 21 2007 Ralf Cors??pius - 1.2-4 - ExcludeArch: ppc64 (BZ 245192, 245196). * Thu Jun 21 2007 Ralf Cors??pius - 1.2-3 - Remove demeter (Defective, abandoned by upstream). amanda-2.5.2p1-1.fc8 -------------------- * Thu Jun 21 2007 Radek Brich 2.5.2.p1-1 - New upstream version. - Client rpm now installs amanda-client.conf. - Removed obsolete patches -bug18322 and -rsh. - Clean up spec file (non-utf8 error and some warnings from rpmlint). * Mon Feb 19 2007 Jay Fenlason 2.5.1p3-1.fc8 - Upgrade to new upstream release, now that 2.5.1 is somewhat stable. - Note that this requires changing the xinetd configuration and amanda.conf because of the new authentication mechanism. - -server subpackage does not require xinetd. - -server scriptlets do not need to reload xinetd. * Mon Sep 25 2006 Jay Fenlason 2.5.0p2-4 - Include my -dump_size patch to close bz#206129: Dump output size determined incorrectly - Clean up the spec file, following some suggestions in bz#185659: amanda 2.5.0 - Use a tarball without the problematic contrib/sst directory. - Include my new_gnutar (based on a patch by Orion Poplawski ) to work around changed incremental file format in newer (>1.15.1) versions of gnutar. - include my -wildcards patch to turn on wildcards with new versions of tar. cegui-0.5.0b-3.fc8 ------------------ * Sun Jun 17 2007 Ian Chapman 0.5.0b-3.fc8 - rpath fixes for x86_64 * Sun Jun 10 2007 Ian Chapman 0.5.0b-2.fc8 - Added patch to fix undefined-non-weak-symbol warnings * Wed May 30 2007 Ian Chapman 0.5.0b-1.fc8 - Upgrade to 0.5.0b - Added patch from Gentoo to compile with lua 5.1 - Updated the patch to use versioned .so for dlopen() - Dropped several patches as they are no longer needed - Dropped useless provides. Nothing used them anyway - Added support for the SILLY image codec - Added support for xerces-c charis-fonts-4.100-2.fc8 ------------------------ * Thu Jun 21 2007 Nicolas Mailhot ??? 4.100-2 ??? Fix URL (bug #245101) control-center-1:2.19.4-4.fc8 ----------------------------- * Thu Jun 21 2007 Matthias Clasen - 2.19.4-4 - Fix starting of screensavers coolkey-1.1.0-3.1.fc8 --------------------- * Thu Jun 21 2007 Kai Engert - 1.1.0-3.1 - rebuild crystal-clear-20050622-5.fc8 ---------------------------- * Thu Jun 21 2007 Chitlesh Goorah 20050622-5 - fixed url: # 245106 dvd+rw-tools-7.0-4.fc8 ---------------------- * Thu Jun 21 2007 Harald Hoyer - 7.0-4 - fixed exit status (#243036) - Allow session to cross 4GB boundary regardless of medium type. Add a -F option (used instead of -M or -Z), which displays next_session offset and capacity. (#237967) * Tue Feb 27 2007 Harald Hoyer - 7.0-3 - fixed specfile issues (#209985) * Thu Dec 14 2006 Harald Hoyer - 7.0-0.4 - set pthread stack size according to limit (#215818) fail2ban-0.8.0-9.fc8 -------------------- * Thu Jun 21 2007 Axel Thimm - 0.8.0-9 - Fix remote log injection (no CVE assignment yet). gdb-6.6-17.fc8 -------------- * Thu Jun 21 2007 Jan Kratochvil - 6.6-17 - Support for stepping over PPC atomic instruction sequences (BZ 237572). - `set scheduler-locking step' is no longer enforced but it is now default. geomview-1.9.3-1.fc8 -------------------- * Thu Jun 21 2007 Rex Dieter 1.9.3-1 - geomview-1.9.3 glibmm24-2.13.6-2.fc8 --------------------- * Fri Jun 22 2007 Denis Leroy - 2.13.6-2 - Moved documentation to devhelp directory * Thu Jun 21 2007 Denis Leroy - 2.13.6-1 - Update to unstable 2.13 tree to follow glib2 version gtk2-engines-2.11.2-2.fc8 ------------------------- * Thu Jun 21 2007 Matthias Clasen - 2.11.2-2 - Make the new tooltip api yellow, too kanatest-0.4.2-2.fc8 -------------------- * Thu Jun 21 2007 Robert Marcano - 0.4.2-2 - Update to upstream release 0.4.2 - Bug 245177 - URL changed - Bug 245177 kdebase-6:3.5.7-5.fc8 --------------------- * Wed Jun 20 2007 Rex Dieter - 6:3.5.7-5 - Provides: kdebase3(-devel) koffice-1.6.3-6.fc8 ------------------- * Thu Jun 21 2007 Rex Dieter 1.6.2-6 - use simpler NoDisplay=True hack (workaround #245190) - disable (kross)ruby on rawhide (for now) * Wed Jun 20 2007 Rex Dieter 1.6.2-5 - mark applnk/.hidden/*.desktop NoDisplay=True instead (#245061) * Fri Jun 15 2007 Rex Dieter 1.6.2-3 - (really) require version of kdelibs used to build against (#244091) kudzu-1.2.71.1-1 ---------------- * Mon Jun 04 2007 Bill Nottingham - 1.2.71.1-1 - fix the hpt special cases (#242270, ) libmusicbrainz-2.1.5-1.fc8 -------------------------- * Thu Jun 21 2007 - Bastien Nocera - 2.1.5-1 - Update to 2.1.5 libselinux-2.0.22-1.fc8 ----------------------- * Thu Jun 21 2007 Dan Walsh - 2.0.22-1 - Upgrade to upstream * Labeling and callback interface patches from Eamon Walsh. * Tue Jun 19 2007 Dan Walsh - 2.0.21-2 - Refactored swig libsepol-2.0.4-1.fc8 -------------------- * Thu Jun 21 2007 Dan Walsh 2.0.4-1 - Upgrade to latest from NSA * Merged error handling patch from Eamon Walsh. magic-7.4.35-2.fc8 ------------------ * Thu Jun 21 2007 Chitlesh Goorah - 7.4.35-2 - fix desktop file #241443 marble-0.3.1-4.fc8 ------------------ * Thu Jun 21 2007 Chitlesh Goorah 0.3.1-4 - fix for ppc64 mash-0.1.18-1.fc8 ----------------- * Thu Jun 21 2007 Bill Nottingham 0.1.18-1 - pull in cyrus-sasl plugins (#245176) nip2-7.12.0-1.fc8 ----------------- * Sat May 05 2007 Adam Goode - 7.12.0-1 - New upstream release - Update desktop file - Remove X-Fedora category ntp-4.2.4p2-1.fc8 ----------------- * Thu Jun 21 2007 Miroslav Lichvar 4.2.4p2-1 - update to 4.2.4p2 opensc-0.11.3-0.1.pre1.fc8 -------------------------- * Thu Jun 21 2007 Ville Skytt?? - 0.11.3-0.1.pre1 - 0.11.3-pre1. opensp-1.5.2-5.fc8 ------------------ * Thu Jun 21 2007 Ondrej Vasik 1.5.2-5 - fixed SIGSEGV (bug #245104) pcb-0.20070208-2.fc8 -------------------- * Thu Jun 21 2007 Chitlesh Goorah - 0.20070208-2 - fixed docdir * Fri Feb 09 2007 Chitlesh Goorah - 0.20070208-1 - New upstream release - 20070208 pcmciautils-014-9.fc8 --------------------- * Thu Jun 21 2007 Harald Hoyer - 014-9 - fixed modprobe udev rule policycoreutils-2.0.22-1.fc8 ---------------------------- * Thu Jun 21 2007 Dan Walsh 2.0.22-1 - Update to match NSA * Rebase setfiles to use new labeling interface. puppet-0.23.0-1.fc8 ------------------- * Wed Jun 20 2007 David Lutterkort - 0.23.0-1 - Install one puppet.conf instead of old config files, keep old configs around to ease update - Use plain shell commands in install instead of macros python-2.5.1-2.fc8 ------------------ * Thu Jun 21 2007 Jeremy Katz - 2.5.1-2 - rebuild to take advantage of hardlinking between identical pyc/pyo files * Thu May 31 2007 Jeremy Katz - 2.5.1-1 - update to python 2.5.1 * Mon Mar 19 2007 Jeremy Katz - 2.5.3-12 - fix alpha build (#231961) python-genshi-0.4.2-1.fc8 ------------------------- * Thu Jun 21 2007 Jeffrey C. Ollie - 0.4.2-1 - Update to 0.4.2 scim-1.4.6-6.fc8 ---------------- * Fri Jun 22 2007 Jens Petersen - 1.4.6-6 - make Cangjie3 the default input method for Hong Kong and disable Cangjie by default instead of Cangjie3 and Cangjie5 (Roy Chan, #245121) * Thu Jun 21 2007 Jens Petersen - 1.4.6-5 - add scim-lang-* meta packages to aid yum package group handling of scim core packages so they no longer need to be installed by default * Tue Jun 05 2007 Jens Petersen - 1.4.6-4 - drop scim_panel_gtk-settle-toolbar-after-drag.patch since it interferes with user toolbar placement (reported by Ryo Dairiki, #242610) scummvm-0.10.0-1.fc8 -------------------- * Thu Jun 21 2007 Matthias Saou 0.10.0-1 - Update to 0.10.0, since Hans is away for a few days ;-) - Install icons the same way as the theme, and preserve timestamps. - Use a downloads.sf.net source URL. - Remove two no longer needed patches (gcc41 and new-flac). smartmontools-1:5.37-4.fc8 -------------------------- * Thu Jun 21 2007 Tomas Smetana - 1:5.37-4 - fix #241389 - smartd-conf.py pulls in a big dependency chain, so build a separate config package texmaker-1:1.6-2.fc8 -------------------- * Thu Jun 21 2007 Deji Akingunola - 1:1.6-2.fc8 - Change default dvi viewer back to xdvi, and require tetex-xdvi for it * Thu Jun 21 2007 Deji Akingunola - 1:1.6-1.fc8 - New Release vips-7.12.0-1.fc8 ----------------- * Sat May 05 2007 Adam Goode - 7.12.0-1 - New upstream release xchat-1:2.8.2-11.fc8 -------------------- * Thu Jun 21 2007 Kevin Kofler - 1:2.8.2-11 - add missing BR desktop-file-utils * Thu Jun 21 2007 Kevin Kofler - 1:2.8.2-10 - remove Application; and X-Red-Hat-Extras; categories from .desktop file (merge review #226551) - install the .desktop file properly (merge review #226551) yum-3.2.1-1.fc8 --------------- * Thu Jun 21 2007 Seth Vidal - 3.2.1-1 - bump to 3.2.1 * Wed May 16 2007 Seth Vidal - 3.2.0-1 - pull out yum-misc-fixes patch - bump to 3.2.0 * Mon Apr 30 2007 Jeremy Katz - 3.1.7-2 - add fix for fastestmirror (#238276) Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From nicolas.mailhot at laposte.net Fri Jun 22 07:45:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 22 Jun 2007 09:45:34 +0200 (CEST) Subject: Fedora 8 internet keys support detailed plan + patches In-Reply-To: References: <1182454920.32315.59.camel@rousalka.dyndns.org> Message-ID: <57398.192.54.193.51.1182498334.squirrel@rousalka.dyndns.org> Le Ven 22 juin 2007 00:16, Goede, J.W.R. de a ?crit : > In the case of userspace > using evdev then there is nothing to emulate though, as the > kernel then directly exports all features of the hardware > as it sees them. You still need to fix the quirks of keyboards that do not follow the microsoft spec > Or are you talking about emulating a microsoft multimedia > keys having ps/2 keyboard, in that case I gully agree, and > so thus upstream as that is what they are already doing. I'm talking about emulating a microsoft multimedia keys having usb keyboard as presented by the kernel, as the kernel handling of microsoft P2/2 keyboards is not 100% correct. > There is no such thing as a target keyboard. Target physical device is always nice as it helps to check assumptions. I wouldn't assume the ms spec is complete or 100% correct. MS keyboards are the closest thing we have to reference hardware. > Fedora currently is using the Xorg keyboard driver, not > evdev. Since AFAIK there are no plans to change that for > F-8 and I want to see this fixed before F-8, I don't think > that switching to evdev is a good idea, too much work, too > much chances for regressions, little short term gain. Upstream (and let be honest, a huge part of input upstream is at Suse) has been focusing its efforts on evdev. I don't think it's wise to pour efforts somewhere else. You've been plainly told evdev is were linux input is going. Did you even try evdev in rawhide? Just switching to evdev fixed 3/4 of my extended keys. Also evdev is pretty much a requirement for a lot of usb keyboards, were extended keys hang from several usb devices and kbd only looks at the first device. > Yes, no matter how e get X to send the correct X-keysyms > for internet keys, we still need to fix the apps. So lets > take a minimal effort approach to getting X to send the > correct jeysyms and then focus on fixing the apps. Right now the old way of sending X-keysyms is so full of quirks and warts I really don't hink minimal effort would be to try to fix it. > if the user wants to binf this keysym to something > other then search, thats fine, just like the user can make > the 'a' key always launch an xterm when pressed. IOW, what > does this have todo with anything? If user = technical person that's true If user = someone who expects to find a remapping app like the ones provided with every single extended input devices under windows that's wrong. The closest we have is the GNOME keybinding app which 1. only handles GNOME-wide keybindings 2. only handles one accel per action (ie selecting a new accel kills the old one) -- Nicolas Mailhot From laroche at redhat.com Fri Jun 22 10:55:43 2007 From: laroche at redhat.com (Florian La Roche) Date: Fri, 22 Jun 2007 12:55:43 +0200 Subject: Fedora development tree and "athlon" Message-ID: <20070622105543.GA16563@dudweiler.stuttgart.redhat.com> I assume these will be removed over time again once newer rpms are pushed. They should be leftovers from some buildsystem typo: [laroche at dudweiler Fedora]$ ls *.athlon.rpm beagle-0.2.17-1.fc8.athlon.rpm mono-data-1.2.4-1.fc8.athlon.rpm mono-locale-extras-1.2.4-1.fc8.athlon.rpm beagle-evolution-0.2.17-1.fc8.athlon.rpm mono-data-firebird-1.2.4-1.fc8.athlon.rpm mono-nunit-1.2.4-1.fc8.athlon.rpm beagle-gui-0.2.17-1.fc8.athlon.rpm mono-data-oracle-1.2.4-1.fc8.athlon.rpm mono-nunit-devel-1.2.4-1.fc8.athlon.rpm bytefx-data-mysql-1.2.4-1.fc8.athlon.rpm mono-data-postgresql-1.2.4-1.fc8.athlon.rpm mono-web-1.2.4-1.fc8.athlon.rpm ibm-data-db2-1.2.4-1.fc8.athlon.rpm mono-data-sqlite-1.2.4-1.fc8.athlon.rpm mono-winforms-1.2.4-1.fc8.athlon.rpm libbeagle-0.2.17-1.fc8.athlon.rpm mono-data-sybase-1.2.4-1.fc8.athlon.rpm oprofile-0.9.2-9.fc8.athlon.rpm libbeagle-devel-0.2.17-1.fc8.athlon.rpm mono-devel-1.2.4-1.fc8.athlon.rpm oprofile-devel-0.9.2-9.fc8.athlon.rpm libbeagle-python-0.2.17-1.fc8.athlon.rpm mono-extras-1.2.4-1.fc8.athlon.rpm oprofile-gui-0.9.2-9.fc8.athlon.rpm mono-core-1.2.4-1.fc8.athlon.rpm mono-jscript-1.2.4-1.fc8.athlon.rpm tomboy-0.7.1-1.fc8.athlon.rpm [laroche at dudweiler Fedora]$ regards, Florian La Roche From martin.sourada at seznam.cz Fri Jun 22 11:11:18 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 22 Jun 2007 13:11:18 +0200 Subject: CodecBuddy - fluendo only? Message-ID: <1182510678.3080.22.camel@pc-notebook> Hi, I read about the CodecBuddy spesc on wiki and was a little shocked when I have found that it would suggest as a solution to missing codecs only the fluendo web site. I am well aware that in the US there is no other way how to get these codes legally but in most of the EU (and maybe even in most of the world) it is legal (AFAIK) to install the codecs provided by livna/freshrpms/{insert your favourite third party repo} and I think that installing well maintained rpm is a better way than untaring some binary libraries to /usr/lib... Is there any reason why not to point the users from software-patent-free countries to this solution? IMHO it could be made like an another option like this: "If you are in a country where software patents does not exist you can legally install the codecs from third party repo via yum. Click here for more info." Or something like this to not cause legal problems in the US and provide (IMHO) better option for users from the EU. At least for the codecs that are in the gstreamer-plugins-{ugly;bad} packages. Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at lovesunix.net Fri Jun 22 11:23:22 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 22 Jun 2007 13:23:22 +0200 Subject: CodecBuddy - fluendo only? In-Reply-To: <1182510678.3080.22.camel@pc-notebook> References: <1182510678.3080.22.camel@pc-notebook> Message-ID: <1182511402.10318.10.camel@dawkins> fre, 22 06 2007 kl. 13:11 +0200, skrev Martin Sourada: > Hi, > > I read about the CodecBuddy spesc on wiki and was a little shocked when > I have found that it would suggest as a solution to missing codecs only > the fluendo web site. I am well aware that in the US there is no other > way how to get these codes legally but in most of the EU (and maybe even > in most of the world) it is legal (AFAIK) to install the codecs provided > by livna/freshrpms/{insert your favourite third party repo} and I think > that installing well maintained rpm is a better way than untaring some > binary libraries to /usr/lib... > > Is there any reason why not to point the users from software-patent-free > countries to this solution? IMHO it could be made like an another option > like this: "If you are in a country where software patents does not > exist you can legally install the codecs from third party repo via yum. > Click here for more info." Or something like this to not cause legal > problems in the US and provide (IMHO) better option for users from the > EU. At least for the codecs that are in the gstreamer-plugins-{ugly;bad} > packages. I think it's sanest to leave this one to Red Hat Legal to give a recommendation on this and document it extensively on the wiki to avoid causing a massive flamewar over an issue that really requires the sutle touch of a lawyer. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From ffesti at redhat.com Fri Jun 22 11:30:24 2007 From: ffesti at redhat.com (Florian Festi) Date: Fri, 22 Jun 2007 13:30:24 +0200 Subject: Fedora 8 internet keys support detailed plan + patches In-Reply-To: <57398.192.54.193.51.1182498334.squirrel@rousalka.dyndns.org> References: <1182454920.32315.59.camel@rousalka.dyndns.org> <57398.192.54.193.51.1182498334.squirrel@rousalka.dyndns.org> Message-ID: <467BB2D0.9070708@redhat.com> Relax everyone! This topic is too complicated that any of us has a chance of knowing all problems yet. All efforts that make sure that hardware key presses are mapped to the right kernel keycodes are highly appreciated (laptops, PS/2 keyboards, USB keyboards). Btw I have written some scripts to convert keyboard setting from various sources into setkeycodes scripts (or anything else) including hotkey-setup, lineak, keytouch. They are currently checked into the hotkey-setup repository: https://developer.berlios.de/projects/hotkey-setup/ http://svn.berlios.de/wsvn/hotkey-setup/trunk/tools/?rev=0&sc=0 If this works the linux kernel will only show one kind of keyboard to both console and X11. And it doesn't matter much if this is called the linux or the Microsoft keyboard. As Nicolas already stated the AT keyboard emulation as used by the X11 kbd driver (setting the console to raw mode) has a limitation to 240 keys. Problem here is that the linux kernel has a lot of key codes that are out of range (see linux/input.h 0x160 up). These cannot mapped consistently into the 240 key range of the emulation. Because of this X11 has to switch to the evdev driver in the long run. Any work in this direction is appreciated. Nevertheless this might not be the right step for F8 as evdev wasn't in good shape when I looked at it 7 months ago. Things are even worse as on the X11 side there are no Xkeysyms to map lots of the kernel keysyms to. I put together a list half a year ago. They can be found at the bottom of http://fedoraproject.org/wiki/SIGs/Laptop/HotKeys. Don't give too much an the other text on the page. Nicolas Mailhot wrote: > Right now the old way of sending X-keysyms is so full of quirks and > warts I really don't hink minimal effort would be to try to fix it. Patching the xkbd map shouldn't be too much effort for the time until we switched really everything to the evdev driver. > Note: Stanislav Brabec who created /usr/share/X11/xkb/symbols/inet is > currently working on an xkb patch which will create a virtual linux > keyboard model. Have you any pointers? I have the model already finished (mostly)... Florian Festi From yaneti at declera.com Fri Jun 22 11:43:59 2007 From: yaneti at declera.com (Yanko Kaneti) Date: Fri, 22 Jun 2007 14:43:59 +0300 Subject: additional *-python splits Message-ID: <1182512639.7069.5.camel@indigo.declera.com> Hi, Before wrestling with bugzilla, I'd like to ask if there are any objections to further splitting of *-python subpackages for some core libraries. It would make removing python on a minimal install less painful. Three patches for libsemanage, newt and libuser attached. Yanko -------------- next part -------------- A non-text attachment was scrubbed... Name: libsemanage.spec-python.diff Type: text/x-patch Size: 1569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libuser.spec-python.diff Type: text/x-patch Size: 1538 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newt.spec-python.diff Type: text/x-patch Size: 1634 bytes Desc: not available URL: From laurent.rineau__fedora at normalesup.org Fri Jun 22 13:28:37 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Fri, 22 Jun 2007 15:28:37 +0200 Subject: Please unpush a package for me from Bohdi. Message-ID: <200706221528.37100@rineau.tsetse> I change changed the email address of my Fedora account. As a side effect, I am not longer considered as the owner of my package in updates-testing, in Bodhi. Can a Bodhi admin *unpush* the following package for me: https://admin.fedoraproject.org/updates/testing/F7/CGAL-3.3-3.fc7 CGAL-3.3-4.fc7 has already been pushed in updates, as a bug fix of CGAL-3.3-3.fc7. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From mackay_d at bellsouth.net Fri Jun 22 12:31:06 2007 From: mackay_d at bellsouth.net (David G. Mackay) Date: Fri, 22 Jun 2007 07:31:06 -0500 Subject: 586 kernels. In-Reply-To: <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> Message-ID: <1182515466.14270.4.camel@vorpal.macdev.com> On Thu, 2007-06-21 at 08:39 -0800, Jeff Spaleta wrote: > On 6/21/07, Dave Jones wrote: > > http://smolt.fedoraproject.org > > > we have to be somewhat careful with regard to interpreting smolt stats > for fine-grained decision making, especially since f7 is the first > release with it available by default. When I installed F7 on the AMD-K6 that I use for a firewall/router, I did a text mode install and didn't install X at all. I don't recall being given the opportunity to contribute to the smolt stats. Dave From jkeating at redhat.com Fri Jun 22 13:58:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 09:58:12 -0400 Subject: Fedora development tree and "athlon" In-Reply-To: <20070622105543.GA16563@dudweiler.stuttgart.redhat.com> References: <20070622105543.GA16563@dudweiler.stuttgart.redhat.com> Message-ID: <200706220958.12536.jkeating@redhat.com> On Friday 22 June 2007 06:55:43 Florian La Roche wrote: > I assume these will be removed over time again once > newer rpms are pushed. yes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 22 13:59:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 09:59:09 -0400 Subject: additional *-python splits In-Reply-To: <1182512639.7069.5.camel@indigo.declera.com> References: <1182512639.7069.5.camel@indigo.declera.com> Message-ID: <200706220959.09183.jkeating@redhat.com> On Friday 22 June 2007 07:43:59 Yanko Kaneti wrote: > Before wrestling with bugzilla, I'd like to ask if there are any > objections to further splitting of *-python subpackages for some core > libraries. It would make removing python on a minimal install less > painful. Is your minimal install not going to include yum? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 22 14:01:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 10:01:37 -0400 Subject: Please unpush a package for me from Bohdi. In-Reply-To: <200706221528.37100@rineau.tsetse> References: <200706221528.37100@rineau.tsetse> Message-ID: <200706221001.38076.jkeating@redhat.com> On Friday 22 June 2007 09:28:37 Laurent Rineau wrote: > I change changed the email address of my Fedora account. As a side effect, > I am not longer considered as the owner of my package in updates-testing, > in Bodhi. Can a Bodhi admin *unpush* the following package for me: > https://admin.fedoraproject.org/updates/testing/F7/CGAL-3.3-3.fc7 > CGAL-3.3-4.fc7 has already been pushed in updates, as a bug fix of > CGAL-3.3-3.fc7. > Done. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Fri Jun 22 14:13:40 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 22 Jun 2007 09:13:40 -0500 Subject: additional *-python splits In-Reply-To: <200706220959.09183.jkeating@redhat.com> References: <1182512639.7069.5.camel@indigo.declera.com> <200706220959.09183.jkeating@redhat.com> Message-ID: <1182521620.3801.3.camel@lt21223.campus.dmacc.edu> On Fri, 2007-06-22 at 09:59 -0400, Jesse Keating wrote: > On Friday 22 June 2007 07:43:59 Yanko Kaneti wrote: > > Before wrestling with bugzilla, I'd like to ask if there are any > > objections to further splitting of *-python subpackages for some core > > libraries. It would make removing python on a minimal install less > > painful. > > Is your minimal install not going to include yum? I can think of an example where I wouldn't need/want yum or even RPM... Building custom Live{CD,USBKey,CF,SD,etc} for appliances like a firewall or a media device. You wouldn't need yum or RPM because you would update the software by rolling a new live image. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From yaneti at declera.com Fri Jun 22 14:19:26 2007 From: yaneti at declera.com (Yanko Kaneti) Date: Fri, 22 Jun 2007 17:19:26 +0300 Subject: additional *-python splits In-Reply-To: <200706220959.09183.jkeating@redhat.com> References: <1182512639.7069.5.camel@indigo.declera.com> <200706220959.09183.jkeating@redhat.com> Message-ID: <1182521966.7069.13.camel@indigo.declera.com> On Fri, 2007-06-22 at 09:59 -0400, Jesse Keating wrote: > On Friday 22 June 2007 07:43:59 Yanko Kaneti wrote: > > Before wrestling with bugzilla, I'd like to ask if there are any > > objections to further splitting of *-python subpackages for some core > > libraries. It would make removing python on a minimal install less > > painful. > > Is your minimal install not going to include yum? rpm based distributions have been known to be usable even without yum ;) yum-less install of F7 can be achieved the usual way by unchecking everything when the installer asks you for package selection. From jkeating at redhat.com Fri Jun 22 14:14:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 10:14:36 -0400 Subject: additional *-python splits In-Reply-To: <1182521966.7069.13.camel@indigo.declera.com> References: <1182512639.7069.5.camel@indigo.declera.com> <200706220959.09183.jkeating@redhat.com> <1182521966.7069.13.camel@indigo.declera.com> Message-ID: <200706221014.36989.jkeating@redhat.com> On Friday 22 June 2007 10:19:26 Yanko Kaneti wrote: > On Fri, 2007-06-22 at 09:59 -0400, Jesse Keating wrote: > > On Friday 22 June 2007 07:43:59 Yanko Kaneti wrote: > > > Before wrestling with bugzilla, I'd like to ask if there are any > > > objections to further splitting of *-python subpackages for some core > > > libraries. It would make removing python on a minimal install less > > > painful. > > > > Is your minimal install not going to include yum? > > rpm based distributions have been known to be usable even without yum ;) > > yum-less install of F7 can be achieved the usual way by unchecking > everything when the installer asks you for package selection. I didn't say it was impossible, just curious (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jun 22 14:22:39 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Jun 2007 16:22:39 +0200 Subject: additional *-python splits In-Reply-To: <200706220959.09183.jkeating@redhat.com> References: <1182512639.7069.5.camel@indigo.declera.com> <200706220959.09183.jkeating@redhat.com> Message-ID: <20070622162239.34dd18b7@python3.es.egwn.lan> Jesse Keating wrote : > On Friday 22 June 2007 07:43:59 Yanko Kaneti wrote: > > Before wrestling with bugzilla, I'd like to ask if there are any > > objections to further splitting of *-python subpackages for some core > > libraries. It would make removing python on a minimal install less > > painful. > > Is your minimal install not going to include yum? FWIW, the last Fedora minimal install I made (unselecting "Base") did not include yum. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.36 0.42 0.35 From bpepple at fedoraproject.org Fri Jun 22 14:28:50 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 22 Jun 2007 10:28:50 -0400 Subject: FESCo Meeting Summary for 2007-06-21 Message-ID: <1182522530.2808.1.camel@kennedy> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Rex Dieter (rdieter) * Christian Iseli (c4chris) * Warren Togami (warren) * Josh Boyer (jwb) Members Absent * Tom Callaway (spot) == Summary == FPC Static Lib Policy Change Proposal * FESCo had no objects to the Fedora Packaging Committee's proposal for a blanket exception for linking against libraries that are only available as static, and the initialCC requirement. For more information please refer to: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges New Sponsors * FESCo approved the sponsor nomination requests for Xavier Lamien and Dominik Mierzejewski. * bpepple was upgraded to an admin in the cvsextras group, so that he can handle the account upgrading of new sponsors. Including binary firmware for the Libertas usb8488 * FESCo approved the OLPC request to include the binary firmware for the Libertas usb8488. Bodhi Updates-Testing Autopush * FESCo asked for the QA & rel-eng teams to work on a proposal for autopromoting of updates. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070621 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Fri Jun 22 14:38:53 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 22 Jun 2007 10:38:53 -0400 Subject: 586 kernels. In-Reply-To: <1182515466.14270.4.camel@vorpal.macdev.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <20070621163106.GD29060@redhat.com> <604aa7910706210939i3ea03bc6ob19ca50b97a199f6@mail.gmail.com> <1182515466.14270.4.camel@vorpal.macdev.com> Message-ID: <20070622143853.GA9924@jadzia.bu.edu> On Fri, Jun 22, 2007 at 07:31:06AM -0500, David G. Mackay wrote: > > we have to be somewhat careful with regard to interpreting smolt stats > > for fine-grained decision making, especially since f7 is the first > > release with it available by default. > When I installed F7 on the AMD-K6 that I use for a firewall/router, I > did a text mode install and didn't install X at all. I don't recall > being given the opportunity to contribute to the smolt stats. Good point -- this means the data is inherently skewed against lower-powered CPUs. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From harald at redhat.com Fri Jun 22 15:18:54 2007 From: harald at redhat.com (Harald Hoyer) Date: Fri, 22 Jun 2007 17:18:54 +0200 Subject: Parallel Booting Message-ID: <467BE85E.4070807@redhat.com> Hello, some of you may have read some wiki pages about the plans for the new init system [1]. As a first step in this direction [2], I packaged prcsys from Mandriva, patched initscripts with a very small patch, and uploaded the src.rpm to [3]. To enable parallel booting just build and install both packages and edit /etc/sysconfig/init. Set PARALLEL_STARTUP=yes and there we go. The next step would be to modify all initscripts in /etc/init.d to be LSB compliant [4]. This will speed up booting, because they can and will be started in parallel. You should file bugzillas against the component, to which this initscript belongs, with a patch (this has to be done anyway to be LSB compliant in regards to initscripts over time). Especially the exit codes need to be fixed (which will make status queries a lot easier and more robust). Early login [5] is also a next step towards a "fast boot" user experience. Alternatives to SysVInit (like upstart/initng) can live in Fedora as well, but we are very conservative in changing the startup mechanism that proved to function for a long time now. Unless the "real" killer feature is absolutly needed, we would like to keep backwards compatibility as long as possible. I hope many of you try and test [3] and write patches to improve our service initscripts to be LSB compliant :-) Parallel booting is the reward. Happy testing, Harald [1] http://fedoraproject.org/wiki/FCNewInit [2] http://fedoraproject.org/wiki/FCNewInit/RC [3] http://people.redhat.com/harald/downloads/initscripts/parallel/ [4] http://fedoraproject.org/wiki/FCNewInit/Initscripts [5] http://fedoraproject.org/wiki/FCNewInit/xdm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From drago01 at gmail.com Fri Jun 22 15:23:11 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 22 Jun 2007 17:23:11 +0200 Subject: Parallel Booting In-Reply-To: <467BE85E.4070807@redhat.com> References: <467BE85E.4070807@redhat.com> Message-ID: <467BE95F.4070404@gmail.com> Harald Hoyer wrote: > > I hope many of you try and test [3] and write patches to improve our > service initscripts to be LSB compliant > :-) Parallel booting is the reward. for testing an empty dir ? ;) From harald at redhat.com Fri Jun 22 15:38:46 2007 From: harald at redhat.com (Harald Hoyer) Date: Fri, 22 Jun 2007 17:38:46 +0200 Subject: Parallel Booting In-Reply-To: <467BE95F.4070404@gmail.com> References: <467BE85E.4070807@redhat.com> <467BE95F.4070404@gmail.com> Message-ID: <467BED06.9030904@redhat.com> dragoran schrieb: > Harald Hoyer wrote: >> >> I hope many of you try and test [3] and write patches to improve our >> service initscripts to be LSB compliant >> :-) Parallel booting is the reward. > for testing an empty dir ? ;) > fixed :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Fri Jun 22 16:12:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Jun 2007 12:12:40 -0400 Subject: additional *-python splits In-Reply-To: <1182512639.7069.5.camel@indigo.declera.com> References: <1182512639.7069.5.camel@indigo.declera.com> Message-ID: <20070622161240.GC4649@nostromo.devel.redhat.com> Yanko Kaneti (yaneti at declera.com) said: > Before wrestling with bugzilla, I'd like to ask if there are any > objections to further splitting of *-python subpackages for some core > libraries. It would make removing python on a minimal install less > painful. > > Three patches for libsemanage, newt and libuser attached. Does this include patches for packages that need their Requires: changed? Bill From root at martin-papadopoulos.de Fri Jun 22 18:45:20 2007 From: root at martin-papadopoulos.de (Martin Papadopoulos) Date: Fri, 22 Jun 2007 20:45:20 +0200 Subject: mod_ruby Message-ID: <467C18C0.1010402@martin-papadopoulos.de> are there any plans to integrate mod_ruby into fedora 8 ? ist there a doc on how to get mod_ruby working with f7+apache ? greetz mpa -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From yaneti at declera.com Fri Jun 22 18:58:18 2007 From: yaneti at declera.com (Yanko Kaneti) Date: Fri, 22 Jun 2007 21:58:18 +0300 Subject: additional *-python splits In-Reply-To: <20070622161240.GC4649@nostromo.devel.redhat.com> References: <1182512639.7069.5.camel@indigo.declera.com> <20070622161240.GC4649@nostromo.devel.redhat.com> Message-ID: <1182538698.7069.23.camel@indigo.declera.com> On Fri, 2007-06-22 at 12:12 -0400, Bill Nottingham wrote: > Yanko Kaneti (yaneti at declera.com) said: > > Before wrestling with bugzilla, I'd like to ask if there are any > > objections to further splitting of *-python subpackages for some core > > libraries. It would make removing python on a minimal install less > > painful. > > > > Three patches for libsemanage, newt and libuser attached. > > Does this include patches for packages that need their Requires: changed? Here is my best attempt. At the following url http://www.declera.com/~yaneti/splitpy/ are all the related patches that I could muster the original three spec file splitting patches for: libsemanage libuser newt spec file requirements fixes for: anaconda authconfig firstboot policycoreutils system-config-date system-config-rootpassword system-config-samba system-config-users system-switch-java system-switch-mail patch for anaconda's secrips/upd-instroot that needs to be applied to anaconda upstream Hope I didn't miss something. Yanko From kevin.kofler at chello.at Fri Jun 22 19:45:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Jun 2007 19:45:35 +0000 (UTC) Subject: additional *-python splits References: <1182512639.7069.5.camel@indigo.declera.com> <200706220959.09183.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > Is your minimal install not going to include yum? That's what apt is for. ;-) But of course a really minimal installation doesn't include any depsolver at all. Kevin Kofler From mschwendt.tmp0701.nospam at arcor.de Fri Jun 22 22:15:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 23 Jun 2007 00:15:44 +0200 Subject: rpms/libosip/FC-6 libosip.spec,1.10,1.11 In-Reply-To: <200706222141.l5MLfVa8015009@cvs-int.fedora.redhat.com> References: <200706222141.l5MLfVa8015009@cvs-int.fedora.redhat.com> Message-ID: <20070623001544.fabea45d.mschwendt.tmp0701.nospam@arcor.de> On Fri, 22 Jun 2007 17:41:31 -0400, Jeffrey C. Ollie wrote: > Author: jcollie > > Update of /cvs/pkgs/rpms/libosip/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14977 > > Modified Files: > libosip.spec > Log Message: > Fix URL > > > Index: libosip.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/libosip/FC-6/libosip.spec,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -u -r1.10 -r1.11 > --- libosip.spec 30 Aug 2006 14:52:47 -0000 1.10 > +++ libosip.spec 22 Jun 2007 21:40:55 -0000 1.11 > @@ -1,11 +1,11 @@ > Name: libosip > Version: 0.9.7 > -Release: 10%{?dist} > +Release: 11%{?dist} > Summary: oSIP is an implementation of SIP > > Group: System Environment/Libraries > License: LGPL > -URL: http://www.fsf.org/software/osip/osip.html > +URL: http://www.gnu.org/software/osip/ > Source0: http://ftp.gnu.org/gnu/osip/libosip-0.9.7.tar.gz > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > @@ -69,6 +69,9 @@ > %{_mandir}/man1/* > > %changelog > +* Fri Jun 22 2007 Jeffrey C. Ollie - 0.9.7-11 > +- Update URL > + > * Wed Aug 30 2006 Jeffrey C. Ollie - 0.9.7-10 > - Bump release and rebuild. A rebuild only for a fixed URL? =:-O From jeff at ocjtech.us Fri Jun 22 22:37:04 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 22 Jun 2007 17:37:04 -0500 Subject: rpms/libosip/FC-6 libosip.spec,1.10,1.11 In-Reply-To: <20070623001544.fabea45d.mschwendt.tmp0701.nospam@arcor.de> References: <200706222141.l5MLfVa8015009@cvs-int.fedora.redhat.com> <20070623001544.fabea45d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1182551824.3628.18.camel@lt21223.campus.dmacc.edu> On Sat, 2007-06-23 at 00:15 +0200, Michael Schwendt wrote: > On Fri, 22 Jun 2007 17:41:31 -0400, Jeffrey C. Ollie wrote: > > > > %changelog > > +* Fri Jun 22 2007 Jeffrey C. Ollie - 0.9.7-11 > > +- Update URL > > + > > * Wed Aug 30 2006 Jeffrey C. Ollie - 0.9.7-10 > > - Bump release and rebuild. > > A rebuild only for a fixed URL? =:-O Well, this package doesn't get updated very often, so a rebuild was probably in order anyway. In fact, I debated about declaring this package dead - the original tarballs have been removed from upstream. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mschwendt.tmp0701.nospam at arcor.de Fri Jun 22 22:53:42 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 23 Jun 2007 00:53:42 +0200 Subject: rpms/libosip/FC-6 libosip.spec,1.10,1.11 In-Reply-To: <1182551824.3628.18.camel@lt21223.campus.dmacc.edu> References: <200706222141.l5MLfVa8015009@cvs-int.fedora.redhat.com> <20070623001544.fabea45d.mschwendt.tmp0701.nospam@arcor.de> <1182551824.3628.18.camel@lt21223.campus.dmacc.edu> Message-ID: <20070623005342.95688599.mschwendt.tmp0701.nospam@arcor.de> On Fri, 22 Jun 2007 17:37:04 -0500, Jeffrey C. Ollie wrote: > On Sat, 2007-06-23 at 00:15 +0200, Michael Schwendt wrote: > > On Fri, 22 Jun 2007 17:41:31 -0400, Jeffrey C. Ollie wrote: > > > > > > %changelog > > > +* Fri Jun 22 2007 Jeffrey C. Ollie - 0.9.7-11 > > > +- Update URL > > > + > > > * Wed Aug 30 2006 Jeffrey C. Ollie - 0.9.7-10 > > > - Bump release and rebuild. > > > > A rebuild only for a fixed URL? =:-O > > Well, this package doesn't get updated very often, so a rebuild was > probably in order anyway. Why? No special BuildRequires, and we don't mass-rebuild the stable rest of Fedora 6 either just because a few months have passed. "ortp" was rebuilt just for a changed URL, too: %changelog +* Fri Jun 22 2007 Jeffrey C. Ollie - 0.13.1-2 +- Fix URL + * Mon Apr 23 2007 Jeffrey C. Ollie - 0.13.1-1 - Update to 0.13.1 - BR doxygen and graphviz for building documentation It's about time for package update guidelines. From david at lovesunix.net Sat Jun 23 02:05:07 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 23 Jun 2007 04:05:07 +0200 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <200706121507.01675.jkeating@redhat.com> References: <466EAA1D.70409@redhat.com> <20070612172602.GA5972@nostromo.devel.redhat.com> <466EECF8.7030100@fedoraproject.org> <200706121507.01675.jkeating@redhat.com> Message-ID: <1182564307.8763.10.camel@dawkins> tir, 12 06 2007 kl. 15:07 -0400, skrev Jesse Keating: > On Tuesday 12 June 2007 14:59:04 Rahul Sundaram wrote: > > We have end users wondering why we are holding back on the release after > > the images are ready instead of making it available on the bittorrent > > Quite simply because a release date is a release date. We set a coordinated > release date for /many/ reasons. Just because one method of distribution is > ready before others is _not_ a reason to fracture your release process. If > it really makes you feel better, I'll delay getting the torrents ready until > just before the coordinated release date. You'll still be faced with the problem that there is always one mirror that forgets to set the permission bits right which leads to users bittorrenting this on their own. We get the choice between issuing the torrent ourselves and thus hopefully avoid overloading said mirror. Provided we don't users will continue overloading mirrors and providing unofficial torrents thus sucking up remote bandwidth anyways. I think the important thing to note here is that there is a large community of people who cannot wait for a new release, they pride themselves in finding that one mirror that's open before time and distributing as many copies as they can before we do the official release. I think we should pride ourselves a little in this being a problem at all, users want the release so much they are willing to suffer the risk of unofficial torrents or dogslow overnight downloads from a misconfigured mirror.. that's love people. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jeff at ocjtech.us Sat Jun 23 03:58:15 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 22 Jun 2007 22:58:15 -0500 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-11 In-Reply-To: <200706121507.01675.jkeating@redhat.com> References: <466EAA1D.70409@redhat.com> <20070612172602.GA5972@nostromo.devel.redhat.com> <466EECF8.7030100@fedoraproject.org> <200706121507.01675.jkeating@redhat.com> Message-ID: <1182571095.9861.11.camel@lt21223.campus.dmacc.edu> On Tue, 2007-06-12 at 15:07 -0400, Jesse Keating wrote: > On Tuesday 12 June 2007 14:59:04 Rahul Sundaram wrote: > > We have end users wondering why we are holding back on the release after > > the images are ready instead of making it available on the bittorrent > > Quite simply because a release date is a release date. We set a coordinated > release date for /many/ reasons. Just because one method of distribution is > ready before others is _not_ a reason to fracture your release process. If > it really makes you feel better, I'll delay getting the torrents ready until > just before the coordinated release date. I think that what will help is having more than one bittorrent seed ready to go on D-day and H-hour. But instead of setting up some "secret" bittorrent to get the seeds ready to go, we should be working with some of the mirror operators. The official mirrors will have copies of the ISOs before the release day. The mirror operators can then use those ISOs to pre-seed a bittorrent client. That will get more seeds operating more quickly. Within a few hours the mirror operators can shut down their bittorrent clients because there will be other seeds available by then. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From guthrie at counterexample.org Sat Jun 23 04:53:39 2007 From: guthrie at counterexample.org (John T. Guthrie III) Date: Sat, 23 Jun 2007 00:53:39 -0400 (EDT) Subject: R500 initial driver release In-Reply-To: <1181852757.30663.99.camel@localhost.localdomain> from "Adam Jackson" at Jun 14, 2007 04:25:57 PM Message-ID: <200706230453.l5N4rd8a014447@gauss.counterexample.org> > On Thu, 2007-06-14 at 09:57 -0400, Adam Jackson wrote: > > On Tue, 2007-06-12 at 16:33 -0500, Mike Chambers wrote: > > I need to test that it actually works on at least one piece of hardware > > first. > > Well, it doesn't work on my T60p, for lack of PCI ID if nothing else. > > Test build: > > http://people.redhat.com/ajackson/avivo/ > > Requires libpciaccess, which thus far is only in rawhide, but should be > in F-7 updates in the next push. Eats babies, etc. > > Once we actually have this working on at least one piece of kit out of > the box I'll get it imported. I was sort of able to get it to run on my X1300 Mobility. I did need to patch the PCI ID in before I could get anything. (The PCI device ID is 0x7149.) In native resolution of 1680x1050, it just blanks the screen, and you have to reboot. If I uncomment the following ModeLine, then it comes up looking like a television whose horizontal is screwy: ModeLine "1680x1050" 119.2 1680 1728 1760 1840 1050 1052 1058 1080 I consider that an improvement over a blank screen that accepts no input since I can at least see the mouse move with this mode line. I'm guessing there are mode line problems. (I foudn this mode line a while back while trying to find a way to get my Dell E1505 to display in full native resolution. Alas, that could never happen using VESA. :-( ) If I try to force it into 1400x1050, then I just get a blank screen as well. I can provide an X server log if needed. John Guthrie guthrie at counterexample.org From buildsys at redhat.com Sat Jun 23 10:08:07 2007 From: buildsys at redhat.com (Build System) Date: Sat, 23 Jun 2007 06:08:07 -0400 Subject: rawhide report: 20070623 changes Message-ID: <200706231008.l5NA87X8023492@porkchop.devel.redhat.com> New package babel Tools for internationalizing Python applications New package cvsplot Collect statistics from CVS controlled files New package gpsdrive A GPS based navigation tool New package ketchup Linux Kernel source switch/update tool New package mod_auth_ntlm_winbind NTLM authentication for the Apache web server using winbind daemon New package perl-MogileFS-Client Client library for the MogileFS distributed file system Removed package itext Removed package rssowl Updated Packages: adminutil-1.1.2-1.fc8 --------------------- * Fri Jun 22 2007 Rich Megginson - 1.1.2-1 - Updated version to 1.1.2 - This version fixes some memory leaks and invalid memory use - issues amanda-2.5.2p1-2.fc8 -------------------- * Fri Jun 22 2007 Radek Brich 2.5.2.p1-2 - Fix undefined symbols in libamserver.so. - Fix ./autogen so it automatically installs ylwrap (bug 224143). - Run ./autogen in prep section (otherwise the -pie patch had no effect). - Update -pie patch. amavisd-new-2.5.2-0.1.rc2.fc8 ----------------------------- * Fri Jun 22 2007 Steven Pritchard 2.5.2-0.1.rc2 - Update to 2.5.2-rc2. * Fri Jun 22 2007 Steven Pritchard 2.5.1-1 - Update to 2.5.1. - Fix amavis-clamd.conf (bug #237252). - Update amavisd-conf.patch. - Require p7zip and tar. - Improve pre/preun/post scripts. anaconda-11.3.0.4-1 ------------------- * Fri Jun 22 2007 Chris Lumens - 11.3.0.4-1 - Add a firmware loader, remove nash firmware bits (pjones). - Fix module loading to work for multiple modules.cgz locations (pjones). - Handle IPv4 CIDR prefixes in iscsi config (hhara AT miraclelinux DOT com). - Better error handling in iscsi config (dwpang AT redflag-linux DOT com, hhara AT miraclelinux DOT com). - Fix livecd traceback (#244764). - Copy over entire driver disk directory contents for new layout. bcfg2-0.9.4-0.1.pre4.fc8 ------------------------ * Thu Jun 21 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre4 - Update to 0.9.4pre4 * Thu Jun 14 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre3 - Update to 0.9.4pre3 dbus-1.0.2-6.fc8 ---------------- * Fri Jun 22 2007 Matthias Clasen - 1.0.2-6 - Don't require libxml-python needlessly (#245300) * Sun Jun 17 2007 Matthias Clasen - 1.0.2-5 - Require pkgconfig in -devel, not in -x11 (#244385) * Sat Apr 14 2007 Matthias Clasen - 1.0.2-4 - Move the dbus-launch man page to the x11 subpackage dbus-python-0.82.0-1.fc8 ------------------------ * Fri Jun 22 2007 Matthias Clasen - 0.82.0-1 - Update to 0.82.0 - Put all docs in the usual place * Tue Apr 03 2007 David Zeuthen - 0.80.2-3 - Rebuild * Tue Apr 03 2007 David Zeuthen - 0.80.2-2 - Don't examine args for functions declared METH_NOARGS (#235017) digikam-0.9.2-2.fc8 ------------------- * Fri Jun 22 2007 Marcin Garski 0.9.2-2 - Create symlinks in pixmaps directory (#242978) * Tue Jun 19 2007 Marcin Garski 0.9.2-1 - Update to version 0.9.2-final - Remove digikam-0.9.2-beta3-fix-exiv2-dep.patch, merged upstream * Wed Jun 06 2007 Marcin Garski 0.9.2-0.3.beta3 - Fix .desktop category e2fsprogs-1.39-14.fc8 --------------------- * Fri Jun 22 2007 Eric Sandeen 1.39-14 - Many coverity-found potential leaks, segfaults, etc (#239354) - Fix debugfs segfaults when no fs open (#208416, #209330) - Avoid recursive loops in logdump due to symlinks in /dev (#210371) - Don't write changes to the backup superblocks by default (#229561) - Correct byteswapping for fast symlinks with xattrs (#232663) - e2fsck: added sanity check for xattr validation (#230193) empathy-0.8-1.fc8 ----------------- * Fri Jun 22 2007 David Nielsen - 0.8-1 - bump to 0.8 - Now with aspell support (deat to teh speeling mistaks) flex-2.5.33-8.fc8 ----------------- * Fri Jun 22 2007 Petr Machata - 2.5.33-8 - Don't emit yy-prefixed variables in C++ mode. Thanks Srinivas Aji. - Related: #242742 - Related: #244259 * Fri May 11 2007 Petr Machata - 2.5.33-7 - Allow joining short options into one commandline argument. - Resolves: #239695 frozen-bubble-2.1.0-3.fc8 ------------------------- * Fri Jun 22 2007 Matthias Saou 2.1.0-3 - Fix build with perl-devel split (ExtUtils/MakeMaker.pm build requirement). - Cosmetic changes to the spec file. - Change fbubble user's home from / to %{_datadir}/%{name}. - Remove the desktop file's "fedora" prefix. - Remove executable bit from the man pages. gcombust-1:0.1.55-10 -------------------- * Fri Jun 22 2007 Matthias Saou 1:0.1.55-10 - Include desktop patch : UTF-8, remove bogus category and themeable icon. - Minor spec file cleanups. - Convert xpm icon to png in hicolor, with needed scriplets. - Use DESTDIR install method. gentoo-0.11.56-3 ---------------- * Fri Jun 22 2007 Matthias Saou 0.11.56-3 - Use DESTDIR install method. - Remove "fedora" prefix and useless category from desktop file. - Preserve timestamps on - Externalize desktop file. - Remove dist, as it might be a long while before a new rebuild takes place. giblib-1.2.4-8 -------------- * Fri Jun 22 2007 Matthias Saou 1.2.4-8 - Use DESTDIR install method. - Disable building static library and remove it from the devel package. - Remove dist, as it might be a while before the next rebuild. gkrellm-aclock-0.3.4-2 ---------------------- * Fri Jun 22 2007 Matthias Saou 0.3.4-2 - Remove dist, as it might be a while before the next rebuild. gkrellm-freq-1.0-4 ------------------ * Fri Jun 22 2007 Matthias Saou 1.0-4 - Remove dist, as it might be a while before the next rebuild. gkrellm-moon-0.6-3 ------------------ gkrellm-sun-1.0.0-3 ------------------- gtkmm24-2.11.3-1.fc8 -------------------- * Thu Jun 21 2007 Denis Leroy - 2.11.3-1 - Update to unstable 2.11 tree to follow gtk2 version - Fixed documentation devhelp support hunspell-pl-0.20070622-1.fc8 ---------------------------- jd-1.9.5-0.5.svn1148.fc8 ------------------------ * Sat Jun 23 2007 Mamoru Tasaka - 1.9.5-0.5.svn1148 - svn 1148 kernel-2.6.21-1.3234.fc8 ------------------------ * Fri Jun 22 2007 Dave Jones - 2.6.22-rc5-git6. * Thu Jun 21 2007 Dave Jones - Remove some unnecessary parts of execshield. * Thu Jun 21 2007 Dave Jones - Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu. lash-0.5.1-14.fc8 ----------------- * Fri Jun 22 2007 Florian La Roche 0.5.1-14 - info files are gzipped, add info dir entry libXfont-1.2.9-1.fc8 -------------------- * Fri Jun 22 2007 Kristian H??gsberg - 1.2.9-1 - Pull 1.2.9 down to get the catalogue feature. libdaemon-0.11-1.fc8 -------------------- * Fri Jun 22 2007 Martin Bacovsky - 0.11-1 - update no new upstream version 0.11 libosip-0.9.7-11.fc8 -------------------- * Fri Jun 22 2007 Jeffrey C. Ollie - 0.9.7-11 - Update URL mozldap-6.0.4-1.fc8 ------------------- * Wed Jun 20 2007 Rich Megginson - 6.0.4-1 - bump version to 6.0.4 - this version has some memory leak - fixes for SASL related code, fixes for control handling with - referral chasing, and packaging improvements - use -p when installing include files to preserve timestamps * Thu May 24 2007 Rich Megginson - 6.0.3-3 - We only need cyrus-sasl-devel as a BuildRequires in the main package * Mon May 21 2007 Rich Megginson - 6.0.3-2 - added cyrus-sasl-devel and pkgconfig to devel package Requires opencv-1.0.0-3.fc8 ------------------ ortp-0.13.1-3.fc8 ----------------- * Fri Jun 22 2007 Jeffrey C. Ollie - 0.13.1-2 - Fix URL perl-Mozilla-LDAP-1.5.1-1.fc8 ----------------------------- * Wed Jun 20 2007 Rich Megginson - 1.5.1-1 - all files have been GPL/LGPL/MPL tri-licensed pitivi-0.10.3-1.fc8 ------------------- * Fri Jun 22 2007 Jeffrey C. Ollie - 0.10.3-1 - Update to 0.10.3 policycoreutils-2.0.22-2.fc8 ---------------------------- * Fri Jun 22 2007 Dan Walsh 2.0.22-2 - Fix else path in chcat postgrey-1.28-1.fc8 ------------------- * Fri Jun 22 2007 Matthias Saou 1.28-1 - Update to 1.28. - Update URL to the new homepage. slib-3a4-2.fc8 -------------- * Fri Jun 22 2007 Miroslav Lichvar 3a4-2 - fix summary and buildroot (#226421) smolt-0.9.8.3-1.fc8 ------------------- * Fri Jun 22 2007 Mike McGrath 0.9.8.3 - Upstream released new version stardict-2.4.8-3.fc8 -------------------- * Fri Jun 22 2007 Hu Zheng - 2.4.8-3 - Add dic and treedict directory. taskjuggler-2.4.0-1.fc8 ----------------------- * Fri Jun 22 2007 Ondrej Vasik - 2.4.0-1 - update to latest stable upstream version(2.4.0) - removed patches included in 2.4.0 xchat-1:2.8.2-12.fc8 -------------------- * Fri Jun 22 2007 Kevin Kofler - 1:2.8.2-12 - install the .desktop file with --vendor="" to keep the old name xorg-x11-server-1.3.0.0-10.fc8 ------------------------------ * Fri Jun 22 2007 Kristian H??gsberg - 1.3.0.0-10 - Change the default font path to catalogue:/etc/X11/fontpath.d,built-ins - Drop build dependency xorg-x11-font-utils. xorg-x11-xfs-1:1.0.4-1 ---------------------- * Fri Jun 22 2007 Kristian H??gsberg - 1:1.0.4-1 - Require catalogue capable libXfont. - Drop xfs.config.in, just use catalogue font path. - Stop xorg.conf munging madness. * Sat Apr 21 2007 Matthias Clasen - 1:1.0.2-4 - Don't install INSTALL * Wed Jul 12 2006 Jesse Keating - 1:1.0.2-3.1 - rebuild xscorch-0.2.0-10.fc8 -------------------- * Fri Jun 22 2007 Marcin Garski 0.2.0-10 - Create symlinks in pixmaps directory - Preserve upstream .desktop vendor - Fix .desktop category * Sat May 05 2007 Marcin Garski 0.2.0-9 - Spec tweak xterm-226-1.fc8 --------------- * Fri Jun 22 2007 Miroslav Lichvar 226-1 - update to 226 yafc-1.1.1-8.fc8 ---------------- * Fri Jun 22 2007 Chris Petersen 1.1.1-8 - Revision bump due to buildsys version conflict preventing F-7 build Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.10-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From kevin.kofler at chello.at Sat Jun 23 12:34:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 Jun 2007 12:34:08 +0000 (UTC) Subject: rawhide report: 20070623 changes References: <200706231008.l5NA87X8023492@porkchop.devel.redhat.com> Message-ID: Build System redhat.com> writes: > gentoo-0.11.56-3 > ---------------- > * Fri Jun 22 2007 Matthias Saou 0.11.56-3 > - Use DESTDIR install method. > - Remove "fedora" prefix and useless category from desktop file. Huh? * Does this mean this now has no vendor? The guidelines say that there should be a valid vendor and "fedora" should be used if upstream doesn't use one. * I just got lectured about how bad it is to change the name of an existing .desktop file due to menu editing when I tried doing that on xchat (to add "--vendor fedora", not to remove it)... That's also mentioned in the guidelines. Kevin Kofler From frank-buettner at gmx.net Sat Jun 23 15:43:51 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 23 Jun 2007 17:43:51 +0200 Subject: Build system for FC5/6 damage?? Message-ID: <467D3FB7.1050707@gmx.net> When I try to build my new packages I get only this errors: Local build witch mock and at the devel system(F-8) will work. Result for FC-6 http://buildsys.fedoraproject.org/build-status/job.psp?uid=34459 and for FC-5 http://buildsys.fedoraproject.org/build-status/job.psp?uid=34461 same package but with other source file was build for some time without any problems. Any ideas what have changed at the build system? Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jun 23 16:05:36 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 24 Jun 2007 01:05:36 +0900 Subject: Build system for FC5/6 damage?? In-Reply-To: <467D3FB7.1050707@gmx.net> References: <467D3FB7.1050707@gmx.net> Message-ID: <467D44D0.9050208@ioa.s.u-tokyo.ac.jp> Frank B?ttner wrote, at 06/24/2007 12:43 AM +9:00: > When I try to build my new packages I get only this errors: > Local build witch mock and at the devel system(F-8) will work. > Result for FC-6 > http://buildsys.fedoraproject.org/build-status/job.psp?uid=34459 > and for FC-5 > http://buildsys.fedoraproject.org/build-status/job.psp?uid=34461 > same package but with other source file was build for some time without > any problems. > > Any ideas what have changed at the build system? It seems you forgot to "cvs add" ctapi.h. Actually when I did "cvs co ctapi-cyberjack", ctapi.h is missing on FC-6 and FC-5 branches. Mamoru From tmz at pobox.com Sat Jun 23 16:26:30 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 23 Jun 2007 12:26:30 -0400 Subject: rawhide report: 20070623 changes In-Reply-To: References: <200706231008.l5NA87X8023492@porkchop.devel.redhat.com> Message-ID: <20070623162630.GG25468@psilocybe.teonanacatl.org> Kevin Kofler wrote: > Build System redhat.com> writes: >> gentoo-0.11.56-3 >> ---------------- >> * Fri Jun 22 2007 Matthias Saou 0.11.56-3 >> - Use DESTDIR install method. >> - Remove "fedora" prefix and useless category from desktop file. > > Huh? > * Does this mean this now has no vendor? The guidelines say that > there should be a valid vendor and "fedora" should be used if > upstream doesn't use one. > * I just got lectured about how bad it is to change the name of an > existing .desktop file due to menu editing when I tried doing that > on xchat (to add "--vendor fedora", not to remove it)... That's also > mentioned in the guidelines. I had a reviewer tell me repeatedly that I needed to remove the vendor arg from desktop-file-install for one of my packages, despite my quoting the clear guidelines over and over. I think the reviewer was confused about another guidelines section which admonishes use of the Vendor: header in the spec file. Perhaps that confusion has spread? :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To urge more gentlemen to go into politics was the same as arguing that the cure for prostitution was to send more virgins into brothels. -- H.L. Mencken -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From frank-buettner at gmx.net Sat Jun 23 16:27:09 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 23 Jun 2007 18:27:09 +0200 Subject: Build system for FC5/6 damage?? In-Reply-To: <467D44D0.9050208@ioa.s.u-tokyo.ac.jp> References: <467D3FB7.1050707@gmx.net> <467D44D0.9050208@ioa.s.u-tokyo.ac.jp> Message-ID: <467D49DD.20807@gmx.net> Mamoru Tasaka schrieb: > Frank B?ttner wrote, at 06/24/2007 12:43 AM +9:00: >> When I try to build my new packages I get only this errors: >> Local build witch mock and at the devel system(F-8) will work. >> Result for FC-6 >> http://buildsys.fedoraproject.org/build-status/job.psp?uid=34459 >> and for FC-5 >> http://buildsys.fedoraproject.org/build-status/job.psp?uid=34461 >> same package but with other source file was build for some time without >> any problems. >> >> Any ideas what have changed at the build system? > > It seems you forgot to "cvs add" ctapi.h. > Actually when I did "cvs co ctapi-cyberjack", ctapi.h is > missing on FC-6 and FC-5 branches. > > Mamoru > Yes after re add the file it will work. Very mysterious why the file was lost??? Ok thanks for the help. Frank. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Sat Jun 23 17:54:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 23 Jun 2007 23:24:09 +0530 Subject: buggbot is broken In-Reply-To: <467B0D6B.4070809@fedoraproject.org> References: <467B0D6B.4070809@fedoraproject.org> Message-ID: <467D5E41.6040507@fedoraproject.org> Marek Mahut wrote: > Hey guys, > > Buggbot on #fedorabot seems to be broken. Who take care of that? It is maintained by Max Kanat-Alexander, rel eng for upstream Bugzilla. CC'ed. Rahul From cddesjardins at gmail.com Sat Jun 23 19:34:43 2007 From: cddesjardins at gmail.com (Christopher David Desjardins) Date: Sat, 23 Jun 2007 14:34:43 -0500 Subject: KDE suggestions for Fedora 8 and beyond Message-ID: <200706231434.43864.lontra@localhost.localdomain> Hi I'd like to throw a couple of my thoughts about KDE in Fedora and how it could be improved. 1. QT-Frontend for YUM There are lots of good GTK frontends for yum (pirut, yumex) but there aren't really any good QT frontends for yum. There is kyum but it's certainly lacking in comparison to yumex. I think a QT version of yumex could be real nice and it could cut down on GTK dependencies in KDE, maybe? Another suggestions would be to port Adept from Kubuntu or Debian. 2. KDE Update Notifier Maybe a frontend for pup in QT or adept-updater? 3. Selecting KDE meta-package on the dvd brings in KDE only apps (except maybe GIMP and Firefox). I noticed when I selected KDE and deselected GNOME that it still wanted to install rhythmbox, soundjuicer, totem, pidgin, and other GNOME apps. This is not only adding to bloat from a KDE users stand point but it's also a bit annoying. I am sure GNOME users don't want a lot of KDE apps stinking of their desktops unless they select them. 4. Nice windeco and style The inclusion of KDE4 and oxygen might obsolete this thought. 5. A KDE irc channel Something like #fedora-kde on irc.freenode.net would be a nice place for those interested in KDE to discuss KDE on fedora, packaging, KDE4, and other related issues. This would not be for support and this would of course be specified in the topic. This could provide a place for the KDE developers and those interested in packaging, art, and helping out to discuss relevant issues. I know that opensuse, debian, and kubuntu all have channels similar to this. Cheers, Chris From max_list at fedorafaq.org Sat Jun 23 23:43:51 2007 From: max_list at fedorafaq.org (Max Kanat-Alexander) Date: Sat, 23 Jun 2007 16:43:51 -0700 Subject: buggbot is broken In-Reply-To: <467D5E41.6040507@fedoraproject.org> References: <467B0D6B.4070809@fedoraproject.org> <467D5E41.6040507@fedoraproject.org> Message-ID: <20070623234740.010FB868002@help.trusthosting.net> On Sat, 23 Jun 2007 23:24:09 +0530 Rahul Sundaram wrote: > Marek Mahut wrote: > > Hey guys, > > > > Buggbot on #fedorabot seems to be broken. Who take care of that? > > It is maintained by Max Kanat-Alexander, rel eng for upstream > Bugzilla. CC'ed. He watches particular product names. So he broke when "Fedora Core" was renamed. :-) I've fixed it now, he should be reporting bugs again. If anybody wants him to report any subset of bugs to any channel on any IRC network, just let me know. (I'm mkanat on FreeNode, or you can email me, just remove the _list from my email address here.) -Max -- http://www.insiderfaq.com/ The Insider FAQ: Linux Made Simple. From guhvies at gmail.com Sat Jun 23 23:55:46 2007 From: guhvies at gmail.com (ne...) Date: Sun, 24 Jun 2007 00:55:46 +0100 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: <200706231434.43864.lontra@localhost.localdomain> References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: On 6/23/07, Christopher David Desjardins wrote: > Hi I'd like to throw a couple of my thoughts about KDE in Fedora and how it > could be improved. > > 1. QT-Frontend for YUM > There are lots of good GTK frontends for yum (pirut, yumex) but there aren't > really any good QT frontends for yum. There is kyum but it's certainly > lacking in comparison to yumex. I think a QT version of yumex could be real > nice and it could cut down on GTK dependencies in KDE, maybe? Another > suggestions would be to port Adept from Kubuntu or Debian. You need to code that and submit it. > 2. KDE Update Notifier > Maybe a frontend for pup in QT or adept-updater? See remark above. > 3. Selecting KDE meta-package on the dvd brings in KDE only apps (except > maybe GIMP and Firefox). Neither GIMP nor Firefox are KDE apps. They will need to be brought it seperately. Personally, I use neither on Linux. Konqui does the job for me. > I noticed when I selected KDE and deselected GNOME that it still wanted to > install rhythmbox, soundjuicer, totem, pidgin, and other GNOME apps. This is > not only adding to bloat from a KDE users stand point but it's also a bit > annoying. I am sure GNOME users don't want a lot of KDE apps stinking of > their desktops unless they select them. Amen, brotha, preach on. Tell them like it should be. I am personally sick of having to unselect all the gnome stuff and then forcefully remove them via 'rpm -e --nodeps'. I want a pure KDE desktop, not a hybrid one. > 4. Nice windeco and style > The inclusion of KDE4 and oxygen might obsolete this thought. > > 5. A KDE irc channel > Something like #fedora-kde on irc.freenode.net would be a nice place for > those interested in KDE to discuss KDE on fedora, packaging, KDE4, and other > related issues. This would not be for support and this would of course be > specified in the topic. This could provide a place for the KDE developers > and those interested in packaging, art, and helping out to discuss relevant > issues. I know that opensuse, debian, and kubuntu all have channels similar > to this. Not sure whether this had already been done in the past. Still, I've stopped doing irc, so I am not sure whether I would hang out there. ne... -- Registered Linux User # 125653 (http://counter.li.org) Certified: 75% bastard, 42% of which is tard. http://www.thespark.com/bastardtest Now accepting personal mail for GMail invites. From kwade at redhat.com Sun Jun 24 00:14:49 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 23 Jun 2007 17:14:49 -0700 Subject: FESCo elections In-Reply-To: <1182358804.8424.12.camel@localhost.localdomain> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <467936A6.2060402@redhat.com> <1182358804.8424.12.camel@localhost.localdomain> Message-ID: <1182644089.10205.291.camel@erato.phig.org> On Wed, 2007-06-20 at 10:00 -0700, Toshio Kuratomi wrote: > Basically, you should be able to vote if you are under FESCo's > authority. You should not be able to vote if you are not. The problem I have with this is that FESCo, unlike all bodies save the Board, makes decisions that affect the entire project. I think "affects" should be the criteria, not "authority." Probably what is bugging me the most about this is that I want to be able to vote for FESCo members. Not only that, but in the last FDSCo elections, I wanted the pool of eligible voters to be all of FAS. I cannot think of a single good reason to divide Fedora contributors into voting pools, but I can think of lots of good reasons we should be able to vote across sub-project steering committees. All of the talk about political v. technical are spurious. This is not a government, we are not a physical nation. Decisions that affect all of us are a split of technical, social, community, etc. Why cling to preconceived notions of how a "democracy" works? Look at ancient Athens, the "first democracry" -- as long as you were a free man and the eldest son of a property owning family.[1] We actually are free to reinvent the notion ourselves. - Karsten [1] At least they, unlike the US Congress, actually had to go fight the wars they voted to have. -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sun Jun 24 00:20:49 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 23 Jun 2007 17:20:49 -0700 Subject: FESCo elections In-Reply-To: <20070621132431.GA6618@free.fr> References: <4678D15C.6030108@nigelj.com> <20070620101642.GB3164@free.fr> <1182345199.14977.13.camel@weaponx.rchland.ibm.com> <20070620191144.GA3929@free.fr> <1182367998.14977.81.camel@weaponx.rchland.ibm.com> <20070621073528.GA3140@free.fr> <1182424239.3865.17.camel@vader.jdub.homelinux.org> <1182426466.6710.34.camel@mccallum.corsepiu.local> <1182430572.8010.13.camel@weaponx.rchland.ibm.com> <1182431822.6710.63.camel@mccallum.corsepiu.local> <20070621132431.GA6618@free.fr> Message-ID: <1182644449.10205.294.camel@erato.phig.org> On Thu, 2007-06-21 at 15:24 +0200, Patrice Dumas wrote: > There are countries where some people of the administration are elected > (I think it is the case in the US). Well, yes, the President. That person, once elected, then appoints a whole series of sub-administrators. So, to do FESCo elections the way the US government is structured, we would *all* (all citizens) elect the FESCo chair, who would then populate FESCo with appointments. The problem is, trying to apply real world examples ("technical", "political", "administration") where they have nothing to do with the situation at hand. Why are we binding ourselves with these meatspace distinctions? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sun Jun 24 00:25:31 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 23 Jun 2007 17:25:31 -0700 Subject: FESCo elections In-Reply-To: References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> Message-ID: <1182644731.10205.300.camel@erato.phig.org> On Wed, 2007-06-20 at 14:25 -0500, Jason L Tibbitts III wrote: > >>>>> "JS" == Jeff Spaleta writes: > > JS> If someone was going to attempt to ask for sponsorship without > JS> submitting a new package...where do they start? > > Apply for cvsextras membership in the account system and find someone > to sponsor them through whatever channels they wish. OK, so, if I really want to vote for FESCo, I can sneak my way into the voting pool if I know somebody? This does not sound like the kind of "democracy" that we want. Why have a special pool of citizens? And does the special pool have to be made up only of the kind of people who are being elected? Special pools of voters for special positions: * Only lawyers can vote for Federal Judges. * Only medicos are allowed to vote for Surgeon General. * Only white males are allowed to vote for President. What if you are not in that special pool and want to run or vote? Put on some whiteface and fake a law degree? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sun Jun 24 00:36:40 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 23 Jun 2007 17:36:40 -0700 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: <200706231434.43864.lontra@localhost.localdomain> References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: <1182645400.10205.310.camel@erato.phig.org> On Sat, 2007-06-23 at 14:34 -0500, Christopher David Desjardins wrote: [snip suggestions] I would hope that with the ability to remix Fedora, some enterprising KDE folks who solve some of your "pure KDE desktop" desires. Maybe you are one of them? > 5. A KDE irc channel The best way to start an IRC channel that you want people to join is like this: 1. Start IRC client and connect to irc.freenode.net 2. '/join #fedora-kde' 3. '/msg chanserv register #fedora-kde ' 4. '/msg chanserv help' for other goodies, and this page is helpful: http://freenode.net/channel_guidelines.shtml 5. '/msg chanserv set #fedora-kde guard on' - ChanServ joins and guards the channel while you are absent 6. '/msg chanserv set #fedora-kda alternate - Pick another Fedora KDE user to be an alternative channel contact 7. '/topic #fedora-kde The Fedora KDE discussion channel, NOT FOR SUPPORT (join #fedora for that); topics include packaging, builds, KDE4, and other kfun' 8. Announce on 'fedora-devel-announce' the formation of a new channel; watch people come by; when they do, say, "Hi, welcome" Don't think it's presumptuous to do it that way, that's how most "official" channels get started. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at lovesunix.net Sun Jun 24 01:16:29 2007 From: david at lovesunix.net (David Nielsen) Date: Sun, 24 Jun 2007 03:16:29 +0200 Subject: Making ndesk-dbus build in mock Message-ID: <1182647789.4366.12.camel@dawkins> I've noticed that most mono apps depend on dbus-sharp which turns out to be wrong. Take Banshee as the example, if the new managed DBus implementation[1] is not present it will build against a bundled copy of it making the dependency obsolete. This also makes all Dbus communication with Banshee not work for some reason, so your multimedia keys won't work. Since a lot of application use this approach there would be an advantage in having a package of ndesk-dbus for packagers to build against. I've spend most of today trying to build such a set of packages but I'm faced with a problem, not only is the code bundled in a somewhat nonsensical way upstream but while it builds fine outside of mock, it refuses to build in mock. Even if the missing component it complains about should be provided, so I'm asking for a few pointers here in the interest of making out Mono apps work nicer for users. Can anyone spot my mistake? http://www.lovesunix.net/fedora/ndesk-dbus.spec http://www.lovesunix.net/fedora/ndesk-dbus-0.5.2-1.fc8.src.rpm http://www.lovesunix.net/fedora/ndesk-dbus-glib.spec http://www.lovesunix.net/fedora/ndesk-dbus-glib-0.3-1.fc8.src.rpm - David Nielsen [1] http://www.ndesk.org/DBusSharp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From ddmbox2 at yahoo.co.uk Sun Jun 24 00:24:52 2007 From: ddmbox2 at yahoo.co.uk (dexter) Date: Sun, 24 Jun 2007 01:24:52 +0100 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: <200706231434.43864.lontra@localhost.localdomain> References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: <200706240124.54620.ddmbox2@yahoo.co.uk> On Sat June 23 2007 20:34:43 Christopher David Desjardins wrote: > Hi I'd like to throw a couple of my thoughts about KDE in Fedora and how it > could be improved. > > 1. QT-Frontend for YUM > There are lots of good GTK frontends for yum (pirut, yumex) but there > aren't really any good QT frontends for yum. There is kyum but it's > certainly lacking in comparison to yumex. I think a QT version of yumex > could be real nice and it could cut down on GTK dependencies in KDE, maybe? > Another suggestions would be to port Adept from Kubuntu or Debian. > I actally like kyum (now it works!) as far as a point & click solution never tried yumex, but if you build the code they will come. :-) > 2. KDE Update Notifier > Maybe a frontend for pup in QT or adept-updater? > > 3. Selecting KDE meta-package on the dvd brings in KDE only apps (except > maybe GIMP and Firefox). > I noticed when I selected KDE and deselected GNOME that it still wanted to > install rhythmbox, soundjuicer, totem, pidgin, and other GNOME apps. This > is not only adding to bloat from a KDE users stand point but it's also a > bit annoying. I am sure GNOME users don't want a lot of KDE apps stinking > of their desktops unless they select them. file bugs. > > 4. Nice windeco and style > The inclusion of KDE4 and oxygen might obsolete this thought. > > 5. A KDE irc channel > Something like #fedora-kde on irc.freenode.net would be a nice place for > those interested in KDE to discuss KDE on fedora, packaging, KDE4, and > other related issues. This would not be for support and this would of > course be specified in the topic. This could provide a place for the KDE > developers and those interested in packaging, art, and helping out to > discuss relevant issues. I know that opensuse, debian, and kubuntu all > have channels similar to this. +1 bring all this up at the next kde sig meeting. which time escapes me. > > Cheers, > Chris ...dex ___________________________________________________________ All New Yahoo! Mail ? Tired of Vi at gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html From rdieter at math.unl.edu Sun Jun 24 01:49:31 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 23 Jun 2007 20:49:31 -0500 Subject: KDE suggestions for Fedora 8 and beyond References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: ne... wrote: > I want a pure KDE desktop, not a hybrid one. If you use a loose definition of "pure", the Fedora 7 Live spin gives you something close to that. -- Rex From chitlesh at fedoraproject.org Sun Jun 24 02:03:23 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 24 Jun 2007 04:03:23 +0200 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: <13dbfe4f0706231903j5e1049dbm726d5cea5abfb1e7@mail.gmail.com> On 6/24/07, ne... wrote: > > 1. QT-Frontend for YUM > > There are lots of good GTK frontends for yum (pirut, yumex) but there aren't > > really any good QT frontends for yum. There is kyum but it's certainly > > lacking in comparison to yumex. I think a QT version of yumex could be real > > nice and it could cut down on GTK dependencies in KDE, maybe? Another > > suggestions would be to port Adept from Kubuntu or Debian. > You need to code that and submit it. > > > 2. KDE Update Notifier > > Maybe a frontend for pup in QT or adept-updater? > See remark above. There is already someone who was porting adept to fedora. But however their site is dead right now: http://web.mornfall.net/blog/adept_2.2_on_fedora.html http://www.redhat.com/archives/fedora-devel-list/2007-April/msg00321.html My wish item for fedora kde would be : * one click rpm installation with konqueror (just like in firefox) :) that will help some newbies, since dependencies are met automatically. Chitlesh -- http://clunixchit.blogspot.com From lostson at lostsonsvault.org Sun Jun 24 02:40:40 2007 From: lostson at lostsonsvault.org (lostson) Date: Sat, 23 Jun 2007 21:40:40 -0500 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: <200706231434.43864.lontra@localhost.localdomain> References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: <1182652840.5514.1.camel@localhost.localdomain> On Sat, 2007-06-23 at 14:34 -0500, Christopher David Desjardins wrote: > Hi I'd like to throw a couple of my thoughts about KDE in Fedora and how it > could be improved. > > 1. QT-Frontend for YUM Try kyum http://www.kde-apps.org/content/show.php?content=22185 > There are lots of good GTK frontends for yum (pirut, yumex) but there aren't > really any good QT frontends for yum. There is kyum but it's certainly > lacking in comparison to yumex. I think a QT version of yumex could be real > nice and it could cut down on GTK dependencies in KDE, maybe? Another > suggestions would be to port Adept from Kubuntu or Debian. > > 2. KDE Update Notifier > Maybe a frontend for pup in QT or adept-updater? > > 3. Selecting KDE meta-package on the dvd brings in KDE only apps (except > maybe GIMP and Firefox). > I noticed when I selected KDE and deselected GNOME that it still wanted to > install rhythmbox, soundjuicer, totem, pidgin, and other GNOME apps. This is > not only adding to bloat from a KDE users stand point but it's also a bit > annoying. I am sure GNOME users don't want a lot of KDE apps stinking of > their desktops unless they select them. > > 4. Nice windeco and style > The inclusion of KDE4 and oxygen might obsolete this thought. > > 5. A KDE irc channel > Something like #fedora-kde on irc.freenode.net would be a nice place for > those interested in KDE to discuss KDE on fedora, packaging, KDE4, and other > related issues. This would not be for support and this would of course be > specified in the topic. This could provide a place for the KDE developers > and those interested in packaging, art, and helping out to discuss relevant > issues. I know that opensuse, debian, and kubuntu all have channels similar > to this. > > Cheers, > Chris > -- LostSon http://www.lostsonsvault.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cddesjardins at gmail.com Sun Jun 24 02:42:48 2007 From: cddesjardins at gmail.com (Christopher David Desjardins) Date: Sat, 23 Jun 2007 21:42:48 -0500 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: <1182645400.10205.310.camel@erato.phig.org> References: <200706231434.43864.lontra@localhost.localdomain> <1182645400.10205.310.camel@erato.phig.org> Message-ID: <200706232142.48945.lontra@localhost.localdomain> On Saturday 23 June 2007 19:36:40 Karsten Wade wrote: > I would hope that with the ability to remix Fedora, some enterprising > KDE folks who solve some of your "pure KDE desktop" desires. ?Maybe you > are one of them? > > > 5. ?A KDE irc channel > > The best way to start an IRC channel that you want people to join is > like this: > > 1. Start IRC client and connect to irc.freenode.net > 2. '/join #fedora-kde' > 3. '/msg chanserv register #fedora-kde ' > 4. '/msg chanserv help' for other goodies, and this page is helpful: > ? ?http://freenode.net/channel_guidelines.shtml > 5. '/msg chanserv set #fedora-kde guard on' > ? ?- ChanServ joins and guards the channel while you are absent > 6. '/msg chanserv set #fedora-kda alternate > ? ?- Pick another Fedora KDE user to be an alternative channel contact > 7. '/topic #fedora-kde The Fedora KDE discussion channel, NOT FOR > SUPPORT (join #fedora for that); topics include packaging, builds, KDE4, > and other kfun' > 8. Announce on 'fedora-devel-announce' the formation of a new channel; > watch people come by; when they do, say, "Hi, welcome" > > Don't think it's presumptuous to do it that way, that's how most > "official" channels get started. I've taken it upon myself to start a fedora-kde channel at #fedora-kde. If anyone is interested in being an alternative channel contact let me know. cheers, Chris From lightsolphoenix at gmail.com Sun Jun 24 03:46:07 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 23 Jun 2007 23:46:07 -0400 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: <200706231434.43864.lontra@localhost.localdomain> References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: <200706232346.08328.lightsolphoenix@gmail.com> On Saturday, June 23, 2007 3:34 pm Christopher David Desjardins wrote: > 1. QT-Frontend for YUM > There are lots of good GTK frontends for yum (pirut, yumex) but there > aren't really any good QT frontends for yum. There is kyum but it's > certainly lacking in comparison to yumex. I think a QT version of yumex > could be real nice and it could cut down on GTK dependencies in KDE, maybe? > Another suggestions would be to port Adept from Kubuntu or Debian. > > 2. KDE Update Notifier > Maybe a frontend for pup in QT or adept-updater? When my current responsibilities are up, I'm going to try writing a KDE4 version of Adept targetted at Fedora myself. However, I don't really know when that might be... -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From jeevanullas at gmail.com Sun Jun 24 05:18:53 2007 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Sun, 24 Jun 2007 10:48:53 +0530 Subject: glade3 in fedora7 Message-ID: <1182662333.5754.2.camel@localhost.localdomain> Hi, Is Glade3 available on Fedora7. I saw it has been stable for long time now and I found no package with name Glade3. Is there no Glade3 in Fedora7 and if it isn't why is it so ? Thanks From laroche at redhat.com Sun Jun 24 05:47:23 2007 From: laroche at redhat.com (Florian La Roche) Date: Sun, 24 Jun 2007 07:47:23 +0200 Subject: rawhide report: 20070623 changes In-Reply-To: <20070623162630.GG25468@psilocybe.teonanacatl.org> References: <200706231008.l5NA87X8023492@porkchop.devel.redhat.com> <20070623162630.GG25468@psilocybe.teonanacatl.org> Message-ID: <20070624054723.GA3341@dudweiler.stuttgart.redhat.com> > I think the reviewer was confused about another guidelines section > which admonishes use of the Vendor: header in the spec file. Perhaps > that confusion has spread? :) I've seen one rpm package that defined a macro named "vendor" and that then also shows up as RPMTAG_VENDOR. The cure for this would be to just use a different macro name within the spec file. regards, Florian La Roche From lightsolphoenix at gmail.com Sun Jun 24 05:57:51 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 24 Jun 2007 01:57:51 -0400 Subject: glade3 in fedora7 In-Reply-To: <1182662333.5754.2.camel@localhost.localdomain> References: <1182662333.5754.2.camel@localhost.localdomain> Message-ID: <200706240157.52449.lightsolphoenix@gmail.com> On Sunday, June 24, 2007 1:18 am Deependra Singh Shekhawat wrote: > Hi, > > Is Glade3 available on Fedora7. I saw it has been stable for long time > now and I found no package with name Glade3. > > Is there no Glade3 in Fedora7 and if it isn't why is it so ? > > Thanks I just ran through the whole collection of packages in the main repo (setting up my laptop) and I saw the version of Gazpacho that's compatible with Glade3, but not Glade3 itself. Only Glade2. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From kevin.kofler at chello.at Sun Jun 24 06:05:13 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 24 Jun 2007 06:05:13 +0000 (UTC) Subject: KDE suggestions for Fedora 8 and beyond References: <200706231434.43864.lontra@localhost.localdomain> <13dbfe4f0706231903j5e1049dbm726d5cea5abfb1e7@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > There is already someone who was porting adept to fedora. That someone is the author of Adept himself, who happens to work for Red Hat: http://people.redhat.com/prockai/ :-) I don't know what happened to either mornfall.net or the apt-rpm port of Adept though. > My wish item for fedora kde would be : > * one click rpm installation with konqueror (just like in firefox) :) > that will help some newbies, since dependencies are met automatically. This is just a matter of assigning the RPM MIME type to system-install-packages. It should happen automatically with KDE 4 now that it's using the same shared-mime-info data GNOME is using. Kevin Kofler From splinux at fedoraproject.org Sun Jun 24 06:19:32 2007 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 24 Jun 2007 08:19:32 +0200 Subject: glade3 in fedora7 In-Reply-To: <1182662333.5754.2.camel@localhost.localdomain> References: <1182662333.5754.2.camel@localhost.localdomain> Message-ID: 2007/6/24, Deependra Singh Shekhawat : > > Hi, > > Is Glade3 available on Fedora7. I saw it has been stable for long time > now and I found no package with name Glade3. > > Is there no Glade3 in Fedora7 and if it isn't why is it so ? > > Thanks There's a review request there : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177747 -------------- next part -------------- An HTML attachment was scrubbed... URL: From buytenh at wantstofly.org Sun Jun 24 06:28:58 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Sun, 24 Jun 2007 08:28:58 +0200 Subject: fedora for ARM In-Reply-To: <20070602032955.GC16918@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> Message-ID: <20070624062858.GA22368@xi.wantstofly.org> On Sat, Jun 02, 2007 at 05:29:55AM +0200, Lennert Buytenhek wrote: > I'm posting here because I would really really like to get the relevant > diffs merged back into Fedora. I believe that ARM is well-supported in > the various upstream projects that Fedora packages, and so this should > be a relatively painless process (if you look at the diffs referenced > above, most diffs are actually only spec file changes to cope with the > addition of a new architecture.) A number of things have happened since I wrote this. For one, we now have a wiki page: http://fedoraproject.org/wiki/ARM We also have a mailing list: http://www.redhat.com/mailman/listinfo/fedora-arm And an IRC channel: #fedora-arm on freenode And I've submitted most of our 'easy' patches to the bug monster: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245418 To anyone interested in the ARM port, feel free to join the fedora-arm@ mailing list and/or the IRC channel. cheers, Lennert From guhvies at gmail.com Sun Jun 24 07:51:58 2007 From: guhvies at gmail.com (ne...) Date: Sun, 24 Jun 2007 08:51:58 +0100 Subject: KDE suggestions for Fedora 8 and beyond In-Reply-To: References: <200706231434.43864.lontra@localhost.localdomain> Message-ID: On 6/24/07, Rex Dieter wrote: > ne... wrote: > > > I want a pure KDE desktop, not a hybrid one. > > If you use a loose definition of "pure", the Fedora 7 Live spin gives you > something close to that. I agree with what you are saying, however this is needed from the dvd install. The dvd gives a choice of both gnome & KDE. If I choose KDE, I should not have to go thru everything unselecting gnome stuff and choosing KDE. I had to do this for kdegames and gnome-games. That really ticked me off. Kudos for te gr8 job U do. ne... -- Registered Linux User # 125653 (http://counter.li.org) Certified: 75% bastard, 42% of which is tard. http://www.thespark.com/bastardtest Now accepting personal mail for GMail invites. From bbbush.yuan at gmail.com Sun Jun 24 08:05:35 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sun, 24 Jun 2007 16:05:35 +0800 Subject: glade3 in fedora7 In-Reply-To: References: <1182662333.5754.2.camel@localhost.localdomain> Message-ID: <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> 2007/6/24, Damien Durand : > > > > > There's a review request there : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177747 > Hi, I no longer want to submit that package (I cannot get that package passed for a very long time, partly because my laziness.) How to cancel my review request and forward it to another contributor? Thanks! -- bbbush ^_^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikigoyal at gmail.com Sun Jun 24 08:37:09 2007 From: vikigoyal at gmail.com (Vikram Goyal) Date: Sun, 24 Jun 2007 14:07:09 +0530 Subject: Parallel Booting In-Reply-To: <467BE85E.4070807@redhat.com> References: <467BE85E.4070807@redhat.com> Message-ID: <20070624083709.GA10572@f7host.f7domain> On Fri, Jun 22, 2007 at 05:18:54PM +0200, Harald Hoyer wrote: > Hello, > > some of you may have read some wiki pages about the plans for the new init system [1]. As a first step in > this direction [2], I packaged prcsys from Mandriva, patched initscripts with a very small patch, and uploaded > the src.rpm to [3]. To enable parallel booting just build and install both packages and edit > /etc/sysconfig/init. Set PARALLEL_STARTUP=yes and there we go. > > The next step would be to modify all initscripts in /etc/init.d to be LSB compliant [4]. This will speed up > booting, because they can and will be started in parallel. You should file bugzillas against the component, to > which this initscript belongs, with a patch (this has to be done anyway to be LSB compliant in regards to > initscripts over time). Especially the exit codes need to be fixed (which will make status queries a lot > easier and more robust). > > Early login [5] is also a next step towards a "fast boot" user experience. > > Alternatives to SysVInit (like upstart/initng) can live in Fedora as well, but we are very conservative in > changing the startup mechanism that proved to function for a long time now. Unless the "real" killer feature > is absolutly needed, we would like to keep backwards compatibility as long as possible. > > I hope many of you try and test [3] and write patches to improve our service initscripts to be LSB compliant > :-) Parallel booting is the reward. > > Happy testing, > Harald > > [1] http://fedoraproject.org/wiki/FCNewInit > [2] http://fedoraproject.org/wiki/FCNewInit/RC > [3] http://people.redhat.com/harald/downloads/initscripts/parallel/ > [4] http://fedoraproject.org/wiki/FCNewInit/Initscripts > [5] http://fedoraproject.org/wiki/FCNewInit/xdm > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/x-pkcs7-signature > Size: 3623 bytes > Desc: S/MIME Cryptographic Signature > Url : https://www.redhat.com/archives/fedora-devel-list/attachments/20070622/1a38ff1b/smime.bin > > ------------------------------ > Is it something like the script attached? If so then that'll be a really great idea. #----------------------------------------------------------------------- #/bin/bash # NAME: forfastboot # PLACE: /root/bin/ # AUTHOR: vikram goyal 230407 # # The file is to be called as: # The first time call is the filename itself and then its through service call # # service staggered start # # So that these services load up in the background & save boot time # [ -z "$STLOG" ] && STLOG=/dev/tty # DEBUGGING #echo \$1=$1 >> $STLOG SERVICEDIR=/etc/init.d SERVICENAME=staggered addchkserv() { # ADD/CHK THE SERVICE # ~~~~~~~~~~~~~~~~~~~ # If service file has changed copy the new one. If it does not # exist yet make a new one. if [ -f $SERVICEDIR/$SERVICENAME ]; then fchk=`mktemp` createserv $fchk [ -n "`diff $fchk $SERVICEDIR/$SERVICENAME`" ] && \ /sbin/chkconfig --del staggered && \ mv -f $fchk $SERVICEDIR/$SERVICENAME setperms else createserv $SERVICEDIR/$SERVICENAME echo service staggered added. setperms fi } addlogrotate() { if [ ! -f /etc/logrotate.d/$SERVICENAME ]; then eval cat >/etc/logrotate.d/$SERVICENAME <$servicesnames <> $STLOG fi } setperms() { /bin/chmod +x $SERVICEDIR/$SERVICENAME /sbin/chkconfig staggered on } createserv() { # Create service file in /etc/init.d/ eval cat >$1 < /dev/null 2>&1 #touch \$lockfile echo_success && echo } stop() { echo -n \$"Stopping service staggered: " #rm -f \$lockfile echo_success && echo } case "\$1" in start|stop) \$1 ;; restart) stop start ;; *) echo $"Usage: \$0 {start|stop|restart}" exit 1 ;; esac exit \$RETVAL EOF } START () { FN="$1" R=`/sbin/runlevel|cut -d ' ' -f2` echo -e "\n\t`date`\nSTART:" >> $STLOG # DEBUGGING #echo \$R=$R >> $STLOG for x in $STAGGERED_SERVICES do [ -n "`echo $x|egrep [0-9]\{1,2\}:?$`" ] && continue echo >> $STLOG [ ! -f $SERVICEDIR/$x ] && echo "error: file $SERVICEDIR/$x not found" >> $STLOG && continue [ -n "$EXCLUDE" ] && \ [ -n "`echo $EXCLUDE|grep -w $x`" ] && echo "service $x in exclude list" >> $STLOG && continue # Switch off the service. We will manage it ourselves. /sbin/chkconfig $x off >> $STLOG 2>&1 & unset C C=`cat $SERVICEDIR/$x|grep chkconfig|tr '[ ]' '[:]'|tr -s '[:]'|cut -d ":" -f3|grep [\-$R]` # DEBUGGING #echo \$C=$C \$R=$R >> $STLOG # Since the service x has been turned off. Check if it is supposed # to run in this level. If yes start it. if [ -n "$C" ]; then if [ -n "`echo $C|grep \-`" -a -z "`echo $R|grep [2345]`" ]; then echo "$R not one of 2,3,4,5 :$x not started" >> $STLOG continue fi /sbin/service $x status >> $STLOG 2>&1 && continue [ $? -gt 0 ] && \ ( /sbin/service $x start >> $STLOG & 2>&1; sleep ${STAGGERTIME}s ) else echo "error: $x not to start in $R" >> $STLOG fi done rm -f "/tmp/$FN" echo -e "\n\t`date`\nEND:" >> $STLOG } if [ -n "$servicesnames" ]; then . $servicesnames else # Not called from service file. It may not exist yet. addchkserv addservnames addlogrotate fi if [ -f "$1" ]; then # Tmp lock file has been created, so call the function. [ -z "$STAGGERTIME" ] && STAGGERTIME=7 # DEBUGGING #echo "loop \$1=$1 exe" >> $STLOG START $1 exit 0 elif [ "$1" != servicecall ]; then echo "call $0 from service staggered." exit 1 fi LF=`mktemp` touch "$LF" || exit 1 $0 "$LF" & exit #----------------------------------------------------------------------- -- vikram... |||||||| |||||||| ^^'''''^^||root||^^^'''''''^^ // \\ )) //(( \\// \\ // /\\ || \\ || / )) (( \\ -- My own business always bores me to death; I prefer other people's. -- Oscar Wilde -- ~|~ = Registered Linux User #285795 From splinux at fedoraproject.org Sun Jun 24 08:50:07 2007 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 24 Jun 2007 10:50:07 +0200 Subject: glade3 in fedora7 In-Reply-To: <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> Message-ID: Hi, > > I no longer want to submit that package (I cannot get that package passed > for a very long time, partly because my laziness.) How to cancel my review > request and forward it to another contributor? Thanks! > You can close your bug report, I'll repackage it later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben at rubenkerkhof.com Sun Jun 24 08:51:41 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sun, 24 Jun 2007 10:51:41 +0200 Subject: glade3 in fedora7 In-Reply-To: <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> Message-ID: <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> On 24-jun-2007, at 10:05, Yuan Yijun wrote: > Hi, > > I no longer want to submit that package (I cannot get that package > passed for a very long time, partly because my laziness.) How to > cancel my review request and forward it to another contributor? > Thanks! Write in the comments that you're no longer interested. Remove the FE-REVIEW blocker, and reassign to nobody at fedoraproject.org http://fedoraproject.org/wiki/Extras/Policy/StalledReviews Cheers, Ruben From jeevanullas at gmail.com Sun Jun 24 09:12:54 2007 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Sun, 24 Jun 2007 14:42:54 +0530 Subject: glade3 in fedora7 In-Reply-To: <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> Message-ID: <1182676374.7266.2.camel@localhost.localdomain> Hi, Do anyone care to tell when will I see glade3 in fedora7. It seems it has no future at the moment. I don't know much about package creation and maintain's so I guess I can't help. Earlier it was python-twisted and now it's Glade. Some of the old packages I listed on this mailing list. Waiting for glade3 on f7 soon !! Thanks On Sun, 2007-06-24 at 10:51 +0200, Ruben Kerkhof wrote: > On 24-jun-2007, at 10:05, Yuan Yijun wrote: > > > Hi, > > > > I no longer want to submit that package (I cannot get that package > > passed for a very long time, partly because my laziness.) How to > > cancel my review request and forward it to another contributor? > > Thanks! > > Write in the comments that you're no longer interested. > > Remove the FE-REVIEW blocker, and reassign to nobody at fedoraproject.org > http://fedoraproject.org/wiki/Extras/Policy/StalledReviews > > Cheers, > > Ruben > -- http://freeshells.ch/~source/ From buildsys at redhat.com Sun Jun 24 09:19:34 2007 From: buildsys at redhat.com (Build System) Date: Sun, 24 Jun 2007 05:19:34 -0400 Subject: rawhide report: 20070624 changes Message-ID: <200706240919.l5O9JYih029165@porkchop.devel.redhat.com> Updated Packages: ctapi-cyberjack-3.0.0-2.fc8 --------------------------- * Sat Jun 23 2007 Frank B??ttner - 3.0.0-2.fc8 - rebuild because of missing file in the cvs system * Sat Jun 23 2007 Frank B??ttner - 3.0.0-1.fc8 - final release for 3.0.0 dbmail-2.2.5-5.fc8 ------------------ * Sat Jun 23 2007 Bernard Johnson 2.2.5-5 - patch to reopen logs files on -HUP - patch to send error when thread references requested - don't filter libdbmail.so* * Sat Jun 23 2007 Bernard Johnson 2.2.5-4 - kill ld.so config - filter private libraries from provides (bz#245326) hatari-0.95-1.fc8 ----------------- * Sat Jun 23 2007 Andrea Musuruane 0.95-1.fc8 - updated to upstream 0.95 - updated description - README.tos and hatari.desktop are no longer built in the spec file - added new upstream hmsa tool - added new upstream french man page - updated icon cache scriptlets to be compliant to new guidelines - cosmetic changes * Sat Mar 17 2007 Andrea Musuruane 0.90-6.fc8 - dropped --add-category X-Fedora from desktop-file-install - changed .desktop category to Game;Emulator; - now using sed to fix makefile not to strip binaries during make install - cosmetic changes to BR section * Mon Oct 23 2006 Andrea Musuruane 0.90-5.fc8 - added a patch not to strip binaries during make install - added hicolor-icon-theme to Requires libXtst-1.0.2-1.fc8 ------------------- * Sat Jun 23 2007 Adam Jackson 1.0.2-1. - libXtst 1.0.2 * Sat Apr 21 2007 Matthias Clasen - 1.0.1-4 - Don't install INSTALL * Wed Jul 12 2006 Jesse Keating - 1.0.1-3.1 - rebuild perl-Email-Address-1.888-1.fc8 ------------------------------ * Sat Jun 23 2007 Jose Pedro Oliveira - 1.888-1 - Update to 1.888. perl-Net-DNS-0.60-1.fc8 ----------------------- * Sat Jun 23 2007 Robin Norwood - 0.60-1 - Upgrade to latest upstream version - 0.60 perl-Text-CSV_XS-0.30-1.fc8 --------------------------- * Sat Jun 23 2007 Jose Pedro Oliveira - 0.30-1 - Update to 0.30. revisor-2.0.3.11-1.fc8 ---------------------- * Sat Jun 23 2007 Jeroen van Meeuwen 2.0.3.11-1 - Adding comps-f7 to our distribution - Removing pungi configuration files - Fixed a major bug in unlinking / unmounting the left-overs of a previous live media run. - Enabled translation - Added ExcludeArch: ppc, ppc64. Our dependency livecd-tools is not available for these archs. srecord-1.35-1.fc8 ------------------ * Sat Jun 23 2007 Jose Pedro Oliveira - 1.35-1 - Update to 1.35. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.11-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From ville.skytta at iki.fi Sun Jun 24 10:37:19 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 24 Jun 2007 13:37:19 +0300 Subject: Parallel Booting In-Reply-To: <467BE85E.4070807@redhat.com> References: <467BE85E.4070807@redhat.com> Message-ID: <200706241337.20067.ville.skytta@iki.fi> On Friday 22 June 2007, Harald Hoyer wrote: > The next step would be to modify all initscripts in /etc/init.d to be LSB > compliant [4]. Does this imply that these modified init scripts should also be installed/removed with the LSB tools instead of chkconfig? See https://bugzilla.redhat.com/245494 From fedora at camperquake.de Sun Jun 24 11:15:51 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 24 Jun 2007 13:15:51 +0200 Subject: rawhide report: 20070623 changes In-Reply-To: <200706231008.l5NA87X8023492@porkchop.devel.redhat.com> References: <200706231008.l5NA87X8023492@porkchop.devel.redhat.com> Message-ID: <20070624131551.6f085835@lain.camperquake.de> Hi. On Sat, 23 Jun 2007 06:08:07 -0400, Build System wrote > kernel-2.6.21-1.3234.fc8 > ------------------------ > * Fri Jun 22 2007 Dave Jones > - 2.6.22-rc5-git6. There seem to be no mac80211 drivers in this package. From ivazqueznet at gmail.com Sun Jun 24 14:00:45 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 24 Jun 2007 10:00:45 -0400 Subject: Making ndesk-dbus build in mock In-Reply-To: <1182647789.4366.12.camel@dawkins> References: <1182647789.4366.12.camel@dawkins> Message-ID: <1182693645.3780.1.camel@ignacio.lan> On Sun, 2007-06-24 at 03:16 +0200, David Nielsen wrote: > Can anyone spot my mistake? > > http://www.lovesunix.net/fedora/ndesk-dbus.spec > http://www.lovesunix.net/fedora/ndesk-dbus-0.5.2-1.fc8.src.rpm WORKSFORME Built fine for both F7 and Rawhide in mock. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at lovesunix.net Sun Jun 24 14:30:48 2007 From: david at lovesunix.net (David Nielsen) Date: Sun, 24 Jun 2007 16:30:48 +0200 Subject: Making ndesk-dbus build in mock In-Reply-To: <1182693645.3780.1.camel@ignacio.lan> References: <1182647789.4366.12.camel@dawkins> <1182693645.3780.1.camel@ignacio.lan> Message-ID: <1182695448.28322.5.camel@dawkins> s?n, 24 06 2007 kl. 10:00 -0400, skrev Ignacio Vazquez-Abrams: > On Sun, 2007-06-24 at 03:16 +0200, David Nielsen wrote: > > Can anyone spot my mistake? > > > > http://www.lovesunix.net/fedora/ndesk-dbus.spec > > http://www.lovesunix.net/fedora/ndesk-dbus-0.5.2-1.fc8.src.rpm > > WORKSFORME > > Built fine for both F7 and Rawhide in mock. Very odd.. it fails every frikkin time here, I clean the specs up a bit and submitted them for review (#245491 and #245492). I'm hoping it's just my setup that's slightly wonky then. Thank you for testing though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From sundaram at fedoraproject.org Sun Jun 24 16:02:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 24 Jun 2007 21:32:45 +0530 Subject: glade3 in fedora7 In-Reply-To: <1182676374.7266.2.camel@localhost.localdomain> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> <1182676374.7266.2.camel@localhost.localdomain> Message-ID: <467E95A5.2060506@fedoraproject.org> Deependra Singh Shekhawat wrote: > Hi, > > Do anyone care to tell when will I see glade3 in fedora7. It seems it > has no future at the moment. I don't know much about package creation > and maintain's so I guess I can't help. Sure you can learn to, if you have the interest. Rahul From laxathom at fedoraproject.org Sun Jun 24 16:34:09 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sun, 24 Jun 2007 12:34:09 -0400 Subject: glade3 in fedora7 In-Reply-To: <467E95A5.2060506@fedoraproject.org> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> <1182676374.7266.2.camel@localhost.localdomain> <467E95A5.2060506@fedoraproject.org> Message-ID: <62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com> hi folks, if you agree, i can take it over and upload an spec and sprm files for the next week. Damien, do you already work to spawn a package or plan to ? -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbbush.yuan at gmail.com Sun Jun 24 16:36:58 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Mon, 25 Jun 2007 00:36:58 +0800 Subject: glade3 in fedora7 In-Reply-To: <62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> <1182676374.7266.2.camel@localhost.localdomain> <467E95A5.2060506@fedoraproject.org> <62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com> Message-ID: <76e72f800706240936u2f529c4x6d37983f64a53900@mail.gmail.com> 2007/6/25, Xavier Lamien : > > hi folks, > > if you agree, i can take it over and upload an spec and sprm files for the > next week. > > Damien, do you already work to spawn a package or plan to ? Hi, You can still use my SPEC and SRPM at ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3.spec ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3-3.2.0-1.src.rpm Wish you are lucky and get it reviewed soon. Thanks! -- bbbush ^_^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From laxathom at fedoraproject.org Sun Jun 24 16:42:46 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sun, 24 Jun 2007 12:42:46 -0400 Subject: glade3 in fedora7 In-Reply-To: <76e72f800706240936u2f529c4x6d37983f64a53900@mail.gmail.com> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> <1182676374.7266.2.camel@localhost.localdomain> <467E95A5.2060506@fedoraproject.org> <62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com> <76e72f800706240936u2f529c4x6d37983f64a53900@mail.gmail.com> Message-ID: <62bc09df0706240942k2ad55381wcae32d4aceb2a5c4@mail.gmail.com> 2007/6/24, Yuan Yijun : > > > > 2007/6/25, Xavier Lamien : > > > > hi folks, > > > > if you agree, i can take it over and upload an spec and sprm files for > > the next week. > > > > Damien, do you already work to spawn a package or plan to ? > > > > Hi, > > You can still use my SPEC and SRPM at > > ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3.spec > ftp://ftp.fedora.cn/pub/fedora-cn/in-review/glade3-3.2.0-1.src.rpm > > Wish you are lucky and get it reviewed soon. Thanks! > Thanks, I'll check them out. -- > bbbush ^_^ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at apestaart.org Sun Jun 24 13:37:32 2007 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 24 Jun 2007 15:37:32 +0200 Subject: glade3 in fedora7 In-Reply-To: <1182676374.7266.2.camel@localhost.localdomain> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> <1182676374.7266.2.camel@localhost.localdomain> Message-ID: <1182692252.3665.1.camel@otto.amantes> On Sun, 2007-06-24 at 14:42 +0530, Deependra Singh Shekhawat wrote: > Hi, > > Do anyone care to tell when will I see glade3 in fedora7. It seems it > has no future at the moment. I don't know much about package creation > and maintain's so I guess I can't help. > > Earlier it was python-twisted and now it's Glade. Some of the old > packages I listed on this mailing list. With all due respect, Fedora is put together by volunteers. Just as I told you about python-twisted, things happen faster if you actually contribute usefully. You could also try to phrase your requests less like demands, I find in general that helps a lot more. Thomas -- I will play you like a shark And I'll clutch at your heart I'll come flying like a spark To enflame you -- MOAP - Maintaining your projects since 2006 https://apestaart.org/moap/trac/ From jwboyer at jdub.homelinux.org Sun Jun 24 20:18:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 24 Jun 2007 15:18:55 -0500 Subject: FESCo elections In-Reply-To: <1182644731.10205.300.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> <1182644731.10205.300.camel@erato.phig.org> Message-ID: <1182716335.16446.18.camel@vader.jdub.homelinux.org> On Sat, 2007-06-23 at 17:25 -0700, Karsten Wade wrote: > On Wed, 2007-06-20 at 14:25 -0500, Jason L Tibbitts III wrote: > > >>>>> "JS" == Jeff Spaleta writes: > > > > JS> If someone was going to attempt to ask for sponsorship without > > JS> submitting a new package...where do they start? > > > > Apply for cvsextras membership in the account system and find someone > > to sponsor them through whatever channels they wish. > > OK, so, if I really want to vote for FESCo, I can sneak my way into the > voting pool if I know somebody? It is possible. Would be odd if someone were added to cvsextras without a decent reason though. > This does not sound like the kind of "democracy" that we want. Who said it was a democracy? > Why have > a special pool of citizens? Almost every election system I know of has some kind of qualifications for potential voters. > And does the special pool have to be made > up only of the kind of people who are being elected? >From where I sit, to a degree, yes. Or at least of a similar role. FESCo makes the _engineering_ decisions. Those decisions effect the package maintainers, rel-eng, QA, infrastructure, docs, etc. groups directly. If you aren't in one of those groups, it is a rare occasion that a FESCo decision has direct impact on you. If you want to open it up to anyone with the CLA signed, fine. I'm not directly against that. I don't see what benefit that has, but ok. Frankly, I think the FPB election is the one that should be more "open" if you will. Those decisions will likely have far more impact on the broader Fedora universe. Remember, FPB is "big idea, big change, big impact" type decisions. > Special pools of voters for special positions: > > * Only lawyers can vote for Federal Judges. > * Only medicos are allowed to vote for Surgeon General. > * Only white males are allowed to vote for President. > > What if you are not in that special pool and want to run or vote? Put > on some whiteface and fake a law degree? Do not attempt to compare the election process with some form of racism. It is not, and the comparison is so far off base that I'm fairly pissed you even made it. josh From greno at verizon.net Sun Jun 24 21:36:36 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 24 Jun 2007 17:36:36 -0400 Subject: yum upgrade error http 404 on tsclient rpm Message-ID: <467EE3E4.1040307@verizon.net> I decided to try to yum upgrade an FC6 machine today to F7 so I installed the fedora-release rpms for F7 and then ran yum upgrade, but I'm getting 404 errors on package tsclient. It tries a bunch of mirrors and then says no more mirrors to try. Is anyone else seeing this? From greno at verizon.net Sun Jun 24 22:16:23 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 24 Jun 2007 18:16:23 -0400 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467EE3E4.1040307@verizon.net> References: <467EE3E4.1040307@verizon.net> Message-ID: <467EED37.6010802@verizon.net> Gerry Reno wrote: > I decided to try to yum upgrade an FC6 machine today to F7 so I > installed the fedora-release rpms for F7 and then ran yum upgrade, but > I'm getting 404 errors on package tsclient. It tries a bunch of > mirrors and then says no more mirrors to try. Is anyone else seeing > this? > > Ok, I waited a while a retried this again. It goes along for quite a while and then finally gets these errors: --> Finished Dependency Resolution Error: Missing Dependency: libnetsnmp.so.10 is needed by package net-snmp-utils Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package mysql-bench Error: Missing Dependency: krb5-libs = 1.5-21 is needed by package krb5-server Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by package mono-data Error: Missing Dependency: libdvdread.so.3 is needed by package k3b Error: Missing Dependency: php-common = 5.1.6-3.6.fc6 is needed by package php-mbstring Error: Missing Dependency: libsndfile.so.1(libsndfile.so.1.0) is needed by package k3b Error: Missing Dependency: gnutls = 1.4.1-2 is needed by package gnutls-utils Error: Missing Dependency: python(abi) = 2.4 is needed by package aqbanking Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package qt-ODBC Error: Missing Dependency: libgcj.so.7rh is needed by package libglade-java Error: Missing Dependency: poppler = 0.5.4-5.fc6 is needed by package poppler-utils Error: Missing Dependency: vim-common = 2:7.0.235-1.fc6 is needed by package vim-X11 Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package gcc-gnat Error: Missing Dependency: libgcj.so.7rh is needed by package libgconf-java Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by package mono-web Error: Missing Dependency: libpq.so.4 is needed by package postgresql-odbc Error: Missing Dependency: libsamplerate.so.0(libsamplerate.so.0.0) is needed by package k3b Error: Missing Dependency: libgcj.so.7rh is needed by package libgtk-java Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by package mono-data-sqlite Error: Missing Dependency: nmap = 2:4.11 is needed by package nmap-frontend Error: Missing Dependency: unixODBC = 2.2.11-7.1 is needed by package unixODBC-kde Error: Missing Dependency: libpisock.so.8 is needed by package gnome-pilot-conduits Error: Missing Dependency: libavahi-core.so.4 is needed by package avahi-tools Error: Missing Dependency: libgcj.so.7rh is needed by package cairo-java Error: Missing Dependency: openldap = 2.3.30-2.fc6 is needed by package openldap-servers Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package gcc-objc Error: Missing Dependency: libsndfile.so.1 is needed by package k3b Error: Missing Dependency: net-snmp = 1:5.3.1 is needed by package net-snmp-utils Error: Missing Dependency: python(abi) = 2.4 is needed by package avahi-tools Error: Missing Dependency: avahi = 0.6.16 is needed by package avahi-tools Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package mysql-devel Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package qt-MySQL Error: Missing Dependency: libnetsnmp.so.10 is needed by package stonith Error: Missing Dependency: libedataserver-1.2.so.7 is needed by package evolution-sharp Error: Missing Dependency: libgcj.so.7rh is needed by package libgnome-java Error: Missing Dependency: libsamplerate.so.0 is needed by package k3b Error: Missing Dependency: neon = 0.25.5-5.1 is needed by package neon-devel Error: Missing Dependency: hal = 0.5.8.1-6.fc6 is needed by package hal-gnome Error: Missing Dependency: libgcj.so.7rh is needed by package libvte-java # From dtimms at iinet.net.au Sun Jun 24 23:25:36 2007 From: dtimms at iinet.net.au (David Timms) Date: Mon, 25 Jun 2007 09:25:36 +1000 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467EED37.6010802@verizon.net> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> Message-ID: <467EFD70.4080004@iinet.net.au> Gerry Reno wrote: > Gerry Reno wrote: >> I decided to try to yum upgrade an FC6 machine today to F7 so I >> installed the fedora-release rpms for F7 and then ran yum upgrade, but >> I'm getting 404 errors on package tsclient. It tries a bunch of >> mirrors and then says no more mirrors to try. Is anyone else seeing >> this? >> >> > Ok, I waited a while a retried this again. It goes along for quite a > while and then finally gets these errors: > > --> Finished Dependency Resolution > Error: Missing Dependency: libnetsnmp.so.10 is needed by package > net-snmp-utils > Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package > mysql-bench > Error: Missing Dependency: krb5-libs = 1.5-21 is needed by package > krb5-server > Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by > package mono-data > Error: Missing Dependency: libdvdread.so.3 is needed by package k3b > Error: Missing Dependency: php-common = 5.1.6-3.6.fc6 is needed by > package php-mbstring > Error: Missing Dependency: libsndfile.so.1(libsndfile.so.1.0) is needed > by package k3b > Error: Missing Dependency: gnutls = 1.4.1-2 is needed by package > gnutls-utils > Error: Missing Dependency: python(abi) = 2.4 is needed by package aqbanking > Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package > qt-ODBC > Error: Missing Dependency: libgcj.so.7rh is needed by package libglade-java > Error: Missing Dependency: poppler = 0.5.4-5.fc6 is needed by package > poppler-utils > Error: Missing Dependency: vim-common = 2:7.0.235-1.fc6 is needed by > package vim-X11 > Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package gcc-gnat > Error: Missing Dependency: libgcj.so.7rh is needed by package libgconf-java > Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by > package mono-web > Error: Missing Dependency: libpq.so.4 is needed by package postgresql-odbc > Error: Missing Dependency: libsamplerate.so.0(libsamplerate.so.0.0) is > needed by package k3b > Error: Missing Dependency: libgcj.so.7rh is needed by package libgtk-java > Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by > package mono-data-sqlite > Error: Missing Dependency: nmap = 2:4.11 is needed by package nmap-frontend > Error: Missing Dependency: unixODBC = 2.2.11-7.1 is needed by package > unixODBC-kde > Error: Missing Dependency: libpisock.so.8 is needed by package > gnome-pilot-conduits > Error: Missing Dependency: libavahi-core.so.4 is needed by package > avahi-tools > Error: Missing Dependency: libgcj.so.7rh is needed by package cairo-java > Error: Missing Dependency: openldap = 2.3.30-2.fc6 is needed by package > openldap-servers > Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package gcc-objc > Error: Missing Dependency: libsndfile.so.1 is needed by package k3b > Error: Missing Dependency: net-snmp = 1:5.3.1 is needed by package > net-snmp-utils > Error: Missing Dependency: python(abi) = 2.4 is needed by package > avahi-tools > Error: Missing Dependency: avahi = 0.6.16 is needed by package avahi-tools > Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package > mysql-devel > Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package > qt-MySQL > Error: Missing Dependency: libnetsnmp.so.10 is needed by package stonith > Error: Missing Dependency: libedataserver-1.2.so.7 is needed by package > evolution-sharp > Error: Missing Dependency: libgcj.so.7rh is needed by package libgnome-java > Error: Missing Dependency: libsamplerate.so.0 is needed by package k3b > Error: Missing Dependency: neon = 0.25.5-5.1 is needed by package > neon-devel > Error: Missing Dependency: hal = 0.5.8.1-6.fc6 is needed by package > hal-gnome > Error: Missing Dependency: libgcj.so.7rh is needed by package libvte-java I think this is because some of the packages {tsclient} are not in "what was previously known as core": http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/ If you do the upgrade using the Everything, you might have better luck since it includes what was known as extras {needed for some of the packages you currently have installed}: http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Everything/i386 The other option is to rpm -qa>mypackages.txt, then remove the packages that cause problems, and then upgrade. DaveT. From greno at verizon.net Sun Jun 24 23:49:50 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 24 Jun 2007 19:49:50 -0400 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467EFD70.4080004@iinet.net.au> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> <467EFD70.4080004@iinet.net.au> Message-ID: <467F031E.40108@verizon.net> David Timms wrote: > Gerry Reno wrote: >> Gerry Reno wrote: >>> I decided to try to yum upgrade an FC6 machine today to F7 so I >>> installed the fedora-release rpms for F7 and then ran yum upgrade, >>> but I'm getting 404 errors on package tsclient. It tries a bunch of >>> mirrors and then says no more mirrors to try. Is anyone else seeing >>> this? >>> >>> >> Ok, I waited a while a retried this again. It goes along for quite a >> while and then finally gets these errors: >> >> --> Finished Dependency Resolution >> Error: Missing Dependency: libnetsnmp.so.10 is needed by package >> net-snmp-utils >> Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package >> mysql-bench >> Error: Missing Dependency: krb5-libs = 1.5-21 is needed by package >> krb5-server >> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >> package mono-data >> Error: Missing Dependency: libdvdread.so.3 is needed by package k3b >> Error: Missing Dependency: php-common = 5.1.6-3.6.fc6 is needed by >> package php-mbstring >> Error: Missing Dependency: libsndfile.so.1(libsndfile.so.1.0) is >> needed by package k3b >> Error: Missing Dependency: gnutls = 1.4.1-2 is needed by package >> gnutls-utils >> Error: Missing Dependency: python(abi) = 2.4 is needed by package >> aqbanking >> Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package >> qt-ODBC >> Error: Missing Dependency: libgcj.so.7rh is needed by package >> libglade-java >> Error: Missing Dependency: poppler = 0.5.4-5.fc6 is needed by package >> poppler-utils >> Error: Missing Dependency: vim-common = 2:7.0.235-1.fc6 is needed by >> package vim-X11 >> Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package >> gcc-gnat >> Error: Missing Dependency: libgcj.so.7rh is needed by package >> libgconf-java >> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >> package mono-web >> Error: Missing Dependency: libpq.so.4 is needed by package >> postgresql-odbc >> Error: Missing Dependency: libsamplerate.so.0(libsamplerate.so.0.0) >> is needed by package k3b >> Error: Missing Dependency: libgcj.so.7rh is needed by package >> libgtk-java >> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >> package mono-data-sqlite >> Error: Missing Dependency: nmap = 2:4.11 is needed by package >> nmap-frontend >> Error: Missing Dependency: unixODBC = 2.2.11-7.1 is needed by package >> unixODBC-kde >> Error: Missing Dependency: libpisock.so.8 is needed by package >> gnome-pilot-conduits >> Error: Missing Dependency: libavahi-core.so.4 is needed by package >> avahi-tools >> Error: Missing Dependency: libgcj.so.7rh is needed by package cairo-java >> Error: Missing Dependency: openldap = 2.3.30-2.fc6 is needed by >> package openldap-servers >> Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package >> gcc-objc >> Error: Missing Dependency: libsndfile.so.1 is needed by package k3b >> Error: Missing Dependency: net-snmp = 1:5.3.1 is needed by package >> net-snmp-utils >> Error: Missing Dependency: python(abi) = 2.4 is needed by package >> avahi-tools >> Error: Missing Dependency: avahi = 0.6.16 is needed by package >> avahi-tools >> Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package >> mysql-devel >> Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package >> qt-MySQL >> Error: Missing Dependency: libnetsnmp.so.10 is needed by package stonith >> Error: Missing Dependency: libedataserver-1.2.so.7 is needed by >> package evolution-sharp >> Error: Missing Dependency: libgcj.so.7rh is needed by package >> libgnome-java >> Error: Missing Dependency: libsamplerate.so.0 is needed by package k3b >> Error: Missing Dependency: neon = 0.25.5-5.1 is needed by package >> neon-devel >> Error: Missing Dependency: hal = 0.5.8.1-6.fc6 is needed by package >> hal-gnome >> Error: Missing Dependency: libgcj.so.7rh is needed by package >> libvte-java > I think this is because some of the packages {tsclient} are not in > "what was previously known as core": > http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/ > > > If you do the upgrade using the Everything, you might have better luck > since it includes what was known as extras {needed for some of the > packages you currently have installed}: > http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Everything/i386 > > The other option is to rpm -qa>mypackages.txt, then remove the > packages that cause problems, and then upgrade. > > DaveT. > Hmm... I don't think I want to do an Everything upgrade on this server. As far as removing packages. Sure as heck if I start removing some of these it will break some other dependencies. I just don't see why it says all these are missing as they are all installed: rpm -q mysql krb5-libs mono-core php-common gnutls python qt poppler vim-common gcc nmap unixODBC openldap net-snmp avahi mysql neon hal mysql-5.0.27-1.fc6 krb5-libs-1.5-21 mono-core-1.1.17.1-4.fc6 php-common-5.1.6-3.6.fc6 gnutls-1.4.1-2 python-2.4.4-1.fc6 qt-3.3.7-0.1.fc6 poppler-0.5.4-5.fc6 vim-common-7.0.235-1.fc6 gcc-4.1.1-51.fc6 nmap-4.11-1.1 unixODBC-2.2.11-7.1 openldap-2.3.30-2.fc6 net-snmp-5.3.1-14.fc6 avahi-0.6.16-4.fc6 mysql-5.0.27-1.fc6 neon-0.25.5-5.1 hal-0.5.8.1-6.fc6 From greno at verizon.net Mon Jun 25 00:29:05 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 24 Jun 2007 20:29:05 -0400 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467F031E.40108@verizon.net> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> <467EFD70.4080004@iinet.net.au> <467F031E.40108@verizon.net> Message-ID: <467F0C51.1030402@verizon.net> Gerry Reno wrote: > David Timms wrote: >> Gerry Reno wrote: >>> Gerry Reno wrote: >>>> I decided to try to yum upgrade an FC6 machine today to F7 so I >>>> installed the fedora-release rpms for F7 and then ran yum upgrade, >>>> but I'm getting 404 errors on package tsclient. It tries a bunch >>>> of mirrors and then says no more mirrors to try. Is anyone else >>>> seeing this? >>>> >>>> >>> Ok, I waited a while a retried this again. It goes along for quite >>> a while and then finally gets these errors: >>> >>> --> Finished Dependency Resolution >>> Error: Missing Dependency: libnetsnmp.so.10 is needed by package >>> net-snmp-utils >>> Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package >>> mysql-bench >>> Error: Missing Dependency: krb5-libs = 1.5-21 is needed by package >>> krb5-server >>> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >>> package mono-data >>> Error: Missing Dependency: libdvdread.so.3 is needed by package k3b >>> Error: Missing Dependency: php-common = 5.1.6-3.6.fc6 is needed by >>> package php-mbstring >>> Error: Missing Dependency: libsndfile.so.1(libsndfile.so.1.0) is >>> needed by package k3b >>> Error: Missing Dependency: gnutls = 1.4.1-2 is needed by package >>> gnutls-utils >>> Error: Missing Dependency: python(abi) = 2.4 is needed by package >>> aqbanking >>> Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package >>> qt-ODBC >>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>> libglade-java >>> Error: Missing Dependency: poppler = 0.5.4-5.fc6 is needed by >>> package poppler-utils >>> Error: Missing Dependency: vim-common = 2:7.0.235-1.fc6 is needed by >>> package vim-X11 >>> Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package >>> gcc-gnat >>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>> libgconf-java >>> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >>> package mono-web >>> Error: Missing Dependency: libpq.so.4 is needed by package >>> postgresql-odbc >>> Error: Missing Dependency: libsamplerate.so.0(libsamplerate.so.0.0) >>> is needed by package k3b >>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>> libgtk-java >>> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >>> package mono-data-sqlite >>> Error: Missing Dependency: nmap = 2:4.11 is needed by package >>> nmap-frontend >>> Error: Missing Dependency: unixODBC = 2.2.11-7.1 is needed by >>> package unixODBC-kde >>> Error: Missing Dependency: libpisock.so.8 is needed by package >>> gnome-pilot-conduits >>> Error: Missing Dependency: libavahi-core.so.4 is needed by package >>> avahi-tools >>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>> cairo-java >>> Error: Missing Dependency: openldap = 2.3.30-2.fc6 is needed by >>> package openldap-servers >>> Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package >>> gcc-objc >>> Error: Missing Dependency: libsndfile.so.1 is needed by package k3b >>> Error: Missing Dependency: net-snmp = 1:5.3.1 is needed by package >>> net-snmp-utils >>> Error: Missing Dependency: python(abi) = 2.4 is needed by package >>> avahi-tools >>> Error: Missing Dependency: avahi = 0.6.16 is needed by package >>> avahi-tools >>> Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package >>> mysql-devel >>> Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by package >>> qt-MySQL >>> Error: Missing Dependency: libnetsnmp.so.10 is needed by package >>> stonith >>> Error: Missing Dependency: libedataserver-1.2.so.7 is needed by >>> package evolution-sharp >>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>> libgnome-java >>> Error: Missing Dependency: libsamplerate.so.0 is needed by package k3b >>> Error: Missing Dependency: neon = 0.25.5-5.1 is needed by package >>> neon-devel >>> Error: Missing Dependency: hal = 0.5.8.1-6.fc6 is needed by package >>> hal-gnome >>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>> libvte-java >> I think this is because some of the packages {tsclient} are not in >> "what was previously known as core": >> http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/ >> >> >> If you do the upgrade using the Everything, you might have better >> luck since it includes what was known as extras {needed for some of >> the packages you currently have installed}: >> http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Everything/i386 >> >> The other option is to rpm -qa>mypackages.txt, then remove the >> packages that cause problems, and then upgrade. >> >> DaveT. >> > Hmm... I don't think I want to do an Everything upgrade on this > server. As far as removing packages. Sure as heck if I start > removing some of these it will break some other dependencies. I just > don't see why it says all these are missing as they are all installed: > > rpm -q mysql krb5-libs mono-core php-common gnutls python qt poppler > vim-common gcc nmap unixODBC openldap net-snmp avahi mysql neon hal > > mysql-5.0.27-1.fc6 > krb5-libs-1.5-21 > mono-core-1.1.17.1-4.fc6 > php-common-5.1.6-3.6.fc6 > gnutls-1.4.1-2 > python-2.4.4-1.fc6 > qt-3.3.7-0.1.fc6 > poppler-0.5.4-5.fc6 > vim-common-7.0.235-1.fc6 > gcc-4.1.1-51.fc6 > nmap-4.11-1.1 > unixODBC-2.2.11-7.1 > openldap-2.3.30-2.fc6 > net-snmp-5.3.1-14.fc6 > avahi-0.6.16-4.fc6 > mysql-5.0.27-1.fc6 > neon-0.25.5-5.1 > hal-0.5.8.1-6.fc6 > Reran the upgrade again and same result. Ok, now I need the 'yum undo'. How can I reset everything back with yum. So it quits saying 'set to be installed' to a big list of packages. From sundaram at fedoraproject.org Mon Jun 25 00:58:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Jun 2007 06:28:52 +0530 Subject: fedora for ARM In-Reply-To: <20070624062858.GA22368@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <20070624062858.GA22368@xi.wantstofly.org> Message-ID: <467F134C.3070809@fedoraproject.org> Lennert Buytenhek wrote: > On Sat, Jun 02, 2007 at 05:29:55AM +0200, Lennert Buytenhek wrote: > >> I'm posting here because I would really really like to get the relevant >> diffs merged back into Fedora. I believe that ARM is well-supported in >> the various upstream projects that Fedora packages, and so this should >> be a relatively painless process (if you look at the diffs referenced >> above, most diffs are actually only spec file changes to cope with the >> addition of a new architecture.) > > A number of things have happened since I wrote this. > > For one, we now have a wiki page: > http://fedoraproject.org/wiki/ARM > > We also have a mailing list: > http://www.redhat.com/mailman/listinfo/fedora-arm > > And an IRC channel: > #fedora-arm on freenode > > And I've submitted most of our 'easy' patches to the bug monster: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245418 > > To anyone interested in the ARM port, feel free to join the > fedora-arm@ mailing list and/or the IRC channel. You should add the mailing and irc channel info to http://fedoraproject.org/wiki/Communicate Rahul From n0dalus+redhat at gmail.com Mon Jun 25 01:14:32 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Mon, 25 Jun 2007 10:44:32 +0930 Subject: Inconsistent package tags Message-ID: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Hi all, On my rawhide system, I noticed that there are a lot of packages with inconsistent tags. There are (numbers in brackets are for packages built in the past 14 days): - 369 (216) packages with fc8 in the release tag (shouldn't we be using f8?) - 354 (1) packages with fc7 in the release tag - 205 (27) packages with no fedora version in the release tag - 42 (0) packages with fc6 in the release tag - 465 (0) packages with Vendor: Red Hat, Inc - 431 (244) packages with Vendor: Fedora Project - 74 (0) packages with Vendor: Koji - 465 (0) packages with Packager: Red Hat, Inc. - 363 (244) packages with Packager: Fedora Project - 74 (0) packages with Packager: Koji - 68 (0) packages with Packager: Fedora Project - 437 (244) packages with Distribution: Unknown - 369 (0) packages with Distribution: Red Hat (FC-7) - 90 (0) packages with Distribution: Red Hat (FC-6) - 68 (0) packages with Distribution: Fedora Extras - 6 (0) packages with Distribution: (none) - 759 (243) packages with Signature: (none) - 81 (0) packages with Signature: fd372689897da07a (Red Hat Beta?) - 72 (1) packages with Signature: b44269d04f2a6fd2 (Fedora?) - 58 (0) packages with Signature: 82ed95041ac70ce6 (Extras?) Obviously a lot of these packages haven't gone through the build system of late, but even the ones that have still show a few inconsistencies. Is this something that is being worked on? n0dalus. From greno at verizon.net Mon Jun 25 01:26:58 2007 From: greno at verizon.net (Gerry Reno) Date: Sun, 24 Jun 2007 21:26:58 -0400 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467F0C51.1030402@verizon.net> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> <467EFD70.4080004@iinet.net.au> <467F031E.40108@verizon.net> <467F0C51.1030402@verizon.net> Message-ID: <467F19E2.5090603@verizon.net> Gerry Reno wrote: > Gerry Reno wrote: >> David Timms wrote: >>> Gerry Reno wrote: >>>> Gerry Reno wrote: >>>>> I decided to try to yum upgrade an FC6 machine today to F7 so I >>>>> installed the fedora-release rpms for F7 and then ran yum upgrade, >>>>> but I'm getting 404 errors on package tsclient. It tries a bunch >>>>> of mirrors and then says no more mirrors to try. Is anyone else >>>>> seeing this? >>>>> >>>>> >>>> Ok, I waited a while a retried this again. It goes along for quite >>>> a while and then finally gets these errors: >>>> >>>> --> Finished Dependency Resolution >>>> Error: Missing Dependency: libnetsnmp.so.10 is needed by package >>>> net-snmp-utils >>>> Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by >>>> package mysql-bench >>>> Error: Missing Dependency: krb5-libs = 1.5-21 is needed by package >>>> krb5-server >>>> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >>>> package mono-data >>>> Error: Missing Dependency: libdvdread.so.3 is needed by package k3b >>>> Error: Missing Dependency: php-common = 5.1.6-3.6.fc6 is needed by >>>> package php-mbstring >>>> Error: Missing Dependency: libsndfile.so.1(libsndfile.so.1.0) is >>>> needed by package k3b >>>> Error: Missing Dependency: gnutls = 1.4.1-2 is needed by package >>>> gnutls-utils >>>> Error: Missing Dependency: python(abi) = 2.4 is needed by package >>>> aqbanking >>>> Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by >>>> package qt-ODBC >>>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>>> libglade-java >>>> Error: Missing Dependency: poppler = 0.5.4-5.fc6 is needed by >>>> package poppler-utils >>>> Error: Missing Dependency: vim-common = 2:7.0.235-1.fc6 is needed >>>> by package vim-X11 >>>> Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package >>>> gcc-gnat >>>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>>> libgconf-java >>>> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >>>> package mono-web >>>> Error: Missing Dependency: libpq.so.4 is needed by package >>>> postgresql-odbc >>>> Error: Missing Dependency: libsamplerate.so.0(libsamplerate.so.0.0) >>>> is needed by package k3b >>>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>>> libgtk-java >>>> Error: Missing Dependency: mono-core = 1.1.17.1-4.fc6 is needed by >>>> package mono-data-sqlite >>>> Error: Missing Dependency: nmap = 2:4.11 is needed by package >>>> nmap-frontend >>>> Error: Missing Dependency: unixODBC = 2.2.11-7.1 is needed by >>>> package unixODBC-kde >>>> Error: Missing Dependency: libpisock.so.8 is needed by package >>>> gnome-pilot-conduits >>>> Error: Missing Dependency: libavahi-core.so.4 is needed by package >>>> avahi-tools >>>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>>> cairo-java >>>> Error: Missing Dependency: openldap = 2.3.30-2.fc6 is needed by >>>> package openldap-servers >>>> Error: Missing Dependency: gcc = 4.1.1-51.fc6 is needed by package >>>> gcc-objc >>>> Error: Missing Dependency: libsndfile.so.1 is needed by package k3b >>>> Error: Missing Dependency: net-snmp = 1:5.3.1 is needed by package >>>> net-snmp-utils >>>> Error: Missing Dependency: python(abi) = 2.4 is needed by package >>>> avahi-tools >>>> Error: Missing Dependency: avahi = 0.6.16 is needed by package >>>> avahi-tools >>>> Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by >>>> package mysql-devel >>>> Error: Missing Dependency: qt = 1:3.3.7-0.1.fc6 is needed by >>>> package qt-MySQL >>>> Error: Missing Dependency: libnetsnmp.so.10 is needed by package >>>> stonith >>>> Error: Missing Dependency: libedataserver-1.2.so.7 is needed by >>>> package evolution-sharp >>>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>>> libgnome-java >>>> Error: Missing Dependency: libsamplerate.so.0 is needed by package k3b >>>> Error: Missing Dependency: neon = 0.25.5-5.1 is needed by package >>>> neon-devel >>>> Error: Missing Dependency: hal = 0.5.8.1-6.fc6 is needed by package >>>> hal-gnome >>>> Error: Missing Dependency: libgcj.so.7rh is needed by package >>>> libvte-java >>> I think this is because some of the packages {tsclient} are not in >>> "what was previously known as core": >>> http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/ >>> >>> >>> If you do the upgrade using the Everything, you might have better >>> luck since it includes what was known as extras {needed for some of >>> the packages you currently have installed}: >>> http://ftp.iinet.net.au/pub/fedora/linux/releases/7/Everything/i386 >>> >>> The other option is to rpm -qa>mypackages.txt, then remove the >>> packages that cause problems, and then upgrade. >>> >>> DaveT. >>> >> Hmm... I don't think I want to do an Everything upgrade on this >> server. As far as removing packages. Sure as heck if I start >> removing some of these it will break some other dependencies. I just >> don't see why it says all these are missing as they are all installed: >> >> rpm -q mysql krb5-libs mono-core php-common gnutls python qt poppler >> vim-common gcc nmap unixODBC openldap net-snmp avahi mysql neon hal >> >> mysql-5.0.27-1.fc6 >> krb5-libs-1.5-21 >> mono-core-1.1.17.1-4.fc6 >> php-common-5.1.6-3.6.fc6 >> gnutls-1.4.1-2 >> python-2.4.4-1.fc6 >> qt-3.3.7-0.1.fc6 >> poppler-0.5.4-5.fc6 >> vim-common-7.0.235-1.fc6 >> gcc-4.1.1-51.fc6 >> nmap-4.11-1.1 >> unixODBC-2.2.11-7.1 >> openldap-2.3.30-2.fc6 >> net-snmp-5.3.1-14.fc6 >> avahi-0.6.16-4.fc6 >> mysql-5.0.27-1.fc6 >> neon-0.25.5-5.1 >> hal-0.5.8.1-6.fc6 >> > > Reran the upgrade again and same result. Ok, now I need the 'yum > undo'. How can I reset everything back with yum. So it quits saying > 'set to be installed' to a big list of packages. > > I went and looked at the list of packages and dependencies again and it looks like some of the missing dependencies are for packages that have been marked for update to newer versions. So why isn't yum requiring newer versions of the packages for which it is complaining the dependencies are missing? Yum depsolv seems to be messed up. Using yum 3.0.6. From tibbs at math.uh.edu Mon Jun 25 01:31:22 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Jun 2007 20:31:22 -0500 Subject: Inconsistent package tags In-Reply-To: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: >>>>> "n" == n0dalus writes: n> Hi all, On my rawhide system, I noticed that there are a lot of n> packages with inconsistent tags. There are (numbers in brackets are n> for packages built in the past 14 days): n> 369 (216) packages with fc8 in the release tag (shouldn't we be n> using f8?) No, it's fc8. f8 would sort less than fc7, causing badness. n> 354 (1) packages with fc7 in the release tag 205 Well, the old packages are just fine; there's no reason for the tag to change if the package isn't rebuilt. The new one is troubling. Maybe someone tried to build with an outdated common directory, or perhaps there some other issue with the buildsys. n> (27) packages with no fedora version in the release tag What's wrong with that? n> 42 (0) packages with fc6 in the release tag What's wrong with that? - J< From ssorce at redhat.com Mon Jun 25 02:20:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 24 Jun 2007 22:20:58 -0400 Subject: Inconsistent package tags In-Reply-To: References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: <1182738058.10600.4.camel@localhost.localdomain> On Sun, 2007-06-24 at 20:31 -0500, Jason L Tibbitts III wrote: > No, it's fc8. f8 would sort less than fc7, causing badness. What about changing it to be fr8 (Fedora Release 8) ? Would that make more sense than keeping around a meaningless 'c' ? From n0dalus+redhat at gmail.com Mon Jun 25 02:34:24 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Mon, 25 Jun 2007 12:04:24 +0930 Subject: Inconsistent package tags In-Reply-To: References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: <6280325c0706241934xb1ae9f1j824b32b68881ad34@mail.gmail.com> On 24 Jun 2007 20:31:22 -0500, Jason L Tibbitts III wrote: > n> 369 (216) packages with fc8 in the release tag (shouldn't we be > n> using f8?) > > No, it's fc8. f8 would sort less than fc7, causing badness. I know, but its still undesirable to need to put 'fc' in every package of every release from this point on. Could packages be moved over to f8 by using release numbers, epochs or some other rpm hack? > n> (27) packages with no fedora version in the release tag > > What's wrong with that? > Technically nothing, but my point was that its inconsistent. n0dalus. From peter at thecodergeek.com Mon Jun 25 02:34:53 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 24 Jun 2007 19:34:53 -0700 Subject: Inconsistent package tags In-Reply-To: <1182738058.10600.4.camel@localhost.localdomain> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182738058.10600.4.camel@localhost.localdomain> Message-ID: <1182738893.3990.0.camel@tuxhugs> On Sun, 2007-06-24 at 22:20 -0400, Simo Sorce wrote: > What about changing it to be fr8 (Fedora Release 8) ? > Would that make more sense than keeping around a meaningless 'c' ? The "c" is not meaningless. The "FC" acronym now means "Fedora Collection" rather than "Fedora Core" in this case of the tags. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Jun 25 06:27:30 2007 From: kwade at redhat.com (Karsten Wade) Date: Sun, 24 Jun 2007 23:27:30 -0700 Subject: FESCo elections In-Reply-To: <1182716335.16446.18.camel@vader.jdub.homelinux.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> <1182644731.10205.300.camel@erato.phig.org> <1182716335.16446.18.camel@vader.jdub.homelinux.org> Message-ID: <1182752850.10205.371.camel@erato.phig.org> On Sun, 2007-06-24 at 15:18 -0500, Josh Boyer wrote: > On Sat, 2007-06-23 at 17:25 -0700, Karsten Wade wrote: > Who said it was a democracy? Elected meritocracy? Whatever you want to call it, it's a situation where a body is being elected, who has influence over a group of people who are being casually disenfranchised. > > Why have > > a special pool of citizens? > > Almost every election system I know of has some kind of qualifications > for potential voters. Usually blanket and minimal, such as, "Must be a citizen and of age." Not, "Member of a special guild," be it merchants or software packagers. > > And does the special pool have to be made > > up only of the kind of people who are being elected? > > >From where I sit, to a degree, yes. Or at least of a similar role. > FESCo makes the _engineering_ decisions. Those decisions effect the > package maintainers, rel-eng, QA, infrastructure, docs, etc. groups > directly. If you aren't in one of those groups, it is a rare occasion > that a FESCo decision has direct impact on you. If you want to open it > up to anyone with the CLA signed, fine. I'm not directly against that. > I don't see what benefit that has, but ok. Thanks for including Docs. That's the first time it was on anyone's list in this thread. I don't recall seeing L10n on anyone's list, but I guarantee they are greatly affected by FESCo decisions. In fact ... uh, I can make a case that every project is under the affect of FESCo decisions. Heading forward from here, your "rare case" is going to be flipped to the opposite position. Maybe not in all decisions, but in enough. > Frankly, I think the FPB election is the one that should be more "open" > if you will. Those decisions will likely have far more impact on the > broader Fedora universe. Remember, FPB is "big idea, big change, big > impact" type decisions. +1 ... but I figured that was a given. Have Fedora account, have ability to vote for FPB. But perhaps there is a "more open" you are looking for? > > Special pools of voters for special positions: > > > > * Only lawyers can vote for Federal Judges. > > * Only medicos are allowed to vote for Surgeon General. > > * Only white males are allowed to vote for President. > > > > What if you are not in that special pool and want to run or vote? Put > > on some whiteface and fake a law degree? > > Do not attempt to compare the election process with some form of racism. > It is not, and the comparison is so far off base that I'm fairly pissed > you even made it. I'm sorry that you took it as comparison to racism; it would have deserved a modified Godwin's, if that were the case. One hundred year ago, in the US, entire segments of the population were disenfranchised. The reasons why those groups were not allowed the vote were numerous. Yes, racism and sexism were chief amongst those reasons. Also, tradition ("Only white males run for President"). Inertia ("We'll never get a black/woman/Jew elected President"). The habit of the power elite to do what it takes to keep in power. Etc. My point is that, many in this thread have casually disenfranchised hundreds and hundreds[1] of active contributors. Rather than the disenfranchised explaining why they have a right to vote, I'd like us to consider this discussion from the other angle. Is there any good reason *not* to open FESCo elections (members and voting) to all of Fedora? This is predicated on the recent clarifications that show that it is FESCo's role to do the tactical deeds to make the Board's strategic vision come true. FESCo is specifically the body overseeing most of Fedora's sub-project activities, and while it may be a 'peer' with FAMSCo and FDSCo, it is really FESCo's decisions and actions that greatly affect the other groups, and not the other way around. If we proceed with FESCo election, we'll be disenfranchising nearly 2/3rd of our contributors based on if you happened to remind someone in this thread that your group should be included in the voters/candidates pool. Seems pretty senseless to me. - Karsten [1] Last I looked at cvsextras, it was ~438 members, while the total cla_done was 1300+. So, 'thousands' is an exa -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Jun 25 06:43:22 2007 From: kwade at redhat.com (Karsten Wade) Date: Sun, 24 Jun 2007 23:43:22 -0700 Subject: user created at install added in sudoers ? In-Reply-To: <20070620194028.GA5240@jadzia.bu.edu> References: <16de708d0706190756r7a68c9dau98378832d2b19039@mail.gmail.com> <4677F326.20905@RedHat.com> <1182276012.20455.1.camel@moogle> <46781CA7.2000706@fedoraproject.org> <364d303b0706191428n1f34d85dg2d0b00de9790bd68@mail.gmail.com> <46784D9B.8080608@fedoraproject.org> <364d303b0706191505j413474ele1cdec513bcdca7e@mail.gmail.com> <467871C8.20308@fedoraproject.org> <364d303b0706200156o25a13c5cl949e50f0fcb8b4bb@mail.gmail.com> <46796C4A.9030209@fedoraproject.org> <20070620194028.GA5240@jadzia.bu.edu> Message-ID: <1182753802.10205.377.camel@erato.phig.org> On Wed, 2007-06-20 at 15:40 -0400, Matthew Miller wrote: > On Wed, Jun 20, 2007 at 11:34:58PM +0530, Rahul Sundaram wrote: > > Documentation mentions su -c "command" all over the place. You have to > > consider whether you want to mention sudo or su or both if this is made > > a option. Dismissing concerns as poor without being involved is pretty > > easy. Documentation is far from the only concern with adding more options. > > We could easily set up the sudoers file like this: > > a) for wheel-group members, auth-as-self. > b) for non-wheel-group-members, sudo prompts for the *root* password. > > Then, 'su -c "command"' could be replaced with "sudo command" in the > documentation and would be correct in both cases. And since sudo has several > advantages over 'su -c', this is a win-win. We specifically settled on 'su -c' because we couldn't count on the existence of a properly configured sudoers file. We even have a simple sudo how-to that we were going to put in front as a "requirement", but the chance that someone is dropping in to a document via Google is too great to have any kind of enforceable requirements. If there were a reliable sudo situation, I doubt there would be any objection to adjusting the docs to use the superior method. - Karsten, NOPASSWD: ALL -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mschwendt.tmp0701.nospam at arcor.de Mon Jun 25 07:13:24 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 25 Jun 2007 09:13:24 +0200 Subject: Inconsistent package tags In-Reply-To: <1182738058.10600.4.camel@localhost.localdomain> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182738058.10600.4.camel@localhost.localdomain> Message-ID: <20070625091324.d00eeb73.mschwendt.tmp0701.nospam@arcor.de> On Sun, 24 Jun 2007 22:20:58 -0400, Simo Sorce wrote: > On Sun, 2007-06-24 at 20:31 -0500, Jason L Tibbitts III wrote: > > > No, it's fc8. f8 would sort less than fc7, causing badness. > > What about changing it to be fr8 (Fedora Release 8) ? > Would that make more sense than keeping around a meaningless 'c' ? It would create some more confusion, since ".fr" used to be a repo tag at freshrpms.net. From opensource at till.name Mon Jun 25 07:01:40 2007 From: opensource at till.name (Till Maas) Date: Mon, 25 Jun 2007 09:01:40 +0200 Subject: FESCo elections In-Reply-To: <1182752850.10205.371.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> Message-ID: <200706250901.41791.opensource@till.name> On Mo Juni 25 2007, Karsten Wade wrote: > Thanks for including Docs. That's the first time it was on anyone's > list in this thread. I don't recall seeing L10n on anyone's list, but I > guarantee they are greatly affected by FESCo decisions. In fact ... uh, > I can make a case that every project is under the affect of FESCo > decisions. Did anyone exclude Docs or L10n on purpose? I did not even know, that they were excluded. In fact as a maintainer, I do not know anything about how Docs or L10n are organised, e.g. who decides on the final release notes or how permissions are granted in cvs. So for a better discussion it may be better if you name all the groups that in you opinion should be able to vote. This makes it easier for Newbies like me to understand, what exactly is the problem. To include everyone with cla_done sounds not so good to me, because then everone in the world who gpg-signed the cla may vote, without there beeing a clear connection to Fedora. > consider this discussion from the other angle. Is there any good reason > *not* to open FESCo elections (members and voting) to all of Fedora? Who are all of Fedora? Is this everyone who installed Fedora or is using a system where Fedora is installed? Regards, Till From nicolas.mailhot at laposte.net Mon Jun 25 07:12:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 25 Jun 2007 09:12:48 +0200 (CEST) Subject: Inconsistent package tags In-Reply-To: <20070625091324.d00eeb73.mschwendt.tmp0701.nospam@arcor.de> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182738058.10600.4.camel@localhost.localdomain> <20070625091324.d00eeb73.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <64380.192.54.193.51.1182755568.squirrel@rousalka.dyndns.org> Le Lun 25 juin 2007 09:13, Michael Schwendt a ?crit : > On Sun, 24 Jun 2007 22:20:58 -0400, Simo Sorce wrote: > >> On Sun, 2007-06-24 at 20:31 -0500, Jason L Tibbitts III wrote: >> >> > No, it's fc8. f8 would sort less than fc7, causing badness. >> >> What about changing it to be fr8 (Fedora Release 8) ? >> Would that make more sense than keeping around a meaningless 'c' ? > > It would create some more confusion, since ".fr" used to be a > repo tag at freshrpms.net. actually it could be fe as in fedora everything if we insist on keeping this term (I'd rather have fedora collection used instead of everything myself, since it's much less english-specific) -- Nicolas Mailhot From ffesti at redhat.com Mon Jun 25 07:36:17 2007 From: ffesti at redhat.com (Florian Festi) Date: Mon, 25 Jun 2007 09:36:17 +0200 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467F19E2.5090603@verizon.net> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> <467EFD70.4080004@iinet.net.au> <467F031E.40108@verizon.net> <467F0C51.1030402@verizon.net> <467F19E2.5090603@verizon.net> Message-ID: <467F7071.6030506@redhat.com> Gerry Reno wrote: > I went and looked at the list of packages and dependencies again and it > looks like some of the missing dependencies are for packages that have > been marked for update to newer versions. So why isn't yum requiring > newer versions of the packages for which it is complaining the > dependencies are missing? Yum depsolv seems to be messed up. Using yum > 3.0.6. Check if those packages are installed twice with different versions. It is also possible that some multilib issues keeps some older versions from being removed during the update. yum doesn't handle such situations as graciously as one could image. So some manual help may be required. Florian Festi From buildsys at fedoraproject.org Mon Jun 25 08:47:29 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 25 Jun 2007 04:47:29 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-25 Message-ID: <20070625084729.40B69152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 19 adminutil-1.1.2-1.fc6 NEW babel-0.8-1.fc6 : Tools for internationalizing Python applications ctapi-cyberjack-3.0.0-2.fc6 NEW cvsplot-1.7.4-4.fc6 : Collect statistics from CVS controlled files dbmail-2.2.5-5.fc6 empathy-0.8-1.fc6 hatari-0.95-1.fc6 libosip-0.9.7-11.fc6 mod_fcgid-2.1-3.fc6 mozldap-6.0.4-1.fc6 ortp-0.13.1-3.fc6 perl-Email-Address-1.888-1.fc6 perl-Mozilla-LDAP-1.5.1-1.fc6 pitivi-0.10.3-1.fc6 scrip-1.4-7.fc6 smolt-0.9.8.3-1.fc6 srecord-1.35-1.fc6 (!) svrcore-4.0.4-1.fc6 : INVALID rebuild, not published! xscorch-0.2.0-9.fc6 Packages built and released for Fedora Extras 5: 26 asymptote-1.30-1.fc5 ctapi-cyberjack-3.0.0-2.fc5 dbmail-2.2.5-5.fc5 libxfce4mcs-4.2.4-1.fc5 libxfce4util-4.2.4-1.fc5 libxfcegui4-4.2.4-1.fc5 perl-Email-Address-1.888-1.fc5 qt4-4.3.0-1.fc5 srecord-1.35-1.fc5 (!) svrcore-4.0.4-1.fc5 : INVALID rebuild, not published! xfcalendar-4.2.4-1.fc5 xfce-mcs-manager-4.2.4-1.fc5 xfce-mcs-plugins-4.2.4-1.fc5 xfce-utils-4.2.4-1.fc5 xfce4-appfinder-4.2.4-1.fc5 xfce4-icon-theme-4.2.4-1.fc5 xfce4-iconbox-4.2.4-1.fc5 xfce4-mixer-4.2.4-1.fc5 xfce4-panel-4.2.4-1.fc5 xfce4-systray-4.2.4-1.fc5 xfce4-toys-4.2.4-1.fc5 xfce4-trigger-launcher-4.2.4-1.fc5 xfdesktop-4.2.4-1.fc5 xfprint-4.2.4-1.fc5 xfwm4-4.2.4-1.fc5 xfwm4-themes-4.2.4-1.fc5 Changes in Fedora Extras 6: adminutil-1.1.2-1.fc6 --------------------- * Fri Jun 22 2007 Rich Megginson - 1.1.2-1 - Updated version to 1.1.2 - This version fixes some memory leaks and invalid memory use - issues babel-0.8-1.fc6 --------------- * Thu Jun 21 2007 Jeffrey C. Ollie - 0.8-1 - First version for Fedora ctapi-cyberjack-3.0.0-2.fc6 --------------------------- * Sat Jun 23 2007 Frank B?ttner - 3.0.0-2.fc6 - rebuild because of missing file in the cvs system * Sat Jun 23 2007 Frank B?ttner - 3.0.0-1.fc6 - final release for 3.0.0 * Thu May 31 2007 Frank B?ttner - 3.0.0beta1-2.fc6 - rebuild with the missing file * Tue May 08 2007 Frank B?ttner - 3.0.0beta1-1.fc6 - first build for the new version * Fri May 04 2007 Frank B?ttner - 2.0.14-2.fc6 - rebuild for the ppc64 arch cvsplot-1.7.4-4.fc6 ------------------- * Sat Jun 23 2007 Marek Mahut - 1.7.4-4 - rebuild * Thu Jun 14 2007 Marek Mahut - 1.7.4-3 - Added patch for compatibility with gnuplot 4 - Fixing spec file dbmail-2.2.5-5.fc6 ------------------ * Sat Jun 23 2007 Bernard Johnson 2.2.5-5 - patch to reopen logs files on -HUP - patch to send error when thread references requested - don't filter libdbmail.so* * Sat Jun 23 2007 Bernard Johnson 2.2.5-4 - kill ld.so config - filter private libraries from provides (bz#245326) * Wed Jun 20 2007 Bernard Johnson 2.2.5-3 - assign uid from package user registry (bz#244611) empathy-0.8-1.fc6 ----------------- * Fri Jun 22 2007 David Nielsen - 0.8-1 - bump to 0.8 - Now with aspell support (deat to teh speeling mistaks) hatari-0.95-1.fc6 ----------------- * Sat Jun 23 2007 Andrea Musuruane 0.95-1.fc6 - updated to upstream 0.95 - updated description - README.tos and hatari.desktop are no longer built in the spec file - added new upstream hmsa tool - added new upstream french man page - updated icon cache scriptlets to be compliant to new guidelines - cosmetic changes * Sat Mar 17 2007 Andrea Musuruane 0.90-6.fc6 - dropped --add-category X-Fedora from desktop-file-install - changed .desktop category to Game;Emulator; - now using sed to fix makefile not to strip binaries during make install - cosmetic changes to BR section libosip-0.9.7-11.fc6 -------------------- * Fri Jun 22 2007 Jeffrey C. Ollie - 0.9.7-11 - Update URL mod_fcgid-2.1-3.fc6 ------------------- * Fri Jun 15 2007 Paul Howarth 2.1-3 - Major update of SELinux policy, supporting accessing data on NFS/CIFS shares and a new boolean, httpd_fastcgi_can_sendmail, to allow connections to SMTP servers - Fix for SELinux policy on Fedora 7, which didn't work due to changes in the permissions macros in the underlying selinux-policy package * Wed Mar 21 2007 Paul Howarth 2.1-2 - Add RHEL5 with SELinux support - Rename README.Fedora to README.RPM mozldap-6.0.4-1.fc6 ------------------- * Wed Jun 20 2007 Rich Megginson - 6.0.4-1 - bump version to 6.0.4 - this version has some memory leak - fixes for SASL related code, fixes for control handling with - referral chasing, and packaging improvements - use -p when installing include files to preserve timestamps * Thu May 24 2007 Rich Megginson - 6.0.3-3 - We only need cyrus-sasl-devel as a BuildRequires in the main package * Mon May 21 2007 Rich Megginson - 6.0.3-2 - added cyrus-sasl-devel and pkgconfig to devel package Requires ortp-0.13.1-3.fc6 ----------------- * Fri Jun 22 2007 Jeffrey C. Ollie - 0.13.1-2 - Fix URL perl-Email-Address-1.888-1.fc6 ------------------------------ * Sat Jun 23 2007 Jose Pedro Oliveira - 1.888-1 - Update to 1.888. * Thu Apr 05 2007 Jose Pedro Oliveira - 1.887-1 - Update to 1.887. perl-Mozilla-LDAP-1.5.1-1.fc6 ----------------------------- * Wed Jun 20 2007 Rich Megginson - 1.5.1-1 - all files have been GPL/LGPL/MPL tri-licensed pitivi-0.10.3-1.fc6 ------------------- * Fri Jun 22 2007 Jeffrey C. Ollie - 0.10.3-1 - Update to 0.10.3 * Mon May 28 2007 Jeffrey C. Ollie - 0.10.2.2-3 - BR gettext * Mon May 28 2007 Jeffrey C. Ollie - 0.10.2.2-2 - BR perl(XML::Parser) * Mon May 28 2007 Jeffrey C. Ollie - 0.10.2.2-1 - Update to 0.10.2.2 * Wed Jan 31 2007 Jeffrey C. Ollie - 0.10.2-2 - Don't forget to add new patch to CVS * Wed Jan 31 2007 Jeffrey C. Ollie - 0.10.2-1 - Update to 0.10.2 - Drop sync patch - Add find_lang to pick up localizations - Temporarily re-run auto* tools until PyGTK detection is fixed. - See http://bugzilla.gnome.org/show_bug.cgi?id=402995 scrip-1.4-7.fc6 --------------- * Sun Jun 24 2007 Ed Hill - 1.4-7 - fix URL (Fedora bz 245388) smolt-0.9.8.3-1.fc6 ------------------- * Fri Jun 22 2007 Mike McGrath 0.9.8.3 - Upstream released new version srecord-1.35-1.fc6 ------------------ * Sat Jun 23 2007 Jose Pedro Oliveira - 1.35-1 - Update to 1.35. svrcore-4.0.4-1.fc6 ------------------- * Tue Mar 13 2007 Rich Megginson - 4.0.4-1 - Removed some autoconf generated files which were GPL only - all - code needs to be tri-licensed - updated version to 4.0.4 - added empty COPYING file - do not use the one generated by autoreconf - use bz2 for source tarball instead of gz xscorch-0.2.0-9.fc6 ------------------- * Fri Jun 22 2007 Marcin Garski 0.2.0-9 - Create symlinks in pixmaps directory - Fix .desktop category - Spec tweak Changes in Fedora Extras 5: asymptote-1.30-1.fc5 -------------------- * Sat Jun 16 2007 Jose Pedro Oliveira - 1.30-1 - Update to 1.30. * Sat Jun 16 2007 Jose Pedro Oliveira - 1.29-3 - Using "evince" as the default PS and PDF viewers (#244151). (patch file: asymptote-1.29-settings.patch) - Use relative symbolic links in the {emacs,xemacs}-common triggers (#155750). - Use relative symbolic links in the vim-common triggers. * Sat Jun 02 2007 Jose Pedro Oliveira - 1.29-2 - Add asy-faq to install-info (#155750). - Add support for vim 7.1. ctapi-cyberjack-3.0.0-2.fc5 --------------------------- * Sat Jun 23 2007 Frank B?ttner - 3.0.0-2.fc5 - rebuild because of missing file in the cvs system * Sat Jun 23 2007 Frank B?ttner - 3.0.0-1.fc5 - final release for 3.0.0 * Thu May 31 2007 Frank B?ttner - 3.0.0beta1-2.fc5 - rebuild with the missing file * Tue May 08 2007 Frank B?ttner - 3.0.0beta1-1.fc5 - first build for the new version * Fri May 04 2007 Frank B?ttner - 2.0.14-2.fc5 - rebuild for the ppc64 arch dbmail-2.2.5-5.fc5 ------------------ * Sat Jun 23 2007 Bernard Johnson 2.2.5-5 - patch to reopen logs files on -HUP - patch to send error when thread references requested - don't filter libdbmail.so* * Sat Jun 23 2007 Bernard Johnson 2.2.5-4 - kill ld.so config - filter private libraries from provides (bz#245326) * Wed Jun 20 2007 Bernard Johnson 2.2.5-3 - assign uid from package user registry (bz#244611) libxfce4mcs-4.2.4-1.fc5 ----------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - enable-gtk-doc libxfce4util-4.2.4-1.fc5 ------------------------ * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Patch to disable rpath in xfce4-kiosk-query - Remove superflurious %Requires and %Prereq - enable-gtk-doc libxfcegui4-4.2.4-1.fc5 ----------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - enable-gtk-doc - Fix %files section to not include libxfcegui4.so twice - Remove superflurious %Requires and %Prereq - Own %{_libdir}/xfce4/ and %{_datadir}/xfce4/ * Mon Jun 05 2006 Kevin Fenzi - 4.2.3-5 - Add gettext and intltool %BuildRequires (fixes #194138) perl-Email-Address-1.888-1.fc5 ------------------------------ * Sat Jun 23 2007 Jose Pedro Oliveira - 1.888-1 - Update to 1.888. * Thu Apr 05 2007 Jose Pedro Oliveira - 1.887-1 - Update to 1.887. qt4-4.3.0-1.fc5 --------------- * Wed May 30 2007 Rex Dieter 4.3.0-1 - qt-4.3.0(final) * Fri May 04 2007 Kevin Kofler 4.3.0-0.5.rc1 - update to 4.3.0 RC1 - drop LD_RUN_PATH hack * Fri May 04 2007 Kevin Kofler 4.3.0-0.3.snapshot20070423 - update to qt-4.3.0-snapshot-20070423 - build with SSL support (BR openssl-devel) - drop upstreamed mysql_config.patch * Wed May 02 2007 Rex Dieter 4.3.0-0.2.beta - qt-4.3.0beta - -system-libtiff, BR: libtiff-devel * Wed May 02 2007 Rex Dieter 4.2.3-8 - QFileDialog file wrapping patch (qt#153635, rh#236908) - License: GPL, dropping LICENSE.QPL (#237702) srecord-1.35-1.fc5 ------------------ * Sat Jun 23 2007 Jose Pedro Oliveira - 1.35-1 - Update to 1.35. svrcore-4.0.4-1.fc5 ------------------- * Tue Mar 13 2007 Rich Megginson - 4.0.4-1 - Removed some autoconf generated files which were GPL only - all - code needs to be tri-licensed - updated version to 4.0.4 - added empty COPYING file - do not use the one generated by autoreconf - use bz2 for source tarball instead of gz xfcalendar-4.2.4-1.fc5 ---------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Use versioned %BuildRequires for the xfce stuff - Require xfce-mcs-manager - Run gtk-update-icon-cache in %post and %postun - Use desktop-file-install and add Category "Office" (#243601) xfce-mcs-manager-4.2.4-1.fc5 ---------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Run gtk-update-icon-cache in %post and %postun - Own %{_libdir}/xfce4/mcs-plugins/ and %{_datadir}/xfce4/doc xfce-mcs-plugins-4.2.4-1.fc5 ---------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Run gtk-update-icon-cache in %post and %postun xfce-utils-4.2.4-1.fc5 ---------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Require xfce-mcs-manager - Run gtk-update-icon-cache in %post and %postun xfce4-appfinder-4.2.4-1.fc5 --------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Minor spec file changes xfce4-icon-theme-4.2.4-1.fc5 ---------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Update %files section to not include /usr/share/icons xfce4-iconbox-4.2.4-1.fc5 ------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Require xfce-mcs-manager xfce4-mixer-4.2.4-1.fc5 ----------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Build with ALSA instead of OSS (fixes bug #239513) - Require xfce-mcs-manager - No longer own %{_libdir}/xfce4/{mcs|panel}-plugins - Remove empty TODO from %doc xfce4-panel-4.2.4-1.fc5 ----------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Run gtk-update-icon-cache in %post and %postun xfce4-systray-4.2.4-1.fc5 ------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - No longer own %{_libdir}/xfce4/ and %{_libdir}/xfce4/panel-plugins xfce4-toys-4.2.4-1.fc5 ---------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Own /usr/share/xfce4/tips and /usr/share/xfce4/eyes - No longer own %{_libdir}/xfce4/panel-plugins xfce4-trigger-launcher-4.2.4-1.fc5 ---------------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - No longer own %{_libdir}/xfce4/ and %{_libdir}/xfce4/panel-plugins xfdesktop-4.2.4-1.fc5 --------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Run gtk-update-icon-cache in %post and %postun xfprint-4.2.4-1.fc5 ------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Run gtk-update-icon-cache in %post and %postun xfwm4-4.2.4-1.fc5 ----------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - disable-static instead of removing .a files - Use versioned %BuildRequires for the xfce stuff - Run gtk-update-icon-cache in %post and %postun xfwm4-themes-4.2.4-1.fc5 ------------------------ * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - No longer own %{_datadir}/themes since it is already owned by xfwm4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jun 25 08:54:32 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 25 Jun 2007 10:54:32 +0200 Subject: Parallel Booting In-Reply-To: <200706241337.20067.ville.skytta@iki.fi> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> Message-ID: <20070625105432.488ee86e@python3.es.egwn.lan> Ville Skytt? wrote : > On Friday 22 June 2007, Harald Hoyer wrote: > > > The next step would be to modify all initscripts in /etc/init.d to be LSB > > compliant [4]. > > Does this imply that these modified init scripts should also be > installed/removed with the LSB tools instead of chkconfig? See > https://bugzilla.redhat.com/245494 Ouch! As much as the new approach seems interesting, I always remove the redhat-lsb package from my minimal installs because of all the useless (in my case) X related packages it pulls in :-/ BTW, is this just some initial test? Or will Fedora officially move in this direction, with the change discussed and approved by FESCO? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.21 0.34 0.40 From buildsys at redhat.com Mon Jun 25 09:43:28 2007 From: buildsys at redhat.com (Build System) Date: Mon, 25 Jun 2007 05:43:28 -0400 Subject: rawhide report: 20070625 changes Message-ID: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> Updated Packages: apr-1.2.9-1 ----------- * Mon Jun 25 2007 Bojan Smojver 1.2.9-1 - bump up to 1.2.9 * Mon Jun 04 2007 Joe Orton 1.2.8-7 - drop %check section entirely; inappropriate to run in build env. * Fri Mar 30 2007 Joe Orton 1.2.8-6 - merge review (#225253): drop .a archive; drop use of CC/CXX, use BuildRequires; drop old Conflicts; URL reference for Source bash-completion-20060301-4.fc8 ------------------------------ * Sun Jun 24 2007 Jeff Sheltren - 20060301-4 - Update triggers to work with older versions of RPM jd-1.9.5-0.5.svn1150.fc8 ------------------------ * Mon Jun 25 2007 Mamoru Tasaka - 1.9.5-0.5.svn1150 - svn 1150 * Sat Jun 16 2007 Mamoru Tasaka - 1.9.5-0.5.beta070616 - 1.9.5 beta 070616 * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.4.beta070611 - 1.9.5 beta 070611 kernel-2.6.21-1.3235.fc8 ------------------------ * Sat Jun 23 2007 Dave Jones - DMI based module autoloading. * Sat Jun 23 2007 Dave Jones - 2.6.22-rc5-git8. - Update to latest upstream cfs scheduler. krb5-1.6.1-5 ------------ * Sun Jun 24 2007 Nalin Dahyabhai 1.6.1-5 - add missing pam-devel build requirement, force selinux-or-fail build * Sun Jun 24 2007 Nalin Dahyabhai 1.6.1-4 - rebuild * Sun Jun 24 2007 Nalin Dahyabhai 1.6.1-3 - label all files at creation-time according to the SELinux policy (#228157) kyum-0.7.5-7.fc8 ---------------- * Thu Jun 21 2007 Jochen Schmitt 0.7.5-7 - Fix UTF-8 issue (#221730) - Remove usage of 'make -f Makefile.cvs' - Change categories of desktop file. - Add automake16 as a BR perl-PAR-Dist-0.23-1.fc8 ------------------------ * Mon Jun 25 2007 Ville Skytt?? - 0.23-1 - 0.23. * Sun May 06 2007 Ville Skytt?? - 0.22-1 - 0.22. revisor-2.0.3.12-1.fc8 ---------------------- * Sun Jun 24 2007 Jeroen van Meeuwen 2.0.3.12-1 - Removed excludearchs ppc, ppc64 and added some logic to the spec file including a patch to disable livecd composure. - Fixed bug in repository configuration - Re-enabled CLI ruby-1.8.6.36-3.fc8 ------------------- * Wed Jul 25 2007 Akira TAGOH - 1.8.6.36-3 - ruby-r12567.patch: backport patch from upstream svn to get rid of the unnecessary declarations. (#245446) * Fri Jul 20 2007 Akira TAGOH - 1.8.6.36-2 - New upstream release. - Fix Etc::getgrgid to get the correct gid as requested. (#236647) * Wed Mar 28 2007 Akira TAGOH - 1.8.6-2 - Fix search path breakage. (#234029) sqlite-3.4.0-2.fc8 ------------------ * Sun Jun 24 2007 Paul Nasrat - 3.4.0-2 - Disable load for now (#245486) star-1.5a76-3.fc8 ----------------- * Sun Jun 24 2007 Peter Vrabec 1.5a76-3 - build star on ARM platforms (#245465) * Mon Jan 29 2007 Peter Vrabec 1.5a76-2 - fix buildreq. and rebuild * Thu Jan 18 2007 Jan Cholasta 1.5a76-1 - upgrade warzone2100-2.0.7-2.fc8.1 ------------------------- * Sun Jun 24 2007 Karol Trzcionka - 2.0.7-2 - Add ppc64 to ExcludeArch * Sun Jun 24 2007 Karol Trzcionka - 2.0.7-1 - Update to v2.0.7 xdg-utils-1.0.2-1.fc8 --------------------- * Sun Jun 24 2007 Rex Dieter 1.0.2-1 - xdg-utils-1.0.2 xemacs-21.5.28-3.fc8 -------------------- * Sun Jun 24 2007 Ville Skytt?? - 21.5.28-3 - Apply upstream fix for #245017. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump koan - 0.3.1-2.fc7.noarch requires syslinux libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From dwmw2 at infradead.org Mon Jun 25 09:45:52 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 25 Jun 2007 10:45:52 +0100 Subject: rawhide report: 20070625 changes In-Reply-To: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> References: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> Message-ID: <1182764752.12109.31.camel@pmac.infradead.org> On Mon, 2007-06-25 at 05:43 -0400, Build System wrote: > warzone2100-2.0.7-2.fc8.1 > ------------------------- > * Sun Jun 24 2007 Karol Trzcionka - 2.0.7-2 > - Add ppc64 to ExcludeArch I don't see this in https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-ExcludeArch-ppc64 -- dwmw2 From hughsient at gmail.com Mon Jun 25 09:54:02 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 25 Jun 2007 10:54:02 +0100 Subject: rawhide report: 20070625 changes In-Reply-To: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> References: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> Message-ID: <1182765242.2519.2.camel@work> On Mon, 2007-06-25 at 05:43 -0400, Build System wrote: > kernel-2.6.21-1.3235.fc8 > ------------------------ > * Sat Jun 23 2007 Dave Jones > - DMI based module autoloading. Cool. Does that mean we can get rid of the userspace dmi/modprobe hacks? Richard. From dwmw2 at infradead.org Mon Jun 25 10:17:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 25 Jun 2007 11:17:38 +0100 Subject: rawhide report: 20070625 changes In-Reply-To: <1182764752.12109.31.camel@pmac.infradead.org> References: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> <1182764752.12109.31.camel@pmac.infradead.org> Message-ID: <1182766658.12109.42.camel@pmac.infradead.org> On Mon, 2007-06-25 at 10:45 +0100, David Woodhouse wrote: > On Mon, 2007-06-25 at 05:43 -0400, Build System wrote: > > warzone2100-2.0.7-2.fc8.1 > > ------------------------- > > * Sun Jun 24 2007 Karol Trzcionka - 2.0.7-2 > > - Add ppc64 to ExcludeArch > > I don't see this in > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-ExcludeArch-ppc64 Ah, I see there was already a bug for x86_64. As usual, it's not an arch-specific issue. The mailing list seems to be mangling the Cc field and removing recipients. Please could it be fixed. -- dwmw2 From mlichvar at redhat.com Mon Jun 25 12:02:07 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 25 Jun 2007 14:02:07 +0200 Subject: additional *-python splits In-Reply-To: <1182538698.7069.23.camel@indigo.declera.com> References: <1182512639.7069.5.camel@indigo.declera.com> <20070622161240.GC4649@nostromo.devel.redhat.com> <1182538698.7069.23.camel@indigo.declera.com> Message-ID: <20070625120207.GA7258@localhost> On Fri, Jun 22, 2007 at 09:58:18PM +0300, Yanko Kaneti wrote: > Here is my best attempt. At the following url > http://www.declera.com/~yaneti/splitpy/ > are all the related patches that I could muster > > the original three spec file splitting patches for: > libsemanage > libuser > newt Ok, I've commited the patch for newt and the package is ready for build. Should I wait for other packages to minimize the time when rawhide is broken or just build the package? -- Miroslav Lichvar From greno at verizon.net Mon Jun 25 13:54:43 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 25 Jun 2007 09:54:43 -0400 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467F7071.6030506@redhat.com> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> <467EFD70.4080004@iinet.net.au> <467F031E.40108@verizon.net> <467F0C51.1030402@verizon.net> <467F19E2.5090603@verizon.net> <467F7071.6030506@redhat.com> Message-ID: <467FC923.2040400@verizon.net> Florian Festi wrote: > Gerry Reno wrote: >> I went and looked at the list of packages and dependencies again and >> it looks like some of the missing dependencies are for packages that >> have been marked for update to newer versions. So why isn't yum >> requiring newer versions of the packages for which it is complaining >> the dependencies are missing? Yum depsolv seems to be messed up. >> Using yum 3.0.6. > > Check if those packages are installed twice with different versions. > It is also possible that some multilib issues keeps some older > versions from being removed during the update. yum doesn't handle such > situations as graciously > as one could image. So some manual help may be required. > > Florian Festi > I went and checked just a few of the packages and I don't see anything installed twice: # yum list mysql Loading "installonlyn" plugin Setting up repositories fedora 100% |=========================| 2.1 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 freshrpms 100% |=========================| 2.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 2.6 MB 00:07 fedora : ################################################## 7401/7401 primary.xml.gz 100% |=========================| 56 kB 00:00 freshrpms : ################################################## 152/152 Installed Packages mysql.i386 5.0.27-1.fc6 installed Available Packages mysql.i386 5.0.37-2.fc7 fedora [root at grp-01-30-02 ~]# rpm -q mysql mysql-5.0.27-1.fc6 [root at grp-01-30-02 ~]# [root at grp-01-30-02 ~]# [root at grp-01-30-02 ~]# yum list k3b Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Installed Packages k3b.i386 0.12.17-1 installed Available Packages k3b.i386 1.0.1-1.fc7 updates [root at grp-01-30-02 ~]# rpm -q k3b k3b-0.12.17-1 [root at grp-01-30-02 ~]# [root at grp-01-30-02 ~]# yum list gcc Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Installed Packages gcc.i386 4.1.1-51.fc6 installed Available Packages gcc.i386 4.1.2-12 fedora [root at grp-01-30-02 ~]# rpm -q gcc gcc-4.1.1-51.fc6 So what are my options here? I can't even install just one package to check if for instance updating k3b would fix the missing dependency because yum now wants to check 'all' the dependencies for all the packages that have been marked for update. From jkeating at redhat.com Mon Jun 25 13:54:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 09:54:16 -0400 Subject: FESCo elections In-Reply-To: <1182752850.10205.371.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> Message-ID: <200706250954.19676.jkeating@redhat.com> On Monday 25 June 2007 02:27:30 Karsten Wade wrote: > ?Is there any good reason > *not* to open FESCo elections (members and voting) to all of Fedora? (ignoring all the flamebait) Look, tying it to the account system provides us an easy way to measure who has voted and only take one vote per account. Which accounts get to vote is a pretty trivial discussion, one that could be made easily during a meeting without spewing all kinds of hate across the mailing lists. I'm perfectly fine with a cla_done membership having the power to vote. Is that too high of a bar to you? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yaneti at declera.com Mon Jun 25 13:59:14 2007 From: yaneti at declera.com (Yanko Kaneti) Date: Mon, 25 Jun 2007 16:59:14 +0300 Subject: additional *-python splits In-Reply-To: <20070625120207.GA7258@localhost> References: <1182512639.7069.5.camel@indigo.declera.com> <20070622161240.GC4649@nostromo.devel.redhat.com> <1182538698.7069.23.camel@indigo.declera.com> <20070625120207.GA7258@localhost> Message-ID: <1182779954.7069.35.camel@indigo.declera.com> On Mon, 2007-06-25 at 14:02 +0200, Miroslav Lichvar wrote: > On Fri, Jun 22, 2007 at 09:58:18PM +0300, Yanko Kaneti wrote: > > Here is my best attempt. At the following url > > http://www.declera.com/~yaneti/splitpy/ > > are all the related patches that I could muster > > > > the original three spec file splitting patches for: > > libsemanage > > libuser > > newt > > Ok, I've commited the patch for newt and the package is ready for > build. > > Should I wait for other packages to minimize the time when rawhide > is broken or just build the package? IMHO ideally, due to the nature of the patches, one person with enough access should commit all of them and announce broadly (fedora-devel-announce,fedora-devel,fedora-maintainers). Yanko From jkeating at redhat.com Mon Jun 25 14:04:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 10:04:20 -0400 Subject: Inconsistent package tags In-Reply-To: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: <200706251004.20581.jkeating@redhat.com> On Sunday 24 June 2007 21:14:32 n0dalus wrote: > Hi all, > > On my rawhide system, I noticed that there are a lot of packages with > inconsistent tags. There are (numbers in brackets are for packages > built in the past 14 days): > - 369 (216) packages with fc8 in the release tag (shouldn't we be using > f8?) No, fedora collection 8. > - 354 (1) packages with fc7 in the release tag We still inherit many Fedora 7 builds. Unless there is a good technical reason to rebuild them we don't waste resources in rebuilding just for a cosmetic package version. > - 205 (27) packages with no fedora version in the release tag dist tag is optional. In many cases it is preferred to /not/ have one, like data files that won't change from release to release. No sense in rebuilding them all the time, just update the oldest supported release first, and all the newer collections will inherit it. > - 42 (0) packages with fc6 in the release tag Again, we still inherit some packages all the way back to fc6. If there is significant technical reason to rebuild then they would be, but cosmetics is not a reason. > - 465 (0) packages with Vendor: Red Hat, Inc Built internally as part of "Core" > - 431 (244) packages with Vendor: Fedora Project Built with Koji and/or Plague IIRC > - 74 (0) packages with Vendor: Koji Built with Koji for a short period of time where we lost the Vendor definitions. Not a reason to rebuild, they'll pick up the new Vendor tag next time they're built for a real reason. > - 465 (0) packages with Packager: Red Hat, Inc. > > - 363 (244) packages with Packager: Fedora Project > - 74 (0) packages with Packager: Koji > - 68 (0) packages with Packager: Fedora Project > See above response, same thing going on here. > > - 437 (244) packages with Distribution: Unknown This may be the only actual problem I see here. Perhaps we lost Distribution definition in our current koji setup. I'll investigate. > - 369 (0) packages with Distribution: Red Hat (FC-7) > - 90 (0) packages with Distribution: Red Hat (FC-6) > - 68 (0) packages with Distribution: Fedora Extras > - 6 (0) packages with Distribution: (none) > > - 759 (243) packages with Signature: (none) > - 81 (0) packages with Signature: fd372689897da07a (Red Hat Beta?) > - 72 (1) packages with Signature: b44269d04f2a6fd2 (Fedora?) > - 58 (0) packages with Signature: 82ed95041ac70ce6 (Extras?) Inheritance once again, and we don't automatically sign Rawhide builds at this time. > Obviously a lot of these packages haven't gone through the build > system of late, but even the ones that have still show a few > inconsistencies. Is this something that is being worked on? I only saw one issue above that needs any attention, and that's the Distribution tag. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Mon Jun 25 14:11:09 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 25 Jun 2007 10:11:09 -0400 Subject: fedora for ARM In-Reply-To: <20070624062858.GA22368@xi.wantstofly.org> References: <20070602032955.GC16918@xi.wantstofly.org> <20070624062858.GA22368@xi.wantstofly.org> Message-ID: <1182780669.30663.297.camel@localhost.localdomain> On Sun, 2007-06-24 at 08:28 +0200, Lennert Buytenhek wrote: > On Sat, Jun 02, 2007 at 05:29:55AM +0200, Lennert Buytenhek wrote: > > > I'm posting here because I would really really like to get the relevant > > diffs merged back into Fedora. I believe that ARM is well-supported in > > the various upstream projects that Fedora packages, and so this should > > be a relatively painless process (if you look at the diffs referenced > > above, most diffs are actually only spec file changes to cope with the > > addition of a new architecture.) > > A number of things have happened since I wrote this. > > For one, we now have a wiki page: > http://fedoraproject.org/wiki/ARM > > We also have a mailing list: > http://www.redhat.com/mailman/listinfo/fedora-arm > > And an IRC channel: > #fedora-arm on freenode > > And I've submitted most of our 'easy' patches to the bug monster: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245418 Many of these are just adding %{arm} to ExclusiveArch. I'm becoming of the opinion that ExclusiveArch is almost always worse than ExcludeArch, and that the presence of either one should be justified either in the review or in the spec itself. At the moment, the packaging guidelines say nothing about this, afaict. - ajax From ajackson at redhat.com Mon Jun 25 14:12:28 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 25 Jun 2007 10:12:28 -0400 Subject: Inconsistent package tags In-Reply-To: <6280325c0706241934xb1ae9f1j824b32b68881ad34@mail.gmail.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <6280325c0706241934xb1ae9f1j824b32b68881ad34@mail.gmail.com> Message-ID: <1182780748.30663.299.camel@localhost.localdomain> On Mon, 2007-06-25 at 12:04 +0930, n0dalus wrote: > On 24 Jun 2007 20:31:22 -0500, Jason L Tibbitts III wrote: > > n> 369 (216) packages with fc8 in the release tag (shouldn't we be > > n> using f8?) > > > > No, it's fc8. f8 would sort less than fc7, causing badness. > > I know, but its still undesirable to need to put 'fc' in every package > of every release from this point on. Could packages be moved over to > f8 by using release numbers, epochs or some other rpm hack? No. - ajax From mschwendt.tmp0701.nospam at arcor.de Mon Jun 25 14:27:31 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 25 Jun 2007 16:27:31 +0200 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467EED37.6010802@verizon.net> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> Message-ID: <20070625162731.51a37af2.mschwendt.tmp0701.nospam@arcor.de> On Sun, 24 Jun 2007 18:16:23 -0400, Gerry Reno wrote: > Gerry Reno wrote: > > I decided to try to yum upgrade an FC6 machine today to F7 so I > > installed the fedora-release rpms for F7 and then ran yum upgrade, but > > I'm getting 404 errors on package tsclient. It tries a bunch of > > mirrors and then says no more mirrors to try. Is anyone else seeing > > this? > > > > > Ok, I waited a while a retried this again. It goes along for quite a > while and then finally gets these errors: > > --> Finished Dependency Resolution > Error: Missing Dependency: libnetsnmp.so.10 is needed by package > net-snmp-utils > Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package > mysql-bench You need to enable the Fedora "Everything" repository to upgrade several of your packages from Fedora 6. The rest of your messages are based on misinterpreting the Yum error messages. For example: | Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package | mysql-bench This can mean two things, but in your case it means that the version of "mysql-bench" that is installed on your machine blocks "mysql" from being upgraded without breaking dependencies. The newer "mysql" is in the repository, but the corresponding "mysql-bench" is not. Hence the upgrade fails. Enable the full repository where Yum will find the missing packages like mysql-bench and net-snmp-utils. From Jochen at herr-schmitt.de Mon Jun 25 14:38:05 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Jun 2007 16:38:05 +0200 Subject: Are there Plans to include gcc-4.2.0 into F-8 or later Message-ID: <0MKxQS-1I2phu2KW3-0008Ib@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, I want to ask, if there any efforts to include gcc-4.2.0 into F-8 ore late? Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGf9NiT2AHK6txfgwRAslqAKD5K0p7KAgWS5c70MbaGDe9e0pzMQCg4LXd vbJ3ZKWlwQlEBPRJcEBaDzo= =2Gpq -----END PGP SIGNATURE----- From greno at verizon.net Mon Jun 25 14:42:34 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 25 Jun 2007 10:42:34 -0400 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <20070625162731.51a37af2.mschwendt.tmp0701.nospam@arcor.de> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> <20070625162731.51a37af2.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <467FD45A.5040400@verizon.net> Michael Schwendt wrote: > On Sun, 24 Jun 2007 18:16:23 -0400, Gerry Reno wrote: > > >> Gerry Reno wrote: >> >>> I decided to try to yum upgrade an FC6 machine today to F7 so I >>> installed the fedora-release rpms for F7 and then ran yum upgrade, but >>> I'm getting 404 errors on package tsclient. It tries a bunch of >>> mirrors and then says no more mirrors to try. Is anyone else seeing >>> this? >>> >>> >>> >> Ok, I waited a while a retried this again. It goes along for quite a >> while and then finally gets these errors: >> >> --> Finished Dependency Resolution >> Error: Missing Dependency: libnetsnmp.so.10 is needed by package >> net-snmp-utils >> Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package >> mysql-bench >> > > You need to enable the Fedora "Everything" repository to upgrade several > of your packages from Fedora 6. > > The rest of your messages are based on misinterpreting the Yum error > messages. For example: > > | Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by package > | mysql-bench > > This can mean two things, but in your case it means that the version of > "mysql-bench" that is installed on your machine blocks "mysql" from being > upgraded without breaking dependencies. The newer "mysql" is in the > repository, but the corresponding "mysql-bench" is not. Hence the upgrade > fails. Enable the full repository where Yum will find the missing > packages like mysql-bench and net-snmp-utils. > > Ok, I'll try this. Here is what is in my fedora.repo: [fedora] name=Fedora $releasever - $basearch #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY [fedora-debuginfo] name=Fedora $releasever - $basearch - Debug #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/ mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-debug-$releasever&arch=$basearch enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY [fedora-source] name=Fedora $releasever - Source #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/ mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-source-$releasever&arch=$basearch enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY So I'm assuming that you mean to uncomment the 'baseurl' which has Everything and comment the 'mirrorlist' for [fedora]. And if it succeeds how should I set the repositories going forward? Do I leave it set to Everything or should I set it back to 'mirrorlist' once the initial upgrade succeeds? From bruno at wolff.to Mon Jun 25 14:48:18 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 25 Jun 2007 09:48:18 -0500 Subject: FESCo elections In-Reply-To: <200706250954.19676.jkeating@redhat.com> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> Message-ID: <20070625144818.GA27410@wolff.to> On Mon, Jun 25, 2007 at 09:54:16 -0400, Jesse Keating wrote: > On Monday 25 June 2007 02:27:30 Karsten Wade wrote: > > ?Is there any good reason > > *not* to open FESCo elections (members and voting) to all of Fedora? > > (ignoring all the flamebait) > > Look, tying it to the account system provides us an easy way to measure who > has voted and only take one vote per account. Which accounts get to vote is Which isn't necessarily the same as one vote per person. I think the chance of significant ballot stuffing going on to influence who gets to do a lot of work for free are low. But someone might try something as a prank. It's been a few months since I did the CLA, and my memory is that the process is automatic up until the point where I need to get into a group that can do something. > a pretty trivial discussion, one that could be made easily during a meeting > without spewing all kinds of hate across the mailing lists. I'm perfectly > fine with a cla_done membership having the power to vote. Is that too high > of a bar to you? I think the requirement should be membership in some (any) other group than cla_done. This shows a bit more interest. It also requires manual approval so that some prankster can't hose an election by creating a lot of dummy accounts. (This would most likely be detected, but would still be a significant annoyance to have to clean up after.) I think this category would include all of the people that people have been concerned about in this discussion. From bpepple at fedoraproject.org Mon Jun 25 15:09:45 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 25 Jun 2007 11:09:45 -0400 Subject: FESCo elections In-Reply-To: <1182752850.10205.371.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> <1182644731.10205.300.camel@erato.phig.org> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> Message-ID: <1182784185.2851.15.camel@kennedy> On Sun, 2007-06-24 at 23:27 -0700, Karsten Wade wrote: > Is there any good reason *not* to open FESCo elections (members and voting) > to all of Fedora? Familiarity with the candidate's work, and how they interact with the community? I wonder how aware people in other aspects of the project are with all the FESCo candidates, if they aren't following the mailing lists, CVS commits, reviews, etc. For example, I really don't feel qualified voting for candidates in say, the Fedora Artwork team, since I can probably only name one or two people involved there, and that is only due to them blogging about their work there. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Jun 25 15:42:07 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 08:42:07 -0700 Subject: FESCo elections In-Reply-To: <200706250901.41791.opensource@till.name> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250901.41791.opensource@till.name> Message-ID: <1182786127.10205.396.camel@erato.phig.org> On Mon, 2007-06-25 at 09:01 +0200, Till Maas wrote: > Did anyone exclude Docs or L10n on purpose? I did not even know, that they > were excluded. I don't think anyone did it intentionally. But once everyone started to draw a line where some were inside of the voting circle, others out, that's when existing contributors got excluded. > In fact as a maintainer, I do not know anything about how Docs > or L10n are organised, e.g. who decides on the final release notes or how > permissions are granted in cvs. So for a better discussion it may be better > if you name all the groups that in you opinion should be able to vote. This > makes it easier for Newbies like me to understand, what exactly is the > problem. To include everyone with cla_done sounds not so good to me, because > then everone in the world who gpg-signed the cla may vote, without there > beeing a clear connection to Fedora. My opinion is that anyone who is a contributor should vote. The best and only measure we have so far is, "Has FAS account." > Who are all of Fedora? Is this everyone who installed Fedora or is using a > system where Fedora is installed? Contributors. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Jun 25 15:50:38 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 08:50:38 -0700 Subject: FESCo elections In-Reply-To: <200706250954.19676.jkeating@redhat.com> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> Message-ID: <1182786638.10205.404.camel@erato.phig.org> On Mon, 2007-06-25 at 09:54 -0400, Jesse Keating wrote: > On Monday 25 June 2007 02:27:30 Karsten Wade wrote: > > Is there any good reason > > *not* to open FESCo elections (members and voting) to all of Fedora? > > (ignoring all the flamebait) Heh, and 'hate' isn't flamebait? > Look, tying it to the account system provides us an easy way to measure who > has voted and only take one vote per account. Which accounts get to vote is > a pretty trivial discussion, one that could be made easily during a meeting Not everyone can make it to a meeting, or know one exists, or etc. The mailing list is a level ground where > without spewing all kinds of hate across the mailing lists. I'm sorry if my passion about the subject is a turn-off for you. To call it 'hate' ... well, it's certainly at least as hyperbolic than I was being, but without the self-righteous air. > I'm perfectly > fine with a cla_done membership having the power to vote. Is that too high > of a bar to you? That's the best measure we have right now of an active contributor. It's the only fair choice we have. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jun 25 16:01:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Jun 2007 12:01:16 -0400 Subject: rawhide report: 20070623 changes In-Reply-To: <20070624131551.6f085835@lain.camperquake.de> References: <200706231008.l5NA87X8023492@porkchop.devel.redhat.com> <20070624131551.6f085835@lain.camperquake.de> Message-ID: <20070625160116.GA19608@nostromo.devel.redhat.com> Ralf Ertzinger (fedora at camperquake.de) said: > > kernel-2.6.21-1.3234.fc8 > > ------------------------ > > * Fri Jun 22 2007 Dave Jones > > - 2.6.22-rc5-git6. > > There seem to be no mac80211 drivers in this package. The patch broke with the -rc5 update. Bill From kwade at redhat.com Mon Jun 25 16:02:53 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 09:02:53 -0700 Subject: FESCo elections In-Reply-To: <20070625144818.GA27410@wolff.to> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> <20070625144818.GA27410@wolff.to> Message-ID: <1182787373.10205.417.camel@erato.phig.org> On Mon, 2007-06-25 at 09:48 -0500, Bruno Wolff III wrote: > On Mon, Jun 25, 2007 at 09:54:16 -0400, > Jesse Keating wrote: > > On Monday 25 June 2007 02:27:30 Karsten Wade wrote: > > > Is there any good reason > > > *not* to open FESCo elections (members and voting) to all of Fedora? > > > > (ignoring all the flamebait) > > > > Look, tying it to the account system provides us an easy way to measure who > > has voted and only take one vote per account. Which accounts get to vote is > > Which isn't necessarily the same as one vote per person. I think the chance > of significant ballot stuffing going on to influence who gets to do a lot > of work for free are low. But someone might try something as a prank. > It's been a few months since I did the CLA, and my memory is that the > process is automatic up until the point where I need to get into a group > that can do something. If we don't have something in our election process to protect ourselves against pranks and so forth, we need it. The risk to the future of the community is greater if we put security, protection of the election, and paranoia as higher priorities than openness, inclusiveness, and fairness. > I think the requirement should be membership in some (any) other group than > cla_done. This is still going to disenfranchise folks without any other measure of if they should be. Only cla_done means not an active contributor? Not so, the Wiki is a legit contribution area and only requires cla_done. > This shows a bit more interest. It also requires manual approval > so that some prankster can't hose an election by creating a lot of dummy > accounts. (This would most likely be detected, but would still be a > significant annoyance to have to clean up after.) I think this category > would include all of the people that people have been concerned about in > this discussion. Well, it requires gaming gpg.mit.edu in the process, but I'm sure it could be done. I propose we include the entirety of cla_done, but announce an age limit on the account -- it must be older than one week. This gives people a chance to get an account for the election (since voting lasts longer than a week) while leaving enough time for us to notice any pranks/gaming of the system. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Jun 25 16:04:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 12:04:09 -0400 Subject: FESCo elections In-Reply-To: <1182787373.10205.417.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <20070625144818.GA27410@wolff.to> <1182787373.10205.417.camel@erato.phig.org> Message-ID: <200706251204.09510.jkeating@redhat.com> On Monday 25 June 2007 12:02:53 Karsten Wade wrote: > Well, it requires gaming gpg.mit.edu in the process, but I'm sure it > could be done. Not really. I have unlimited email addresses at my disposal, and I can generate a new gpg key for each and upload them. No "gaming" necessary. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Mon Jun 25 16:10:26 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 09:10:26 -0700 Subject: FESCo elections In-Reply-To: <1182784185.2851.15.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> <1182644731.10205.300.camel@erato.phig.org> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <1182784185.2851.15.camel@kennedy> Message-ID: <1182787826.10205.427.camel@erato.phig.org> On Mon, 2007-06-25 at 11:09 -0400, Brian Pepple wrote: > On Sun, 2007-06-24 at 23:27 -0700, Karsten Wade wrote: > > Is there any good reason *not* to open FESCo elections (members and voting) > > to all of Fedora? > > Familiarity with the candidate's work, and how they interact with the > community? I wonder how aware people in other aspects of the project > are with all the FESCo candidates, if they aren't following the mailing > lists, CVS commits, reviews, etc. > > For example, I really don't feel qualified voting for candidates in say, > the Fedora Artwork team, since I can probably only name one or two > people involved there, and that is only due to them blogging about their > work there. FESCo's charter is clearly larger and affects the entirety of the project (all contributors). This is new, yes, but shouldn't be ignored. What is the real risk of someone from another part of the project voting on e.g. Artwork's leaders? Don't all members of the community have say as to who these general leaders should be? Isn't art part of the distro, the front face first seen by many, and so forth? Ultimately, if _you_ don't feel qualified to vote across sub-projects, then don't. But if _I_ feel so qualified, please don't make policies that block me from voting across sub-projects. We need a higher bar for disenfranchisement than, "I wouldn't vote for anyone in that group, why would anyone else want to?" Remember, a steering committee elects its own chair, so the risk of a full coup are pretty low and easy to detect. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Jun 25 16:14:16 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 09:14:16 -0700 Subject: FESCo elections In-Reply-To: <200706251204.09510.jkeating@redhat.com> References: <1182223698.2796.0.camel@kennedy> <20070625144818.GA27410@wolff.to> <1182787373.10205.417.camel@erato.phig.org> <200706251204.09510.jkeating@redhat.com> Message-ID: <1182788056.10205.431.camel@erato.phig.org> On Mon, 2007-06-25 at 12:04 -0400, Jesse Keating wrote: > On Monday 25 June 2007 12:02:53 Karsten Wade wrote: > > Well, it requires gaming gpg.mit.edu in the process, but I'm sure it > > could be done. > > Not really. I have unlimited email addresses at my disposal, and I can > generate a new gpg key for each and upload them. No "gaming" necessary. Well, that's within my definition of gaming a system - taking advantage of a flaw, weakness, or other open part to get an outcome that you want. Is the first priority in Fedora elections protection of the election system? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linux_4ever at yahoo.com Mon Jun 25 16:21:56 2007 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 25 Jun 2007 09:21:56 -0700 (PDT) Subject: Changing default syslog package Message-ID: <845616.56525.qm@web51509.mail.re2.yahoo.com> Hi, I wanted to bring an issue up so that everyone knows about a change that we would like to make regarding system logging. As you may (or may not) know, sysklogd upstream seems dead with no new developments being released. However, there is a lot of new features that people would like to have and are asking for: 1) TCP based network transport for log messages. 2) Secure transport over the network. 3) A realtime analysis framework for logmessages (e.g. to launch programs on alerts). 4) Database backend. 5) Rule (pattern) based de-multiplexing of log messages (e.g. logging to different files based on regexp). 6) Backward compatibility with existing syslog configuration We looked at several packages to be the new default syslog daemon. The one that comes the closest is rsyslog. It has an active upstream and it is backwards compatible since its forked from the current default daemon. It has a bunch of features that you may want to look at: http://www.rsyslog.com/module-Static_Docs-view-f-features.html.phtml The package has just passed a Fedora Review, bz 243831. Its feature for feature compatible with the old sysklogd. And you should not notice a change in service. But what you will get is a syslog daemon that has advanced features and is actively being maintained and will be getting even more capabilities. As for the mechanics of making this happen, how should we go about switching out syslog daemons? IOW, should we put an obsoletes statement in the specfile now. And would we want to go ahead with the switchout in rawhide now? Thanks, -Steve ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news From jwboyer at jdub.homelinux.org Mon Jun 25 15:43:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 25 Jun 2007 10:43:24 -0500 Subject: FESCo elections In-Reply-To: <20070625144818.GA27410@wolff.to> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> <20070625144818.GA27410@wolff.to> Message-ID: <1182786204.23775.44.camel@weaponx.rchland.ibm.com> On Mon, 2007-06-25 at 09:48 -0500, Bruno Wolff III wrote: > > > a pretty trivial discussion, one that could be made easily during a meeting > > without spewing all kinds of hate across the mailing lists. I'm perfectly > > fine with a cla_done membership having the power to vote. Is that too high > > of a bar to you? > > I think the requirement should be membership in some (any) other group than > cla_done. This shows a bit more interest. It also requires manual approval > so that some prankster can't hose an election by creating a lot of dummy > accounts. (This would most likely be detected, but would still be a > significant annoyance to have to clean up after.) I think this category > would include all of the people that people have been concerned about in > this discussion. I think this is the best suggestion to date. josh From notting at redhat.com Mon Jun 25 16:44:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Jun 2007 12:44:35 -0400 Subject: Parallel Booting In-Reply-To: <200706241337.20067.ville.skytta@iki.fi> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> Message-ID: <20070625164435.GB19608@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > On Friday 22 June 2007, Harald Hoyer wrote: > > > The next step would be to modify all initscripts in /etc/init.d to be LSB > > compliant [4]. > > Does this imply that these modified init scripts should also be > installed/removed with the LSB tools instead of chkconfig? No. You can be LSB compliant in exit status, dependencies, etc. without using the LSB wrappers (in fact, it's greatly preferred to *NOT* use the LSB wrappers.) My questions about this approach are: - where are the benchmarks? What's the actual gain? - how would this be useful for the case where facilities that are provided are determined at runtime (say, NetworkManager providing $network instead of /etc/init.d/network, or $remote_fs being provided by either rc.sysinit or /etc/init.d/netfs, depending on configuration). Similarly, you may want a meta-dependency for 'authorization available', which would be at different times depending on whether or not you're using local passwords, KRB5, etc. - does this work with dbus system activation? Bill From bpepple at fedoraproject.org Mon Jun 25 16:58:05 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 25 Jun 2007 12:58:05 -0400 Subject: FESCo elections In-Reply-To: <1182787826.10205.427.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> <1182644731.10205.300.camel@erato.phig.org> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <1182784185.2851.15.camel@kennedy> <1182787826.10205.427.camel@erato.phig.org> Message-ID: <1182790685.2851.29.camel@kennedy> On Mon, 2007-06-25 at 09:10 -0700, Karsten Wade wrote: > On Mon, 2007-06-25 at 11:09 -0400, Brian Pepple wrote: > > > > Familiarity with the candidate's work, and how they interact with the > > community? I wonder how aware people in other aspects of the project > > are with all the FESCo candidates, if they aren't following the mailing > > lists, CVS commits, reviews, etc. > > > > For example, I really don't feel qualified voting for candidates in say, > > the Fedora Artwork team, since I can probably only name one or two > > people involved there, and that is only due to them blogging about their > > work there. > > FESCo's charter is clearly larger and affects the entirety of the > project (all contributors). This is new, yes, but shouldn't be ignored. > > What is the real risk of someone from another part of the project voting > on e.g. Artwork's leaders? Don't all members of the community have say > as to who these general leaders should be? Isn't art part of the > distro, the front face first seen by many, and so forth? I wonder why people that are that interested in voting for FESCo, wouldn't be interested in joining up with one of the groups (packaging, QA, etc) that under the governance of FESCo? It's not like the bar for entry is that high for all of them. Regardless, I think we have a fundamental difference of opinion here, but I would be willing to have this brought up for a vote at this week's FESCo meeting if you would like. If you could give me a proposal for what you think the requirement for voting would be, I'll add it to this week's schedule. Later, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Mon Jun 25 17:20:25 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 25 Jun 2007 12:20:25 -0500 Subject: FESCo elections In-Reply-To: <1182787373.10205.417.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> <20070625144818.GA27410@wolff.to> <1182787373.10205.417.camel@erato.phig.org> Message-ID: <20070625172025.GA13877@wolff.to> On Mon, Jun 25, 2007 at 09:02:53 -0700, Karsten Wade wrote: > > I think the requirement should be membership in some (any) other group than > > cla_done. > > This is still going to disenfranchise folks without any other measure of > if they should be. Only cla_done means not an active contributor? Not > so, the Wiki is a legit contribution area and only requires cla_done. There is still some manual setup required to be able to edit the wiki. I looked at my groups and I just have cla_done and cla_fedora which were both generated by the automated sign up process. In order to edit the wiki you need to be in the wiki's EditGroup (which is not a fedora account group). However I can see treating membership in that group the same as having a fedora account group that was manually approved. Looking at my preferences doesn't make it clear how the wiki accounts are bound to the fedora accounts. There may be a field that isn't visible or it may be based on email address. But presumably there would be some relatively easy way to get a list of fedora accounts corresponding to people that are allowed to edit wiki pages. From bruno at wolff.to Mon Jun 25 17:24:51 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 25 Jun 2007 12:24:51 -0500 Subject: FESCo elections In-Reply-To: <1182790685.2851.29.camel@kennedy> References: <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> <1182644731.10205.300.camel@erato.phig.org> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <1182784185.2851.15.camel@kennedy> <1182787826.10205.427.camel@erato.phig.org> <1182790685.2851.29.camel@kennedy> Message-ID: <20070625172451.GB13877@wolff.to> On Mon, Jun 25, 2007 at 12:58:05 -0400, Brian Pepple wrote: > > Regardless, I think we have a fundamental difference of opinion here, > but I would be willing to have this brought up for a vote at this week's > FESCo meeting if you would like. If you could give me a proposal for > what you think the requirement for voting would be, I'll add it to this > week's schedule. My proposal is that anyone that has a fedora account group other than cla_done or cla_fedora or alternatively is a member of the EditGroup for the wiki should be able to vote. The intention is to allow anyone who was manually vetted as part of the project to vote. Allowing anyone who has just cla_fedora or cla_done to vote would open the system to abuse as those groups are added without human intervention. From tibbs at math.uh.edu Mon Jun 25 17:29:35 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 25 Jun 2007 12:29:35 -0500 Subject: Changing default syslog package In-Reply-To: <845616.56525.qm@web51509.mail.re2.yahoo.com> References: <845616.56525.qm@web51509.mail.re2.yahoo.com> Message-ID: >>>>> "SG" == Steve G writes: SG> We looked at several packages to be the new default syslog SG> daemon. The one that comes the closest is rsyslog. I can't help but wonder what happened to syslog_ng, which was at one point supposed to be the syslog replacement in Fedora. - J< From poelstra at redhat.com Mon Jun 25 17:41:04 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 25 Jun 2007 10:41:04 -0700 Subject: Fedora Features Process Message-ID: <467FFE30.6090307@redhat.com> Based on https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.html I have drafted a proposed Feature process. I submitted it to the Fedora Board for a first pass via the wiki page (see inline comments). Now I am submitting it for additional public review and would like to have it discussed and ratified at the next FESCo meeting. Please add your feedback and changes to the wiki page. http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft Thanks, John From katzj at redhat.com Mon Jun 25 17:41:08 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Jun 2007 13:41:08 -0400 Subject: Changing default syslog package In-Reply-To: <845616.56525.qm@web51509.mail.re2.yahoo.com> References: <845616.56525.qm@web51509.mail.re2.yahoo.com> Message-ID: <1182793268.31081.50.camel@erebor.boston.redhat.com> On Mon, 2007-06-25 at 09:21 -0700, Steve G wrote: > As for the mechanics of making this happen, how should we go about switching out > syslog daemons? IOW, should we put an obsoletes statement in the specfile now. > And would we want to go ahead with the switchout in rawhide now? It would be good to see some of the use cases that switching enables spelled out a bit better and a feature description[1] written up on the wiki... Jeremy [1] http://fedoraproject.org/wiki/Releases/FeatureTemplate From bpepple at fedoraproject.org Mon Jun 25 17:43:19 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 25 Jun 2007 13:43:19 -0400 Subject: Fedora Core Merge Reviews Message-ID: <1182793399.2851.47.camel@kennedy> Hi, One of the items still left to do with regard to the recent merging of Core & Extras is the reviews on packages that previously were in Core. FESCo has been trying to determine what type of goal we should set for completion by F8 test 2. Most of us felt that it wasn't a reasonable goal to finish them all by that time, since there are more that 700 still needing to be completed. I'm looking for suggestions from the community on what you think is a reasonable number or percentage of reviews to complete by F8t2. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linux_4ever at yahoo.com Mon Jun 25 17:45:17 2007 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 25 Jun 2007 10:45:17 -0700 (PDT) Subject: Changing default syslog package In-Reply-To: Message-ID: <20070625174517.87477.qmail@web51502.mail.re2.yahoo.com> >> We looked at several packages to be the new default syslog >> daemon. The one that comes the closest is rsyslog. > >I can't help but wonder what happened to syslog_ng, which was at one >point supposed to be the syslog replacement in Fedora. For one, its dual licensed. If we go adding the features that are in the non-free version, I think that will create bad-blood. Its configuration file does not appear to be backawards compatible, meaning everyone will have to go reconfigure their logging. Anyone that prefers syslog-ng can still use that. -Steve ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 From caillon at redhat.com Mon Jun 25 18:11:51 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 25 Jun 2007 14:11:51 -0400 Subject: FESCo elections In-Reply-To: <1182787373.10205.417.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> <20070625144818.GA27410@wolff.to> <1182787373.10205.417.camel@erato.phig.org> Message-ID: <46800567.4000109@redhat.com> Karsten Wade wrote: > I propose we include the entirety of cla_done, but announce an age limit > on the account -- it must be older than one week. This gives people a > chance to get an account for the election (since voting lasts longer > than a week) while leaving enough time for us to notice any > pranks/gaming of the system. Let's hope the folks at ${anti-linux-company} won't see this as an opportunity to have all their folks sign CLAs and rig future elections. From caillon at redhat.com Mon Jun 25 18:19:25 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 25 Jun 2007 14:19:25 -0400 Subject: Fedora Core Merge Reviews In-Reply-To: <1182793399.2851.47.camel@kennedy> References: <1182793399.2851.47.camel@kennedy> Message-ID: <4680072D.3080806@redhat.com> Brian Pepple wrote: > Hi, > > One of the items still left to do with regard to the recent merging of > Core & Extras is the reviews on packages that previously were in Core. > FESCo has been trying to determine what type of goal we should set for > completion by F8 test 2. Most of us felt that it wasn't a reasonable > goal to finish them all by that time, since there are more that 700 > still needing to be completed. > > I'm looking for suggestions from the community on what you think is a > reasonable number or percentage of reviews to complete by F8t2. This depends on whether Red Hat can do reviews of these packages. Many of us are under the assumption that since the packages came from Red Hat, we ought to let the community review them. From jkeating at redhat.com Mon Jun 25 18:27:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 14:27:40 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/25/07 - 1:30PM EDT Message-ID: <200706251427.41110.jkeating@redhat.com> O U T A G E R E P O R T F O R M =================================== Incident Date: 6/25/07 Incident Time: 1:30PM EDT Elapsed Time of Incident: Ongoing People/Groups Impacted: Package builders / update tool / koji web services Site Affected: koji.fedoraproject.org Description: The koji.fedoraproject.org server is experiencing very high load. Attempts to login and address the load issue are under way. Future Recommendations: Continue investigating process issues with httpd (if that proves to be the culprit once more). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jwboyer at jdub.homelinux.org Mon Jun 25 18:31:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 25 Jun 2007 13:31:03 -0500 Subject: Fedora Core Merge Reviews In-Reply-To: <4680072D.3080806@redhat.com> References: <1182793399.2851.47.camel@kennedy> <4680072D.3080806@redhat.com> Message-ID: <1182796263.23775.47.camel@weaponx.rchland.ibm.com> On Mon, 2007-06-25 at 14:19 -0400, Christopher Aillon wrote: > Brian Pepple wrote: > > Hi, > > > > One of the items still left to do with regard to the recent merging of > > Core & Extras is the reviews on packages that previously were in Core. > > FESCo has been trying to determine what type of goal we should set for > > completion by F8 test 2. Most of us felt that it wasn't a reasonable > > goal to finish them all by that time, since there are more that 700 > > still needing to be completed. > > > > I'm looking for suggestions from the community on what you think is a > > reasonable number or percentage of reviews to complete by F8t2. > > This depends on whether Red Hat can do reviews of these packages. Many > of us are under the assumption that since the packages came from Red > Hat, we ought to let the community review them. I don't think we need to be that restrictive. I would say as long as the maintainer of the package isn't also doing the review, it's fine. There is no need to segregate reviewers based on employer. It just needlessly limits the reviewer pool. josh From katzj at redhat.com Mon Jun 25 18:32:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Jun 2007 14:32:22 -0400 Subject: Fedora Core Merge Reviews In-Reply-To: <4680072D.3080806@redhat.com> References: <1182793399.2851.47.camel@kennedy> <4680072D.3080806@redhat.com> Message-ID: <1182796342.31081.68.camel@erebor.boston.redhat.com> On Mon, 2007-06-25 at 14:19 -0400, Christopher Aillon wrote: > Brian Pepple wrote: > > One of the items still left to do with regard to the recent merging of > > Core & Extras is the reviews on packages that previously were in Core. > > FESCo has been trying to determine what type of goal we should set for > > completion by F8 test 2. Most of us felt that it wasn't a reasonable > > goal to finish them all by that time, since there are more that 700 > > still needing to be completed. > > > > I'm looking for suggestions from the community on what you think is a > > reasonable number or percentage of reviews to complete by F8t2. > > This depends on whether Red Hat can do reviews of these packages. Many > of us are under the assumption that since the packages came from Red > Hat, we ought to let the community review them. While you shouldn't review your own package (or perhaps also for packages that you're a substantial contributor to the packaging), I don't think there's any problem at all with having another community contributor who happens to have an @redhat.com address do a review of the package. Remember, everyone is a part of the community. Jeremy From greno at verizon.net Mon Jun 25 18:42:09 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 25 Jun 2007 14:42:09 -0400 Subject: yum upgrade error http 404 on tsclient rpm In-Reply-To: <467FD45A.5040400@verizon.net> References: <467EE3E4.1040307@verizon.net> <467EED37.6010802@verizon.net> <20070625162731.51a37af2.mschwendt.tmp0701.nospam@arcor.de> <467FD45A.5040400@verizon.net> Message-ID: <46800C81.5070709@verizon.net> Gerry Reno wrote: > Michael Schwendt wrote: >> You need to enable the Fedora "Everything" repository to upgrade several >> of your packages from Fedora 6. >> >> The rest of your messages are based on misinterpreting the Yum error >> messages. For example: >> >> | Error: Missing Dependency: mysql = 5.0.27-1.fc6 is needed by >> package | mysql-bench >> >> This can mean two things, but in your case it means that the version of >> "mysql-bench" that is installed on your machine blocks "mysql" from >> being >> upgraded without breaking dependencies. The newer "mysql" is in the >> repository, but the corresponding "mysql-bench" is not. Hence the >> upgrade >> fails. Enable the full repository where Yum will find the missing >> packages like mysql-bench and net-snmp-utils. >> > Ok, I'll try this. > > Here is what is in my fedora.repo: > [fedora] > name=Fedora $releasever - $basearch > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ > > mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch > > enabled=1 > gpgcheck=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora > file:///etc/pki/rpm-gpg/RPM-GPG-KEY > > [fedora-debuginfo] > name=Fedora $releasever - $basearch - Debug > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/ > > mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-debug-$releasever&arch=$basearch > > enabled=0 > gpgcheck=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora > file:///etc/pki/rpm-gpg/RPM-GPG-KEY > > [fedora-source] > name=Fedora $releasever - Source > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/ > > mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-source-$releasever&arch=$basearch > > enabled=0 > gpgcheck=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora > file:///etc/pki/rpm-gpg/RPM-GPG-KEY > > > So I'm assuming that you mean to uncomment the 'baseurl' which has > Everything and comment the 'mirrorlist' for [fedora]. > And if it succeeds how should I set the repositories going forward? Do > I leave it set to Everything or should I set it back to 'mirrorlist' > once the initial upgrade succeeds? > > The Everything repo succeeded in getting the machine updated to F7 with the exception that neither of the new kernels will boot the machine. They both get all kinds of ATA errors. I'm opening bugs on these issues. But at least the FC6 -> F7 upgrade does work from a yum point of view. So if I ever get the kernels to boot can I safely uncomment the 'mirrorlist' in fedora.repo for F7? From tmz at pobox.com Mon Jun 25 18:43:02 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 25 Jun 2007 14:43:02 -0400 Subject: Fedora Core Merge Reviews In-Reply-To: <1182796263.23775.47.camel@weaponx.rchland.ibm.com> References: <1182793399.2851.47.camel@kennedy> <4680072D.3080806@redhat.com> <1182796263.23775.47.camel@weaponx.rchland.ibm.com> Message-ID: <20070625184302.GG11776@psilocybe.teonanacatl.org> Josh Boyer wrote: > On Mon, 2007-06-25 at 14:19 -0400, Christopher Aillon wrote: >> This depends on whether Red Hat can do reviews of these packages. >> Many of us are under the assumption that since the packages came >> from Red Hat, we ought to let the community review them. > > I don't think we need to be that restrictive. I would say as long > as the maintainer of the package isn't also doing the review, it's > fine. > > There is no need to segregate reviewers based on employer. It just > needlessly limits the reviewer pool. Agreed. It would, of course, look bad if there were a ton of obviously blanket approval reviews. But the many packagers @redhat are definitely part of the community and their help should be welcomed. (Can we send stalled reviews to some folks inside redhat so they can toss various objects across the cubicles at any co-workers who've been too busy to reply to merge reviews yet? :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The more laws, the less justice. -- Marcus Tullius Cicero "De Officiis", 44 B.C. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From bpepple at fedoraproject.org Mon Jun 25 18:43:42 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 25 Jun 2007 14:43:42 -0400 Subject: Fedora Core Merge Reviews In-Reply-To: <1182796342.31081.68.camel@erebor.boston.redhat.com> References: <1182793399.2851.47.camel@kennedy> <4680072D.3080806@redhat.com> <1182796342.31081.68.camel@erebor.boston.redhat.com> Message-ID: <1182797022.2851.50.camel@kennedy> On Mon, 2007-06-25 at 14:32 -0400, Jeremy Katz wrote: > On Mon, 2007-06-25 at 14:19 -0400, Christopher Aillon wrote: > > > > This depends on whether Red Hat can do reviews of these packages. Many > > of us are under the assumption that since the packages came from Red > > Hat, we ought to let the community review them. > > While you shouldn't review your own package (or perhaps also for > packages that you're a substantial contributor to the packaging), I > don't think there's any problem at all with having another community > contributor who happens to have an @redhat.com address do a review of > the package. +1. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Jun 25 18:44:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 14:44:21 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/25/07 - 1:30PM EDT In-Reply-To: <200706251427.41110.jkeating@redhat.com> References: <200706251427.41110.jkeating@redhat.com> Message-ID: <200706251444.21175.jkeating@redhat.com> On Monday 25 June 2007 14:27:40 Jesse Keating wrote: > O U T A G E ? R E P O R T ? F O R M > =================================== > > Incident Date: ? ? ? ? ? > 6/25/07 ? ? ? ? ? ? > > Incident Time: ? ? ? ? ? > 1:30PM EDT ? ? ? ? ? > > Elapsed Time of Incident: > Ongoing ? ? The outage is now over. The server was rebooted. All active builds at tiem of the outage should continue through. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From debarshi.ray at gmail.com Mon Jun 25 19:26:38 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 26 Jun 2007 00:56:38 +0530 Subject: gnome-password-generator Message-ID: <3170f42f0706251226t26d9603ds82dd99acfc2b5495@mail.gmail.com> http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages The above URL lists gnome-password-generator as an orphaned package. I am interested in picking it up. If I am not stepping on anyone's toes I will submit a review request sometime soon. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From rdieter at math.unl.edu Mon Jun 25 20:07:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 25 Jun 2007 15:07:16 -0500 Subject: Fedora Core Merge Reviews References: <1182793399.2851.47.camel@kennedy> <4680072D.3080806@redhat.com> Message-ID: Christopher Aillon wrote: > Brian Pepple wrote: >> Hi, >> >> One of the items still left to do with regard to the recent merging of >> Core & Extras is the reviews on packages that previously were in Core. >> FESCo has been trying to determine what type of goal we should set for >> completion by F8 test 2. Most of us felt that it wasn't a reasonable >> goal to finish them all by that time, since there are more that 700 >> still needing to be completed. >> >> I'm looking for suggestions from the community on what you think is a >> reasonable number or percentage of reviews to complete by F8t2. > > This depends on whether Red Hat can do reviews of these packages. Many > of us are under the assumption that since the packages came from Red > Hat, we ought to let the community review them. As long as reviewer != pkg-owner, tis ok. -- Rex From kwade at redhat.com Mon Jun 25 20:11:49 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 13:11:49 -0700 Subject: FESCo elections In-Reply-To: <1182790685.2851.29.camel@kennedy> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <20070620082156.GA3069@dudweiler.stuttgart.redhat.com> <1182349833.30259.4.camel@erebor.boston.redhat.com> <1182350116.14977.20.camel@weaponx.rchland.ibm.com> <604aa7910706201014w67de72d6w72a23560321034fb@mail.gmail.com> <1182365777.14977.75.camel@weaponx.rchland.ibm.com> <604aa7910706201213g38ee4f97of5d9c256f35cddcc@mail.gmail.com> <1182644731.10205.300.camel@erato.phig.org> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <1182784185.2851.15.camel@kennedy> <1182787826.10205.427.camel@erato.phig.org> <1182790685.2851.29.camel@kennedy> Message-ID: <1182802309.10205.517.camel@erato.phig.org> On Mon, 2007-06-25 at 12:58 -0400, Brian Pepple wrote: > I wonder why people that are that interested in voting for FESCo, > wouldn't be interested in joining up with one of the groups (packaging, > QA, etc) that under the governance of FESCo? It's not like the bar for > entry is that high for all of them. Maybe someone is waiting for the right leadership to follow? Or hasn't found quite the right place? Hard to know, hard to guess, risky to assume. > Regardless, I think we have a fundamental difference of opinion here, > but I would be willing to have this brought up for a vote at this week's > FESCo meeting if you would like. If you could give me a proposal for > what you think the requirement for voting would be, I'll add it to this > week's schedule. I did my best to compile all of the proposals into this page. http://fedoraproject.org/wiki/KarstenWade/FranchisementGrantProposals You are all free to edit it there or copy it to another namespace. I hope I have done a fair job in making my point. I think this matter is very serious. The granting of a franchise should not be taken lightly. IMHO, enfranchisement is above the realm of 'opinion' and into the realm of 'ideal'. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Jun 25 20:16:45 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 13:16:45 -0700 Subject: FESCo elections In-Reply-To: <46800567.4000109@redhat.com> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> <20070625144818.GA27410@wolff.to> <1182787373.10205.417.camel@erato.phig.org> <46800567.4000109@redhat.com> Message-ID: <1182802605.10205.523.camel@erato.phig.org> On Mon, 2007-06-25 at 14:11 -0400, Christopher Aillon wrote: > Karsten Wade wrote: > > I propose we include the entirety of cla_done, but announce an age limit > > on the account -- it must be older than one week. This gives people a > > chance to get an account for the election (since voting lasts longer > > than a week) while leaving enough time for us to notice any > > pranks/gaming of the system. > > Let's hope the folks at ${anti-linux-company} won't see this as an > opportunity to have all their folks sign CLAs and rig future elections. I think the short-term risk is worth it, compared to disenfranchising hundreds. Highly agree with the security concerns; my proposal[1] is one-time only, and we need to immediately decide what is the magical meaning of contributor, how do we measure it, and use that forevermore. Right now, there are people making a *ton* of contributions on fedora-list, maybe they have an FAS account for future usage or would be encouraged to get one because of open elections. Just because we haven't found a way to count those folks for grant of a franchise doesn't mean they should get shorted. Best to lower the barrier as far as we can, one time, and then raise it in a proper, clear, documented, well-known way, forevermore. - Karsten [1] http://fedoraproject.org/wiki/KarstenWade/FranchisementGrantProposals#head-64c24e995a46b9a520094255db89b5fba2645dd3 -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Jun 25 20:28:22 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 25 Jun 2007 13:28:22 -0700 Subject: FESCo elections In-Reply-To: <1182786204.23775.44.camel@weaponx.rchland.ibm.com> References: <1182223698.2796.0.camel@kennedy> <1182716335.16446.18.camel@vader.jdub.homelinux.org> <1182752850.10205.371.camel@erato.phig.org> <200706250954.19676.jkeating@redhat.com> <20070625144818.GA27410@wolff.to> <1182786204.23775.44.camel@weaponx.rchland.ibm.com> Message-ID: <1182803302.10205.535.camel@erato.phig.org> On Mon, 2007-06-25 at 10:43 -0500, Josh Boyer wrote: > On Mon, 2007-06-25 at 09:48 -0500, Bruno Wolff III wrote: > > > > I think the requirement should be membership in some (any) other group than > > cla_done. This shows a bit more interest. It also requires manual approval > > so that some prankster can't hose an election by creating a lot of dummy > > accounts. (This would most likely be detected, but would still be a > > significant annoyance to have to clean up after.) I think this category > > would include all of the people that people have been concerned about in > > this discussion. > > I think this is the best suggestion to date. Fair enough suggestion, we'll survive if that's the way we go[1]. :) Please review, edit, fix, etc. the proposals before FESCo meets and decides on this. My draft page is at: http://fedoraproject.org/wiki/KarstenWade/FranchisementGrantProposals Brian or someone from FESCo can move it to another namespace, as you wish. - Karsten [1] There is going to be overlap in these groups. But compared to "cvsextras + qa + releng" where this thread started, it is obvious that even just Bruno's proposal brings in hundreds of people who should be voting for FESCo. accounts 6 ambassadors 222 art 21 cla_dell 2 cla_done 1349 cla_fedora 1290 cla_ibm admin 6 cla_redhat 133 cvsadmin 12 cvsdevel 14 cvsdirsec 14 cvsdocs admin 112 cvseclipse 2 cvsextras 420 cvsfedora 86 cvsfont llch 6 cvsl10n kwade 80 cvslegacy 6 distribution 3 epel_signers 2 extras_signers 7 fedorabugs 463 freemedia 2 gitbluecurve 2 gitkernel 5 -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Jun 25 21:35:24 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 25 Jun 2007 14:35:24 -0700 Subject: FESCo elections In-Reply-To: <1182644089.10205.291.camel@erato.phig.org> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <467936A6.2060402@redhat.com> <1182358804.8424.12.camel@localhost.localdomain> <1182644089.10205.291.camel@erato.phig.org> Message-ID: <1182807324.4173.50.camel@localhost.localdomain> On Sat, 2007-06-23 at 17:14 -0700, Karsten Wade wrote: > On Wed, 2007-06-20 at 10:00 -0700, Toshio Kuratomi wrote: > > Basically, you should be able to vote if you are under FESCo's > > authority. You should not be able to vote if you are not. > > The problem I have with this is that FESCo, unlike all bodies save the > Board, makes decisions that affect the entire project. > > I think "affects" should be the criteria, not "authority." > This raises some interesting thought-experiments. Let me state my core thought before diving off on those tangents, though: I think "authority" should be the guiding principle. "Affects" is much too broad. To take the argument to absurdium, what FESCo decides affects Ubuntu, SuSE, and the rest of the greater Linux Community. Should they be allowed to vote? At some point in the spectrum between cvsextras and absurdium, FESCo is the ruler of a body of people and therefore needs to listen to the wishes of those people by being elected by them. At some point beyond that, FESCo becomes the ruler of a neighboring project and FESCo's Project and the Neighbor Project have to learn to get along with each other. The farther out from the central purpose of a group that you cast your net of enfranchisement, the more you dilute the knowledge of what work the people you're voting for are doing presently. What is candidate A going to contribute to FESCo's future? Are they active in groups that are part of the central purpose of FESCo? Do they make good decisions there? Do they stick to their guns on things that are important and compromise on things that are not? The wider the scope of people, the more likely that you're going to end up with people who only know about a single issue: Candidate A wanted to delay the Fedora 8 Release Date, what do I care about their decisions on acls, packaging standards, string freeze, legality of firmware, etc. The only thing that affected me was the Release Date. That said, I won't argue that FESCo's authority has been expanded since the merge. Is FESCo's new charter to have (loose) authority over all of Fedora? FESCo is in charge of implementing Board decisions so Art, Docs, l10n, infrastructure, and the rest of Fedora are subprojects of FESCo? For the purposes of the election I can see a certain attraction to this. What you say about FESCo's decisions affecting everybody within Fedora has merit. For the purposes of working within the Fedora Project I am a small bit worried, though. Firstly, FESCo can only be a part of so much, involved in so much, accountable for so much. Secondly, Docs, Art, and other groups are viable independent communities that don't need the (hopefully light) hand of another committee sitting between them and the Board. In concrete terms, I'm against opening the election to cla_done. I'm for expanding and contracting FESCo's area of authority until it includes the groups that want to vote for FESCo (if everyone does and we end up including every group that's not cla_done/cla_fedora I'd be a little worried about the long term ramifications but we'll see when we get there.) P.S. If we include the wiki EditGroup in the "groups that can vote" someone has to write an importer that turns the EditGroup into Fedora Account System (FAS) accounts and adds them to a new FAS group. This may not be as hard as writing a new package dep solver but it is not trivial. And we're on a deadline. [OFFTOPIC] In our current world we have one very large and powerful neighbor that every other community has to learn to exist with. Would the world be better or worse if everyone affected by the neighbor had the ability to vote in the elections held there? Bonus points for humor if your reply starts with "Does this assume Microsoft stocks are equally distributed or still concentrated in the hands of a few?" ;-) [/OFFTOPIC] -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Jun 25 21:56:16 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 25 Jun 2007 23:56:16 +0200 Subject: Changing default syslog package In-Reply-To: <20070625174517.87477.qmail@web51502.mail.re2.yahoo.com> References: <20070625174517.87477.qmail@web51502.mail.re2.yahoo.com> Message-ID: <1182808576.1229.5.camel@rousalka.dyndns.org> Le lundi 25 juin 2007 ? 10:45 -0700, Steve G a ?crit : > Its configuration file does not > appear to be backawards compatible, meaning everyone will have to go reconfigure > their logging. Anyone that prefers syslog-ng can still use that. Actually it's painful to look at traditional syslog syntax after the nice syslog-ng streamlined format. And "reconfigure" is only people who didn't keep the default conf (not the vast majority of users). And this kind of user will rewrite his conf file to take advantage of the filtering modern syslog replacements allow anyway. -- 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 bruno at wolff.to Mon Jun 25 21:44:00 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 25 Jun 2007 16:44:00 -0500 Subject: FESCo elections In-Reply-To: <1182807324.4173.50.camel@localhost.localdomain> References: <1182223698.2796.0.camel@kennedy> <4678920A.5010308@redhat.com> <1182309035.29855.57.camel@localhost.localdomain> <1182317830.21966.415.camel@erato.phig.org> <1182347004.2806.20.camel@kennedy> <467936A6.2060402@redhat.com> <1182358804.8424.12.camel@localhost.localdomain> <1182644089.10205.291.camel@erato.phig.org> <1182807324.4173.50.camel@localhost.localdomain> Message-ID: <20070625214400.GA2844@wolff.to> On Mon, Jun 25, 2007 at 14:35:24 -0700, Toshio Kuratomi wrote: > > P.S. If we include the wiki EditGroup in the "groups that can vote" > someone has to write an importer that turns the EditGroup into Fedora > Account System (FAS) accounts and adds them to a new FAS group. This > may not be as hard as writing a new package dep solver but it is not > trivial. And we're on a deadline. There probably should be some easy way to associate EditGroup members with FAS accounts in any case, since I would think people would want to be able to audit that people in the EditGroup actually did do a cla. In theory, you can make a good first cut matching the email address in the wiki with the one in the FAS. A one time version of this should be easily doable before the election. In the long run the wiki and FAS should be tied closer together. From tcallawa at redhat.com Mon Jun 25 22:48:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 25 Jun 2007 17:48:20 -0500 Subject: fedora for ARM In-Reply-To: <1182780669.30663.297.camel@localhost.localdomain> References: <20070602032955.GC16918@xi.wantstofly.org> <20070624062858.GA22368@xi.wantstofly.org> <1182780669.30663.297.camel@localhost.localdomain> Message-ID: <1182811700.29010.72.camel@localhost.localdomain> On Mon, 2007-06-25 at 10:11 -0400, Adam Jackson wrote: > Many of these are just adding %{arm} to ExclusiveArch. I'm becoming of > the opinion that ExclusiveArch is almost always worse than ExcludeArch, > and that the presence of either one should be justified either in the > review or in the spec itself. > > At the moment, the packaging guidelines say nothing about this, afaict. But, for what it is worth, the SecondaryArchitectures draft does comment on this subject: "Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture. By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new secondary architectures, rather than being immediately ignored by a blanket ExclusiveArch." http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures ~spot From sundaram at fedoraproject.org Mon Jun 25 23:21:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 Jun 2007 04:51:38 +0530 Subject: Fedora 7 common bugs and FAQ Message-ID: <46804E02.8060409@fedoraproject.org> Hi Common bugs reported and discussed about Fedora 7 are documented in http://fedoraproject.org/wiki/Bugs/F7Common Also a Fedora 7 specific FAQ is maintained by me at http://fedoraproject.org/wiki/Fedora7/FAQ which is linked from Fedora Documentation section. If there are other common bugs that have a proper bug report in Red Hat Bugzilla associated with them or if you have any other frequently asked questions on Fedora 7, edit the wiki directly or let me know. Rahul From cweyl at alumni.drew.edu Tue Jun 26 00:45:41 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 25 Jun 2007 17:45:41 -0700 Subject: F7 && Firewire? Message-ID: <7dd7ab490706251745o699249fcv9ba83bb91f3b785b@mail.gmail.com> Hey all-- I'm thinking about upgrading my main workstation to F7; however I I haven't been following things very closely for the last couple weeks. Are there still issues that would reasonably preclude my upgrading? (Not being able to burn DVD's or use my iPod counts :)) Thanks- -Chris -- Chris Weyl Ex astris, scientia From sundaram at fedoraproject.org Tue Jun 26 00:51:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 Jun 2007 06:21:15 +0530 Subject: F7 && Firewire? In-Reply-To: <7dd7ab490706251745o699249fcv9ba83bb91f3b785b@mail.gmail.com> References: <7dd7ab490706251745o699249fcv9ba83bb91f3b785b@mail.gmail.com> Message-ID: <46806303.7030207@fedoraproject.org> Chris Weyl wrote: > Hey all-- > > I'm thinking about upgrading my main workstation to F7; however I I > haven't been following things very closely for the last couple weeks. > Are there still issues that would reasonably preclude my upgrading? > (Not being able to burn DVD's or use my iPod counts :)) > > Thanks- I heard some grumbling in a couple posts about firewire in the forums. Why don't you check it out first using the Live images? Rahul From cweyl at alumni.drew.edu Tue Jun 26 01:03:12 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 25 Jun 2007 18:03:12 -0700 Subject: F7 && Firewire? In-Reply-To: <46806303.7030207@fedoraproject.org> References: <7dd7ab490706251745o699249fcv9ba83bb91f3b785b@mail.gmail.com> <46806303.7030207@fedoraproject.org> Message-ID: <7dd7ab490706251803i5f3f8c8doc144e1afbaa10bba@mail.gmail.com> On 6/25/07, Rahul Sundaram wrote: > I heard some grumbling in a couple posts about firewire in the forums. > Why don't you check it out first using the Live images? Such a simple solution, of course I'd overlook it. Thanks :) -Chris -- Chris Weyl Ex astris, scientia From pmatilai at redhat.com Tue Jun 26 06:30:37 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 26 Jun 2007 09:30:37 +0300 (EEST) Subject: New rpm version about to hit rawhide Message-ID: Just a heads-up: at long last, there's a brand new rpm version (4.4.2.1 release candidate) coming soon to rawhide near you. It's mostly just boring old bugfixes but the total amount of changes since 4.4.2 is such that you never know. More details here for those who are interested: https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000406.html Expect memory use go up, dramatically. That's the price to pay for finally "fixing" the multilib %doc etc file removal bug by nuking the nasty skipDir hack that caused it to begin with. Whether we can actually live with the ballooned memory usage, especially in the installer, remains to be seen... - Panu - From andy at warmcat.com Tue Jun 26 08:11:50 2007 From: andy at warmcat.com (Andy Green) Date: Tue, 26 Jun 2007 09:11:50 +0100 Subject: New rpm version about to hit rawhide In-Reply-To: References: Message-ID: <4680CA46.3010904@warmcat.com> Panu Matilainen wrote: > Expect memory use go up, dramatically. That's the price to pay for > finally "fixing" the multilib %doc etc file removal bug by nuking > the nasty skipDir hack that caused it to begin with. Whether we can > actually live with the ballooned memory usage, especially in the > installer, remains to be seen... Of the two issues, surely memory use is the worst? I installed F7 on my in-laws' old laptop with 256MB last week, it did install okay because I took the precaution of turning everything except the most basic stuff off (including X), then yumming it in afterwards. Previously I upgraded FC5 on a 384MB box and it took most of the day. Are the "dramatic" increases only seen in the multilib case itself? That wouldn't be so bad since x86_64 boxes will have lots of memory... -Andy From mschwendt.tmp0701.nospam at arcor.de Tue Jun 26 08:48:11 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 26 Jun 2007 10:48:11 +0200 Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> Message-ID: <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> On Mon, 25 Jun 2007 13:34:30 -0400, Eric Tanguy (tanguy) wrote: > Author: tanguy > > Update of /cvs/extras/rpms/libupnp/FC-6 > %changelog > +* Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 > +- Update to version 1.6.0 > + Blacklisted for now together with ushare. It breaks dependencies in several packages. Run "repoquery --whatrequires libupnp.so.2", use rpmdev-diff, announce such ABI breakage on fedora-maintainers list, and if such a version upgrade is really necessary, coordinate rebuilds appropriately. From pnasrat at redhat.com Tue Jun 26 09:35:36 2007 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 26 Jun 2007 10:35:36 +0100 Subject: New rpm version about to hit rawhide In-Reply-To: <4680CA46.3010904@warmcat.com> References: <4680CA46.3010904@warmcat.com> Message-ID: <1182850536.2974.25.camel@enki.eridu> On Tue, 2007-06-26 at 09:11 +0100, Andy Green wrote: > Panu Matilainen wrote: > > > Expect memory use go up, dramatically. That's the price to pay for > > finally "fixing" the multilib %doc etc file removal bug by nuking > > the nasty skipDir hack that caused it to begin with. Whether we can > > actually live with the ballooned memory usage, especially in the > > installer, remains to be seen... > > Of the two issues, surely memory use is the worst? Many people seem to disagree. > I installed F7 on my > in-laws' old laptop with 256MB last week, it did install okay because I > took the precaution of turning everything except the most basic stuff > off (including X), then yumming it in afterwards. Previously I upgraded > FC5 on a 384MB box and it took most of the day. Are the "dramatic" > increases only seen in the multilib case itself? That wouldn't be so > bad since x86_64 boxes will have lots of memory... No the issue is not purely on multilib occurs with multiple identical basenames - eg multiple kernels, COPYING etc. Paul From buildsys at fedoraproject.org Tue Jun 26 09:45:04 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 26 Jun 2007 05:45:04 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-26 Message-ID: <20070626094504.0B746152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 14 bcfg2-0.9.4-2.fc6 gnu-smalltalk-2.3.5-1.fc6.1 gprolog-1.3.0-9.fc6 gwget-0.99-1.fc6 jd-1.9.5-0.6.rc070625.fc6 NEW libgsasl-0.2.18-3.fc6 : GNU SASL library NEW libntlm-0.3.13-3.fc6 : NTLM authentication library mock-0.7.2-1.fc6.1 NEW perl-Crypt-Simple-0.06-3.fc6 : Encrypt stuff simply NEW perl-Test-Number-Delta-1.03-1.fc6 : Compare the difference between numbers against a given tolerance pidgin-2.0.2-3.fc6.1 wine-0.9.39-1.fc6 NEW xawtv-3.95-3.fc6 : TV applications for video4linux compliant devices xfce4-places-plugin-0.3.0-1.fc6 Packages built and released for Fedora Extras 5: 1 jd-1.9.5-0.6.rc070625.fc5 Changes in Fedora Extras 6: bcfg2-0.9.4-2.fc6 ----------------- * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-2 - Bump revision and rebuild * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-1 - Update to 0.9.4 final * Thu Jun 21 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre4 - Update to 0.9.4pre4 * Thu Jun 14 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre3 - Update to 0.9.4pre3 * Tue Jun 12 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre2 - Update to 0.9.4pre2 gnu-smalltalk-2.3.5-1.fc6.1 --------------------------- * Mon Jun 25 2007 Jochen Schmitt 2.3.5-1.1 - Try to fix tagging issue * Sun Jun 03 2007 Jochen Schmitt 2.3.5-1 - New upstream release * Wed May 30 2007 Jochen Schmitt 2.3.4-4 - Remove references to sigseg lib shiped with the package * Mon May 28 2007 Jochen Schmitt 2.3.4-1 - New upstream release gprolog-1.3.0-9.fc6 ------------------- * Wed Jun 13 2007 Jochen Schmitt 1.3.0-9 - Rebuild to solve a koji issue. * Thu May 24 2007 Jochen Schmitt 1.3.0-8 - Include the PPC arch to build - Remove _smp_mflags becouse is make trouble - Used unmodified optflags gwget-0.99-1.fc6 ---------------- * Mon Jun 25 2007 Christoph Wickert 0.99-1 - Update to 0.99 - Remove epiphany patch, not needed any longer for FC6 - Update desktop file * Sat Nov 11 2006 Christoph Wickert 0.98.2-1 - Update to 0.98.2. - Don't crash notification area (#213480). - Add support for epiphany 2.17. jd-1.9.5-0.6.rc070625.fc6 ------------------------- * Mon Jun 25 2007 Mamoru Tasaka - 1.9.5-0.6.rc070625 - 1.9.5 rc 070625 libgsasl-0.2.18-3.fc6 --------------------- * Tue Jun 26 2007 Nikolay Vladimirov - 0.2.18-3 - added NTLM support * Fri Jun 22 2007 Nikolay Vladimirov - 0.2.18-2 - fixed mixed-use-of-spaces-and-tabs - fixed timestamps for header files - edited summary * Thu Jun 21 2007 Nikolay Vladimirov - 0.2.18-1 - initial release libntlm-0.3.13-3.fc6 -------------------- * Thu Jun 21 2007 Nikolay Vladimirov - 0.3.13-3 - minor mixed-use-of-spaces-and-tabs fix * Thu Jun 21 2007 Nikolay Vladimirov - 0.3.13-2 - fixed summary - fixed requires and buildrequires for pkgconfig - fixed the timestamp of ntlm.h * Wed Jun 20 2007 Nikolay Vladimirov - 0.3.13-1 - initial release mock-0.7.2-1.fc6.1 ------------------ * Wed Jun 13 2007 Michael Brown - 0.7.1-1 - Fix problem with autocache where different users couldnt share same cache - Fix problem creating resolv.conf in rootfs - cleanup perms on rootfs /etc/ * Tue Jun 12 2007 Michael Brown - 0.7.1-1 - add EPEL 5 config files * Mon Jun 11 2007 Clark Williams - 0.7-1 - fixed bind mount problems - added code to allow multiple users to use --no-clean - merged mock-0-6-branch to head and changed version * Thu Jun 07 2007 Clark Williams - 0.6.17-1 - added F-7 config files (BZ#242276) - modified epel configs for changed mirrorlist location (BZ#239981) - added bind mount of /dev (BZ#236428) - added copy of /etc/resolv.conf to chroot (BZ#237663 and BZ#238101) * Tue May 01 2007 Clark Williams - 0.6.16-1 - timeout code adds new cmdline option that will kill build process after specified timeout. Useful for automated builds of things that may hang during build and you just want it to fail. * Tue Apr 10 2007 Clark Williams - 0.6.15-1 - Fixed typo in FC4 -epel configs (BZ 235490) * Sat Feb 24 2007 Clark Williams - 0.6.14-1 - Ville Skytt?'s fix for RPM_OPT_FLAGS (BZ 226673) * Tue Feb 20 2007 Clark Williams - 0.6.13-1 - Handle --no-clean option when doing yum.conf symlink (BZ 230824) * Fri Feb 16 2007 Clark Williams - 0.6.12-1 - added safety symlink for yum.conf * Wed Feb 07 2007 Clark Williams - 0.6.11-1 - added error() calls to print command output on failed commands * Tue Feb 06 2007 Clark Williams - 0.6.11-1 - added installdeps command for long-term chroot management perl-Crypt-Simple-0.06-3.fc6 ---------------------------- * Mon Jun 25 2007 Allisson Azevedo 0.06-3 - Remove perl-Test-Simple and perl-ExtUtils-MakeMaker * Sat Jun 23 2007 Allisson Azevedo 0.06-2 - Add missing buildrequires * Mon Jun 11 2007 Allisson Azevedo 0.06-1 - Initial RPM release perl-Test-Number-Delta-1.03-1.fc6 --------------------------------- * Sun Jun 24 2007 Jose Pedro Oliveira - 1.03-1 - First build. pidgin-2.0.2-3.fc6.1 -------------------- * Tue Jun 19 2007 Warren Togami - 2.0.2-3 - libpurple obsoletes and provides gaim This smoothens multilib the upgrade path. * Fri Jun 15 2007 Stu Tomlinson - 2.0.2-1 - 2.0.2 * Wed Jun 06 2007 Stu Tomlinson - 2.0.1-5 - Enable Bonjour support (#242949) - Fix building against latest evolution-data-server * Tue Jun 05 2007 Stu Tomlinson - 2.0.1-4 - Fix purple-remote for AIM & ICQ accounts (#240589) - Add missing Requires to -devel packages - Add missing BuildRequires for libxml2-devel * Thu May 31 2007 Stu Tomlinson - 2.0.1-2 - Call g_thread_init early (#241883) - Fix purple-remote syntax error (#241905) wine-0.9.39-1.fc6 ----------------- * Sun Jun 17 2007 Andreas Bierfert - 0.9.39-1 - version upgrade - convert to utf8 (#244046) - fix mime entry (#243511) * Sun Jun 03 2007 Andreas Bierfert 0.9.38-2 - allow full opt flags again - set ExclusiveArch to i386 for koji to only build i386 * Sat Jun 02 2007 Andreas Bierfert 0.9.38-1 - version upgrade (#242087) - fix menu problem (#220723) - fix BR - clean up desktop file section * Wed May 23 2007 Andreas Bierfert 0.9.37-1 - version upgrade - add BR for xcursor (#240648) - add desktop entry for wineboot (#240683) - add mime handler for msi files (#240682) - minor cleanups xawtv-3.95-3.fc6 ---------------- * Mon Jun 25 2007 Dmitry Butskoy - 3.95-3 - add patch for use getpagesize() instead of a kernel headers macro * Thu Jun 21 2007 Dmitry Butskoy - 3.95-1 - spec file cleanup - accepted for Fedora (review by Jason Tibbitts ) xfce4-places-plugin-0.3.0-1.fc6 ------------------------------- * Thu May 17 2007 Christoph Wickert - 0.3.0-1 - Update to 0.3.0 Changes in Fedora Extras 5: jd-1.9.5-0.6.rc070625.fc5 ------------------------- * Mon Jun 25 2007 Mamoru Tasaka - 1.9.5-0.6.rc070625 - 1.9.5 rc 070625 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From andy at warmcat.com Tue Jun 26 09:48:29 2007 From: andy at warmcat.com (Andy Green) Date: Tue, 26 Jun 2007 10:48:29 +0100 Subject: New rpm version about to hit rawhide In-Reply-To: <1182850536.2974.25.camel@enki.eridu> References: <4680CA46.3010904@warmcat.com> <1182850536.2974.25.camel@enki.eridu> Message-ID: <4680E0ED.2070202@warmcat.com> Paul Nasrat wrote: > On Tue, 2007-06-26 at 09:11 +0100, Andy Green wrote: >> Panu Matilainen wrote: >> >>> Expect memory use go up, dramatically. That's the price to pay for >>> finally "fixing" the multilib %doc etc file removal bug by nuking >>> the nasty skipDir hack that caused it to begin with. Whether we can >>> actually live with the ballooned memory usage, especially in the >>> installer, remains to be seen... >> Of the two issues, surely memory use is the worst? > > Many people seem to disagree. I guess those 'many' people aren't installing and updating on low end machines from a couple of years ago. >> I installed F7 on my >> in-laws' old laptop with 256MB last week, it did install okay because I >> took the precaution of turning everything except the most basic stuff >> off (including X), then yumming it in afterwards. Previously I upgraded >> FC5 on a 384MB box and it took most of the day. Are the "dramatic" >> increases only seen in the multilib case itself? That wouldn't be so >> bad since x86_64 boxes will have lots of memory... > > No the issue is not purely on multilib occurs with multiple identical > basenames - eg multiple kernels, COPYING etc. What I meant is, if the increases in memory footprint are only seen when libraries from multiple arches are actually being dealt with, it wouldn't be a regression for the older x86 boxes with relatively low memory, nor such a problem for x86_64 boxes which typically have lots of memory. But if the price in memory for solving a multilib issue has to be paid for even when a single arch is all there is, that would be more painful since already struggling low memory single-arch boxes have to pay it for no benefit to them. -Andy From buildsys at fedoraproject.org Tue Jun 26 09:51:53 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 26 Jun 2007 09:51:53 -0000 Subject: Summary - Broken dependencies in Fedora 5 - 2007-06-25 Message-ID: <20070626095153.19355.56904@extras64.linux.duke.edu> Summary of broken packages (by owner): matthias AT rpmforge.net python-Coherence - 0.2.1-3.fc5.noarch (43 days) python-Coherence - 0.2.1-3.fc5.noarch (43 days) python-Coherence - 0.2.1-3.fc5.noarch (43 days) ====================================================================== Broken packages in fedora-extras-5-i386: python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web python-Coherence-0.2.1-3.fc5.noarch requires python-nevow python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core python-Coherence-0.2.1-3.fc5.noarch requires python-configobj ====================================================================== Broken packages in fedora-extras-5-ppc: python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web python-Coherence-0.2.1-3.fc5.noarch requires python-nevow python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core python-Coherence-0.2.1-3.fc5.noarch requires python-configobj ====================================================================== Broken packages in fedora-extras-5-x86_64: python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web python-Coherence-0.2.1-3.fc5.noarch requires python-nevow python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core python-Coherence-0.2.1-3.fc5.noarch requires python-configobj From drago01 at gmail.com Tue Jun 26 10:01:10 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 26 Jun 2007 12:01:10 +0200 Subject: New rpm version about to hit rawhide In-Reply-To: References: Message-ID: <4680E3E6.4030200@gmail.com> Panu Matilainen wrote: > > Expect memory use go up, dramatically. by how much? any numbers? would be interessting to see... From buildsys at redhat.com Tue Jun 26 10:33:07 2007 From: buildsys at redhat.com (Build System) Date: Tue, 26 Jun 2007 06:33:07 -0400 Subject: rawhide report: 20070626 changes Message-ID: <200706261033.l5QAX7Ma022228@porkchop.devel.redhat.com> New package keepassx Cross-platform password manager New package libgsasl GNU SASL library New package libntlm NTLM authentication library New package nss-mdns glibc plugin for .local name resolution New package perl-Crypt-Simple Encrypt stuff simply New package perl-MogileFS-Utils Utilities for MogileFS New package perl-Test-Number-Delta Compare the difference between numbers against a given tolerance New package xawtv TV applications for video4linux compliant devices Updated Packages: GConf2-2.19.1-1.fc8 ------------------- * Mon Jun 25 2007 Matthias Clasen - 2.19.1-1 - Update to 2.19.1 amanda-2.5.2p1-3.fc8 -------------------- * Mon Jun 25 2007 Radek Brich 2.5.2.p1-3 - Update -undefSymbols patch. All undefined symbols reported by 'ldd -r' should now be fixed (#198178). aqbanking-2.2.9-3.fc8 --------------------- * Mon Jun 25 2007 Bill Nottingham - 2.2.9-3 - fix some build bogosity * Wed Jun 20 2007 Bill Nottingham - 2.2.9-2 - add a dist tag autofs-1:5.0.2-4 ---------------- * Mon Jun 25 2007 Ian Kent - 5.0.2-4 - update multi map nsswitch patch. * Mon Jun 25 2007 Ian Kent - 5.0.2-3 - add missing "multi" map support. - add multi map nsswitch lookup. avahi-0.6.20-3.fc8 ------------------ * Mon Jun 25 2007 Bill Nottingham - 0.6.20-3 - fix %endif typo * Mon Jun 25 2007 Lennart Poettering - 0.6.20-2 - add gtk-sharp2-devel to build deps * Fri Jun 22 2007 Lennart Poettering - 0.6.20-1 - upgrade to new upstream 0.6.20 - fix a few rpmlint warnings - create avahi-autoipd user - no longer create avahi user with a static uid, move to dynamic uids - drop a couple of patches merged upstream - Provide "howl" and "howl-devel" - Split off avahi-autoipd and avahi-dnsconfd - Introduce avahi-ui packages for the first time - Reload D-Bus config after installation using dbus-send - add a couple of missing ldconfig invocations bcfg2-0.9.4-2.fc8 ----------------- * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-2 - Bump revision and rebuild * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-1 - Update to 0.9.4 final curl-7.16.3-1.fc8 ----------------- * Mon Jun 25 2007 Jindrich Novy 7.16.3-1 - update to 7.16.3 - drop .print patch, applied upstream - next series of merge review fixes by Paul Howarth - remove aclocal stuff, no more needed - simplify makefile arguments - don't reference standard library paths in libcurl.pc - include docs/CONTRIBUTE * Mon Jun 18 2007 Jindrich Novy 7.16.2-5 - don't print like crazy (#236981), backported from upstream CVS * Fri Jun 15 2007 Jindrich Novy 7.16.2-4 - another series of review fixes (#225671), thanks to Paul Howarth - check version of ldap library automatically - don't use %makeinstall and preserve timestamps - drop useless patches e2fsprogs-1.39-15.fc8 --------------------- * Mon Jun 25 2007 Eric Sandeen 1.39-15 - Fix up .po files to remove timestamps; multilib issues (#245653) eterm-0.9.4-6.fc8 ----------------- * Mon Jun 25 2007 Terje R??sten - 0.9.4-6 - Remove Application from Categories list in desktop file flex-2.5.33-9.fc8 ----------------- * Fri Jun 22 2007 Petr Machata - 2.5.33-9 - Remove wrong use of @includedir@ in Makefile.in. - Spec cleanups. - Related: #225758 git-1.5.2.2-2.fc8 ----------------- * Thu Jun 21 2007 Josh Boyer 1.5.2.2-2 - Add emacs-git package (#235431) gnucash-2.1.4-1.fc8 ------------------- * Mon Jun 25 2007 Bill Nottingham - 2.1.4-1 - update to RC version 2.1.4 - switch to using goffice04, and stock gtkhtml3 - no more g-wrap or libtool-ltdl - use swig gq-1.2.2-4.fc8 -------------- * Mon Jun 25 2007 Terje R??sten - 1.2.2-4 - Fix categories in desktop file * Sun May 20 2007 Terje R??sten - 1.2.2-3 - Add auth patch * Mon Nov 20 2006 Terje R??sten - 1.2.2-2 - Fix patch/source naming - Add gettext to BuildReq - Move %post/%postun - Remove cp macro - Add libgcrypt-devel to BuildReq hwdata-0.204-1.fc8 ------------------ * Mon Jun 25 2007 Karsten Hopp 0.204-1 - add some Samsung monitors to MonitorsDB, bz#245434, bz#245439 * Mon Jun 25 2007 Karsten Hopp 0.203-1 - add Samsung Syncmaster 591v, bz#240660 - add LG L1740B, Mtek MT-0910, bz#240662 - move blacklist matrxfb_base from module-init-tools blacklist-compat into hwdata's blacklist, bz#241595 - update pci.ids, usb.ids iscsi-initiator-utils-6.2.0.865-0.1.fc7 --------------------------------------- * Mon Jun 25 2007 Mike Christie - 6.2.0.865-0.1 - Rebase to upstream stable which has a fix for the logoutall command. This will fix the service iscsi stop command. - 225915 Compile iscsistart as dynamic. jd-1.9.5-0.6.rc070625.fc8 ------------------------- * Mon Jun 25 2007 Mamoru Tasaka - 1.9.5-0.6.rc070625 - 1.9.5 rc 070625 * Sat Jun 16 2007 Mamoru Tasaka - 1.9.5-0.5.beta070616 - 1.9.5 beta 070616 * Mon Jun 11 2007 Mamoru Tasaka - 1.9.5-0.4.beta070611 - 1.9.5 beta 070611 k3b-0:1.0.2-1.fc8 ----------------- * Sat Jun 23 2007 Rex Dieter - 0:1.0.2-1 - k3b-1.0.2 * Sat Jun 16 2007 Rex Dieter - 0:1.0.1-4 - k3b-iso.desktop,k3b-cue.desktop: +NoDisplay=True (#244513) k3d-0.6.6.0-1.fc7 ----------------- * Wed May 30 2007 Denis Leroy - 0.6.6.0-1 - Update to 0.6.6.0 - Removed patches that moved upstream - Added gnome-vfs2-devel, fixed gnome-vfs2 missing config - Fixed lib64 script to avoid autoreconf - Added aqsis dependency kernel-2.6.21-1.3240.fc8 ------------------------ * Mon Jun 25 2007 Chuck Ebbert - 2.6.22-rc6 - cfs update for -rc6 * Mon Jun 25 2007 John W. Linville - Re-enable wireless-dev patch (updated for current kernel) * Mon Jun 25 2007 Roland McGrath - Let spec-file ApplyPatch function pass extra args to patch. - Re-enable utrace patch with -F2, needed after nearby CFS change. - utrace update (06c303cccb93e7ca3a95923e69b4d82733c1cf00) koan-0.4.0-2.fc7 ---------------- * Mon Jun 04 2007 Michael DeHaan - 0.4.0-2 - ExcludeArch: ppc64 to make F7 buildsys happy * Thu May 31 2007 Michael DeHaan - 0.4.0-1 - Upstream changes (see CHANGELOG) libjpeg-6b-38.fc8 ----------------- * Mon Jun 25 2007 Tom Lane - 6b-38 - Initial review of package by new (old?) maintainer; marginal specfile cleanup - Restore libjpeg.a to distribution, in a separate -static subpackage Resolves: #186060, #215537 - Fix non-security-significant buffer overrun in wrjpgcom, per Lubomir Kundrak Resolves: #226965 - Apply patch4 that was added by previous maintainer, but never applied Resolves: #244778 Related: #238936 - Fix inter-RPM dependencies to include release Resolves: #238780 libupnp-1.6.0-1.fc8 ------------------- * Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 - Update to version 1.6.0 pam_krb5-2.2.12-2 ----------------- * Mon Jun 25 2007 Nalin Dahyabhai - 2.2.12-2 - rebuild * Sun Jun 24 2007 Nalin Dahyabhai - 2.2.12-1 - update to 2.2.12 * Sun Oct 01 2006 Jesse Keating - 2.2.11-2 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 policycoreutils-2.0.22-3.fc8 ---------------------------- * Mon Jun 25 2007 Dan Walsh 2.0.22-3 - Fix spelling mistakes in GUI python-inotify-0.7.0-3.fc8 -------------------------- qt4-4.3.0-5.fc8 --------------- * Sat Jun 23 2007 Rex Dieter 4.3.0-5 - fix rpm macros, (%_qt_plugindir, %_qt4_translationdir} * Thu Jun 21 2007 Rex Dieter 4.3.0-4 - .desktop Category cleanup * Thu Jun 21 2007 Rex Dieter 4.3.0-3 - cleanup qconfig.h/multilib bits, add s390x/s390 scim-pinyin-0.5.91-18.fc8 ------------------------- * Tue Jun 26 2007 Huang Peng - 0.5.91-18 - Refine rpm package to resolve some warning in build.log. sysklogd-1.4.2-10.fc8 --------------------- * Mon Jun 25 2007 Peter Vrabec 1.4.2-10 - fix syslog init script error codes (#245330) w3m-0.5.2-1.fc8 --------------- * Tue Jun 26 2007 Parag Nemade - 0.5.2-1 - Update to 0.5.2 and remove merged patches. - Build against system gc library. - Add BR: nkf for multipart.cgi. - Don't call unneeded autotool * Tue Mar 27 2007 Parag Nemade - 0.5.1-19 - and more cleanup. * Tue Mar 27 2007 Parag Nemade - 0.5.1-18.2 - more cleanup. xorg-x11-drv-amd-0.0-22.20070625.fc8 ------------------------------------ * Mon Jun 25 2007 Dan Williams 0.0-22.20070625 - Udpate to git snapshot - Fix downscaling on the LX - cairo 1.4.4 and Xorg 1.3 fixes * Wed Jun 13 2007 Dan Williams 0.0-21.20070613 - Udpate to git snapshot * Mon May 07 2007 Dan Williams 0.0-21.20070504 - Cleanups and fixes from -Wall xorg-x11-fonts-7.2-1.fc8 ------------------------ * Fri Jun 22 2007 Kristian H??gsberg - 7.2-1 - Use the new catalogue font install mechanism, drop all chkfontpath dependencies. - Unsplit base and misc subpackages, we don't require any base fonts now that we have built-ins. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit - 1:2.18.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gmediaserver - 0.12.0-9.fc7.i386 requires libupnp.so.2 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 ushare - 0.9.10-2.fc7.i386 requires libupnp.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit - 1:2.18.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gmediaserver - 0.12.0-9.fc7.x86_64 requires libupnp.so.2()(64bit) gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) ushare - 0.9.10-2.fc7.x86_64 requires libupnp.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit - 1:2.18.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gmediaserver - 0.12.0-9.fc7.ppc requires libupnp.so.2 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 ushare - 0.9.10-2.fc7.ppc requires libupnp.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-examples - 20070216-2.fc7.noarch requires geda-gschem gedit - 1:2.18.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gmediaserver - 0.12.0-9.fc7.ppc64 requires libupnp.so.2()(64bit) gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) ushare - 0.9.10-2.fc7.ppc64 requires libupnp.so.2()(64bit) From kwizart at gmail.com Tue Jun 26 10:42:59 2007 From: kwizart at gmail.com (KH KH) Date: Tue, 26 Jun 2007 12:42:59 +0200 Subject: F7 && Firewire? In-Reply-To: <46806303.7030207@fedoraproject.org> References: <7dd7ab490706251745o699249fcv9ba83bb91f3b785b@mail.gmail.com> <46806303.7030207@fedoraproject.org> Message-ID: 2007/6/26, Rahul Sundaram : > Chris Weyl wrote: > > Hey all-- > > > > I'm thinking about upgrading my main workstation to F7; however I I > > haven't been following things very closely for the last couple weeks. > > Are there still issues that would reasonably preclude my upgrading? > > (Not being able to burn DVD's or use my iPod counts :)) > > > > Thanks- > > I heard some grumbling in a couple posts about firewire in the forums. > Why don't you check it out first using the Live images? > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Hi! I don't know if there is some news about this, but the the new firewire (juju stack) in Fedora 7 lacks support of eth1394 at this time (I'm concerned as i would like to uses it). If ever there is some patches i could provides feedback... Also, only libdc1394-2 (alpha/beta state - currently in review) seems to be supported but lot of applications still uses libdc1394(-1) (submitted as a review by me), which will not work with the new juju stack unless a backported patch is provided.... Others components ares supposed to work well (you should test them indeed - and report bug if they is). Nicolas (kwizart) From kevin.kofler at chello.at Tue Jun 26 11:18:45 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 26 Jun 2007 11:18:45 +0000 (UTC) Subject: New rpm version about to hit rawhide References: <4680CA46.3010904@warmcat.com> <1182850536.2974.25.camel@enki.eridu> <4680E0ED.2070202@warmcat.com> Message-ID: Andy Green warmcat.com> writes: > >> Of the two issues, surely memory use is the worst? Surely correctness is more important! > But if the price in memory for solving a multilib issue has to be paid > for even when a single arch is all there is, that would be more painful > since already struggling low memory single-arch boxes have to pay it for > no benefit to them. There is a benefit. This bug doesn't only affect multilib. Another common case where it triggers is failed %postun scriptlets. When you then rpm -e --noscripts the old version, suddenly some files are gone. > I guess those 'many' people aren't installing and updating on low end > machines from a couple of years ago. Oh, I am. I have a Pentium II laptop with 160 MB RAM. It was one of the machines hit by this bug (failed nfs-utils %postun) and I ended up resorting to restoring the missing documentation files manually. (I guess I could also just have ignored it, but missing files which are supposed to be installed are bad.) So I'd sure appreciate that laptop getting the fix, even if it means more memory use. > >> I installed F7 on my > >> in-laws' old laptop with 256MB last week, it did install okay because I > >> took the precaution of turning everything except the most basic stuff > >> off (including X), then yumming it in afterwards. I've already given up on Anaconda on that laptop. I just used apt-rpm to upgrade from FC5 to FC6 (which has the advantage of being able to swap out whereas Anaconda tends to simply crash when it runs out of memory) and I'm planning to the the same for FC6->F7. (It's still running FC6 right now.) The FC2->FC5 Anaconda upgrade had to be restarted a couple of times due to Anaconda just locking up from lack of memory. Luckily, it did that when computing the upgrades from the next ISO (I did a HD install with CD ISOs), not in the middle of a transaction. So now I'm unwilling to let Anaconda anywhere near that machine, it doesn't have enough RAM. Oh, and to compensate, apt-rpm memory use is going to improve a lot with SQLite metadata support which is already in the latest development version, so I'm not worried. Kevin Kofler From andy at warmcat.com Tue Jun 26 11:55:26 2007 From: andy at warmcat.com (Andy Green) Date: Tue, 26 Jun 2007 12:55:26 +0100 Subject: New rpm version about to hit rawhide In-Reply-To: References: <4680CA46.3010904@warmcat.com> <1182850536.2974.25.camel@enki.eridu> <4680E0ED.2070202@warmcat.com> Message-ID: <4680FEAE.8090103@warmcat.com> Kevin Kofler wrote: > Andy Green warmcat.com> writes: >>>> Of the two issues, surely memory use is the worst? > > Surely correctness is more important! It is very important, but so is being able to upgrade Fedora at all on a given box. In my usage case I am visiting three different relatives and friends houses now and then with limited time available to do an upgrade, on hardware that is past its use-by date. If the cost of getting the docs straight means actually upgrading it is out of scope that isn't good (besides rm -rf /usr/share/doc is the first move if disk space runs low on these old clunkers). >> But if the price in memory for solving a multilib issue has to be paid >> for even when a single arch is all there is, that would be more painful >> since already struggling low memory single-arch boxes have to pay it for >> no benefit to them. > > There is a benefit. This bug doesn't only affect multilib. Another common case > where it triggers is failed %postun scriptlets. When you then > rpm -e --noscripts the old version, suddenly some files are gone. Well clearly such a bug should be fixed, no doubt about it. But if the implementation of the fix is very expensive in memory it can mean the fix broke the ability of some people to upgrade. So then you have to trade off the apples of the fix with the oranges of the breakage. (Assuming the additional memory use actually represents a bad enough problem for these low end machines, maybe it's just a MB or two in which case it doesn't make much odds.) > I've already given up on Anaconda on that laptop. I just used apt-rpm to > upgrade from FC5 to FC6 (which has the advantage of being able to swap out > whereas Anaconda tends to simply crash when it runs out of memory) and I'm > planning to the the same for FC6->F7. (It's still running FC6 right now.) The > FC2->FC5 Anaconda upgrade had to be restarted a couple of times due to Anaconda > just locking up from lack of memory. Luckily, it did that when computing the Yes F7 Anaconda did a smart thing after the partitioning was defined, told me it was going to do the swap partition right away because it could see I didn't have a lot of memory. Still I was told some years ago that Anaconda had magic meta-knowledge about packages that does not live in the specfiles and that this could lead to diverging behaviour on dist upgrades. And if I am encouraging someone to install Fedora themselves on a low end box, I don't want to have to explain that they have to go around Anaconda. > upgrades from the next ISO (I did a HD install with CD ISOs), not in the middle > of a transaction. So now I'm unwilling to let Anaconda anywhere near that > machine, it doesn't have enough RAM. Oh, and to compensate, apt-rpm memory use > is going to improve a lot with SQLite metadata support which is already in the > latest development version, so I'm not worried. Just saying that "dramatic" increases in memory usage in rpm can destroy the possibility for existing users on existing Fedora machines to upgrade in a reasonable period or possibly at all. Maybe further work in rpm will win all the memory back and more. -Andy From pmatilai at laiskiainen.org Tue Jun 26 12:15:13 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 26 Jun 2007 15:15:13 +0300 (EEST) Subject: New rpm version about to hit rawhide In-Reply-To: <4680FEAE.8090103@warmcat.com> References: <4680CA46.3010904@warmcat.com> <1182850536.2974.25.camel@enki.eridu> <4680E0ED.2070202@warmcat.com> <4680FEAE.8090103@warmcat.com> Message-ID: On Tue, 26 Jun 2007, Andy Green wrote: > Kevin Kofler wrote: >> Andy Green warmcat.com> writes: >>>>> Of the two issues, surely memory use is the worst? >> >> Surely correctness is more important! > > It is very important, but so is being able to upgrade Fedora at all on a > given box. Remember, this is just rawhide, and the main focus right now is to test 4.4.2.1 for correctness. If correctness makes it unusable on a large number of systems, something obviously needs fixing but the skipDir hack which just got nuked is not the answer. - Panu - From twaugh at redhat.com Tue Jun 26 12:27:33 2007 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 26 Jun 2007 13:27:33 +0100 Subject: Questions regarding my man/info summer project In-Reply-To: <4677DC96.3000301@redhat.com> References: <200706121533.50219.vpivaini@cs.helsinki.fi> <4677DC96.3000301@redhat.com> Message-ID: <1182860854.4855.30.camel@cyberelk.elk> On Tue, 2007-06-19 at 15:39 +0200, Florian Festi wrote: > So the question is how can the man pages transformed into wiki markup and > back without loss of information. If there is any possibility of using DocBook for the source format, don't forget ESR's excellent doclifter package. It does a really good job of translating man pages into DocBook -- and of course we already have the stylesheets to translate them back to groff format. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Tue Jun 26 13:18:28 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 26 Jun 2007 09:18:28 -0400 Subject: Parallel Booting In-Reply-To: <467BE85E.4070807@redhat.com> References: <467BE85E.4070807@redhat.com> Message-ID: <1182863908.3711.19.camel@localhost.localdomain> On Fri, 2007-06-22 at 17:18 +0200, Harald Hoyer wrote: > Hello, > > some of you may have read some wiki pages about the plans for the new init system [1]. As a first step in > this direction [2], I packaged prcsys from Mandriva, patched initscripts with a very small patch, and uploaded > the src.rpm to [3]. To enable parallel booting just build and install both packages and edit > /etc/sysconfig/init. Set PARALLEL_STARTUP=yes and there we go. Harald, I had a quick look over the prcsys code, here are some initial impressions - No test suite - Calls system() without checking for error - Doesn't check for $ in facility names - Doesn't differentiate between Required and Should, ie. Should is treated as a hard requirement too, which seems to violate the LSB intent - Checks for mandriva flags, X-Mandriva-Interactive, X-Mandriva-Compat-Mode - Uses the same fixed length of 256 for facility names and paths - There is a bunch of other hardcoded string lengths in there, like char file[255], this should probably be cleaned up - I regularly see "Cannot create temporary file" in --test output - Some init script output seems to go into the log file (might be related to the previous point) - It calls exit(1) a bunch - it probably shouldn't - Typo in message: "Unknow mode" - This looks sneaky, with buflen being a function parameter: char temp_dep[2][buflen]; All of this is fixable of course, this is after all just 1400 lines of code. I guess the question is if Mandriva is willing to develop this as a cross-distro project. If yes, where is the bug tracker to file bugs and patches about these problems ? If not, I don't see us winning too much by reusing 1400 lines of mediocre C code. Anyway, here are what I think are the top priorities if you want to turn this into an rc implementation suitable for Fedora and RHEL: - Add a test suite. I would expect at least tests for the parsing of the LSB headers, for the construction of the dependencies graphs, for correct serialization of the dependencies, handling of missing soft dependencies, and tests for compat mode - Implement Should - Do a thorough audit of the code and make it handle errors carefully and systematically Matthias From Eric.Tanguy at univ-nantes.fr Tue Jun 26 13:46:05 2007 From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY) Date: Tue, 26 Jun 2007 15:46:05 +0200 (CEST) Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> > On Mon, 25 Jun 2007 13:34:30 -0400, Eric Tanguy (tanguy) wrote: > >> Author: tanguy >> >> Update of /cvs/extras/rpms/libupnp/FC-6 > >> %changelog >> +* Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 >> +- Update to version 1.6.0 >> + > > Blacklisted for now together with ushare. > It breaks dependencies in several packages. > > Run "repoquery --whatrequires libupnp.so.2", use rpmdev-diff, announce > such ABI breakage on fedora-maintainers list, and if such a version > upgrade is really necessary, coordinate rebuilds appropriately. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I just announce this on fedora-maintainers list with copy to the owners concerned. All seem to be agree to rebuild their packages against this new lib but we have some questions about this : we tried to rebuild our packages (ushare and gmediaserver) for F-7 but the build system does not see the new libupnp which is in update-testing. What to do ? When we will be ready how to push all the packages at the same time ? And how to synchronize this with livna ? Thanks Eric From pvrabec at redhat.com Tue Jun 26 13:56:45 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Tue, 26 Jun 2007 15:56:45 +0200 Subject: Changing default syslog package In-Reply-To: <1182793268.31081.50.camel@erebor.boston.redhat.com> References: <845616.56525.qm@web51509.mail.re2.yahoo.com> <1182793268.31081.50.camel@erebor.boston.redhat.com> Message-ID: <46811B1D.6010604@redhat.com> http://fedoraproject.org/wiki/Releases/FeatureRsyslog What will I need to change in rsyslog.spec file if we decide to switch from sysklogd to rsyslog? Obsoletes statement is clear to me, is there anything else? Jeremy Katz wrote: > On Mon, 2007-06-25 at 09:21 -0700, Steve G wrote: >> As for the mechanics of making this happen, how should we go about switching out >> syslog daemons? IOW, should we put an obsoletes statement in the specfile now. >> And would we want to go ahead with the switchout in rawhide now? > > It would be good to see some of the use cases that switching enables > spelled out a bit better and a feature description[1] written up on the > wiki... > > Jeremy > > [1] http://fedoraproject.org/wiki/Releases/FeatureTemplate > From dev at nigelj.com Tue Jun 26 14:06:35 2007 From: dev at nigelj.com (Nigel Jones) Date: Wed, 27 Jun 2007 02:06:35 +1200 (NZST) Subject: Summary - Broken dependencies in Fedora 5 - 2007-06-25 In-Reply-To: <20070626095153.19355.56904@extras64.linux.duke.edu> References: <20070626095153.19355.56904@extras64.linux.duke.edu> Message-ID: <52072.202.154.148.243.1182866795.squirrel@webmail.nigelj.com> I wonder, can't we just disable this email now, FC5 is as good as EOL'd so there is no developer worth to it. N.J. > Summary of broken packages (by owner): > > matthias AT rpmforge.net > python-Coherence - 0.2.1-3.fc5.noarch (43 days) > python-Coherence - 0.2.1-3.fc5.noarch (43 days) > python-Coherence - 0.2.1-3.fc5.noarch (43 days) > > > ====================================================================== > Broken packages in fedora-extras-5-i386: > > python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web > python-Coherence-0.2.1-3.fc5.noarch requires python-nevow > python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core > python-Coherence-0.2.1-3.fc5.noarch requires python-configobj > > > ====================================================================== > Broken packages in fedora-extras-5-ppc: > > python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web > python-Coherence-0.2.1-3.fc5.noarch requires python-nevow > python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core > python-Coherence-0.2.1-3.fc5.noarch requires python-configobj > > > ====================================================================== > Broken packages in fedora-extras-5-x86_64: > > python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-web > python-Coherence-0.2.1-3.fc5.noarch requires python-nevow > python-Coherence-0.2.1-3.fc5.noarch requires python-twisted-core > python-Coherence-0.2.1-3.fc5.noarch requires python-configobj > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at theholbrooks.org Tue Jun 26 14:22:33 2007 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Tue, 26 Jun 2007 09:22:33 -0500 Subject: Inconsistent package tags In-Reply-To: <1182780748.30663.299.camel@localhost.localdomain> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <6280325c0706241934xb1ae9f1j824b32b68881ad34@mail.gmail.com> <1182780748.30663.299.camel@localhost.localdomain> Message-ID: <46812129.8010304@theholbrooks.org> Adam Jackson wrote: > On Mon, 2007-06-25 at 12:04 +0930, n0dalus wrote: > >> On 24 Jun 2007 20:31:22 -0500, Jason L Tibbitts III wrote: >> >>> n> 369 (216) packages with fc8 in the release tag (shouldn't we be >>> n> using f8?) >>> >>> No, it's fc8. f8 would sort less than fc7, causing badness. >>> >> I know, but its still undesirable to need to put 'fc' in every package >> of every release from this point on. Could packages be moved over to >> f8 by using release numbers, epochs or some other rpm hack? >> > > No. > > Couldn't we tag all packages built *from this point on* with f8? New builds have to bump the EVR anyway, so 2.f8 is still greater than 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if you assume no other changes to a package's EVR when being rebuilt, but AFAIK there's never been a package rebuilt in fedoraland where the disttag was the only thing that was bumped. Granted, that means there would be a mix of 'fc' and 'f' packages, but that's no more tacky than our current fc6+fc7 mix. -Brandon From jkeating at redhat.com Tue Jun 26 14:18:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Jun 2007 10:18:37 -0400 Subject: Summary - Broken dependencies in Fedora 5 - 2007-06-25 In-Reply-To: <52072.202.154.148.243.1182866795.squirrel@webmail.nigelj.com> References: <20070626095153.19355.56904@extras64.linux.duke.edu> <52072.202.154.148.243.1182866795.squirrel@webmail.nigelj.com> Message-ID: <200706261018.40684.jkeating@redhat.com> On Tuesday 26 June 2007 10:06:35 Nigel Jones wrote: > I wonder, can't we just disable this email now, FC5 is as good as EOL'd so > there is no developer worth to it. Actually now would be a great time to fix it before the doors close. I'm sending an announcement later today that outlines the timelines for shutting down builds. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vpivaini at cs.helsinki.fi Tue Jun 26 14:32:13 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 26 Jun 2007 17:32:13 +0300 Subject: Questions regarding my man/info summer project In-Reply-To: <1182860854.4855.30.camel@cyberelk.elk> References: <200706121533.50219.vpivaini@cs.helsinki.fi> <4677DC96.3000301@redhat.com> <1182860854.4855.30.camel@cyberelk.elk> Message-ID: <200706261732.13749.vpivaini@cs.helsinki.fi> Tim Waugh kirjoitti viestiss??n (l?hetysaika tiistai, 26. kes?kuu 2007 15:27:33): > If there is any possibility of using DocBook for the source format, > don't forget ESR's excellent doclifter package. It does a really good > job of translating man pages into DocBook -- and of course we already > have the stylesheets to translate them back to groff format. > > Tim. > */ That's what I'm using now and according to my tests it works really well. This is how I'm going to implement the publication phase. But for editing, I think DocBook might be a bit intimidating for users who are accustomed to wiki markup. That's why the idea currently is to use wiki markup as the source format, then translate that into DocBook with (probably) the improved DocBook code from last year's GSoC and then that DocBook into any other format needed. But then the "life cycle" of a man page would be something like groff -> wiki markup -> DocBook -> groff (or some other upstream format). And guaranteeing "no loss of information" between three transformations is going to be difficult. So should the idea of using wiki markup be discarded completely? Should we use DocBook as the source format and hope that people won't be too scared of editing it? If we chose DocBook, we would have to do only two transformations, groff -> DocBook -> groff, and guaranteeing consistency would be much more simple. -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi From jkeating at redhat.com Tue Jun 26 14:32:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Jun 2007 10:32:02 -0400 Subject: Inconsistent package tags In-Reply-To: <46812129.8010304@theholbrooks.org> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182780748.30663.299.camel@localhost.localdomain> <46812129.8010304@theholbrooks.org> Message-ID: <200706261032.02641.jkeating@redhat.com> On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote: > Couldn't we tag all packages built *from this point on* with f8? ?New > builds have to bump the EVR anyway, so 2.f8 is still greater than > 1.fc7. ?The whole "f8 is rpm-less than fc7" argument is only valid if > you assume no other changes to a package's EVR when being rebuilt, but > AFAIK there's never been a package rebuilt in fedoraland where the > disttag was the only thing that was bumped. ?Granted, that means there > would be a mix of 'fc' and 'f' packages, but that's no more tacky than > our current fc6+fc7 mix. Many cases the same version-release were built on multiple branches. frobitz-1.2 comes out and we want to release it across all of Fedora. Therefor we can have frobitz-1.2-1%{dist} on each branch and it will automagically calculate to frobitz-1.2-1.fc6 frobitz-1.2-1.fc7 frobitz-1.2-1.fc8 Now, if we used your suggestion and made it just f8, suddenly the frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. Broken upgrade path. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Tue Jun 26 14:48:57 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 26 Jun 2007 16:48:57 +0200 Subject: Inconsistent package tags In-Reply-To: <200706261032.02641.jkeating@redhat.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182780748.30663.299.camel@localhost.localdomain> <46812129.8010304@theholbrooks.org> <200706261032.02641.jkeating@redhat.com> Message-ID: <46812759.3000902@kanarip.com> Jesse Keating wrote: > On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote: >> Couldn't we tag all packages built *from this point on* with f8? New >> builds have to bump the EVR anyway, so 2.f8 is still greater than >> 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if >> you assume no other changes to a package's EVR when being rebuilt, but >> AFAIK there's never been a package rebuilt in fedoraland where the >> disttag was the only thing that was bumped. Granted, that means there >> would be a mix of 'fc' and 'f' packages, but that's no more tacky than >> our current fc6+fc7 mix. > > Many cases the same version-release were built on multiple branches. > frobitz-1.2 comes out and we want to release it across all of Fedora. > Therefor we can have frobitz-1.2-1%{dist} on each branch and it will > automagically calculate to > > frobitz-1.2-1.fc6 > frobitz-1.2-1.fc7 > frobitz-1.2-1.fc8 > > Now, if we used your suggestion and made it just f8, suddenly the > frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. > Broken upgrade path. > > I'm sure I'm saying something stupid, but isn't an upgrade path like that 1) "unlikely" to happen while packages get updated every now and then, and thus will have a complete upgrade path at some point, while 1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8 2) not used by anaconda upgrade -i'm not sure about this one ;-) 3) used only by the not-recommended yum upgrade -again, the "only" part I'm not sure about 4) completely unnecessary while both .fc7 and f8 programs have the same version number, source and are built with the same spec 5) easily fixed by bumping the release number for the 'later' package 6) happening regularly with like dev/udev, libata, stuff like that? I'm sure I'm missing something that prevents 'f8' being the dist-tag, I'm no release engineer after all. These are just things that come to my mind. Kind regards, Jeroen van Meeuwen -kanarip From tmz at pobox.com Tue Jun 26 15:04:11 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 26 Jun 2007 11:04:11 -0400 Subject: Inconsistent package tags In-Reply-To: <46812759.3000902@kanarip.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182780748.30663.299.camel@localhost.localdomain> <46812129.8010304@theholbrooks.org> <200706261032.02641.jkeating@redhat.com> <46812759.3000902@kanarip.com> Message-ID: <20070626150411.GB4214@psilocybe.teonanacatl.org> Jeroen van Meeuwen wrote: > I'm sure I'm missing something that prevents 'f8' being the > dist-tag, I'm no release engineer after all. These are just things > that come to my mind. Perhaps the strongest reasons not to change or worry the dist tag are: a) it has non-zero costs (in that it causes upgrade path issues, etc) b) it provides nothing but some very mild cosmetic value (to some) c) it has been discussed here previously and decided that the fc means fedora collection d) there are far more pressing issues to work on -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Anything that is too stupid to be spoken is sung. -- Voltaire (1694-1778) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kevin.kofler at chello.at Tue Jun 26 14:38:31 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 26 Jun 2007 14:38:31 +0000 (UTC) Subject: Inconsistent package tags References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: Jason L Tibbitts III math.uh.edu> writes: > No, it's fc8. f8 would sort less than fc7, causing badness. Uhm, does fc10 sort greater than fc9? Because if not, disttag chaos is only ~1.5 years away. Kevin Kofler From rc040203 at freenet.de Tue Jun 26 15:13:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 Jun 2007 17:13:20 +0200 Subject: Inconsistent package tags In-Reply-To: <46812759.3000902@kanarip.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182780748.30663.299.camel@localhost.localdomain> <46812129.8010304@theholbrooks.org> <200706261032.02641.jkeating@redhat.com> <46812759.3000902@kanarip.com> Message-ID: <1182870801.3859.75.camel@mccallum.corsepiu.local> On Tue, 2007-06-26 at 16:48 +0200, Jeroen van Meeuwen wrote: > Jesse Keating wrote: > > On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote: > >> Couldn't we tag all packages built *from this point on* with f8? New > >> builds have to bump the EVR anyway, so 2.f8 is still greater than > >> 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if > >> you assume no other changes to a package's EVR when being rebuilt, but > >> AFAIK there's never been a package rebuilt in fedoraland where the > >> disttag was the only thing that was bumped. Granted, that means there > >> would be a mix of 'fc' and 'f' packages, but that's no more tacky than > >> our current fc6+fc7 mix. > > > > Many cases the same version-release were built on multiple branches. > > frobitz-1.2 comes out and we want to release it across all of Fedora. > > Therefor we can have frobitz-1.2-1%{dist} on each branch and it will > > automagically calculate to > > > > frobitz-1.2-1.fc6 > > frobitz-1.2-1.fc7 > > frobitz-1.2-1.fc8 > > > > Now, if we used your suggestion and made it just f8, suddenly the > > frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. > > Broken upgrade path. > > > > > > I'm sure I'm saying something stupid, but isn't an upgrade path like that > 1) "unlikely" to happen while packages get updated every now and then, Nope, converse it very frequent. Wrt. to former FE packages, I'd say it's the "rule". > and thus will have a complete upgrade path at some point, while > 1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8 > 2) not used by anaconda upgrade -i'm not sure about this one ;-) > 3) used only by the not-recommended yum upgrade -again, the "only" part > I'm not sure about > 4) completely unnecessary while both .fc7 and f8 programs have the same > version number, source and are built with the same spec Consider the rpms can differ internally (may use different paths, different compilers, might have different deps etc.) > 5) easily fixed by bumping the release number for the 'later' package > 6) happening regularly with like dev/udev, libata, stuff like that? > > I'm sure I'm missing something that prevents 'f8' being the dist-tag, yes, f8 is not safe against rebuilding from the same spec: # fedora-rpmvercmp Epoch1 :0 Version1 :1 Release1 :1.fc7 Epoch2 :0 Version2 :1 Release2 :1.f8 0:1-1.fc7 is newer Ralf From jkeating at redhat.com Tue Jun 26 15:09:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Jun 2007 11:09:53 -0400 Subject: Inconsistent package tags In-Reply-To: <46812759.3000902@kanarip.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <200706261032.02641.jkeating@redhat.com> <46812759.3000902@kanarip.com> Message-ID: <200706261109.54137.jkeating@redhat.com> On Tuesday 26 June 2007 10:48:57 Jeroen van Meeuwen wrote: > I'm sure I'm saying something stupid, but isn't an upgrade path like that > ?1) "unlikely" to happen while packages get updated every now and then, > ????????and thus will have a complete upgrade path at some point, while > ????????1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8 The same version-release gets applied across the branches fairly often. This is not a made up scenario. > ?2) not used by anaconda upgrade -i'm not sure about this one ;-) We're talking about enabling anaconda upgrades to make use of external repos at upgrade time, in which case this very much /would/ be used by anaconda upgrade. > ?3) used only by the not-recommended yum upgrade -again, the "only" part > ????????I'm not sure about While not upgraded, it is something we try hard to make at least possible. Part of that is ensuring we don't break upgrade paths. > ?4) completely unnecessary while both .fc7 and f8 programs have the same > ????????version number, source and are built with the same spec Not so. Each branch could have different tool sets (gcc), different rpm version creating the package, etc.. Or in the case of python you could be seeing a completely different location on the file system (python2.4 vs python2.5) > ?5) easily fixed by bumping the release number for the 'later' package Why needlessly "fork" the spec file when the majority of the value of dist tags lies in being able to use the identical spec across the branches? > ?6) happening regularly with like dev/udev, libata, stuff like that? How is this happening regularly? We're very against breaking upgrade paths in RPM NVRs. rel-eng just passed a vote that requires rpm nvr paths to be upgradeable at any stage of Fedora development. > I'm sure I'm missing something that prevents 'f8' being the dist-tag, > I'm no release engineer after all. These are just things that come to my > mind. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Tue Jun 26 15:07:33 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 26 Jun 2007 11:07:33 -0400 Subject: Inconsistent package tags In-Reply-To: References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: <1182870453.30663.383.camel@localhost.localdomain> On Tue, 2007-06-26 at 14:38 +0000, Kevin Kofler wrote: > Jason L Tibbitts III math.uh.edu> writes: > > No, it's fc8. f8 would sort less than fc7, causing badness. > > Uhm, does fc10 sort greater than fc9? Because if not, disttag chaos is only > ~1.5 years away. benzedrine:~% fedora-rpmvercmp 0 0 0.fc9 0 0 0.fc10 0:0-0.fc10 is newer - ajax From jkeating at redhat.com Tue Jun 26 15:11:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Jun 2007 11:11:02 -0400 Subject: Inconsistent package tags In-Reply-To: References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: <200706261111.02869.jkeating@redhat.com> On Tuesday 26 June 2007 10:38:31 Kevin Kofler wrote: > Uhm, does fc10 sort greater than fc9? Because if not, disttag chaos is only > ~1.5 years away. yes. fc10 is newer than fc9. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Jun 26 15:40:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 Jun 2007 11:40:07 -0400 Subject: Changing default syslog package In-Reply-To: <46811B1D.6010604@redhat.com> References: <845616.56525.qm@web51509.mail.re2.yahoo.com> <1182793268.31081.50.camel@erebor.boston.redhat.com> <46811B1D.6010604@redhat.com> Message-ID: <20070626154007.GD28752@nostromo.devel.redhat.com> Peter Vrabec (pvrabec at redhat.com) said: > http://fedoraproject.org/wiki/Releases/FeatureRsyslog > > What will I need to change in rsyslog.spec file if we decide to switch > from sysklogd to rsyslog? Obsoletes statement is clear to me, is there > anything else? If the initscript has the same name, you'll need triggers. If it's not, it becomes much simpler. Bill From tibbs at math.uh.edu Tue Jun 26 15:41:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Jun 2007 10:41:06 -0500 Subject: Inconsistent package tags In-Reply-To: References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> Message-ID: >>>>> "KK" == Kevin Kofler writes: KK> Uhm, does fc10 sort greater than fc9? Yes, it does. Install rpmdevtools and run rpmdev-vercmp yourself if you want to see. - J< From krh at redhat.com Tue Jun 26 15:43:00 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Tue, 26 Jun 2007 11:43:00 -0400 Subject: X Crasher in todays rawhide Message-ID: <1182872580.1689.76.camel@hinata.boston.redhat.com> Hi, I pushed the new core X fonts packages yesterday and they appear in todays rawhide. They now use the catalogue font path mechanism, where the package adds a symlink to the font dir in /etc/X11/fontpath.d and the X server automatically picks up the new fonts. The symlinks name can contain attributes such as :unscaled to prevent scaling bitmap fonts or :pri=10 to control the search order. However, there's a bug in the libXfont package in rawhide, that crashes when comparing symlinks with no attributes. I'd suggest either skipping the rawhide upgrade today, avoiding xorg-x11-fonts-*, or do the upgrade and the pull the new libXfont builds manually: http://koji.fedoraproject.org/koji/buildinfo?buildID=9752 Kristian From a.badger at gmail.com Tue Jun 26 15:48:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 Jun 2007 08:48:57 -0700 Subject: Inconsistent package tags In-Reply-To: <46812759.3000902@kanarip.com> References: <6280325c0706241814p1a066edap80f8e4a3647592b8@mail.gmail.com> <1182780748.30663.299.camel@localhost.localdomain> <46812129.8010304@theholbrooks.org> <200706261032.02641.jkeating@redhat.com> <46812759.3000902@kanarip.com> Message-ID: <1182872937.4173.129.camel@localhost.localdomain> On Tue, 2007-06-26 at 16:48 +0200, Jeroen van Meeuwen wrote: > Jesse Keating wrote: > > On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote: > >> Couldn't we tag all packages built *from this point on* with f8? New > >> builds have to bump the EVR anyway, so 2.f8 is still greater than > >> 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if > >> you assume no other changes to a package's EVR when being rebuilt, but > >> AFAIK there's never been a package rebuilt in fedoraland where the > >> disttag was the only thing that was bumped. Granted, that means there > >> would be a mix of 'fc' and 'f' packages, but that's no more tacky than > >> our current fc6+fc7 mix. > > > > Many cases the same version-release were built on multiple branches. > > frobitz-1.2 comes out and we want to release it across all of Fedora. > > Therefor we can have frobitz-1.2-1%{dist} on each branch and it will > > automagically calculate to > > > > frobitz-1.2-1.fc6 > > frobitz-1.2-1.fc7 > > frobitz-1.2-1.fc8 > > > > Now, if we used your suggestion and made it just f8, suddenly the > > frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. > > Broken upgrade path. > > > > > > I'm sure I'm saying something stupid, but isn't an upgrade path like that > 1) "unlikely" to happen while packages get updated every now and then, > and thus will have a complete upgrade path at some point, while > 1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8 If I update the fc7 branch at the same time as the f8 branch I have this transition: yesterday | today foo-1.2-1.fc7 | foo-1.2-2.fc7 foo-1.2-1.fc8 | foo-1.2-2.f8 In order to fix that we'd need to change the disttag on all Fedora branches to f# at the same time. So we'd have 1.f7, 1.f6, etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From krh at redhat.com Tue Jun 26 15:58:14 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Tue, 26 Jun 2007 11:58:14 -0400 Subject: F7 && Firewire? In-Reply-To: <7dd7ab490706251745o699249fcv9ba83bb91f3b785b@mail.gmail.com> References: <7dd7ab490706251745o699249fcv9ba83bb91f3b785b@mail.gmail.com> Message-ID: <1182873494.1689.81.camel@hinata.boston.redhat.com> On Mon, 2007-06-25 at 17:45 -0700, Chris Weyl wrote: > Hey all-- > > I'm thinking about upgrading my main workstation to F7; however I I > haven't been following things very closely for the last couple weeks. > Are there still issues that would reasonably preclude my upgrading? > (Not being able to burn DVD's or use my iPod counts :)) The problems we're still working out are mostly related to multi media devices - web cams (iSight etc), DV camcorders, MPEG2 settop boxes and firewire audio equipment. Storage devices such as external DVD burners and iPods should work, but there has been filed regressions for some storage devices too. Trying the live CD is a good suggestion, and I'd like to hear how that works for you. thanks, Kristian From rhally at mindspring.com Tue Jun 26 16:30:38 2007 From: rhally at mindspring.com (Richard Hally) Date: Tue, 26 Jun 2007 12:30:38 -0400 Subject: X Crasher in todays rawhide In-Reply-To: <1182872580.1689.76.camel@hinata.boston.redhat.com> References: <1182872580.1689.76.camel@hinata.boston.redhat.com> Message-ID: <46813F2E.7040301@mindspring.com> Kristian H?gsberg wrote: > Hi, > > I pushed the new core X fonts packages yesterday and they appear in > todays rawhide. They now use the catalogue font path mechanism, where > the package adds a symlink to the font dir in /etc/X11/fontpath.d and > the X server automatically picks up the new fonts. The symlinks name > can contain attributes such as :unscaled to prevent scaling bitmap fonts > or :pri=10 to control the search order. > > However, there's a bug in the libXfont package in rawhide, that crashes > when comparing symlinks with no attributes. I'd suggest either skipping > the rawhide upgrade today, avoiding xorg-x11-fonts-*, or do the upgrade > and the pull the new libXfont builds manually: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=9752 > > Kristian > > Thanks for the link! The new lib fixes it. Richard From mlichvar at redhat.com Tue Jun 26 16:32:37 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 26 Jun 2007 18:32:37 +0200 Subject: utmp and friends Message-ID: <20070626163237.GE7258@localhost> Hi, I'd like to ask some questions about terminal emulators and utmp. In /var/run/utmp file is stored information about who is currently using the system. The file is writable only for group utmp, so there has to be a mechanism that will allow terminal emulators to add entries to the file. A library called libutempter (used by xterm and konsole) allows to modify the file only to processes that have group utempter. It used to work without setgid, but the utempter binary used by the library is hidden in a directory with permissions "drwx--x--- root utempter" since FC6. The problem is that setgid binaries have some environment variables like LD_LIBRARY_PATH and TMPDIR removed. I got bugs #229360 #243069 reported for xterm. Unfortunately I can't fix it unless utempter is accessible without setgid. Do we really need to protect the file from bad applications? Gnome-terminal, on the other hand, uses gnome-pty-helper binary that has utmp setgid. The binary is not hidden and every application can make entries in the utmp file. To have some consistency, either gnome-pty-helper needs to be also made accessible only to the utempter group and gnome-terminal is made setgid or utemper is made accessible to everyone and xterm drops setgid. Which path are we going to follow? Comments? -- Miroslav Lichvar From Christian.Iseli at licr.org Tue Jun 26 16:33:43 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 26 Jun 2007 18:33:43 +0200 Subject: Fedora Package Status of Jun 26, 2007 Message-ID: <20070626183343.5ee3fdae@ludwig-alpha.unil.ch> Hi folks, Hot of the press... It is still pretty painful updating the wiki pages. Took longer than 15 minutes between the time I pushed the "Save Changes" button until the browser started to display the updated page in the case of the PackageMaintainers/PackageStatus/OpenBugs page... I agree they are kinda big, but still: that seems very long. Enjoy, C ==== Fedora Package Status of Jun 26, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4637 packages - 7641 binary rpms in devel - 108 orphans - 56 packages not available in devel or release Axel dot Thimm at ATrpms dot net vtkdata Axel dot Thimm at ATrpms dot net vtk andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue andreas at bawue dot net perl-NetAddr-IP arnd at arndb dot de dtc arozansk at redhat dot com edac-utils bdpepple at ameritech dot net galago-filesystem bdpepple at ameritech dot net gaim-galago bnocera at redhat dot com gnome-launch-box cgoorah at yahoo dot com dot au netgen cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu gaim-gaym dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask foolish at guezz dot net perl-Net-Packet foolish at guezz dot net perl-SQLite-Simple gauret at free dot fr pdftohtml gnome at dux-linux dot org mrxvt green at redhat dot com ws-common-utils i at stingr dot net roundup icon at fedoraproject dot org mod_evasive jafo at tummy dot com python-mechanoid jafo at tummy dot com python-memcached jmp at safe dot ca clement johnp at redhat dot com GConf2-dbus jorton at redhat dot com libc-client lxtnow at gmail dot com gshutdown mastahnke at gmail dot com epel-release mastahnke at gmail dot com php-magpierss mhalcrow at us dot ibm dot com ecryptfs-utils mpg at redhat dot com olpc-hardware-manager mpg at redhat dot com sugar mpg at redhat dot com sugar-presence-service mpg at redhat dot com xulrunner mpg at redhat dot com sugar-artwork mpg at redhat dot com sugar-datastore mpg at redhat dot com hulahop mpg at redhat dot com xapian-core mpg at redhat dot com pyxapian mpg at redhat dot com xapian-bindings mwringe at redhat dot com jrexx paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman pvrabec at redhat dot com rsyslog rvokal at redhat dot com gaim-guifications splinux at fedoraproject dot org drapes sundaram at redhat dot com olpc-utils vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp wjhns174 at hardakers dot net perl-Crypt-OpenSSL-DSA xgl-maint at redhat dot com xorg-x11-drv-vermilion yufanyufan at gmail dot com audacious-plugins-docklet zhu at redhat dot com stardict-dic - 2 packages not available in devel but present in release caolanm at redhat dot com hunspell-he jorton at redhat dot com newt-perl - 9 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=222191,232702,232703,244523 eclipse bkonrath at redhat.com perl-Compress-Raw-Bzip2 steve at silug.org perl-IO-Compress-Bzip2 steve at silug.org ddrescue splinux25 at gmail.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221717,224458,231861,243006,245649 agg caolanm at redhat.com libsilc wtogami at redhat.com cyrus-imapd tjanouse at redhat.com apr jorton at redhat.com gnome-password-generator debarshi.ray at gmail.com - 3 packages present in the development repo which have no owners entry audacious-docklet s390utils ws-commons-util - 19 orphaned packages, yet available in devel docbook-dtds docbook-simple docbook-slides docbook-style-dsssl docbook-style-xsl docbook-utils driftnet gnome-bluetooth gob2 libbtctl libedit linuxdoc-tools luks-tools openjade opensp pam_usb udftools xmltex xmlto FE-ACCEPT packages stats: - 2731 accepted, closed package reviews - 43 accepted, closed package reviews not in repo - 7 accepted, closed package reviews not in owners - 91 accepted, open package reviews older than 4 weeks; - 122 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 235 open tickets - 81 tickets with no activity in eight weeks - 22 tickets with no activity in four weeks - 16 closed tickets FE-NEW packages stats: - 932 open tickets - 716 tickets with no activity in eight weeks - 47 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 47 open tickets - 4 tickets with no activity in eight weeks - 4 tickets with no activity in four weeks FE-LEGAL packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks OPEN-BUGS packages stats: - 8092 open tickets - 5173 tickets with no activity in eight weeks - 862 tickets with no activity in four weeks CVS stats: - 4642 packages with a devel directory - 4 packages with no owners entry isorelax-0-0.1.release20050331.1jpp.1.src.rpm mysql-administrator postgis tdma - 201 packages were dropped from Fedora Maintainers stats: - 391 maintainers - 2 inactive maintainers with open bugs - 4 inactive maintainers Dropped Fedora packages: - 4 packages were dropped since Fedora 7 Comps.xml files stats: - 2408 packages in comps-f8 file - 1007 packages missing from comps-f8 file - 32 packages in comps-f8 but not in repo - 2388 packages in comps-f7 file - 980 packages missing from comps-f7 file - 30 packages in comps-f7 but not in repo From jaroslav at aster.pl Tue Jun 26 16:44:03 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Tue, 26 Jun 2007 18:44:03 +0200 Subject: FC6 -> F7 (90%) success story Message-ID: <200706261844.11515.jaroslav@aster.pl> Hi, Two days ago I've upgraded FC6 to F7 using yum. The whole process went smoothly - far better than previous one (from FC5 to FC6). No conflicts, "dependency hell" or sth. like that. Just "yum update" and _almost_ everything works OK. Finally, thanks to new 'intel' xorg driver, I don't have to use 915resolution hack to get native resolution (1680x1050) - very nice! One thing that doesn't work is iwl3945 module. No wireless-led, no possibility to turn on the radio (with [Fn]+[F2] as well as with echo 0 > /sys/*/rf_kill). This issue is 240116 at bugzilla I think. So as for now I'm stuck with atrpm's ipw3945 driver (with regulatory daemon) which eventually is not as bad ;) Another small "issue" is that new kde has changed some of preferences (session management, toolbar applets settings, etc.) - but it took me 5 minutes to restore them. thanks all of You for new Fedora, it rocks! J. my hardware: * Dell Inspiron E1505 (aka 6400) laptop * CPU: Centrino Duo T2400 * chipset: ICH7 * GFX: 945GM * SND: Intel HDA (STAC92xx Analog) * wireless: 3945ABG -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue Jun 26 17:46:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 26 Jun 2007 19:46:35 +0200 Subject: X Crasher in todays rawhide In-Reply-To: <46813F2E.7040301@mindspring.com> References: <1182872580.1689.76.camel@hinata.boston.redhat.com> <46813F2E.7040301@mindspring.com> Message-ID: <20070626174635.GA3363@free.fr> Kristian H?gsberg wrote: > Hi, > I pushed the new core X fonts packages yesterday and they appear in > todays rawhide. They now use the catalogue font path mechanism, where > the package adds a symlink to the font dir in /etc/X11/fontpath.d and > the X server automatically picks up the new fonts. The symlinks name > can contain attributes such as :unscaled to prevent scaling bitmap fonts > or :pri=10 to control the search order. > However, there's a bug in the libXfont package in rawhide, that crashes > when comparing symlinks with no attributes. I'd suggest either skipping > the rawhide upgrade today, avoiding xorg-x11-fonts-*, or do the upgrade > and the pull the new libXfont builds manually: > http://koji.fedoraproject.org/koji/buildinfo?buildID=9752 > Kristian The fonts in fluxbox window titles have changed. And in gv, or xpdf (gv is an Xaw app, xpdf is lesstif based), I get: Warning: Cannot convert string "-*-Helvetica-Medium-R-Normal--*-140-*-*-P-*-ISO8859-1" to type FontStruct Warning: Cannot convert string "-*-times-medium-r-normal--14-*-*-*-*-*-iso8859-1" to type FontStruct I don't recall having those error messages before the libXfont update. Is it a bug or a normal side-effect? -- Pat From Christian.Iseli at licr.org Tue Jun 26 16:57:25 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 26 Jun 2007 18:57:25 +0200 Subject: A few questions on CVS content Message-ID: <20070626185725.4298ae70@ludwig-alpha.unil.ch> Hi folks, I have 3 questions/requests: 1. could a CVS admin please remove the isorelax-0-0.1.release20050331.1jpp.1.src.rpm directory ? It's certainly a mistake... 2. What is the status of the postgis package ? It has no entry in owners.list, and has not been built for Fedora 7. The last ChangeLog is from Devrim GUNDUZ on Wed Jan 3 2007... 3. What is the status of the tdma package ? It seems to be an EL-only package, and has no owners.list entry either... I didn't know we had EL-only packages... Bonus question: what should we do in the devel directory of OLPC-only packages ? Put some kind of non-fedora.package file, similarly to the dead.package file, to avoid branching when new fedora releases are created ? Cheers, C From Jochen at herr-schmitt.de Tue Jun 26 18:55:46 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 26 Jun 2007 20:55:46 +0200 Subject: A few questions on CVS content In-Reply-To: <20070626185725.4298ae70@ludwig-alpha.unil.ch> References: <20070626185725.4298ae70@ludwig-alpha.unil.ch> Message-ID: <46816132.7040906@herr-schmitt.de> Christian Iseli schrieb: > I have 3 questions/requests: > 1. could a CVS admin please remove the > isorelax-0-0.1.release20050331.1jpp.1.src.rpm directory ? > It's certainly a mistake... > Normaly I think you will ask for http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#head-529da50ad0b5cf0bedb9fdf47569c76657d79a7b Best Regards: Jochen Schmitt From mschwendt.tmp0701.nospam at arcor.de Tue Jun 26 19:01:49 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 26 Jun 2007 21:01:49 +0200 Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> Message-ID: <20070626210149.06792736.mschwendt.tmp0701.nospam@arcor.de> On Tue, 26 Jun 2007 15:46:05 +0200 (CEST), Eric TANGUY wrote: > I just announce this on fedora-maintainers list with copy to the owners > concerned. All seem to be agree to rebuild their packages against this new > lib but we have some questions about this : > > we tried to rebuild our packages (ushare and gmediaserver) for F-7 but the > build system does not see the new libupnp which is in update-testing. What > to do ? Mail rel-eng and request that they tag the package accordingly. With koji/bodhi and stable dist targets, only stable updates make it into the buildroots by default. This is different than with the plague buildsys. > When we will be ready how to push all the packages at the same time ? And > how to synchronize this with livna ? Building a complete set of updates is a prerequisite to being able to push all packages quickly. Livna doesn't build against updates-testing, however, so making sure that the packages do rebuild successfully as soon as the Fedora updates are released would be important. That is, no surprises such as API breakage and untested rebuilds. Since different people push the packages, the maximum that can be done is to keep the "broken deps" window short. From devrim at CommandPrompt.com Tue Jun 26 18:57:01 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Tue, 26 Jun 2007 21:57:01 +0300 Subject: A few questions on CVS content In-Reply-To: <20070626185725.4298ae70@ludwig-alpha.unil.ch> References: <20070626185725.4298ae70@ludwig-alpha.unil.ch> Message-ID: <1182884221.17076.19.camel@laptop.gunduz.org> Hello, On Tue, 2007-06-26 at 18:57 +0200, Christian Iseli wrote: > 2. What is the status of the postgis package ? I asked upstream about the problem that prevented builds on Fedora-7, and their latest Makefile fixes jdbc problem. I have a little problem left, but it can be solved quickly AFAICS. Will submit to F-7 build ASAP. > It has no entry in owners.list, and has not been built for Fedora 7. Per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220743 , it should have an entry, I think. Regards, -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ruben at rubenkerkhof.com Tue Jun 26 19:09:49 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Tue, 26 Jun 2007 21:09:49 +0200 Subject: A few questions on CVS content In-Reply-To: <1182884221.17076.19.camel@laptop.gunduz.org> References: <20070626185725.4298ae70@ludwig-alpha.unil.ch> <1182884221.17076.19.camel@laptop.gunduz.org> Message-ID: <03C67AF6-71CC-4E09-A144-A6D7EA2E9882@rubenkerkhof.com> On 26-jun-2007, at 20:57, Devrim G?ND?Z wrote: > Per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220743 , it > should have an entry, I think. Next time, set the fedora-cvs flag to ? That way you'll notify the cvs admins. I've just done that for now. Cheers, Ruben From kevin at scrye.com Tue Jun 26 19:24:36 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 26 Jun 2007 13:24:36 -0600 Subject: A few questions on CVS content In-Reply-To: <20070626185725.4298ae70@ludwig-alpha.unil.ch> References: <20070626185725.4298ae70@ludwig-alpha.unil.ch> Message-ID: <20070626132436.771f8944@ghistelwchlohm.scrye.com> On Tue, 26 Jun 2007 18:57:25 +0200 Christian.Iseli at licr.org (Christian Iseli) wrote: > Hi folks, > > I have 3 questions/requests: > 1. could a CVS admin please remove the > isorelax-0-0.1.release20050331.1jpp.1.src.rpm directory ? > It's certainly a mistake... Yeah. It's gone now. > > 2. What is the status of the postgis package ? It has no entry in > owners.list, and has not been built for Fedora 7. The last ChangeLog > is from Devrim GUNDUZ on Wed Jan 3 2007... Fixed now. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220743 > 3. What is the status of the tdma package ? It seems to be an EL-only > package, and has no owners.list entry either... I didn't know we had > EL-only packages... It has a devel branch as well. Will try and track down whats going on there... > Bonus question: what should we do in the devel directory of OLPC-only > packages ? Put some kind of non-fedora.package file, similarly to the > dead.package file, to avoid branching when new fedora releases are > created ? Good question. Not sure what the answer is, so I guess I lose the bonus round. ;) > > Cheers, > C kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jun 26 19:27:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 21:27:29 +0200 Subject: Fedora Core Merge Reviews In-Reply-To: <1182793399.2851.47.camel@kennedy> References: <1182793399.2851.47.camel@kennedy> Message-ID: <20070626192729.GN3345@puariko.nirvana> Hi, On Mon, Jun 25, 2007 at 01:43:19PM -0400, Brian Pepple wrote: > One of the items still left to do with regard to the recent merging of > Core & Extras is the reviews on packages that previously were in Core. > FESCo has been trying to determine what type of goal we should set for > completion by F8 test 2. Most of us felt that it wasn't a reasonable > goal to finish them all by that time, since there are more that 700 > still needing to be completed. 700 is the bugger part of the former Core, of course. > I'm looking for suggestions from the community on what you think is a > reasonable number or percentage of reviews to complete by F8t2. the question is what would such a number help? Would F8t2 have to slip if that number is missed by large? There's a very tight schedule, and returning to the usual cycle seems important to many (which is a valid concern), so we'd probably not make that a blocker (even though having Fedora be fully reviewed is a very noble goal!). What you probably want is some kind of motivation, and in my experience in Fedora it works best if you make some kind of weekly report showing progress and stagnation and frequest calls for reviews. -- 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 notting at redhat.com Tue Jun 26 19:33:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 Jun 2007 15:33:25 -0400 Subject: A few questions on CVS content In-Reply-To: <20070626132436.771f8944@ghistelwchlohm.scrye.com> References: <20070626185725.4298ae70@ludwig-alpha.unil.ch> <20070626132436.771f8944@ghistelwchlohm.scrye.com> Message-ID: <20070626193325.GA5087@nostromo.devel.redhat.com> Kevin Fenzi (kevin at scrye.com) said: > > Bonus question: what should we do in the devel directory of OLPC-only > > packages ? Put some kind of non-fedora.package file, similarly to the > > dead.package file, to avoid branching when new fedora releases are > > created ? > > Good question. Not sure what the answer is, so I guess I lose the bonus > round. ;) Well, it depends on how we do the branch. If we only branch packages that exist in the development/release tree at the time, we don't worry about this problem. (It's what was done for F7.) Bill From tcallawa at redhat.com Tue Jun 26 17:18:04 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 26 Jun 2007 12:18:04 -0500 Subject: Packaging guidelines: Directory ownership clarification Message-ID: <1182878284.5150.23.camel@localhost.localdomain> Guidelines change: http://fedoraproject.org/wiki/Packaging/Guidelines The following addendum was made to the FileAndDirectoryOwnership section: Another exception for directory ownership in packages is when there is no clear dependency hierarchy. An example: Foo-Animal-Emu puts files into /usr/share/Foo/Animal/Emu Foo-Animal-Llama puts files into /usr/share/Foo/Animal/Llama Neither package depends on the other one. Neither package depends on any other package which owns the /usr/share/Foo/Animal/ directory. In this case, each package must own the /usr/share/Foo/Animal/ directory. ~spot _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kwizart at gmail.com Tue Jun 26 20:06:59 2007 From: kwizart at gmail.com (KH KH) Date: Tue, 26 Jun 2007 22:06:59 +0200 Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <20070626210149.06792736.mschwendt.tmp0701.nospam@arcor.de> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> <20070626210149.06792736.mschwendt.tmp0701.nospam@arcor.de> Message-ID: 2007/6/26, Michael Schwendt : > On Tue, 26 Jun 2007 15:46:05 +0200 (CEST), Eric TANGUY wrote: > > > I just announce this on fedora-maintainers list with copy to the owners > > concerned. All seem to be agree to rebuild their packages against this new > > lib but we have some questions about this : > > > > we tried to rebuild our packages (ushare and gmediaserver) for F-7 but the > > build system does not see the new libupnp which is in update-testing. What > > to do ? > > Mail rel-eng and request that they tag the package accordingly. With > koji/bodhi and stable dist targets, only stable updates make it into the > buildroots by default. This is different than with the plague buildsys. > > > When we will be ready how to push all the packages at the same time ? And > > how to synchronize this with livna ? Ok for me...we can update... I don't know if it can build from a updates-testing package or wait for libupnp-devel to be stable...But it is now hardcoded... so when avaible, the package will takes around twenty eight minutes to be built ;) > Building a complete set of updates is a prerequisite to being able to push > all packages quickly. > > Livna doesn't build against updates-testing, however, so making sure that > the packages do rebuild successfully as soon as the Fedora updates are > released would be important. That is, no surprises such as API breakage > and untested rebuilds. > > Since different people push the packages, the maximum that can be done > is to keep the "broken deps" window short. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From karlikt at gmail.com Tue Jun 26 20:49:11 2007 From: karlikt at gmail.com (Karlik) Date: Tue, 26 Jun 2007 22:49:11 +0200 Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> <20070626210149.06792736.mschwendt.tmp0701.nospam@arcor.de> Message-ID: At now it is a little problem. The libupnp should not be in updates stable, because if the people have installed gmediaserver or sth package which require so.2 the yum crash and they can't do update (or do with --exclude=libupnp, but it is not very elegant). We can synchronize and after pushing to stable, we will build and push our packages, but it must be quickly :) 2007/6/26, KH KH : > 2007/6/26, Michael Schwendt : > > On Tue, 26 Jun 2007 15:46:05 +0200 (CEST), Eric TANGUY wrote: > > > > > I just announce this on fedora-maintainers list with copy to the owners > > > concerned. All seem to be agree to rebuild their packages against this new > > > lib but we have some questions about this : > > > > > > we tried to rebuild our packages (ushare and gmediaserver) for F-7 but the > > > build system does not see the new libupnp which is in update-testing. What > > > to do ? > > > > Mail rel-eng and request that they tag the package accordingly. With > > koji/bodhi and stable dist targets, only stable updates make it into the > > buildroots by default. This is different than with the plague buildsys. > > > > > When we will be ready how to push all the packages at the same time ? And > > > how to synchronize this with livna ? > > Ok for me...we can update... > I don't know if it can build from a updates-testing package or wait > for libupnp-devel to be stable...But it is now hardcoded... so when > avaible, the package will takes around twenty eight minutes to be > built ;) > > > > > Building a complete set of updates is a prerequisite to being able to push > > all packages quickly. > > > > Livna doesn't build against updates-testing, however, so making sure that > > the packages do rebuild successfully as soon as the Fedora updates are > > released would be important. That is, no surprises such as API breakage > > and untested rebuilds. > > > > Since different people push the packages, the maximum that can be done > > is to keep the "broken deps" window short. > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mmcgrath at redhat.com Tue Jun 26 21:45:29 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 26 Jun 2007 16:45:29 -0500 Subject: Outage Notification (Bugzilla) - 2007-06-30 01:00 Message-ID: <468188F9.6010401@redhat.com> There will be an outage starting at 2007-06-30 01:00 [UTC], which will last approximately 2 hours. To convert UTC to your local time, use: http://www.timeanddate.com/worldclock/converter.html Affected Services: Bugzilla Unaffected Services: Websites CVS / Source Control Buildsystem Database DNS Mail Torrent Reason for Outage: Red Hat will be taking down bugzilla.rehat.com for maintenance on the bugs database. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kwade at redhat.com Tue Jun 26 21:52:44 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 26 Jun 2007 14:52:44 -0700 Subject: Fedora Package Status of Jun 26, 2007 In-Reply-To: <20070626183343.5ee3fdae@ludwig-alpha.unil.ch> References: <20070626183343.5ee3fdae@ludwig-alpha.unil.ch> Message-ID: <1182894764.10205.647.camel@erato.phig.org> On Tue, 2007-06-26 at 18:33 +0200, Christian Iseli wrote: > Hi folks, > > Hot of the press... It is still pretty painful updating the wiki > pages. Took longer than 15 minutes between the time I pushed the "Save > Changes" button until the browser started to display the updated page > in the case of the PackageMaintainers/PackageStatus/OpenBugs page... > > I agree they are kinda big, but still: that seems very long. Best place to take this is to fedora-infrastructure-list; might not get noticed here for a bit longer. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Tue Jun 26 22:20:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 26 Jun 2007 18:20:13 -0400 Subject: Package Updating Doc Available Message-ID: <1182896413.10532.30.camel@aglarond.local> Documentation describing the new package update process flow is now available at http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. Feel free to update with any clarifications that you feel are needed and can figure out or ask away. Jeremy _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From notting at redhat.com Tue Jun 26 22:26:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 Jun 2007 18:26:39 -0400 Subject: utmp and friends In-Reply-To: <20070626163237.GE7258@localhost> References: <20070626163237.GE7258@localhost> Message-ID: <20070626222639.GB8397@nostromo.devel.redhat.com> Miroslav Lichvar (mlichvar at redhat.com) said: > The problem is that setgid binaries have some environment variables > like LD_LIBRARY_PATH and TMPDIR removed. I got bugs #229360 #243069 > reported for xterm. Unfortunately I can't fix it unless utempter is > accessible without setgid. Do we really need to protect the file from > bad applications? > > Gnome-terminal, on the other hand, uses gnome-pty-helper binary that > has utmp setgid. The binary is not hidden and every application can > make entries in the utmp file. > > To have some consistency, either gnome-pty-helper needs to be also > made accessible only to the utempter group and gnome-terminal is made > setgid or utemper is made accessible to everyone and xterm drops setgid. The entire idea of utempter is so that the terminal *doesn't* need to be setgid - if it's setgid, what's the point of a helper? Bill From mike at miketc.com Tue Jun 26 22:55:03 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 26 Jun 2007 17:55:03 -0500 Subject: Package Updating Doc Available In-Reply-To: <1182896413.10532.30.camel@aglarond.local> References: <1182896413.10532.30.camel@aglarond.local> Message-ID: <1182898504.5184.0.camel@scrappy.miketc.com> On Tue, 2007-06-26 at 18:20 -0400, Jeremy Katz wrote: > Documentation describing the new package update process flow is now > available at > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. > Feel free to update with any clarifications that you feel are needed and > can figure out or ask away. Someone might want to edit the page below where it still has Fedora Core and Fedora Extras... http://fedoraproject.org/wiki/Packaging/NamingGuidelines I think there are about 4-5 places where it has it. -- Mike Chambers Madisonville, KY "Best little town on Earth!" From mike at miketc.com Tue Jun 26 23:00:43 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 26 Jun 2007 18:00:43 -0500 Subject: Package Updating Doc Available In-Reply-To: <1182898504.5184.0.camel@scrappy.miketc.com> References: <1182896413.10532.30.camel@aglarond.local> <1182898504.5184.0.camel@scrappy.miketc.com> Message-ID: <1182898843.5184.5.camel@scrappy.miketc.com> On Tue, 2007-06-26 at 17:55 -0500, Mike Chambers wrote: > Someone might want to edit the page below where it still has Fedora Core > and Fedora Extras... > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > I think there are about 4-5 places where it has it. I wasn't going to say anything and figured you all were doing this on purpose or at least already discussed it, but the below URL still has extras in the email list names or in the cvs paths. Maybe it should be changed to reflect the merge, or at some later date changed when there is a major changeover or something when the change can happen? http://fedoraproject.org/wiki/PackageMaintainers/Join Sorry to nag, but not really, just trying to help point out things from a non-maintainer, or at least new set of eyes. (I'll go off to my corner and sit quietly now hehe) -- Mike Chambers Madisonville, KY "Best little town on Earth!" From Christian.Iseli at licr.org Tue Jun 26 23:13:17 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 27 Jun 2007 01:13:17 +0200 Subject: A few questions on CVS content In-Reply-To: <20070626193325.GA5087@nostromo.devel.redhat.com> References: <20070626185725.4298ae70@ludwig-alpha.unil.ch> <20070626132436.771f8944@ghistelwchlohm.scrye.com> <20070626193325.GA5087@nostromo.devel.redhat.com> Message-ID: <20070627011317.12f23ca9@ludwig-alpha.unil.ch> On Tue, 26 Jun 2007 15:33:25 -0400, Bill Nottingham wrote: > Kevin Fenzi (kevin at scrye.com) said: > > > Bonus question: what should we do in the devel directory of OLPC-only > > > packages ? Put some kind of non-fedora.package file, similarly to the > > > dead.package file, to avoid branching when new fedora releases are > > > created ? > > > > Good question. Not sure what the answer is, so I guess I lose the bonus > > round. ;) > > Well, it depends on how we do the branch. If we only branch packages > that exist in the development/release tree at the time, we don't worry > about this problem. (It's what was done for F7.) That might work, but still leaves the (admittedly a bit nitpicky) problem for me of: how do I know a package is OLPC only in my checking script ? It's a sort of chicken-egg problem: if I notice that the package has not been built for devel, how do I know it is intentional ? C From a.badger at gmail.com Wed Jun 27 00:04:54 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 Jun 2007 17:04:54 -0700 Subject: Package Updating Doc Available In-Reply-To: <1182898843.5184.5.camel@scrappy.miketc.com> References: <1182896413.10532.30.camel@aglarond.local> <1182898504.5184.0.camel@scrappy.miketc.com> <1182898843.5184.5.camel@scrappy.miketc.com> Message-ID: <1182902694.4173.139.camel@localhost.localdomain> On Tue, 2007-06-26 at 18:00 -0500, Mike Chambers wrote: > On Tue, 2007-06-26 at 17:55 -0500, Mike Chambers wrote: > > > Someone might want to edit the page below where it still has Fedora Core > > and Fedora Extras... > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > > > I think there are about 4-5 places where it has it. > Fixed. If you see something else here, let me know. > I wasn't going to say anything and figured you all were doing this on > purpose or at least already discussed it, but the below URL still has > extras in the email list names or in the cvs paths. Maybe it should be > changed to reflect the merge, or at some later date changed when there > is a major changeover or something when the change can happen? > > http://fedoraproject.org/wiki/PackageMaintainers/Join I fixed the cvs path on this page. I don't know if we've migrated any of the other things (fedora-extras-commits mailing list, FAS group) yet so someone else should edit the rest of the document if they know that somethings have changed. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Jun 27 01:36:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Jun 2007 21:36:44 -0400 Subject: A few questions on CVS content In-Reply-To: <20070627011317.12f23ca9@ludwig-alpha.unil.ch> References: <20070626185725.4298ae70@ludwig-alpha.unil.ch> <20070626193325.GA5087@nostromo.devel.redhat.com> <20070627011317.12f23ca9@ludwig-alpha.unil.ch> Message-ID: <200706262136.47351.jkeating@redhat.com> On Tuesday 26 June 2007 19:13:17 Christian Iseli wrote: > That might work, but still leaves the (admittedly a bit nitpicky) > problem for me of: how do I know a package is OLPC only in my checking > script ? ?It's a sort of chicken-egg problem: if I notice that the > package has not been built for devel, how do I know it is intentional ? Existence of the package only in the olpc owners file instead of both files or only owners.list? Checking the output of 'koji list-pkgs --package ' ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tgl at redhat.com Wed Jun 27 03:47:08 2007 From: tgl at redhat.com (Tom Lane) Date: Tue, 26 Jun 2007 23:47:08 -0400 Subject: Package Updating Doc Available In-Reply-To: <1182896413.10532.30.camel@aglarond.local> References: <1182896413.10532.30.camel@aglarond.local> Message-ID: <5300.1182916028@sss.pgh.pa.us> Jeremy Katz writes: > Documentation describing the new package update process flow is now > available at > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. > Feel free to update with any clarifications that you feel are needed and > can figure out or ask away. Surely the steps involving "make" can figure out which platform you are on, ie, the directions ought to be "Use the command make", full stop. If not, it's a pretty severe regression from the Red Hat infrastructure I'm used to. (Platform-specific bugs are another issue of course, but these docs don't seem to intend to dip their toes in that deep water.) regards, tom lane From rjones at redhat.com Wed Jun 27 04:05:08 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 27 Jun 2007 05:05:08 +0100 Subject: Mock - how do I install my own RPMs on top of what's in Fedora? Message-ID: <4681E1F4.8010402@redhat.com> Basic question about mock: I want to test build ocaml-findlib[1] using mock. However this build-requires ocaml >= 3.10.0 which has been packaged[2] but isn't in Fedora. So (I'm guessing) I want to do the mock chroot thing, get the Fedora packages required, then install one or more of my own RPMs, then do the test build. How can I do this? Rich. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240557 [2] http://math.ifi.unizh.ch/fedora/tmp/ -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From tibbs at math.uh.edu Wed Jun 27 04:18:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Jun 2007 23:18:06 -0500 Subject: Mock - how do I install my own RPMs on top of what's in Fedora? In-Reply-To: <4681E1F4.8010402@redhat.com> References: <4681E1F4.8010402@redhat.com> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> So (I'm guessing) I want to do the mock chroot thing, get the RWMJ> Fedora packages required, then install one or more of my own RWMJ> RPMs, then do the test build. I add extra packages all the time; I just add them to a local repository and reference it in the mock configuration file. - J< From tmz at pobox.com Wed Jun 27 04:21:32 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 27 Jun 2007 00:21:32 -0400 Subject: Mock - how do I install my own RPMs on top of what's in Fedora? In-Reply-To: <4681E1F4.8010402@redhat.com> References: <4681E1F4.8010402@redhat.com> Message-ID: <20070627042132.GA2598@psilocybe.teonanacatl.org> Richard W.M. Jones wrote: > Basic question about mock: > > I want to test build ocaml-findlib[1] using mock. However this > build-requires ocaml>= 3.10.0 which has been packaged[2] but isn't > in Fedora. So (I'm guessing) I want to do the mock chroot thing, > get the Fedora packages required, then install one or more of my own > RPMs, then do the test build. > > How can I do this? One way to do this is to edit the mock config file for the target dist. In the yum.conf section, create a new repo (or override the local one). For example, I've added this in some of my configs: [scratch] name=scratch baseurl=file:///path/to/repo Then, put your ocaml packages in /path/to/repo and run createrepo on that dir to create the metadata that yum needs. Now when you call mock it will look in your scratch repo as well as the standard ones and it should use your updated ocaml packages. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I got stopped by a cop the other day. He said, "Why'd you run that stop sign?" I said, "Because I don't believe everything I read." -- Stephen Wright -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From buildsys at redhat.com Wed Jun 27 04:52:45 2007 From: buildsys at redhat.com (Build System) Date: Wed, 27 Jun 2007 00:52:45 -0400 Subject: rawhide report: 20070627 changes Message-ID: <200706270452.l5R4qj6p004167@porkchop.devel.redhat.com> From rc040203 at freenet.de Wed Jun 27 05:15:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jun 2007 07:15:38 +0200 Subject: rpms/stardict/F-7 stardict.spec,1.29,1.30 In-Reply-To: <200706270234.l5R2Y1vR026788@cvs-int.fedora.redhat.com> References: <200706270234.l5R2Y1vR026788@cvs-int.fedora.redhat.com> Message-ID: <1182921339.3859.109.camel@mccallum.corsepiu.local> On Tue, 2007-06-26 at 22:34 -0400, Hu Zheng wrote: > Author: zhu > > Update of /cvs/pkgs/rpms/stardict/F-7 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26607/F-7 > Index: stardict.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/stardict/F-7/stardict.spec,v > retrieving revision 1.29 > retrieving revision 1.30 > diff -u -r1.29 -r1.30 > --- stardict.spec 22 Jun 2007 05:17:06 -0000 1.29 > +++ stardict.spec 27 Jun 2007 02:33:26 -0000 1.30 > @@ -45,11 +45,11 @@ > %doc %{_datadir}/man/man1/stardict.1* 1. This %doc is superfluous. rpm automatically marks mans as %doc 2. You should use %{_mandir} instead of %{_datadir}/man Ralf From eric.tanguy at univ-nantes.fr Wed Jun 27 05:50:25 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Wed, 27 Jun 2007 07:50:25 +0200 Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <20070626210149.06792736.mschwendt.tmp0701.nospam@arcor.de> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> <20070626210149.06792736.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1182923425.2922.4.camel@bureau.maison> Le mardi 26 juin 2007 ? 21:01 +0200, Michael Schwendt a ?crit : > On Tue, 26 Jun 2007 15:46:05 +0200 (CEST), Eric TANGUY wrote: > > > I just announce this on fedora-maintainers list with copy to the owners > > concerned. All seem to be agree to rebuild their packages against this new > > lib but we have some questions about this : > > > > we tried to rebuild our packages (ushare and gmediaserver) for F-7 but the > > build system does not see the new libupnp which is in update-testing. What > > to do ? > > Mail rel-eng and request that they tag the package accordingly. With > koji/bodhi and stable dist targets, only stable updates make it into the > buildroots by default. This is different than with the plague buildsys. > > > When we will be ready how to push all the packages at the same time ? And > > how to synchronize this with livna ? > > Building a complete set of updates is a prerequisite to being able to push > all packages quickly. > > Livna doesn't build against updates-testing, however, so making sure that > the packages do rebuild successfully as soon as the Fedora updates are > released would be important. That is, no surprises such as API breakage > and untested rebuilds. > > Since different people push the packages, the maximum that can be done > is to keep the "broken deps" window short. > So libupnp, ushare and gmediaserver are in -testing. vlc from livna is ready to be rebuilt as soon as libupnp will be in stable. The question is : do we wait 5 or 7 days before pushing libupnp, ushare and gmediaserver in stable or do we push their asap ? Eric From hawat.thufir at gmail.com Wed Jun 27 06:14:38 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 27 Jun 2007 06:14:38 +0000 (UTC) Subject: portage vs yum Message-ID: the pro's for three distros: gentoo: portage is bigger than yum and just as easy to use live cd sabayon: binary builds of portage (for a fee, IIRC) anaconda fedora: live cd anaconda The drawback to fedora is, to my mind, rpm and yum. portage is superior. it's also capable, as sabayon has demonstrated, of distributing binaries. Please switch to something like portage, which builds from source. This would eliminate, or at least, significantly reduce, the need for me to do things like build lshw from source because, and correct me if I'm wrong, it'd be easier to leave "in" and would require less maintenance. Assuming all other things to be equal, as in only GPL 2 stuff is maintained, isn't portage easier to maintain? Wouldn't that mean more stuff for me (I mean users)? Thank you, Thufir From mlichvar at redhat.com Wed Jun 27 08:22:00 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 27 Jun 2007 10:22:00 +0200 Subject: utmp and friends In-Reply-To: <20070626222639.GB8397@nostromo.devel.redhat.com> References: <20070626163237.GE7258@localhost> <20070626222639.GB8397@nostromo.devel.redhat.com> Message-ID: <20070627082200.GB21279@localhost> On Tue, Jun 26, 2007 at 06:26:39PM -0400, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > The problem is that setgid binaries have some environment variables > > like LD_LIBRARY_PATH and TMPDIR removed. I got bugs #229360 #243069 > > reported for xterm. Unfortunately I can't fix it unless utempter is > > accessible without setgid. Do we really need to protect the file from > > bad applications? > > > > Gnome-terminal, on the other hand, uses gnome-pty-helper binary that > > has utmp setgid. The binary is not hidden and every application can > > make entries in the utmp file. > > > > To have some consistency, either gnome-pty-helper needs to be also > > made accessible only to the utempter group and gnome-terminal is made > > setgid or utemper is made accessible to everyone and xterm drops setgid. > > The entire idea of utempter is so that the terminal *doesn't* need to be > setgid - if it's setgid, what's the point of a helper? Well, the terminal doesn't need to be setgid utmp, but only utempter. Setgid utempter allows only adding/removing entries in utmp while setgid utmp allows unrestricted access. The question is, should users be allowed to add entries in utmp without starting a terminal emulator? -- Miroslav Lichvar From rc040203 at freenet.de Wed Jun 27 08:27:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jun 2007 10:27:46 +0200 Subject: rpms/pydict/F-7 pydict-trans.patch,1.2,1.3 pydict.spec,1.14,1.15 In-Reply-To: <200706270721.l5R7L0RU028356@cvs-int.fedora.redhat.com> References: <200706270721.l5R7L0RU028356@cvs-int.fedora.redhat.com> Message-ID: <1182932867.3859.123.camel@mccallum.corsepiu.local> On Wed, 2007-06-27 at 03:21 -0400, Hu Zheng wrote: > Author: zhu > > Index: pydict-trans.patch > =================================================================== > RCS file: /cvs/pkgs/rpms/pydict/F-7/pydict-trans.patch,v > Index: pydict.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/pydict/F-7/pydict.spec,v > retrieving revision 1.14 > retrieving revision 1.15 > diff -u -r1.14 -r1.15 > --- pydict.spec 27 Jun 2007 07:01:01 -0000 1.14 > +++ pydict.spec 27 Jun 2007 07:20:24 -0000 1.15 > @@ -1,7 +1,7 @@ > Summary: English/Chinese Dictionary written with python/gtk > Name: pydict > Version: 0.3.0 > -Release: 10%{?dist} > +Release: 11%{?dist} > Source0: pydict-%{version}.tar.gz > Patch: pydict-trans.patch > Patch1: pydict-0.3.0-python.patch > @@ -57,8 +57,8 @@ > /usr/share/icons/dict.xpm Once more the same bug as with your other rpms: s,/usr/share,%{_datadir}, Ralf From rc040203 at freenet.de Wed Jun 27 08:31:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jun 2007 10:31:38 +0200 Subject: rpms/geda-examples/FC-6 .cvsignore, 1.5, 1.6 geda-examples.spec, 1.5, 1.6 sources, 1.5, 1.6 In-Reply-To: <200706270827.l5R8RCPS013543@cvs-int.fedora.redhat.com> References: <200706270827.l5R8RCPS013543@cvs-int.fedora.redhat.com> Message-ID: <1182933099.3859.127.camel@mccallum.corsepiu.local> On Wed, 2007-06-27 at 04:27 -0400, Chitlesh GOORAH wrote: > Author: chitlesh > > Update of /cvs/extras/rpms/geda-examples/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv13475/FC-6 > > Modified Files: > .cvsignore geda-examples.spec sources > Log Message: > > > > Index: .cvsignore > =================================================================== > RCS file: /cvs/extras/rpms/geda-examples/FC-6/.cvsignore,v > retrieving revision 1.5 > retrieving revision 1.6 > diff -u -r1.5 -r1.6 > --- .cvsignore 29 Mar 2007 07:31:52 -0000 1.5 > +++ .cvsignore 27 Jun 2007 08:26:37 -0000 1.6 > @@ -1 +1 @@ > -geda-examples-20070216.tar.gz > +geda-examples-20070626.tar.gz > > > Index: geda-examples.spec > =================================================================== > RCS file: /cvs/extras/rpms/geda-examples/FC-6/geda-examples.spec,v > retrieving revision 1.5 > retrieving revision 1.6 > diff -u -r1.5 -r1.6 > --- geda-examples.spec 2 Apr 2007 11:24:51 -0000 1.5 > +++ geda-examples.spec 27 Jun 2007 08:26:37 -0000 1.6 > @@ -1,18 +1,27 @@ > -%define gedaexampledir %{_datadir}/gEDA/examples > +%define gedaexampledir %{_docdir}/gEDA/examples > + > +# Set the fedora version for the BR: perl-libs > +# FC_ver may take the value 5, 6, 7 or 8 > +%define FC_ver 6 > +%if "%{?FC_ver}" > "6" > +BuildRequires: perl-libs > +%endif You should use %fedora instead of your %FC_ver macro. Ralf From chitlesh at fedoraproject.org Wed Jun 27 08:34:03 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 27 Jun 2007 10:34:03 +0200 Subject: rpms/geda-examples/FC-6 .cvsignore, 1.5, 1.6 geda-examples.spec, 1.5, 1.6 sources, 1.5, 1.6 In-Reply-To: <1182933099.3859.127.camel@mccallum.corsepiu.local> References: <200706270827.l5R8RCPS013543@cvs-int.fedora.redhat.com> <1182933099.3859.127.camel@mccallum.corsepiu.local> Message-ID: <13dbfe4f0706270134g612e8f1dj1e555700335277a8@mail.gmail.com> On 6/27/07, Ralf Corsepius wrote: > > You should use %fedora instead of your %FC_ver macro. Thanks, I was thinking there should be a cleaner method. Here it is :) However, I'll update it in the next release. Chitlesh -- http://clunixchit.blogspot.com From harald at redhat.com Wed Jun 27 10:16:45 2007 From: harald at redhat.com (Harald Hoyer) Date: Wed, 27 Jun 2007 12:16:45 +0200 Subject: Parallel Booting In-Reply-To: <1182863908.3711.19.camel@localhost.localdomain> References: <467BE85E.4070807@redhat.com> <1182863908.3711.19.camel@localhost.localdomain> Message-ID: <4682390D.1030600@redhat.com> Matthias Clasen wrote: > ... > All of this is fixable of course, this is after all just 1400 lines of > code. I guess the question is if Mandriva is willing to develop this as > a cross-distro project. If yes, where is the bug tracker to file bugs > and patches about these problems ? If not, I don't see us winning too > much by reusing 1400 lines of mediocre C code. https://ml.mandriva.net/wws/info/prcsys -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From mfleming at enlartenment.com Wed Jun 27 10:30:22 2007 From: mfleming at enlartenment.com (Michael Fleming) Date: Wed, 27 Jun 2007 20:30:22 +1000 Subject: portage vs yum In-Reply-To: References: Message-ID: <1182940222.4126.11.camel@defender> On Wed, 2007-06-27 at 06:14 +0000, Thufir wrote: > the pro's for three distros: > > gentoo: > portage is bigger than yum and just as easy to use > live cd > > sabayon: > binary builds of portage (for a fee, IIRC) > anaconda > > fedora: > live cd > anaconda > > The drawback to fedora is, to my mind, rpm and yum. portage is > superior. In what way is portage (which is essentially the "ports" methods from *BSD et. al) superior to yum / RPM? (Or, how is the latter inferior in your view, aside from "it doesn't have all the packages I want/need") > it's also capable, as sabayon has demonstrated, of > distributing binaries. > > Please switch to something like portage, which builds from source. RPM has to get it's sources from somewhere. :-) Ports / portage pulls the sources from the upstream site at build time, if I recall rightly. What happens if/when - and this has happened in the past IIRC - the upstream site tarballs are compromised? What's it's dependency handling like? > This > would eliminate, or at least, significantly reduce, the need for me to do > things like build lshw from source because, and correct me if I'm wrong, > it'd be easier to leave "in" and would require less maintenance. With portage, you'd still need to either build from ports or pull in the binary packages so I'm not seeing a distinct advantage in your proposal. > Assuming all other things to be equal, as in only GPL 2 stuff is > maintained, isn't portage easier to maintain? Wouldn't that mean more > stuff for me (I mean users)? Someone still has to maintain the port, and that would consume the same amount of time and effort as maintaining an RPM as far as I can see it. No win there.. I think what you really want is an RPM for lshw - remembering that this is a community effort, you're quite welcome to have a go yourself (and there are plenty of people on this list who are more than capable in assisting in such an endeavour) or perhaps find an experienced packager that's also interested in maintaining such a package. Changing package managers strikes me as an exercise in wheel reinvention :-) > Thank you, > > Thufir > Michael. -- Michael Fleming in Brisbane, Australia "Be master of your mind, not mastered by mind" From opensource at till.name Wed Jun 27 10:58:21 2007 From: opensource at till.name (Till Maas) Date: Wed, 27 Jun 2007 12:58:21 +0200 Subject: Package Updating Doc Available In-Reply-To: <1182896413.10532.30.camel@aglarond.local> References: <1182896413.10532.30.camel@aglarond.local> Message-ID: <200706271258.24005.opensource@till.name> On Mi Juni 27 2007, Jeremy Katz wrote: > Documentation describing the new package update process flow is now > available at > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. > Feel free to update with any clarifications that you feel are needed and > can figure out or ask away. Can you please explain, how you use diff and patch to sync between devel and F-7? I normally only copy the spec from one place to another. Also, you write, that a package should be build locally for devel and F-7 separately. Afaik will the results only differ, when one uses a devel and a F-7 machine for this. And the "make tag" and "make build" step could be joined into one "make tag build" step imho. Or is there any advantage of doing this seperately? Regards, Till From linux_4ever at yahoo.com Wed Jun 27 11:07:00 2007 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 27 Jun 2007 04:07:00 -0700 (PDT) Subject: utmp and friends In-Reply-To: <20070626163237.GE7258@localhost> Message-ID: <20070627110700.19501.qmail@web51508.mail.re2.yahoo.com> >The problem is that setgid binaries have some environment variables >like LD_LIBRARY_PATH and TMPDIR removed. This is correct. Otherwise you could have a security risk. >Unfortunately I can't fix it unless utempter is accessible without setgid. Do >we really need to protect the file from bad applications? Yes we must restrict access of that file. -Steve ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ From mschwendt.tmp0701.nospam at arcor.de Wed Jun 27 11:31:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 27 Jun 2007 13:31:15 +0200 Subject: portage vs yum In-Reply-To: <1182940222.4126.11.camel@defender> References: <1182940222.4126.11.camel@defender> Message-ID: <20070627133115.ff619f06.mschwendt.tmp0701.nospam@arcor.de> On Wed, 27 Jun 2007 20:30:22 +1000, Michael Fleming wrote: > I think what you really want is an RPM for lshw - remembering that this > is a community effort, you're quite welcome to have a go yourself (and > there are plenty of people on this list who are more than capable in > assisting in such an endeavour) or perhaps find an experienced packager > that's also interested in maintaining such a package. Review Request: lshw - Hardware Lister (lshw) https://bugzilla.redhat.com/229591 From jwboyer at jdub.homelinux.org Wed Jun 27 11:55:38 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 06:55:38 -0500 Subject: Package Updating Doc Available In-Reply-To: <200706271258.24005.opensource@till.name> References: <1182896413.10532.30.camel@aglarond.local> <200706271258.24005.opensource@till.name> Message-ID: <1182945338.23154.0.camel@vader.jdub.homelinux.org> On Wed, 2007-06-27 at 12:58 +0200, Till Maas wrote: > On Mi Juni 27 2007, Jeremy Katz wrote: > > Documentation describing the new package update process flow is now > > available at > > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. > > Feel free to update with any clarifications that you feel are needed and > > can figure out or ask away. > > Can you please explain, how you use diff and patch to sync between devel and > F-7? I normally only copy the spec from one place to another. > > Also, you write, that a package should be build locally for devel and F-7 > separately. Afaik will the results only differ, when one uses a devel and a > F-7 machine for this. Not true. You can use mock to build locally for F-7 and devel on the same machine. Just run 'make mockbuild' from the appropriate branch. josh From jwboyer at jdub.homelinux.org Wed Jun 27 11:59:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 06:59:20 -0500 Subject: Package Updating Doc Available In-Reply-To: <5300.1182916028@sss.pgh.pa.us> References: <1182896413.10532.30.camel@aglarond.local> <5300.1182916028@sss.pgh.pa.us> Message-ID: <1182945560.23154.3.camel@vader.jdub.homelinux.org> On Tue, 2007-06-26 at 23:47 -0400, Tom Lane wrote: > Jeremy Katz writes: > > Documentation describing the new package update process flow is now > > available at > > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. > > Feel free to update with any clarifications that you feel are needed and > > can figure out or ask away. > > Surely the steps involving "make" can figure out which platform you are > on, ie, the directions ought to be "Use the command make", full stop. > If not, it's a pretty severe regression from the Red Hat infrastructure > I'm used to. Gah, I hate that damn word. It's not a regression. What if you have an x86_64 machine, but want to build an i386 rpm? josh From opensource at till.name Wed Jun 27 12:20:37 2007 From: opensource at till.name (Till Maas) Date: Wed, 27 Jun 2007 14:20:37 +0200 Subject: Package Updating Doc Available In-Reply-To: <1182945338.23154.0.camel@vader.jdub.homelinux.org> References: <1182896413.10532.30.camel@aglarond.local> <200706271258.24005.opensource@till.name> <1182945338.23154.0.camel@vader.jdub.homelinux.org> Message-ID: <200706271420.38679.opensource@till.name> On Mi Juni 27 2007, Josh Boyer wrote: > On Wed, 2007-06-27 at 12:58 +0200, Till Maas wrote: > > Also, you write, that a package should be build locally for devel and F-7 > > separately. Afaik will the results only differ, when one uses a devel and > > a F-7 machine for this. > > Not true. You can use mock to build locally for F-7 and devel on the > same machine. Just run 'make mockbuild' from the appropriate branch. Yes, one can use "make mockbuild", but this is not what happens with "make $arch", what is described on the wiki page we are writing about. And when you use mock, then you still need two machines to test the build, except you only want to make sure, that the spec builds at all. Also one should be always aware, that packages built with mock in the default configuration use an repository that contains unsigned rpms, so the resulting rpms should not be installed in an machine that contains secret data, e.g. private ssh keys. Regards, Till From rc040203 at freenet.de Wed Jun 27 12:25:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jun 2007 14:25:07 +0200 Subject: rpms/reciteword/devel reciteword.spec,1.2,1.3 In-Reply-To: <200706270846.l5R8kotZ018725@cvs-int.fedora.redhat.com> References: <200706270846.l5R8kotZ018725@cvs-int.fedora.redhat.com> Message-ID: <1182947107.24184.9.camel@mccallum.corsepiu.local> On Wed, 2007-06-27 at 04:46 -0400, Hu Zheng wrote: > Index: reciteword.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/reciteword/devel/reciteword.spec,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- reciteword.spec 20 Jun 2007 08:57:34 -0000 1.2 > +++ reciteword.spec 27 Jun 2007 08:46:15 -0000 1.3 > +%{_datadir}/reciteword > +%{_datadir}/locale/*/LC_MESSAGES/* Please read http://fedoraproject.org/wiki/Packaging/Guidelines?highlight=%28packaging%29#head-8c605ebf8330f6d505f384e671986fa99a8f72ee and consider to use %find_lang Ralf From fedora at leemhuis.info Wed Jun 27 12:28:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 27 Jun 2007 14:28:12 +0200 Subject: Package Updating Doc Available In-Reply-To: <1182945338.23154.0.camel@vader.jdub.homelinux.org> References: <1182896413.10532.30.camel@aglarond.local> <200706271258.24005.opensource@till.name> <1182945338.23154.0.camel@vader.jdub.homelinux.org> Message-ID: <468257DC.4050801@leemhuis.info> On 27.06.2007 13:55, Josh Boyer wrote: > On Wed, 2007-06-27 at 12:58 +0200, Till Maas wrote: >> On Mi Juni 27 2007, Jeremy Katz wrote: >>> Documentation describing the new package update process flow is now >>> available at >>> http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. >>> Feel free to update with any clarifications that you feel are needed and >>> can figure out or ask away. >> Can you please explain, how you use diff and patch to sync between devel and >> F-7? I normally only copy the spec from one place to another. >> >> Also, you write, that a package should be build locally for devel and F-7 >> separately. Afaik will the results only differ, when one uses a devel and a >> F-7 machine for this. > > Not true. You can use mock to build locally for F-7 and devel on the > same machine. Just run 'make mockbuild' from the appropriate branch. But the doc at that place doesn't mention "make mockbuild", but mentions "make i386, make x86_64, or make ppc" instead ;-) BTW: when jeremy in the doc mentioned to build stuff from both the devel and the F-7 branch locally he afaics meant to do that when the spec files in both branches differ. Otherwise there really is no point in rebuilding them locally without mock or different installs afaics. CU thl (who does a local mock build only for new packages before submitting them for review) From jkeating at redhat.com Wed Jun 27 12:26:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 08:26:29 -0400 Subject: Package Updating Doc Available In-Reply-To: <468257DC.4050801@leemhuis.info> References: <1182896413.10532.30.camel@aglarond.local> <1182945338.23154.0.camel@vader.jdub.homelinux.org> <468257DC.4050801@leemhuis.info> Message-ID: <200706270826.29631.jkeating@redhat.com> On Wednesday 27 June 2007 08:28:12 Thorsten Leemhuis wrote: > BTW: when jeremy in the doc mentioned to build stuff from both the devel > and the F-7 branch locally he afaics meant to do that when the spec > files in both branches differ. Otherwise there really is no point in > rebuilding them locally without mock or different installs afaics. Eh, not really. While the spec file may not differ, the buildroot contents will, so it is somewhat important that you at least expect the build will succeed with the different tool sets. Building locally (if you can) before chucking it at the buildserver will reduce load on the buildserver for all. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 27 12:28:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 08:28:38 -0400 Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <1182923425.2922.4.camel@bureau.maison> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626210149.06792736.mschwendt.tmp0701.nospam@arcor.de> <1182923425.2922.4.camel@bureau.maison> Message-ID: <200706270828.38892.jkeating@redhat.com> On Wednesday 27 June 2007 01:50:25 Tanguy Eric wrote: > So libupnp, ushare and gmediaserver are in -testing. vlc from livna is > ready to be rebuilt as soon as libupnp will be in stable. The question > is : do we wait 5 or 7 days before pushing libupnp, ushare and > gmediaserver in stable or do we push their asap ? Preferably you'd get some feedback form the users of ushare and gmediaserver to make sure they still function as expected with the new libupnp before you mark the set as stable. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Wed Jun 27 12:33:27 2007 From: opensource at till.name (Till Maas) Date: Wed, 27 Jun 2007 14:33:27 +0200 Subject: Package Updating Doc Available In-Reply-To: <5300.1182916028@sss.pgh.pa.us> References: <1182896413.10532.30.camel@aglarond.local> <5300.1182916028@sss.pgh.pa.us> Message-ID: <200706271433.29703.opensource@till.name> On Mi Juni 27 2007, Tom Lane wrote: > Surely the steps involving "make" can figure out which platform you are > on, ie, the directions ought to be "Use the command make", full stop. According to "make help" you can use "make local", but this does not build for i386 but for i686 on an i686 machine. But maybe this is enough for your use cases. Regards, Till From fedora at leemhuis.info Wed Jun 27 12:49:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 27 Jun 2007 14:49:23 +0200 Subject: Package Updating Doc Available In-Reply-To: <200706270826.29631.jkeating@redhat.com> References: <1182896413.10532.30.camel@aglarond.local> <1182945338.23154.0.camel@vader.jdub.homelinux.org> <468257DC.4050801@leemhuis.info> <200706270826.29631.jkeating@redhat.com> Message-ID: <46825CD3.7070008@leemhuis.info> On 27.06.2007 14:26, Jesse Keating wrote: > On Wednesday 27 June 2007 08:28:12 Thorsten Leemhuis wrote: >> BTW: when jeremy in the doc mentioned to build stuff from both the devel >> and the F-7 branch locally he afaics meant to do that when the spec >> files in both branches differ. Otherwise there really is no point in >> rebuilding them locally without mock or different installs afaics. > > Eh, not really. Se ebelow :-) > While the spec file may not differ, the buildroot contents > will, Sure. > so it is somewhat important that you at least expect the build will > succeed with the different tool sets. Sure. > Building locally (if you can) before > chucking it at the buildserver will reduce load on the buildserver for all. Sure. But we did not understand each other ;-) If you just follow the steps in the wiki exactly (e.g. on one system without rebooting, chroots or mock) it makes no difference if the spec files in the different branches are identical. CU thl From opensource at till.name Wed Jun 27 12:53:42 2007 From: opensource at till.name (Till Maas) Date: Wed, 27 Jun 2007 14:53:42 +0200 Subject: Package Updating Doc Available In-Reply-To: <200706271433.29703.opensource@till.name> References: <1182896413.10532.30.camel@aglarond.local> <5300.1182916028@sss.pgh.pa.us> <200706271433.29703.opensource@till.name> Message-ID: <200706271453.44353.opensource@till.name> On Mi Juni 27 2007, Till Maas wrote: > According to "make help" you can use "make local", but this does not build ^^^^^ Imho a new target rpmbuild should be created, because "make rpmbuild" describes better, what it does. Regards, Till From jkeating at redhat.com Wed Jun 27 12:47:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 08:47:17 -0400 Subject: Package Updating Doc Available In-Reply-To: <46825CD3.7070008@leemhuis.info> References: <1182896413.10532.30.camel@aglarond.local> <200706270826.29631.jkeating@redhat.com> <46825CD3.7070008@leemhuis.info> Message-ID: <200706270847.18078.jkeating@redhat.com> On Wednesday 27 June 2007 08:49:23 Thorsten Leemhuis wrote: > But we did not understand each other ;-) If you just follow the steps in > the wiki exactly (e.g. on one system without rebooting, chroots or mock) > it makes no difference if the spec files in the different branches are > identical. Correct. The intent is right, the instructions perhaps not so much. Can you suggest better instructions? Please feel free to update the page. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Jun 27 12:25:24 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 08:25:24 -0400 Subject: utmp and friends In-Reply-To: <20070627082200.GB21279@localhost> References: <20070626163237.GE7258@localhost> <20070626222639.GB8397@nostromo.devel.redhat.com> <20070627082200.GB21279@localhost> Message-ID: <20070627122524.GD23234@nostromo.devel.redhat.com> Miroslav Lichvar (mlichvar at redhat.com) said: > > The entire idea of utempter is so that the terminal *doesn't* need to be > > setgid - if it's setgid, what's the point of a helper? > > Well, the terminal doesn't need to be setgid utmp, but only utempter. > Setgid utempter allows only adding/removing entries in utmp while > setgid utmp allows unrestricted access. Only if it's coded wrong (doesn't drop privs, etc.). By adding a setgid to the binary, you're making the point of separating it merely a code-sharing issue, as opposed to any huge security gains. I'd remove the block on the directory - basically, you're intentionally breaking user's environments for illusory security. Bill From laxathom at fedoraproject.org Wed Jun 27 13:34:32 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 27 Jun 2007 09:34:32 -0400 Subject: Mock - how do I install my own RPMs on top of what's in Fedora? In-Reply-To: <20070627042132.GA2598@psilocybe.teonanacatl.org> References: <4681E1F4.8010402@redhat.com> <20070627042132.GA2598@psilocybe.teonanacatl.org> Message-ID: <62bc09df0706270634h1796827ai2bd09e8c185b13cf@mail.gmail.com> 2007/6/27, Todd Zullinger : > > Richard W.M. Jones wrote: > > Basic question about mock: > > > > I want to test build ocaml-findlib[1] using mock. However this > > build-requires ocaml>= 3.10.0 which has been packaged[2] but isn't > > in Fedora. So (I'm guessing) I want to do the mock chroot thing, > > get the Fedora packages required, then install one or more of my own > > RPMs, then do the test build. > > > > How can I do this? I'll mock your srpm (by uploaded you package on my personnal repository), if you want, i can send you my .cfg modified (which point to my repository) to test it too. As you want ;) However set up a local repository is an excelent point too. One way to do this is to edit the mock config file for the target > dist. In the yum.conf section, create a new repo (or override the > local one). For example, I've added this in some of my configs: > > [scratch] > name=scratch > baseurl=file:///path/to/repo > > Then, put your ocaml packages in /path/to/repo and run createrepo on > that dir to create the metadata that yum needs. Now when you call > mock it will look in your scratch repo as well as the standard ones > and it should use your updated ocaml packages. > > -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I got stopped by a cop the other day. He said, "Why'd you run that > stop sign?" I said, "Because I don't believe everything I read." > -- Stephen Wright > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Wed Jun 27 13:43:13 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 09:43:13 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig Message-ID: <20070627134313.GE23234@nostromo.devel.redhat.com> Sent here before -packaging as I'd like comments before finalizing the draft. .... I'd like to propose changing the guidelines regarding shared libraries as follows: When a package places a shared library in a standard library path, it must do the following: - Package the symlinks for the appropriate soname of the library. If the normal installation process of the library does not install these symlinks, they can be created by running: /sbin/ldconfig -n -N - Have the following scriplets in the package: %posttrans -p /sbin/ldconfig Rationale: ldconfig can be very slow. On a test upgrade of Fedora 7 to the current updates and updates-testing repository, not running ldconfig on %post/%postun sped up the upgrade process by 33%. [1] If these symlinks are properly packaged, there is no need to explicitly call ldconfig. Calling ldconfig once at the end of the transaction should be enough to guarantee any necessary cleanup is done. Bill [1] https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000407.html From buytenh at wantstofly.org Wed Jun 27 13:54:14 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Wed, 27 Jun 2007 15:54:14 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1181662311.25228.42.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> Message-ID: <20070627135414.GA13164@xi.wantstofly.org> On Tue, Jun 12, 2007 at 04:31:51PM +0100, David Woodhouse wrote: > > As gcc matures, it's likely that the libgcc problem will go away by it > > being split out. At that time, the chicken/egg problem will be solved > > without having to resort to clever hacks. > > I think we need to accelerate that rather than waiting for it. > > Binutils at least should be relatively easy. Here's a patch against > binutils/F-7 which lets me: > make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc Works fine for me on arm. (One packaging issue with 'as'/'nm', see below.) Attached is a very hacky patch to the gcc spec file to make it cross build (Fedora -> Fedora.) It requires that you already have glibc and kernel headers installed in your sysroot (/usr/%{_target_platform}). (If you're doing Fedora -> Fedora, presumably you already have glibc packages for the target, which will suffice for bootstrapping.) There's a couple of issues: - Whereas your binutils patch is pretty clean, I can't really seem to find a way to make the cross changes to the gcc spec file not very intrusive. I'm starting to wonder whether the gcc cross stuff should just be in a separate spec file. We _do_ want to use exactly the same sources to build the cross-compiler, so maybe the regular gcc package can provide gcc-source, which can then be pulled in by the gcc-cross variant? - binutils puts as/nm binaries into the sysroot, even though they are host binaries. Your binutils spec patch doesn't package those, which makes sense (I don't fully understand why binutils puts them there to begin with), but gcc insists on being able to invoke the target 'as' as 'as'. I've hacked around that by making /usr/libexec/gcc/$target/$version/as a symlink to $target-as (and the same thing with 'nm'), which seems to work. - There's also two issues with building libstdc++ -- it doesn't pick up the sysroot info correctly (and subsequently tries to link against the host's /lib/libc.so.6 after reading the target libc.so script in the sysroot), and its install target installs various target files not in the sysroot but in the host's directory space. Index: SPECS/gcc41.spec =================================================================== --- SPECS.orig/gcc41.spec +++ SPECS/gcc41.spec @@ -1,32 +1,32 @@ +%if "%{?gcc_target}" == "" +%define gcc_target %{_target_platform} +%define isnative 1 +%else +%define isnative 0 +%define cross %{gcc_target}- +%endif + %define DATE 20070503 %define gcc_version 4.1.2 %define gcc_release 12 %define _unpackaged_files_terminate_build 0 %define multilib_64_archs sparc64 ppc64 s390x x86_64 %define include_gappletviewer 1 +%if !%{isnative} +%define build_ada 0 +%else %ifarch %{ix86} x86_64 ia64 ppc alpha %define build_ada 1 %else %define build_ada 0 %endif +%endif %define build_fortran 0 %define build_java 0 %define build_objc 0 %define run_tests 0 -%ifarch s390x -%define multilib_32_arch s390 -%endif -%ifarch sparc64 -%define multilib_32_arch sparc -%endif -%ifarch ppc64 -%define multilib_32_arch ppc -%endif -%ifarch x86_64 -%define multilib_32_arch i386 -%endif Summary: Various compilers (C, C++, Objective-C, Java, ...) -Name: gcc +Name: %{?cross}gcc Version: %{gcc_version} Release: %{gcc_release}.fa1 License: GPL @@ -44,7 +44,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version # Need binutils which support --hash-style=gnu >= 2.17.50.0.2-7 # Need binutils which support mffgpr and mftgpr >= 2.17.50.0.2-8 # Need binutils which support 2-argument .movsp >= 2.17.50.0.5 -BuildRequires: binutils >= 2.17.50.0.5 +BuildRequires: %{?cross}binutils >= 2.17.50.0.5 BuildRequires: zlib-devel, gettext, dejagnu, bison, flex, texinfo, sharutils %if %{build_java} BuildRequires: gcc-java, libgcj, /usr/share/java/eclipse-ecj.jar, zip, unzip @@ -52,7 +52,7 @@ BuildRequires: gcc-java, libgcj, /usr/sh # Make sure pthread.h doesn't contain __thread tokens # Make sure glibc supports stack protector # Make sure glibc supports DT_GNU_HASH -BuildRequires: glibc-devel >= 2.4.90-13 +BuildRequires: %{?cross}glibc-devel >= 2.4.90-13 BuildRequires: elfutils-devel >= 0.72 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double @@ -69,7 +69,7 @@ BuildRequires: gcc-gnat >= 3.1, libgnat %ifarch ia64 BuildRequires: libunwind >= 0.98 %endif -Requires: cpp = %{version}-%{release} +Requires: %{?cross}cpp = %{version}-%{release} # Need .eh_frame ld optimizations # Need proper visibility support # Need -pie support @@ -80,37 +80,39 @@ Requires: cpp = %{version}-%{release} # Need binutils that supports --hash-style=gnu # Need binutils that support mffgpr/mftgpr # Need binutils that support 2-argument .movsp >= 2.17.50.0.5 -Requires: binutils >= 2.17.50.0.5 +Requires: %{?cross}binutils >= 2.17.50.0.5 # Make sure gdb will understand DW_FORM_strp -Conflicts: gdb < 5.1-2 -Requires: glibc-devel >= 2.2.90-12 +Conflicts: %{?cross}gdb < 5.1-2 +Requires: %{?cross}glibc-devel >= 2.2.90-12 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double -Requires: glibc >= 2.3.90-35 +Requires: %{?cross}glibc >= 2.3.90-35 +%endif +Requires: %{?cross}libgcc >= %{version}-%{release} +%if %{isnative} +Requires: %{?cross}libgomp = %{version}-%{release} %endif -Requires: libgcc >= %{version}-%{release} -Requires: libgomp = %{version}-%{release} -Obsoletes: gcc3 -Obsoletes: egcs +Obsoletes: %{?cross}gcc3 +Obsoletes: %{?cross}egcs %ifarch sparc -Obsoletes: gcc-sparc32 -Obsoletes: gcc-c++-sparc32 +Obsoletes: %{?cross}gcc-sparc32 +Obsoletes: %{?cross}gcc-c++-sparc32 %endif %ifarch ppc -Obsoletes: gcc-ppc32 -Obsoletes: gcc-c++-ppc32 +Obsoletes: %{?cross}gcc-ppc32 +Obsoletes: %{?cross}gcc-c++-ppc32 %endif -Obsoletes: gcc-chill +Obsoletes: %{?cross}gcc-chill %if !%{build_ada} -Obsoletes: gcc-gnat < %{version}-%{release} -Obsoletes: libgnat < %{version}-%{release} +Obsoletes: %{?cross}gcc-gnat < %{version}-%{release} +Obsoletes: %{?cross}libgnat < %{version}-%{release} %endif %ifarch sparc sparc64 -Obsoletes: egcs64 +Obsoletes: %{?cross}egcs64 %endif -Obsoletes: gcc34 -Obsoletes: gcc35 -Obsoletes: gcc4 +Obsoletes: %{?cross}gcc34 +Obsoletes: %{?cross}gcc35 +Obsoletes: %{?cross}gcc4 Prereq: /sbin/install-info AutoReq: true @@ -160,6 +162,7 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch %{arm} %define _gnu %{nil} %endif +%if "%{?gcc_target}" == "" %ifarch sparc %define gcc_target_platform sparc64-%{_vendor}-%{_target_os} %endif @@ -169,17 +172,20 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch sparc ppc %define gcc_target_platform %{_target_platform} %endif +%else +%define gcc_target_platform %{gcc_target} +%endif %description The gcc package contains the GNU Compiler Collection version 4.1. You'll need this package in order to compile C code. -%package -n libgcc +%package -n %{?cross}libgcc Summary: GCC version 4.1 shared support library Group: System Environment/Libraries Autoreq: false -%description -n libgcc +%description -n %{?cross}libgcc This package contains GCC shared support library which is needed e.g. for exception handling support. @@ -200,18 +206,18 @@ This package adds C++ support to the GNU It includes support for most of the current C++ specification, including templates and exception handling. -%package -n libstdc++ +%package -n %{?cross}libstdc++ Summary: GNU Standard C++ Library Group: System Environment/Libraries Obsoletes: libstdc++3 Obsoletes: libstdc++34 Autoreq: true -%description -n libstdc++ +%description -n %{?cross}libstdc++ The libstdc++ package contains a rewritten standard compliant GCC Standard C++ Library. -%package -n libstdc++-devel +%package -n %{?cross}libstdc++-devel Summary: Header files and libraries for C++ development Group: Development/Libraries Requires: libstdc++ = %{version}-%{release}, %{_prefix}/%{_lib}/libstdc++.so.6 @@ -219,7 +225,7 @@ Obsoletes: libstdc++3-devel Obsoletes: libstdc++34-devel Autoreq: true -%description -n libstdc++-devel +%description -n %{?cross}libstdc++-devel This is the GNU implementation of the standard C++ libraries. This package includes the header files and libraries needed for C++ development. This includes rewritten implementation of STL. @@ -246,12 +252,12 @@ Autoreq: true %description objc++ gcc-objc++ package provides Objective-C++ support for the GCC. -%package -n libobjc +%package -n %{?cross}libobjc Summary: Objective-C runtime Group: System Environment/Libraries Autoreq: true -%description -n libobjc +%description -n %{?cross}libobjc This package contains Objective-C shared library which is needed to run Objective-C dynamically linked programs. @@ -271,39 +277,39 @@ Autoreq: true The gcc-gfortran package provides support for compiling Fortran 95 programs with the GNU Compiler Collection. -%package -n libgfortran +%package -n %{?cross}libgfortran Summary: Fortran 95 runtime Group: System Environment/Libraries Obsoletes: libf2c Autoreq: true -%description -n libgfortran +%description -n %{?cross}libgfortran This package contains Fortran 95 shared library which is needed to run Fortran 95 dynamically linked programs. -%package -n libgomp +%package -n %{?cross}libgomp Summary: GCC OpenMP 2.5 shared support library Group: System Environment/Libraries -%description -n libgomp +%description -n %{?cross}libgomp This package contains GCC shared support library which is needed for OpenMP 2.5 support. -%package -n libmudflap +%package -n %{?cross}libmudflap Summary: GCC mudflap shared support library Group: System Environment/Libraries -%description -n libmudflap +%description -n %{?cross}libmudflap This package contains GCC shared support library which is needed for mudflap support. -%package -n libmudflap-devel +%package -n %{?cross}libmudflap-devel Summary: GCC mudflap support Group: Development/Libraries Requires: libmudflap = %{version}-%{release} Requires: gcc = %{version}-%{release} -%description -n libmudflap-devel +%description -n %{?cross}libmudflap-devel This package contains headers and static libraries for building mudflap-instrumented programs. @@ -329,7 +335,7 @@ Autoreq: true This package adds support for compiling Java(tm) programs and bytecode into native code. -%package -n libgcj +%package -n %{?cross}libgcj Summary: Java runtime library for gcc Group: System Environment/Libraries Prereq: /sbin/install-info @@ -352,11 +358,11 @@ Obsoletes: libgcj34 Obsoletes: libgcj4 Autoreq: true -%description -n libgcj +%description -n %{?cross}libgcj The Java(tm) runtime library. You will need this package to run your Java programs compiled using the Java compiler from GNU Compiler Collection (gcj). -%package -n libgcj-devel +%package -n %{?cross}libgcj-devel Summary: Libraries for Java development using GCC Group: Development/Languages Requires: libgcj = %{version}-%{release}, %{_prefix}/%{_lib}/libgcj.so.8rh @@ -368,21 +374,21 @@ Obsoletes: libgcj4-devel Autoreq: false Autoprov: false -%description -n libgcj-devel +%description -n %{?cross}libgcj-devel The Java(tm) static libraries and C header files. You will need this package to compile your Java programs using the GCC Java compiler (gcj). -%package -n libgcj-src +%package -n %{?cross}libgcj-src Summary: Java library sources from GCC4 preview Group: System Environment/Libraries Requires: libgcj = %{version}-%{release} Obsoletes: libgcj4-src Autoreq: true -%description -n libgcj-src +%description -n %{?cross}libgcj-src The Java(tm) runtime library sources for use in Eclipse. -%package -n cpp +%package -n %{?cross}cpp Summary: The C Preprocessor. Group: Development/Languages Prereq: /sbin/install-info @@ -391,7 +397,7 @@ Obsoletes: gnupro %endif Autoreq: true -%description -n cpp +%description -n %{?cross}cpp Cpp is the GNU C-Compatible Compiler Preprocessor. Cpp is a macro processor which is used automatically by the C compiler to transform your program before actual @@ -425,13 +431,13 @@ Autoreq: true GNAT is a GNU Ada 95 front-end to GCC. This package includes development tools, the documents and Ada 95 compiler. -%package -n libgnat +%package -n %{?cross}libgnat Summary: GNU Ada 95 runtime shared libraries Group: System Environment/Libraries Obsoletes: gnat libgnat3 Autoreq: true -%description -n libgnat +%description -n %{?cross}libgnat GNAT is a GNU Ada 95 front-end to GCC. This package includes shared libraries, which are required to run programs compiled with the GNAT. @@ -511,6 +517,7 @@ if [ -d libstdc++-v3/config/abi/sparc64- rm -rf libstdc++-v3/config/abi/sparc64-linux-gnu/32 fi %endif +find -name configure | xargs sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' %build @@ -583,6 +590,7 @@ case "$OPT_FLAGS" in ../gcc/Makefile.in ;; esac +%if %{isnative} CC="$CC" CFLAGS="$OPT_FLAGS" CXXFLAGS="$OPT_FLAGS" XCFLAGS="$OPT_FLAGS" TCFLAGS="$OPT_FLAGS" \ GCJFLAGS="$OPT_FLAGS" \ ../configure --prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \ @@ -632,7 +640,6 @@ CC="$CC" CFLAGS="$OPT_FLAGS" CXXFLAGS="$ --host=%{gcc_target_platform} %endif -#GCJFLAGS="$OPT_FLAGS" make %{?_smp_mflags} BOOT_CFLAGS="$OPT_FLAGS" bootstrap GCJFLAGS="$OPT_FLAGS" make %{?_smp_mflags} BOOT_CFLAGS="$OPT_FLAGS" profiledbootstrap %if %{run_tests} @@ -663,6 +670,19 @@ rm -rf testlogs-%{_target_platform}-%{ve # Make protoize make -C gcc CC="./xgcc -B ./ -O2" proto +%else +CC="$CC" CFLAGS="-O2 -g" CXXFLAGS="-O2 -g" XCFLAGS="-O2 -g" TCFLAGS="-O2 -g" \ + GCJFLAGS="-O2 -g" \ + ../configure --prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \ + --enable-shared --enable-threads=posix --enable-checking=release \ + --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions \ + --enable-languages=c --disable-libgcj --disable-libssp \ + --disable-libgomp --disable-libmudflap \ + --with-sysroot=/usr/%{gcc_target_platform} \ + --target=%{gcc_target_platform} + +GCJFLAGS="-O2 -g" make %{?_smp_mflags} BOOT_CFLAGS="-O2 -g" +%endif # Make generated man pages even if Pod::Man is not new enough perl -pi -e 's/head3/head2/' ../contrib/texi2pod.pl @@ -730,10 +750,10 @@ fi export PATH=`pwd`/java_hacks${PATH:+:$PATH} %endif -TARGET_PLATFORM=%{gcc_target_platform} - +%if %{isnative} # There are some MP bugs in libstdc++ Makefiles make -C %{gcc_target_platform}/libstdc++-v3 +%endif make prefix=$RPM_BUILD_ROOT%{_prefix} mandir=$RPM_BUILD_ROOT%{_mandir} \ infodir=$RPM_BUILD_ROOT%{_infodir} install @@ -748,16 +768,26 @@ FULLPATH=$RPM_BUILD_ROOT%{_prefix}/lib/g FULLEPATH=$RPM_BUILD_ROOT%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} # fix some things +%if %{isnative} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/cc mkdir -p $RPM_BUILD_ROOT/lib ln -sf ..%{_prefix}/bin/cpp $RPM_BUILD_ROOT/lib/cpp +%endif %if %{build_fortran} ln -sf gfortran $RPM_BUILD_ROOT%{_prefix}/bin/f95 %endif rm -f $RPM_BUILD_ROOT%{_infodir}/dir gzip -9 $RPM_BUILD_ROOT%{_infodir}/*.info* +%if %{build_ada} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/gnatgcc +%endif +%if !%{isnative} +ln -s ../../../../bin/%{gcc_target}-as $FULLEPATH/as +ln -s ../../../../bin/%{gcc_target}-nm $FULLEPATH/nm +%endif + +%if %{isnative} cxxconfig="`find %{gcc_target_platform}/libstdc++-v3/include -name c++config.h`" for i in `find %{gcc_target_platform}/[36]*/libstdc++-v3/include -name c++config.h 2>/dev/null`; do if ! diff -up $cxxconfig $i; then @@ -783,6 +813,7 @@ EOF break fi done +%endif %ifarch sparc sparc64 ln -f $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-gcc \ @@ -818,11 +849,13 @@ sed -i -e 's/lib: /&%%{static:%%eJava pr $FULLPATH/libgcj.spec %endif +%if %{isnative} mkdir -p $RPM_BUILD_ROOT/%{_lib} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcc_s.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 chmod 755 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 ln -sf libgcc_s-%{gcc_version}-%{DATE}.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s.so.1 ln -sf /%{_lib}/libgcc_s.so.1 $FULLPATH/libgcc_s.so +%endif %ifarch sparc ppc ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64/libgcc_s.so %endif @@ -830,8 +863,10 @@ ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64 ln -sf /lib/libgcc_s.so.1 $FULLPATH/32/libgcc_s.so %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.spec $FULLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/include/omp.h $FULLPATH/include/ +%endif %if %{build_ada} mv -f $FULLPATH/adalib/libgnarl-*.so $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ @@ -856,16 +891,21 @@ fi pushd $FULLPATH if [ "%{_lib}" = "lib" ]; then +true %if %{build_objc} ln -sf ../../../libobjc.so.1 libobjc.so %endif +%if %{isnative} ln -sf ../../../libstdc++.so.6.* libstdc++.so +%endif %if %{build_fortran} ln -sf ../../../libgfortran.so.1.* libgfortran.so %endif +%if %{isnative} ln -sf ../../../libgomp.so.1.* libgomp.so ln -sf ../../../libmudflap.so.0.* libmudflap.so ln -sf ../../../libmudflapth.so.0.* libmudflapth.so +%endif %if %{build_java} ln -sf ../../../libgcj.so.8rh.* libgcj.so ln -sf ../../../libgcj-tools.so.8rh.* libgcj-tools.so @@ -883,7 +923,9 @@ else %if %{build_objc} ln -sf ../../../../%{_lib}/libobjc.so.1 libobjc.so %endif +%if %{isnative} ln -sf ../../../../%{_lib}/libstdc++.so.6.* libstdc++.so +%endif %if %{build_fortran} ln -sf ../../../../%{_lib}/libgfortran.so.1.* libgfortran.so %endif @@ -907,8 +949,10 @@ fi %if %{build_java} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcj_bc.so $FULLLPATH/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libstdc++.*a $FULLLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libsupc++.*a . +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortranbegin.*a . @@ -916,21 +960,27 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.*a . %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/include/mf-runtime.h include/ +%endif %ifarch sparc ppc %if %{build_objc} ln -sf ../../../../../lib64/libobjc.so.1 64/libobjc.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib/libstdc++.so.6.* | sed s~/lib/~/lib64/~` 64/libstdc++.so +%endif %if %{build_fortran} ln -sf ../`echo ../../../../lib/libgfortran.so.1.* | sed s~/lib/~/lib64/~` 64/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib/libgomp.so.1.* | sed s~/lib/~/lib64/~` 64/libgomp.so ln -sf ../`echo ../../../../lib/libmudflap.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflap.so ln -sf ../`echo ../../../../lib/libmudflapth.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib/libgcj.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj.so ln -sf ../`echo ../../../../lib/libgcj-tools.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj-tools.so @@ -938,7 +988,9 @@ ln -sf ../`echo ../../../../lib/libgij.s ln -sf lib32/libgcj_bc.so libgcj_bc.so ln -sf ../lib64/libgcj_bc.so 64/libgcj_bc.so %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libsupc++.*a 64/ +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgfortran.*a 64/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgfortranbegin.*a 64/ @@ -946,29 +998,37 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/li %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libobjc.*a 64/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgomp.*a 64/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libmudflap{,th}.*a 64/ ln -sf lib32/libstdc++.a libstdc++.a ln -sf ../lib64/libstdc++.a 64/libstdc++.a %endif +%endif %ifarch %{multilib_64_archs} mkdir -p 32 %if %{build_objc} ln -sf ../../../../libobjc.so.1 32/libobjc.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib64/libstdc++.so.6.* | sed s~/../lib64/~/~` 32/libstdc++.so +%endif %if %{build_fortran} ln -sf ../`echo ../../../../lib64/libgfortran.so.1.* | sed s~/../lib64/~/~` 32/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib64/libgomp.so.1.* | sed s~/../lib64/~/~` 32/libgomp.so ln -sf ../`echo ../../../../lib64/libmudflap.so.0.* | sed s~/../lib64/~/~` 32/libmudflap.so ln -sf ../`echo ../../../../lib64/libmudflapth.so.0.* | sed s~/../lib64/~/~` 32/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib64/libgcj.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj.so ln -sf ../`echo ../../../../lib64/libgcj-tools.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj-tools.so ln -sf ../`echo ../../../../lib64/libgij.so.8rh.* | sed s~/../lib64/~/~` 32/libgij.so %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libsupc++.*a 32/ +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgfortran.*a 32/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgfortranbegin.*a 32/ @@ -976,21 +1036,41 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libg %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libobjc.*a 32/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgomp.*a 32/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libmudflap{,th}.*a 32/ %endif +%endif %ifarch sparc64 ppc64 +%if %{isnative} ln -sf ../lib32/libstdc++.a 32/libstdc++.a ln -sf lib64/libstdc++.a libstdc++.a +%endif %if %{build_java} ln -sf ../lib32/libgcj_bc.so 32/libgcj_bc.so ln -sf lib64/libgcj_bc.so libgcj_bc.so %endif %else +case %{gcc_target} in + s390x*) + MULTILIB_32_ARCH=s390 + ;; + sparc64*) + MULTILIB_32_ARCH=sparc + ;; + ppc64*) + MULTILIB_32_ARCH=ppc + ;; + x86_64*) + MULTILIB_32_ARCH=i386 + ;; +esac %ifarch %{multilib_64_archs} -ln -sf ../../../%{multilib_32_arch}-%{_vendor}-%{_target_os}/%{gcc_version}/libstdc++.a 32/libstdc++.a +%if %{isnative} +ln -sf ../../../${MULTILIB_32_ARCH}-%{_vendor}-%{_target_os}/%{gcc_version}/libstdc++.a 32/libstdc++.a +%endif %if %{build_java} -ln -sf ../../../%{multilib_32_arch}-%{_vendor}-%{_target_os}/%{gcc_version}/libgcj_bc.so 32/libgcj_bc.so +ln -sf ../../../${MULTILIB_32_ARCH}-%{_vendor}-%{_target_os}/%{gcc_version}/libgcj_bc.so 32/libgcj_bc.so %endif %endif %endif @@ -1003,8 +1083,10 @@ popd %if %{build_fortran} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.so.1.* %endif +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.so.1.* chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.so.0.* +%endif %if %{build_objc} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.so.1.* %endif @@ -1022,7 +1104,11 @@ for h in `find $FULLPATH/include -name \ fi done +%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c89 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c89 <<"EOF" +%endif #!/bin/sh fl="-std=c89" for opt; do @@ -1034,7 +1120,11 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c99 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c99 <<"EOF" +%endif #!/bin/sh fl="-std=c99" for opt; do @@ -1046,17 +1136,25 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/c?9 +%else +chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c?9 +%endif +%if %{isnative} %ifnarch %{arm} mkdir -p $RPM_BUILD_ROOT%{_prefix}/sbin gcc -static -Os %{SOURCE1} -o $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade strip $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade %endif +%endif cd .. +%if %{isnative} %find_lang %{name} %find_lang cpplib +%endif # Remove binaries we will not be including, so that they don't end up in # gcc-debuginfo @@ -1102,11 +1200,11 @@ if [ $1 = 0 ]; then --info-dir=%{_infodir} %{_infodir}/gcc.info.gz || : fi -%post -n cpp +%post -n %{?cross}cpp /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || : -%preun -n cpp +%preun -n %{?cross}cpp if [ $1 = 0 ]; then /sbin/install-info --delete \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || : @@ -1154,48 +1252,53 @@ fi # Because glibc Prereq's libgcc and /sbin/ldconfig # comes from glibc, it might not exist yet when # libgcc is installed -%post -n libgcc -p %{_prefix}/sbin/libgcc_post_upgrade +%post -n %{?cross}libgcc -p %{_prefix}/sbin/libgcc_post_upgrade %endif -%post -n libstdc++ -p /sbin/ldconfig +%post -n %{?cross}libstdc++ -p /sbin/ldconfig -%postun -n libstdc++ -p /sbin/ldconfig +%postun -n %{?cross}libstdc++ -p /sbin/ldconfig -%post -n libobjc -p /sbin/ldconfig +%post -n %{?cross}libobjc -p /sbin/ldconfig -%postun -n libobjc -p /sbin/ldconfig +%postun -n %{?cross}libobjc -p /sbin/ldconfig -%post -n libgcj +%post -n %{?cross}libgcj /sbin/ldconfig /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/fastjar.info.gz || : -%preun -n libgcj +%preun -n %{?cross}libgcj if [ $1 = 0 ]; then /sbin/install-info --delete \ --info-dir=%{_infodir} %{_infodir}/fastjar.info.gz || : fi -%postun -n libgcj -p /sbin/ldconfig +%postun -n %{?cross}libgcj -p /sbin/ldconfig -%post -n libgfortran -p /sbin/ldconfig +%post -n %{?cross}libgfortran -p /sbin/ldconfig -%postun -n libgfortran -p /sbin/ldconfig +%postun -n %{?cross}libgfortran -p /sbin/ldconfig -%post -n libgnat -p /sbin/ldconfig +%post -n %{?cross}libgnat -p /sbin/ldconfig -%postun -n libgnat -p /sbin/ldconfig +%postun -n %{?cross}libgnat -p /sbin/ldconfig -%post -n libgomp -p /sbin/ldconfig +%post -n %{?cross}libgomp -p /sbin/ldconfig -%postun -n libgomp -p /sbin/ldconfig +%postun -n %{?cross}libgomp -p /sbin/ldconfig -%post -n libmudflap -p /sbin/ldconfig +%post -n %{?cross}libmudflap -p /sbin/ldconfig -%postun -n libmudflap -p /sbin/ldconfig +%postun -n %{?cross}libmudflap -p /sbin/ldconfig +%if %{isnative} %files -f %{name}.lang +%else +%files +%endif %defattr(-,root,root) +%if %{isnative} %{_prefix}/bin/cc %{_prefix}/bin/c89 %{_prefix}/bin/c99 @@ -1203,6 +1306,11 @@ fi %{_prefix}/bin/gcov %{_prefix}/bin/protoize %{_prefix}/bin/unprotoize +%else +%{_prefix}/bin/%{gcc_target_platform}-c89 +%{_prefix}/bin/%{gcc_target_platform}-c99 +%{_prefix}/bin/%{gcc_target_platform}-gcov +%endif %ifarch sparc ppc %{_prefix}/bin/%{_target_platform}-gcc %endif @@ -1213,11 +1321,16 @@ fi %{_prefix}/bin/ppc-%{_vendor}-%{_target_os}-gcc %endif %{_prefix}/bin/%{gcc_target_platform}-gcc +%if %{isnative} %{_mandir}/man1/gcc.1* %{_mandir}/man1/gcov.1* %{_mandir}/man1/protoize.1* %{_mandir}/man1/unprotoize.1* %{_infodir}/gcc* +%else +%{_mandir}/man1/%{gcc_target_platform}-gcc.1* +%{_mandir}/man1/%{gcc_target_platform}-gcov.1* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} @@ -1225,7 +1338,9 @@ fi %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/SYSCALLS.c.X +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stddef.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stdarg.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/varargs.h @@ -1235,6 +1350,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/iso646.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/syslimits.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/unwind.h +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/omp.h %ifarch %{ix86} x86_64 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mmintrin.h @@ -1254,12 +1370,14 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/altivec.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/spe.h %endif +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/README %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/collect2 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/crt*.o %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcov.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_eh.a +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_s.so %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.spec %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.a @@ -1284,30 +1402,50 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.so %endif +%endif +%if !%{isnative} +%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/as +%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/nm +%endif %dir %{_prefix}/libexec/getconf %{_prefix}/libexec/getconf/default %doc gcc/README* rpm.doc/changelogs/gcc/ChangeLog* gcc/COPYING* +%if %{isnative} %files -n cpp -f cpplib.lang +%else +%files -n %{?cross}cpp +%endif %defattr(-,root,root) +%if %{isnative} /lib/cpp %{_prefix}/bin/cpp %{_mandir}/man1/cpp.1* %{_infodir}/cpp* +%else +%{_prefix}/bin/%{gcc_target_platform}-cpp +%endif %dir %{_prefix}/libexec/gcc %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/cc1 -%files -n libgcc +%files -n %{?cross}libgcc %defattr(-,root,root) +%if %{isnative} /%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 /%{_lib}/libgcc_s.so.1 +%else +/%{_prefix}/%{gcc_target_platform}/%{_lib}/libgcc_s.so.1 +%endif +%if %{isnative) %ifnarch %{arm} %{_prefix}/sbin/libgcc_post_upgrade %endif +%endif %doc gcc/COPYING.LIB +%if %{isnative} %files c++ %defattr(-,root,root) %{_prefix}/bin/%{gcc_target_platform}-*++ @@ -1342,11 +1480,11 @@ fi %endif %doc rpm.doc/changelogs/gcc/cp/ChangeLog* -%files -n libstdc++ +%files -n %{?cross}libstdc++ %defattr(-,root,root) %{_prefix}/%{_lib}/libstdc++.so.6* -%files -n libstdc++-devel +%files -n %{?cross}libstdc++-devel %defattr(-,root,root) %dir %{_prefix}/include/c++ %dir %{_prefix}/include/c++/%{gcc_version} @@ -1372,6 +1510,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libsupc++.a %endif %doc rpm.doc/changelogs/libstdc++-v3/ChangeLog* libstdc++-v3/README* libstdc++-v3/docs/html/ +%endif %if %{build_objc} %files objc @@ -1407,7 +1546,7 @@ fi %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/cc1objplus -%files -n libobjc +%files -n %{?cross}libobjc %defattr(-,root,root) %{_prefix}/%{_lib}/libobjc.so.1* %endif @@ -1448,7 +1587,7 @@ fi %endif %doc rpm.doc/gfortran/* -%files -n libgfortran +%files -n %{?cross}libgfortran %defattr(-,root,root) %{_prefix}/%{_lib}/libgfortran.so.1* %endif @@ -1496,7 +1635,7 @@ fi %endif %doc rpm.doc/changelogs/gcc/java/ChangeLog* -%files -n libgcj +%files -n %{?cross}libgcj %defattr(-,root,root) %{_prefix}/bin/jv-convert %{_prefix}/bin/gij @@ -1555,7 +1694,7 @@ fi %doc rpm.doc/README.libgcjwebplugin.so %endif -%files -n libgcj-devel +%files -n %{?cross}libgcj-devel %defattr(-,root,root) %{_prefix}/bin/addr2name.awk %dir %{_prefix}/lib/gcc @@ -1589,7 +1728,7 @@ fi %doc rpm.doc/boehm-gc/* rpm.doc/fastjar/* rpm.doc/libffi/* %doc rpm.doc/libjava/* -%files -n libgcj-src +%files -n %{?cross}libgcj-src %defattr(-,root,root) %dir %{_prefix}/share/java %{_prefix}/share/java/src*.zip @@ -1613,23 +1752,24 @@ fi %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/gnat1 %doc rpm.doc/changelogs/gcc/ada/ChangeLog* -%files -n libgnat +%files -n %{?cross}libgnat %defattr(-,root,root) %{_prefix}/%{_lib}/libgnat-*.so %{_prefix}/%{_lib}/libgnarl-*.so %endif -%files -n libgomp +%if %{isnative} +%files -n %{?cross}libgomp %defattr(-,root,root) %{_prefix}/%{_lib}/libgomp.so.1* %doc rpm.doc/changelogs/libgomp/ChangeLog* -%files -n libmudflap +%files -n %{?cross}libmudflap %defattr(-,root,root) %{_prefix}/%{_lib}/libmudflap.so.0* %{_prefix}/%{_lib}/libmudflapth.so.0* -%files -n libmudflap-devel +%files -n %{?cross}libmudflap-devel %defattr(-,root,root) %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} @@ -1655,6 +1795,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflapth.so %endif %doc rpm.doc/changelogs/libmudflap/ChangeLog* +%endif %changelog * Thu May 3 2007 Jakub Jelinek 4.1.2-12 From rc040203 at freenet.de Wed Jun 27 13:59:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jun 2007 15:59:55 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <20070627135414.GA13164@xi.wantstofly.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <20070627135414.GA13164@xi.wantstofly.org> Message-ID: <1182952795.24184.36.camel@mccallum.corsepiu.local> On Wed, 2007-06-27 at 15:54 +0200, Lennert Buytenhek wrote: > On Tue, Jun 12, 2007 at 04:31:51PM +0100, David Woodhouse wrote: > There's a couple of issues: > - There's also two issues with building libstdc++ - > ... it install target installs various target files > not in the sysroot but in the host's directory space. --enable-version-specific-runtime-libs Ralf From martin.sourada at seznam.cz Wed Jun 27 14:08:16 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 27 Jun 2007 16:08:16 +0200 Subject: XULRunner - will be or won't be? Message-ID: <1182953296.3253.33.camel@pc-notebook> Hi, I have a couple of questions concerning xulrunner packaging: 1. How's the work on xulrunner going (if there is someone who works on it)? 2. Is it targeted on F8 or not? 3. Why is it not mentioned on wiki[1]? Thanks, Martin reference: [1] http://fedoraproject.org/wiki/Releases/8/FeatureList -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jun 27 14:10:19 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 27 Jun 2007 16:10:19 +0200 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: <20070627134313.GE23234@nostromo.devel.redhat.com> References: <20070627134313.GE23234@nostromo.devel.redhat.com> Message-ID: <20070627161019.3d9b11ca@python3.es.egwn.lan> Bill Nottingham wrote : > Sent here before -packaging as I'd like comments before finalizing > the draft. My hero! :-) I'm always all for ripping out any useless stuff, so if all of those ldconfig calls can simply be avoided, count me in for the spec file patching fest ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.19 0.32 0.34 From krh at redhat.com Wed Jun 27 14:18:45 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Wed, 27 Jun 2007 10:18:45 -0400 Subject: X Crasher in todays rawhide In-Reply-To: <20070626174635.GA3363@free.fr> References: <1182872580.1689.76.camel@hinata.boston.redhat.com> <46813F2E.7040301@mindspring.com> <20070626174635.GA3363@free.fr> Message-ID: <1182953925.1689.86.camel@hinata.boston.redhat.com> On Tue, 2007-06-26 at 19:46 +0200, Patrice Dumas wrote: > Kristian H?gsberg wrote: > > Hi, > > I pushed the new core X fonts packages yesterday and they appear in > > todays rawhide. They now use the catalogue font path mechanism, where > > the package adds a symlink to the font dir in /etc/X11/fontpath.d and > > the X server automatically picks up the new fonts. The symlinks name > > can contain attributes such as :unscaled to prevent scaling bitmap fonts > > or :pri=10 to control the search order. > > However, there's a bug in the libXfont package in rawhide, that crashes > > when comparing symlinks with no attributes. I'd suggest either skipping > > the rawhide upgrade today, avoiding xorg-x11-fonts-*, or do the upgrade > > and the pull the new libXfont builds manually: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=9752 > > Kristian > > The fonts in fluxbox window titles have changed. > > And in gv, or xpdf (gv is an Xaw app, xpdf is lesstif based), I get: > Warning: Cannot convert string "-*-Helvetica-Medium-R-Normal--*-140-*-*-P-*-ISO8859-1" to type FontStruct > > Warning: Cannot convert string "-*-times-medium-r-normal--14-*-*-*-*-*-iso8859-1" to type FontStruct > > I don't recall having those error messages before the libXfont update. > Is it a bug or a normal side-effect? That's a problem... could you open a bug, assign to me, attach output from xset q, ls -l /etc/X11/fontpath.d, rpm -qa | grep xorg-x11-fonts and xlsfonts? thanks, Kristian From krh at redhat.com Wed Jun 27 14:18:45 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Wed, 27 Jun 2007 10:18:45 -0400 Subject: X Crasher in todays rawhide In-Reply-To: <20070626174635.GA3363@free.fr> References: <1182872580.1689.76.camel@hinata.boston.redhat.com> <46813F2E.7040301@mindspring.com> <20070626174635.GA3363@free.fr> Message-ID: <1182953925.1689.86.camel@hinata.boston.redhat.com> On Tue, 2007-06-26 at 19:46 +0200, Patrice Dumas wrote: > Kristian H?gsberg wrote: > > Hi, > > I pushed the new core X fonts packages yesterday and they appear in > > todays rawhide. They now use the catalogue font path mechanism, where > > the package adds a symlink to the font dir in /etc/X11/fontpath.d and > > the X server automatically picks up the new fonts. The symlinks name > > can contain attributes such as :unscaled to prevent scaling bitmap fonts > > or :pri=10 to control the search order. > > However, there's a bug in the libXfont package in rawhide, that crashes > > when comparing symlinks with no attributes. I'd suggest either skipping > > the rawhide upgrade today, avoiding xorg-x11-fonts-*, or do the upgrade > > and the pull the new libXfont builds manually: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=9752 > > Kristian > > The fonts in fluxbox window titles have changed. > > And in gv, or xpdf (gv is an Xaw app, xpdf is lesstif based), I get: > Warning: Cannot convert string "-*-Helvetica-Medium-R-Normal--*-140-*-*-P-*-ISO8859-1" to type FontStruct > > Warning: Cannot convert string "-*-times-medium-r-normal--14-*-*-*-*-*-iso8859-1" to type FontStruct > > I don't recall having those error messages before the libXfont update. > Is it a bug or a normal side-effect? That's a problem... could you open a bug, assign to me, attach output from xset q, ls -l /etc/X11/fontpath.d, rpm -qa | grep xorg-x11-fonts and xlsfonts? thanks, Kristian From rdieter at math.unl.edu Wed Jun 27 14:04:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Jun 2007 09:04:01 -0500 Subject: [RFC] change packaging around shared libraries, ldconfig References: <20070627134313.GE23234@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > I'd like to propose changing the guidelines regarding shared libraries > as follows: > > When a package places a shared library in a standard library path, it > must do the following: > > - Package the symlinks for the appropriate soname of the library. If > the normal installation process of the library does not install these > symlinks, they can be created by running: > /sbin/ldconfig -n -N > - Have the following scriplets in the package: > > %posttrans -p /sbin/ldconfig Doesn't ldconfig also update ld.so.cache? If so, won't "bad things" happen if that cache is stale, like when/if 2 pkgs are installed in a transaction, and pkg #2 depends on shlibs from pkg #1? -- Rex From notting at redhat.com Wed Jun 27 14:30:21 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 10:30:21 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: References: <20070627134313.GE23234@nostromo.devel.redhat.com> Message-ID: <20070627143021.GA25715@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Doesn't ldconfig also update ld.so.cache? If so, won't "bad things" happen > if that cache is stale, like when/if 2 pkgs are installed in a transaction, > and pkg #2 depends on shlibs from pkg #1? If the cache is stale, it will look in the directories for something that doesn't exist in the cache. I'm trying to think of a way the cache could point to the wrong *version* of the library, but nothing is coming to mind. Bill From dtimms at iinet.net.au Wed Jun 27 14:34:18 2007 From: dtimms at iinet.net.au (David Timms) Date: Thu, 28 Jun 2007 00:34:18 +1000 Subject: XULRunner - will be or won't be? In-Reply-To: <1182953296.3253.33.camel@pc-notebook> References: <1182953296.3253.33.camel@pc-notebook> Message-ID: <4682756A.7000301@iinet.net.au> Martin Sourada wrote: > Hi, > > I have a couple of questions concerning xulrunner packaging: > > 1. How's the work on xulrunner going (if there is someone who works on > it)? > 2. Is it targeted on F8 or not? > 3. Why is it not mentioned on wiki[1]? > > Thanks, > Martin > > reference: > [1] http://fedoraproject.org/wiki/Releases/8/FeatureList I think I noticed that more than one person had begun developing the packages, and hence you should be able to find it in bugzilla {review request} DaveT. From panemade at gmail.com Wed Jun 27 14:36:15 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 27 Jun 2007 20:06:15 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <1182953296.3253.33.camel@pc-notebook> References: <1182953296.3253.33.camel@pc-notebook> Message-ID: Hi, On 6/27/07, Martin Sourada wrote: > Hi, > > I have a couple of questions concerning xulrunner packaging: > > 1. How's the work on xulrunner going (if there is someone who works on > it)? > 2. Is it targeted on F8 or not? AFAIK its targeted for OLPC-2 branch. > 3. Why is it not mentioned on wiki[1]? http://fedoraproject.org/wiki/OlpcFedoraPartnership > > Thanks, > Martin > > reference: > [1] http://fedoraproject.org/wiki/Releases/8/FeatureList > Regards, Parag. From jan.kratochvil at redhat.com Wed Jun 27 14:37:13 2007 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 27 Jun 2007 16:37:13 +0200 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: <20070627134313.GE23234@nostromo.devel.redhat.com> References: <20070627134313.GE23234@nostromo.devel.redhat.com> Message-ID: <20070627143713.GA4099@host0.dyn.jankratochvil.net> On Wed, 27 Jun 2007 15:43:13 +0200, Bill Nottingham wrote: > Sent here before -packaging as I'd like comments before finalizing > the draft. > > .... > > I'd like to propose changing the guidelines regarding shared libraries > as follows: ... > ldconfig can be very slow. FYI there is now being discussed an incremental ldconfig patch upstream: http://sourceware.org/ml/libc-alpha/2007-06/msg00118.html Jan From jspaleta at gmail.com Wed Jun 27 14:41:10 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Jun 2007 06:41:10 -0800 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: <20070627143021.GA25715@nostromo.devel.redhat.com> References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143021.GA25715@nostromo.devel.redhat.com> Message-ID: <604aa7910706270741y2e5f81f6g216bcd85185eac0a@mail.gmail.com> On 6/27/07, Bill Nottingham wrote: > If the cache is stale, it will look in the directories for something that > doesn't exist in the cache. I'm trying to think of a way the cache could > point to the wrong *version* of the library, but nothing is coming to > mind. Pathological case? Forcing the install of a duplicate library package when there is a soname version bump and there isn't a compat package and you want to keep the old library version on your local system? -jef"i'd rather be fishing"spaleta From notting at redhat.com Wed Jun 27 14:40:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 10:40:32 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: <20070627143713.GA4099@host0.dyn.jankratochvil.net> References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143713.GA4099@host0.dyn.jankratochvil.net> Message-ID: <20070627144032.GC25715@nostromo.devel.redhat.com> Jan Kratochvil (jan.kratochvil at redhat.com) said: > FYI there is now being discussed an incremental ldconfig patch upstream: > http://sourceware.org/ml/libc-alpha/2007-06/msg00118.html Sure. It's still slower than not running it at all. Bill From notting at redhat.com Wed Jun 27 14:42:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 10:42:31 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: <604aa7910706270741y2e5f81f6g216bcd85185eac0a@mail.gmail.com> References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143021.GA25715@nostromo.devel.redhat.com> <604aa7910706270741y2e5f81f6g216bcd85185eac0a@mail.gmail.com> Message-ID: <20070627144231.GD25715@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: >> If the cache is stale, it will look in the directories for something that >> doesn't exist in the cache. I'm trying to think of a way the cache could >> point to the wrong *version* of the library, but nothing is coming to >> mind. > > Pathological case? > Forcing the install of a duplicate library package when there is a > soname version bump and there isn't a compat package and you want to > keep the old library version on your local system? Then the soname doesn't match, so it will DTRT anyway. If the soname is the same, you'll only have the new library on the system, so the cache can't be 'stale' there either in a way that gives you the wrong library. Bill From jakub at redhat.com Wed Jun 27 14:55:33 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 27 Jun 2007 10:55:33 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: <20070627144231.GD25715@nostromo.devel.redhat.com> References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143021.GA25715@nostromo.devel.redhat.com> <604aa7910706270741y2e5f81f6g216bcd85185eac0a@mail.gmail.com> <20070627144231.GD25715@nostromo.devel.redhat.com> Message-ID: <20070627145533.GD7012@devserv.devel.redhat.com> On Wed, Jun 27, 2007 at 10:42:31AM -0400, Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: > >> If the cache is stale, it will look in the directories for something that > >> doesn't exist in the cache. I'm trying to think of a way the cache could > >> point to the wrong *version* of the library, but nothing is coming to > >> mind. > > > > Pathological case? > > Forcing the install of a duplicate library package when there is a > > soname version bump and there isn't a compat package and you want to > > keep the old library version on your local system? > > Then the soname doesn't match, so it will DTRT anyway. If the soname > is the same, you'll only have the new library on the system, so the > cache can't be 'stale' there either in a way that gives you the wrong > library. Well, if you are moving the same SONAME to a different path (found earlier in ldconfig's search path) and adding new symbols at the same time, you can have issues. Say, package foobar used to have libfoobar.so.1 in /usr/lib64, a new version moves it to /lib64 because barbaz program needs it before /usr is mounted. If it adds a new symbol foo to that library at the same time and /bin/bar program which is run during %post needs it, you loose without ldconfig run. Jakub From notting at redhat.com Wed Jun 27 15:04:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 11:04:23 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: <20070627145533.GD7012@devserv.devel.redhat.com> References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143021.GA25715@nostromo.devel.redhat.com> <604aa7910706270741y2e5f81f6g216bcd85185eac0a@mail.gmail.com> <20070627144231.GD25715@nostromo.devel.redhat.com> <20070627145533.GD7012@devserv.devel.redhat.com> Message-ID: <20070627150423.GB26263@nostromo.devel.redhat.com> Jakub Jelinek (jakub at redhat.com) said: > Well, if you are moving the same SONAME to a different path (found earlier > in ldconfig's search path) and adding new symbols at the same time, you can > have issues. > Say, package foobar used to have libfoobar.so.1 in /usr/lib64, a new > version moves it to /lib64 because barbaz program needs it before /usr is > mounted. If it adds a new symbol foo to that library at the same time > and /bin/bar program which is run during %post needs it, you loose > without ldconfig run. This is the only case, though - correct? So this case could be handled with a trigger, or something similar. Bill From martin.sourada at seznam.cz Wed Jun 27 15:05:20 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 27 Jun 2007 17:05:20 +0200 Subject: XULRunner - will be or won't be? In-Reply-To: <4682756A.7000301@iinet.net.au> References: <1182953296.3253.33.camel@pc-notebook> <4682756A.7000301@iinet.net.au> Message-ID: <1182956721.3253.37.camel@pc-notebook> On Wed, 2007-06-27 at 16:34 +0200, David Timms wrote: > I think I noticed that more than one person had begun developing the > packages, and hence you should be able to find it in bugzilla {review > request} > > DaveT. > Well, I've found one [1]. The package was accepted, however it's targeted on OLPC-2 branch, while I was asking about Fedora 8... Any info? Thanks, Martin [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244374 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed Jun 27 15:05:54 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Jun 2007 17:05:54 +0200 Subject: portage vs yum In-Reply-To: <1182940222.4126.11.camel@defender> References: <1182940222.4126.11.camel@defender> Message-ID: <20070627150554.GB4394@free.fr> On Wed, Jun 27, 2007 at 08:30:22PM +1000, Michael Fleming wrote: > > Someone still has to maintain the port, and that would consume the same > amount of time and effort as maintaining an RPM as far as I can see it. > No win there.. In fact, it seems to me that the real main difference between sabayon (gentoo) and fedora is not the port system. One could imagine a port system for for fedora/rpm too, maybe this allready exists, something like: * get all the specfiles from a directory with specfiles * find out the build and runtime dependencies by parsing the spec files and construct a tree of needed build * use spectool -g on the spec file, or get it from a lookaside cache * rpmbuild -ba In my opinion the real difference regarding packaging is that the gentoo ebuilds are much simpler than the specfiles because: * there is no package split in gentoo * gento follows upstream even more closely than fedora, there is no real integration The result is that it is certainly much easier to write ebuilds, that certainly explains for a part why there are more packages. The number of packagers and the time they dedicate to building packages would be the other parameter. These are numbers that is not easily found. Regarding the number of packages, it seems to me that gentoo and debian or ubuntu have more packages than Fedora. But Fedora was really opened only recently to the community, and the number of packages is growing steadily, so it is possible that one day Fedora collection grows to the gentoo or debian/ubuntu level. One advantage of Fedora over gentoo or debian is that there are paid redhat people for the maintainance of the most difficult and moving packages, like firefox, gcc, kernel, glibc, and so on.... -- Pat From caillon at redhat.com Wed Jun 27 15:10:03 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jun 2007 11:10:03 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <1182953296.3253.33.camel@pc-notebook> References: <1182953296.3253.33.camel@pc-notebook> Message-ID: <46827DCB.2010009@redhat.com> Martin Sourada wrote: > 1. How's the work on xulrunner going (if there is someone who works on > it)? Good. > 2. Is it targeted on F8 or not? Yes. > 3. Why is it not mentioned on wiki[1]? Shrug. From jos at xos.nl Wed Jun 27 15:18:01 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 27 Jun 2007 17:18:01 +0200 Subject: portage vs yum In-Reply-To: <20070627150554.GB4394@free.fr>; from pertusus@free.fr on Wed, Jun 27, 2007 at 05:05:54PM +0200 References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> Message-ID: <20070627171801.A2821@xos037.xos.nl> On Wed, Jun 27, 2007 at 05:05:54PM +0200, Patrice Dumas wrote: > * find out the build and runtime dependencies by parsing the spec files > and construct a tree of needed build Run-time dependencies are mostly calculated and can't be extracted from the spec files. > * gento follows upstream even more closely than fedora, there is no > real integration Is this an advantage? ;-) A distro that does not integrate packages to make it consistent? That's how I read this, maybe you meant to say something different... > The result is that it is certainly much easier to write ebuilds, that > certainly explains for a part why there are more packages. The number > of packagers and the time they dedicate to building packages would be > the other parameter. These are numbers that is not easily found. Quality is more important then quantity. > One advantage of Fedora over gentoo or debian is that there are paid > redhat people for the maintainance of the most difficult and moving > packages, like firefox, gcc, kernel, glibc, and so on.... At least you discovered one advantage so far ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From rdieter at math.unl.edu Wed Jun 27 14:36:04 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Jun 2007 09:36:04 -0500 Subject: [RFC] change packaging around shared libraries, ldconfig References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143021.GA25715@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: >> Doesn't ldconfig also update ld.so.cache? If so, won't "bad things" >> happen if that cache is stale, like when/if 2 pkgs are installed in a >> transaction, and pkg #2 depends on shlibs from pkg #1? > > If the cache is stale, it will look in the directories for something that > doesn't exist in the cache. I'm trying to think of a way the cache could > point to the wrong *version* of the library, but nothing is coming to > mind. pkg #1 upgrade: old version includes libfoo.so.1, new version includes libfoo.so.2 pkg #2: scriptlet requires something from pkg #1, which uses libfoo.so.2 bang. ?? -- Rex From skvidal at linux.duke.edu Wed Jun 27 15:20:40 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 27 Jun 2007 11:20:40 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143021.GA25715@nostromo.devel.redhat.com> Message-ID: <1182957640.2852.5.camel@hodge> On Wed, 2007-06-27 at 09:36 -0500, Rex Dieter wrote: > Bill Nottingham wrote: > > > Rex Dieter (rdieter at math.unl.edu) said: > >> Doesn't ldconfig also update ld.so.cache? If so, won't "bad things" > >> happen if that cache is stale, like when/if 2 pkgs are installed in a > >> transaction, and pkg #2 depends on shlibs from pkg #1? > > > > If the cache is stale, it will look in the directories for something that > > doesn't exist in the cache. I'm trying to think of a way the cache could > > point to the wrong *version* of the library, but nothing is coming to > > mind. > > pkg #1 upgrade: old version includes libfoo.so.1, new version includes > libfoo.so.2 > pkg #2: scriptlet requires something from pkg #1, which uses libfoo.so.2 > bang. how would that break? an update is an install then an erase. so we install libfoo which drops in libfoo.so.2 and the symlinks it needs If the scriptlets have a special preun req then they need to have it listed. -sv From lxtnow at gmail.com Wed Jun 27 15:23:29 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Wed, 27 Jun 2007 11:23:29 -0400 Subject: Glade3 [was: glade3 in fedora 7] Message-ID: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> Well, Glade3 has been packaged for fedora 7 (for now) with some improvment and fix. Before request a review for this package, i need to make some additionnal test. I think that there were some question about the both work of glade2 and glade3 together (tell if i'm wrong) currently, the both isntalled work well. If someone if interessting to test it also, i'll glad to point it where he can get it. Cheers, -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at redhat.com Wed Jun 27 15:25:41 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 27 Jun 2007 11:25:41 -0400 Subject: [RFC] change packaging around shared libraries, ldconfig In-Reply-To: References: <20070627134313.GE23234@nostromo.devel.redhat.com> <20070627143021.GA25715@nostromo.devel.redhat.com> Message-ID: <20070627152541.GE7012@devserv.devel.redhat.com> On Wed, Jun 27, 2007 at 09:36:04AM -0500, Rex Dieter wrote: > > Rex Dieter (rdieter at math.unl.edu) said: > >> Doesn't ldconfig also update ld.so.cache? If so, won't "bad things" > >> happen if that cache is stale, like when/if 2 pkgs are installed in a > >> transaction, and pkg #2 depends on shlibs from pkg #1? > > > > If the cache is stale, it will look in the directories for something that > > doesn't exist in the cache. I'm trying to think of a way the cache could > > point to the wrong *version* of the library, but nothing is coming to > > mind. > > pkg #1 upgrade: old version includes libfoo.so.1, new version includes > libfoo.so.2 > pkg #2: scriptlet requires something from pkg #1, which uses libfoo.so.2 > bang. Only if libfoo.so.2 is in some non-standard path. If it is in {,/usr}/lib{,64}, then when it won't be found in ld.so.cache, it will be searched in the standard paths. Jakub From pemboa at gmail.com Wed Jun 27 15:34:08 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 27 Jun 2007 10:34:08 -0500 Subject: Glade3 [was: glade3 in fedora 7] In-Reply-To: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> References: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> Message-ID: <16de708d0706270834j461f9b04y1708d8c237ed975a@mail.gmail.com> On 6/27/07, SmootherFrOgZ wrote: > Well, > Glade3 has been packaged for fedora 7 (for now) with some improvment and > fix. > Before request a review for this package, i need to make some additionnal > test. > > I think that there were some question about the both work of glade2 and > glade3 together (tell if i'm wrong) > currently, the both isntalled work well. > > If someone if interesting to test it also, i'll glad to point it where he > can get it. > > > Cheers, > Please link me, I tried Glade3 on Windows, don't really want to go back to Glade2 on Fedora. Thanks. > -- > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora/EPEL Contributor | > http://fedoraproject.org/wiki/XavierLamien > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Fedora Core 6 and proud From kevin.kofler at chello.at Wed Jun 27 15:07:25 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 Jun 2007 15:07:25 +0000 (UTC) Subject: portage vs yum References: Message-ID: Thufir gmail.com> writes: > The drawback to fedora is, to my mind, rpm and yum. portage is > superior. it's also capable, as sabayon has demonstrated, of > distributing binaries. Portage: * parasites upstream projects for tarball downloads by default. Aside from the security concerns which have been raised elsewhere in this thread, this also: - steals bandwidth from upstream projects, - makes the user dependent on the upstream project's server being up (for every single upstream project) and still carrying the file they want (which isn't always the case, many upstream projects delete old versions, they don't have infinite webspace nor do they want people to download old buggy versions). So this really doesn't scale. It also doesn't comply with the GPL when distributing binaries. SRPMs carry the full source code. * rebuilds everything on the user's machine, so users can get completely different binaries depending on what version of GCC and glibc they happen to have installed when they build it, or even depending on what libraries are autodetected by the configure scripts. Some see this as a feature, but it makes handling bug reports a nightmare. * has only limited support for uninstalling. The biggest problem is that there's no reverse-dependency tracking, you can unmerge a library and it will not know there are still programs depending on it which will be broken by the unmerge. This can be particularly bad on upgrades: when you upgrade a library to an incompatible version (new soname), it will just do it even when there are still packages depending on the old version, breaking those packages. And no, rebuilding everything (i.e. emerge remerge world) isn't really an efficient solution to this problem. Other source-based packaging systems, e.g. *BSD ports, share the same weaknesses. RPMs do allow you to build from source, that's what specfiles and SRPMs are for. Writing your own specfile is not fundamentally different from writing your own portage recipe. Or you can always build from source into /usr/local; unpackaged packages (i.e. packages without a specfile or portage recipe) are also handled essentially the same way in both worlds. Kevin Kofler From sundaram at fedoraproject.org Wed Jun 27 16:07:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 21:37:23 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <46827DCB.2010009@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> Message-ID: <46828B3B.2070408@fedoraproject.org> Christopher Aillon wrote: > Martin Sourada wrote: >> 1. How's the work on xulrunner going (if there is someone who works on >> it)? > > Good. > >> 2. Is it targeted on F8 or not? > > Yes. > >> 3. Why is it not mentioned on wiki[1]? > > Shrug. It would be better to write down the details in the wiki rather than shrugging it off. We would like to depend on it for the release notes for example rather than trying to parse change logs to get the important changes from thousands of packages as being done currently. Rahul From jeevanullas at gmail.com Wed Jun 27 16:01:45 2007 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Wed, 27 Jun 2007 21:31:45 +0530 Subject: Glade3 [was: glade3 in fedora 7] In-Reply-To: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> References: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> Message-ID: <1182960105.4005.0.camel@localhost.localdomain> I would like to test Glade3 on Fedora7. Can you provide me with a link for the RPM's. Thanks in advance. On Wed, 2007-06-27 at 11:23 -0400, SmootherFrOgZ wrote: > Well, > Glade3 has been packaged for fedora 7 (for now) with some improvment > and fix. > Before request a review for this package, i need to make some > additionnal test. > > I think that there were some question about the both work of glade2 > and glade3 together (tell if i'm wrong) > currently, the both isntalled work well. > > If someone if interessting to test it also, i'll glad to point it > where he can get it. > > > Cheers, > > -- > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora/EPEL Contributor | > http://fedoraproject.org/wiki/XavierLamien > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- http://freeshells.ch/~source/ From caillon at redhat.com Wed Jun 27 16:07:48 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jun 2007 12:07:48 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <46828B3B.2070408@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> Message-ID: <46828B54.804@redhat.com> Rahul Sundaram wrote: > Christopher Aillon wrote: >> Martin Sourada wrote: >>> 1. How's the work on xulrunner going (if there is someone who works on >>> it)? >> >> Good. >> >>> 2. Is it targeted on F8 or not? >> >> Yes. >> >>> 3. Why is it not mentioned on wiki[1]? >> >> Shrug. > > It would be better to write down the details in the wiki rather than > shrugging it off. We would like to depend on it for the release notes > for example rather than trying to parse change logs to get the important > changes from thousands of packages as being done currently. I was not aware that in writing things down on the wiki was a requisite for work to get done... And for your information, I have been a contributor to the past 3 or so release notes adding the important changes that I have done to the notes. I don't blame you for failing to notice. From bpepple at fedoraproject.org Wed Jun 27 16:26:07 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 27 Jun 2007 12:26:07 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting Message-ID: <1182961567.6652.7.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00790.html /topic FESCO-Meeting -- MISC -- Feature Polict Draft - http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft /topic FESCO-Meeting -- MISC -- Opening FESCo election vote to more people - http://fedoraproject.org/wiki/KarstenWade/FranchisementGrantProposals /topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-meeting -- Statically link libuu (uulib-static) into klibido -- tibbs -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed Jun 27 16:25:48 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Jun 2007 18:25:48 +0200 Subject: portage vs yum In-Reply-To: <20070627171801.A2821@xos037.xos.nl> References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> <20070627171801.A2821@xos037.xos.nl> Message-ID: <20070627162548.GE4394@free.fr> On Wed, Jun 27, 2007 at 05:18:01PM +0200, Jos Vos wrote: > On Wed, Jun 27, 2007 at 05:05:54PM +0200, Patrice Dumas wrote: > > > * find out the build and runtime dependencies by parsing the spec files > > and construct a tree of needed build > > Run-time dependencies are mostly calculated and can't be extracted > from the spec files. Indeed, I was wrong. As soon as a source package needs a build time dependency that has run time dependency this doesn't work anymore. Of course there would still be a minimal build root in any case since there are build time dependencies between bash, make, gcc, coreutils that are unworkable, even with run-time rpm dependencies. I am wondering whether it would work if runtime requirements of just built packages are also considered. > > * gento follows upstream even more closely than fedora, there is no > > real integration > > Is this an advantage? ;-) A distro that does not integrate packages > to make it consistent? That's how I read this, maybe you meant to > say something different... I am not saying that it is good or bad, I am stating a fact. > > One advantage of Fedora over gentoo or debian is that there are paid > > redhat people for the maintainance of the most difficult and moving > > packages, like firefox, gcc, kernel, glibc, and so on.... > > At least you discovered one advantage so far ;-). In all my mail I didn't tried to weight fedora against gentoo, I tried to disambiguate what the real differences are. If you really want to know, I personnally prefer fedora, that's why I participate in fedora, and there are many reasons for that that are not about package availability, ease to write a package nor package integration. Still for some uses gentoo is nice, not for mine and maybe the gentoo community is nice, but I like the Fedora (with redhat) community. -- Pat From sundaram at fedoraproject.org Wed Jun 27 16:35:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 22:05:03 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <46828B54.804@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> Message-ID: <468291B7.4030405@fedoraproject.org> Christopher Aillon wrote: > I was not aware that in writing things down on the wiki was a requisite > for work to get done... This is sort of a anticipated response but writing things down on the wiki *is part* of getting the work done. See http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft And for your information, I have been a > contributor to the past 3 or so release notes adding the important > changes that I have done to the notes. I don't blame you for failing to > notice. Umm, I did notice since I watch wiki edits which is why I suggested it as a factor but there are other good reasons to use the wiki to describe any major features. It would be helpful to know clearly the feature list for Fedora 8 for Fedora ambassadors. IMO the effect of transparency alone makes it worth the effort. Rahul From caillon at redhat.com Wed Jun 27 16:38:45 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jun 2007 12:38:45 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <468291B7.4030405@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> Message-ID: <46829295.8000309@redhat.com> Rahul Sundaram wrote: > Christopher Aillon wrote: > >> I was not aware that in writing things down on the wiki was a >> requisite for work to get done... > > This is sort of a anticipated response but writing things down on the > wiki *is part* of getting the work done. See > > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft Thankfully, that's still a draft, or I'd have to edit the wiki page that I was about to send you a reply... :-) From sundaram at fedoraproject.org Wed Jun 27 16:54:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 22:24:23 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <46829295.8000309@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> Message-ID: <4682963F.1030301@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Christopher Aillon wrote: >> >>> I was not aware that in writing things down on the wiki was a >>> requisite for work to get done... >> >> This is sort of a anticipated response but writing things down on the >> wiki *is part* of getting the work done. See >> >> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > Thankfully, that's still a draft, or I'd have to edit the wiki page that > I was about to send you a reply... :-) It is waiting on FESCo ratification on the meeting tomorrow. Rahul From mclasen at redhat.com Wed Jun 27 16:48:44 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 27 Jun 2007 12:48:44 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <4682963F.1030301@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> Message-ID: <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> On Wed, 2007-06-27 at 22:24 +0530, Rahul Sundaram wrote: > Christopher Aillon wrote: > > Rahul Sundaram wrote: > >> Christopher Aillon wrote: > >> > >>> I was not aware that in writing things down on the wiki was a > >>> requisite for work to get done... > >> > >> This is sort of a anticipated response but writing things down on the > >> wiki *is part* of getting the work done. See > >> > >> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > > > Thankfully, that's still a draft, or I'd have to edit the wiki page that > > I was about to send you a reply... :-) > > It is waiting on FESCo ratification on the meeting tomorrow. It doesn't make much sense to ratify such policies without asking for feedback from the people who are subject to it first, if you ask me. From sundaram at fedoraproject.org Wed Jun 27 16:59:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 22:29:56 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> Message-ID: <4682978C.2080205@fedoraproject.org> Matthias Clasen wrote: > On Wed, 2007-06-27 at 22:24 +0530, Rahul Sundaram wrote: >> Christopher Aillon wrote: >>> Rahul Sundaram wrote: >>>> Christopher Aillon wrote: >>>> >>>>> I was not aware that in writing things down on the wiki was a >>>>> requisite for work to get done... >>>> This is sort of a anticipated response but writing things down on the >>>> wiki *is part* of getting the work done. See >>>> >>>> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft >>> Thankfully, that's still a draft, or I'd have to edit the wiki page that >>> I was about to send you a reply... :-) >> It is waiting on FESCo ratification on the meeting tomorrow. > > It doesn't make much sense to ratify such policies without asking for > feedback from the people who are subject to it first, if you ask me. Feedback was asked right in this list. Check the archives. Rahul From mclasen at redhat.com Wed Jun 27 16:58:49 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 27 Jun 2007 12:58:49 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <4682978C.2080205@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> Message-ID: <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> On Wed, 2007-06-27 at 22:29 +0530, Rahul Sundaram wrote: > Matthias Clasen wrote: > > On Wed, 2007-06-27 at 22:24 +0530, Rahul Sundaram wrote: > >> Christopher Aillon wrote: > >>> Rahul Sundaram wrote: > >>>> Christopher Aillon wrote: > >>>> > >>>>> I was not aware that in writing things down on the wiki was a > >>>>> requisite for work to get done... > >>>> This is sort of a anticipated response but writing things down on the > >>>> wiki *is part* of getting the work done. See > >>>> > >>>> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > >>> Thankfully, that's still a draft, or I'd have to edit the wiki page that > >>> I was about to send you a reply... :-) > >> It is waiting on FESCo ratification on the meeting tomorrow. > > > > It doesn't make much sense to ratify such policies without asking for > > feedback from the people who are subject to it first, if you ask me. > > Feedback was asked right in this list. Check the archives. I see that John asked for feedback 2 days ago, I don't see a single reponse to that - do you really think that is sufficient discussion to ratify this tomorrow ?! From jwboyer at jdub.homelinux.org Wed Jun 27 17:11:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 12:11:45 -0500 Subject: XULRunner - will be or won't be? In-Reply-To: <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> Message-ID: <1182964305.25376.0.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-27 at 12:58 -0400, Matthias Clasen wrote: > On Wed, 2007-06-27 at 22:29 +0530, Rahul Sundaram wrote: > > Matthias Clasen wrote: > > > On Wed, 2007-06-27 at 22:24 +0530, Rahul Sundaram wrote: > > >> Christopher Aillon wrote: > > >>> Rahul Sundaram wrote: > > >>>> Christopher Aillon wrote: > > >>>> > > >>>>> I was not aware that in writing things down on the wiki was a > > >>>>> requisite for work to get done... > > >>>> This is sort of a anticipated response but writing things down on the > > >>>> wiki *is part* of getting the work done. See > > >>>> > > >>>> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > >>> Thankfully, that's still a draft, or I'd have to edit the wiki page that > > >>> I was about to send you a reply... :-) > > >> It is waiting on FESCo ratification on the meeting tomorrow. > > > > > > It doesn't make much sense to ratify such policies without asking for > > > feedback from the people who are subject to it first, if you ask me. > > > > Feedback was asked right in this list. Check the archives. > > I see that John asked for feedback 2 days ago, I don't see a single > reponse to that - do you really think that is sufficient discussion to > ratify this tomorrow ?! No. josh From sundaram at fedoraproject.org Wed Jun 27 17:17:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 22:47:00 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> Message-ID: <46829B8C.6080200@fedoraproject.org> Matthias Clasen wrote: > I see that John asked for feedback 2 days ago, I don't see a single > reponse to that - do you really think that is sufficient discussion to > ratify this tomorrow ?! John send the mail and the meeting agenda for FESCo has the item listed again which provides alteast two different opportunities for folks to provide any feedback necessary. I send feedback via the wiki as asked in the earlier mail. Policies and guidelines are living documents and can (or will) be updated based on feedback if there is any even after they are ratified. Additional discussions can happen at any point of time. I was merely pointing out that feedback was indeed asked. Rahul From caillon at redhat.com Wed Jun 27 17:25:10 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jun 2007 13:25:10 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <46829B8C.6080200@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> Message-ID: <46829D76.8060704@redhat.com> Rahul Sundaram wrote: > Matthias Clasen wrote: > >> I see that John asked for feedback 2 days ago, I don't see a single >> reponse to that - do you really think that is sufficient discussion to >> ratify this tomorrow ?! > > John send the mail and the meeting agenda for FESCo has the item listed > again which provides alteast two different opportunities for folks to > provide any feedback necessary. > > I send feedback via the wiki as asked in the earlier mail. Policies and > guidelines are living documents and can (or will) be updated based on > feedback if there is any even after they are ratified. Additional > discussions can happen at any point of time. I was merely pointing out > that feedback was indeed asked. That makes no sense. Are you seriously telling me that you ratify changes that may be sub-par with the intent that they can be changed? What is the point of voting then? Just let any old change through and fix it later. Sounds like you need to revise your ratification process (or lack thereof) before people should feel comfortable following anything that gets "voted" on. From jwboyer at jdub.homelinux.org Wed Jun 27 17:29:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 12:29:22 -0500 Subject: XULRunner - will be or won't be? In-Reply-To: <46829D76.8060704@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> Message-ID: <1182965362.25376.2.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-27 at 13:25 -0400, Christopher Aillon wrote: > Rahul Sundaram wrote: > > Matthias Clasen wrote: > > > >> I see that John asked for feedback 2 days ago, I don't see a single > >> reponse to that - do you really think that is sufficient discussion to > >> ratify this tomorrow ?! > > > > John send the mail and the meeting agenda for FESCo has the item listed > > again which provides alteast two different opportunities for folks to > > provide any feedback necessary. > > > > I send feedback via the wiki as asked in the earlier mail. Policies and > > guidelines are living documents and can (or will) be updated based on > > feedback if there is any even after they are ratified. Additional > > discussions can happen at any point of time. I was merely pointing out > > that feedback was indeed asked. > > That makes no sense. Are you seriously telling me that you ratify > changes that may be sub-par with the intent that they can be changed? > What is the point of voting then? Just let any old change through and > fix it later. No. > Sounds like you need to revise your ratification process (or lack > thereof) before people should feel comfortable following anything that > gets "voted" on. Rahul isn't on FESCo. And I agree this needs more discussion before being ratified. josh From ajackson at redhat.com Wed Jun 27 17:21:47 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 27 Jun 2007 13:21:47 -0400 Subject: Upgrade path question Message-ID: <1182964907.30663.402.camel@localhost.localdomain> The received wisdom seems to be "Only care about upgrades with stride <= 2", meaning, FC5 to F7 should work, but FC1 to F7 is madness. Is this written down anywhere, or just tribal knowledge? I ask because there's a fair bit of cruft in the X packages to handle things like Obsoletes: XFree86. We haven't shipped that since FC2, so it's hard to still care. I also don't know how closely this is tied to RHEL construction. So far, RHELs have been issued every other Fedora, so that might be the source of the "stride 2" idea. Maybe that won't be true in the future? Who knows. And if it isn't true, maybe that's just Red Hat's cross to bear. I don't see this in any of the packaging docs in a brief search, so if we could get this written down that'd be helpful. - ajax From jwboyer at jdub.homelinux.org Wed Jun 27 17:31:47 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 12:31:47 -0500 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182961567.6652.7.camel@kennedy> References: <1182961567.6652.7.camel@kennedy> Message-ID: <1182965507.25376.5.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft Please pull this one. It's only had two days of commenting on the list. Note, this isn't a comment on the draft itself. Just that I don't think sufficient time has passed for FESCo to really decide anything on it. josh From sundaram at fedoraproject.org Wed Jun 27 17:32:35 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 23:02:35 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <46829D76.8060704@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> Message-ID: <46829F33.3070701@fedoraproject.org> Christopher Aillon wrote: > That makes no sense. Are you seriously telling me that you ratify > changes that may be sub-par with the intent that they can be changed? No but policies can be ratified with the understanding that they are not written in stone. > Sounds like you need to revise your ratification process (or lack > thereof) before people should feel comfortable following anything that > gets "voted" on. That's a FESCo decision that I am not involved with. Rahul From sundaram at fedoraproject.org Wed Jun 27 17:37:31 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 23:07:31 +0530 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182965507.25376.5.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> Message-ID: <4682A05B.6020001@fedoraproject.org> Josh Boyer wrote: > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: >> /topic FESCO-Meeting -- MISC -- Feature Polict Draft - >> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > Please pull this one. It's only had two days of commenting on the list. Do you want to define how long you want to wait? Rahul From katzj at redhat.com Wed Jun 27 17:38:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Jun 2007 13:38:06 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182965507.25376.5.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> Message-ID: <1182965886.26681.13.camel@aglarond.local> On Wed, 2007-06-27 at 12:31 -0500, Josh Boyer wrote: > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > Please pull this one. It's only had two days of commenting on the list. > > Note, this isn't a comment on the draft itself. Just that I don't think > sufficient time has passed for FESCo to really decide anything on it. Doesn't mean it can't be discussed within FESCo... just because we discuss doesn't mean there has to be a decision tomorrow. Jeremy From ville.skytta at iki.fi Wed Jun 27 17:42:17 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Jun 2007 20:42:17 +0300 Subject: Upgrade path question In-Reply-To: <1182964907.30663.402.camel@localhost.localdomain> References: <1182964907.30663.402.camel@localhost.localdomain> Message-ID: <200706272042.17771.ville.skytta@iki.fi> On Wednesday 27 June 2007, Adam Jackson wrote: > The received wisdom seems to be "Only care about upgrades with stride <= > 2", meaning, FC5 to F7 should work, but FC1 to F7 is madness. Is this > written down anywhere, or just tribal knowledge? Maybe it's not the most obvious place for it, but the "Renaming/replacing existing packages" section of the naming guidelines does have some related info: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d From sundaram at fedoraproject.org Wed Jun 27 17:45:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Jun 2007 23:15:38 +0530 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182961567.6652.7.camel@kennedy> References: <1182961567.6652.7.camel@kennedy> Message-ID: <4682A242.7020806@fedoraproject.org> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- Any objection to this week's report from FPC at > https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00790.html > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > /topic FESCO-Meeting -- MISC -- Opening FESCo election vote to more > people - > http://fedoraproject.org/wiki/KarstenWade/FranchisementGrantProposals > > /topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-meeting -- Statically link libuu (uulib-static) into > klibido -- tibbs -- > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. I would like FESCo to look at making the changes necessary in enabling some form of live upgrades in Fedora. Does a package like this with maybe modifications to Anaconda to point to the next release directly instead of having to feed the URL's make sense? https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00308.html Rahul From caillon at redhat.com Wed Jun 27 17:46:23 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jun 2007 13:46:23 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <46829F33.3070701@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> Message-ID: <4682A26F.7070104@redhat.com> Rahul Sundaram wrote: > Christopher Aillon wrote: > >> That makes no sense. Are you seriously telling me that you ratify >> changes that may be sub-par with the intent that they can be changed? > > No but policies can be ratified with the understanding that they are not > written in stone. > >> Sounds like you need to revise your ratification process (or lack >> thereof) before people should feel comfortable following anything that >> gets "voted" on. > > That's a FESCo decision that I am not involved with. I wonder if I'm the only person that got the impression you were invovled with it based on your comments. Don't try to strongarm people into following _draft_ policies based on the fact that you personally _expect_ it to be ratified. From notting at redhat.com Wed Jun 27 17:51:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 13:51:23 -0400 Subject: Upgrade path question In-Reply-To: <1182964907.30663.402.camel@localhost.localdomain> References: <1182964907.30663.402.camel@localhost.localdomain> Message-ID: <20070627175123.GC29669@nostromo.devel.redhat.com> Adam Jackson (ajackson at redhat.com) said: > The received wisdom seems to be "Only care about upgrades with stride <= > 2", meaning, FC5 to F7 should work, but FC1 to F7 is madness. Is this > written down anywhere, or just tribal knowledge? > > I ask because there's a fair bit of cruft in the X packages to handle > things like Obsoletes: XFree86. We haven't shipped that since FC2, so > it's hard to still care. > > I also don't know how closely this is tied to RHEL construction. So > far, RHELs have been issued every other Fedora, so that might be the > source of the "stride 2" idea. Maybe that won't be true in the future? Technically, it's not quite true now. RHEL 3 =~ RHL9/FC1, RHEL 4 =~ FC 3, RHEL 5 =~ FC 6. Historically, we've supported upgrades from N-2 on the premise that that's what's reasonable to test and make sure works; moreover, with the slightly extended lifecycle, someone can be on a maintained FC5 installation when F7 is released. Anything other than that is gravy. There hasn't been specific policy about garbage collecting obsoletes, to the the best of my knowledge. Strawman would be if we're supporting N-2, to garbage collect after N-4? Bill From katzj at redhat.com Wed Jun 27 17:50:29 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Jun 2007 13:50:29 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <4682A242.7020806@fedoraproject.org> References: <1182961567.6652.7.camel@kennedy> <4682A242.7020806@fedoraproject.org> Message-ID: <1182966629.26681.17.camel@aglarond.local> On Wed, 2007-06-27 at 23:15 +0530, Rahul Sundaram wrote: > I would like FESCo to look at making the changes necessary in enabling > some form of live upgrades in Fedora. Does a package like this with > maybe modifications to Anaconda to point to the next release directly > instead of having to feed the URL's make sense? FESCo discussing it doesn't help. What needs to happen is that somebody needs to actually write the code. Which yes, will require anaconda changes and thus will require sending patches to anaconda-devel-list. Jeremy From jwboyer at jdub.homelinux.org Wed Jun 27 17:55:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 12:55:34 -0500 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182965886.26681.13.camel@aglarond.local> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <1182965886.26681.13.camel@aglarond.local> Message-ID: <1182966934.25376.8.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-27 at 13:38 -0400, Jeremy Katz wrote: > On Wed, 2007-06-27 at 12:31 -0500, Josh Boyer wrote: > > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > > > > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > > > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > > > Please pull this one. It's only had two days of commenting on the list. > > > > Note, this isn't a comment on the draft itself. Just that I don't think > > sufficient time has passed for FESCo to really decide anything on it. > > Doesn't mean it can't be discussed within FESCo... just because we > discuss doesn't mean there has to be a decision tomorrow. True. But we're consistently running long on meetings these days. I see no need to discuss it during the meeting when it's only been an RFC since Monday. If FESCo members really have much to say about it, they can respond to John's original thread, which has gotten exactly 0 feedback. josh From jwboyer at jdub.homelinux.org Wed Jun 27 17:57:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 12:57:54 -0500 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <4682A05B.6020001@fedoraproject.org> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <4682A05B.6020001@fedoraproject.org> Message-ID: <1182967074.25376.11.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-27 at 23:07 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > >> /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > >> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > > > Please pull this one. It's only had two days of commenting on the list. > > Do you want to define how long you want to wait? Yes. More than 2 days. josh From ajackson at redhat.com Wed Jun 27 17:55:07 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 27 Jun 2007 13:55:07 -0400 Subject: Upgrade path question In-Reply-To: <200706272042.17771.ville.skytta@iki.fi> References: <1182964907.30663.402.camel@localhost.localdomain> <200706272042.17771.ville.skytta@iki.fi> Message-ID: <1182966907.30663.409.camel@localhost.localdomain> On Wed, 2007-06-27 at 20:42 +0300, Ville Skytt? wrote: > On Wednesday 27 June 2007, Adam Jackson wrote: > > The received wisdom seems to be "Only care about upgrades with stride <= > > 2", meaning, FC5 to F7 should work, but FC1 to F7 is madness. Is this > > written down anywhere, or just tribal knowledge? > > Maybe it's not the most obvious place for it, but the "Renaming/replacing > existing packages" section of the naming guidelines does have some related > info: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d That does mention the stride-2 convention, but it's predicated on "if there is no standard naming for a package". - ajax From katzj at redhat.com Wed Jun 27 18:07:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Jun 2007 14:07:04 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182966934.25376.8.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <1182965886.26681.13.camel@aglarond.local> <1182966934.25376.8.camel@weaponx.rchland.ibm.com> Message-ID: <1182967624.26681.22.camel@aglarond.local> On Wed, 2007-06-27 at 12:55 -0500, Josh Boyer wrote: > On Wed, 2007-06-27 at 13:38 -0400, Jeremy Katz wrote: > > On Wed, 2007-06-27 at 12:31 -0500, Josh Boyer wrote: > > > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > > > > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > > > > > Please pull this one. It's only had two days of commenting on the list. > > > > > > Note, this isn't a comment on the draft itself. Just that I don't think > > > sufficient time has passed for FESCo to really decide anything on it. > > > > Doesn't mean it can't be discussed within FESCo... just because we > > discuss doesn't mean there has to be a decision tomorrow. > > True. But we're consistently running long on meetings these days. I > see no need to discuss it during the meeting when it's only been an RFC > since Monday. Large chunks of what we discuss has only come up within the space of the previous few days... > If FESCo members really have much to say about it, they can respond to > John's original thread, which has gotten exactly 0 feedback. Maybe the silence is due to agreement (not that I really think so, but still ;-) And this is exactly the sort of new things that we're saying are in FESCo's arena with the merge... so if we put off talking about it, then it further decreases the chances of having any sort of coherent idea of what's going on for Fedora 8. Jeremy From bpepple at fedoraproject.org Wed Jun 27 18:15:48 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 27 Jun 2007 14:15:48 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182966934.25376.8.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <1182965886.26681.13.camel@aglarond.local> <1182966934.25376.8.camel@weaponx.rchland.ibm.com> Message-ID: <1182968148.6652.19.camel@kennedy> On Wed, 2007-06-27 at 12:55 -0500, Josh Boyer wrote: > On Wed, 2007-06-27 at 13:38 -0400, Jeremy Katz wrote: > > > > Doesn't mean it can't be discussed within FESCo... just because we > > discuss doesn't mean there has to be a decision tomorrow. > > True. But we're consistently running long on meetings these days. I > see no need to discuss it during the meeting when it's only been an RFC > since Monday. That's not entirely accurate, since notting sent this item to the FESCo mailing list last Thursday. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wwoods at redhat.com Wed Jun 27 18:24:01 2007 From: wwoods at redhat.com (Will Woods) Date: Wed, 27 Jun 2007 14:24:01 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <46828B3B.2070408@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> Message-ID: <1182968641.5337.1.camel@metroid.rdu.redhat.com> On Wed, 2007-06-27 at 21:37 +0530, Rahul Sundaram wrote: > Christopher Aillon wrote: > > Martin Sourada wrote: > >> 1. How's the work on xulrunner going (if there is someone who works on > >> it)? > > > > Good. > > > >> 2. Is it targeted on F8 or not? > > > > Yes. > > > >> 3. Why is it not mentioned on wiki[1]? > > > > Shrug. > > It would be better to write down the details in the wiki rather than > shrugging it off. We would like to depend on it for the release notes > for example rather than trying to parse change logs to get the important > changes from thousands of packages as being done currently. If you've got time to chide the maintainer about it, you've got time to help the maintainer and write down the details in the wiki yourself. Just a thought. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Wed Jun 27 18:17:09 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 27 Jun 2007 14:17:09 -0400 Subject: Upgrade path question In-Reply-To: <20070627175123.GC29669@nostromo.devel.redhat.com> References: <1182964907.30663.402.camel@localhost.localdomain> <20070627175123.GC29669@nostromo.devel.redhat.com> Message-ID: <1182968229.30663.416.camel@localhost.localdomain> On Wed, 2007-06-27 at 13:51 -0400, Bill Nottingham wrote: > Adam Jackson (ajackson at redhat.com) said: > > The received wisdom seems to be "Only care about upgrades with stride <= > > 2", meaning, FC5 to F7 should work, but FC1 to F7 is madness. Is this > > written down anywhere, or just tribal knowledge? > > > > I ask because there's a fair bit of cruft in the X packages to handle > > things like Obsoletes: XFree86. We haven't shipped that since FC2, so > > it's hard to still care. > > > > I also don't know how closely this is tied to RHEL construction. So > > far, RHELs have been issued every other Fedora, so that might be the > > source of the "stride 2" idea. Maybe that won't be true in the future? > > Technically, it's not quite true now. RHEL 3 =~ RHL9/FC1, RHEL 4 =~ FC 3, > RHEL 5 =~ FC 6. > > Historically, we've supported upgrades from N-2 on the premise that that's > what's reasonable to test and make sure works; moreover, with the slightly > extended lifecycle, someone can be on a maintained FC5 installation when > F7 is released. Anything other than that is gravy. There hasn't been specific > policy about garbage collecting obsoletes, to the the best of my knowledge. > > Strawman would be if we're supporting N-2, to garbage collect after N-4? That sounds reasonable to me. Stride 4 would mean two years to learn a new name and/or upgrade, which seems plausible. Just to be sure we're interpreting this the same way: X was provided by xorg-x11 in FC-4, but modular packages in FC-5. My interpretation of N-4 would be that the Prov/Obs for xorg-x11 could then be removed in the rawhide cycle between F-8 and F-9. - ajax From bpepple at fedoraproject.org Wed Jun 27 17:49:48 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 27 Jun 2007 13:49:48 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> Message-ID: <1182966588.6652.12.camel@kennedy> On Wed, 2007-06-27 at 12:48 -0400, Matthias Clasen wrote: > On Wed, 2007-06-27 at 22:24 +0530, Rahul Sundaram wrote: > > Christopher Aillon wrote: > > > Rahul Sundaram wrote: > > >> Christopher Aillon wrote: > > >> > > >>> I was not aware that in writing things down on the wiki was a > > >>> requisite for work to get done... > > >> > > >> This is sort of a anticipated response but writing things down on the > > >> wiki *is part* of getting the work done. See > > >> > > >> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > > > > > Thankfully, that's still a draft, or I'd have to edit the wiki page that > > > I was about to send you a reply... :-) > > > > It is waiting on FESCo ratification on the meeting tomorrow. > > It doesn't make much sense to ratify such policies without asking for > feedback from the people who are subject to it first, if you ask me. I believe John did send this proposal to the lists for feedback. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Wed Jun 27 17:54:06 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 27 Jun 2007 13:54:06 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182965507.25376.5.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> Message-ID: <1182966846.6652.15.camel@kennedy> On Wed, 2007-06-27 at 12:31 -0500, Josh Boyer wrote: > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > Please pull this one. It's only had two days of commenting on the list. > > Note, this isn't a comment on the draft itself. Just that I don't think > sufficient time has passed for FESCo to really decide anything on it. I think we should keep it on the schedule for now to discuss it. It doesn't mean that we have to ratify it tomorrow. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Jun 27 18:42:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 14:42:09 -0400 Subject: Upgrade path question In-Reply-To: <1182968229.30663.416.camel@localhost.localdomain> References: <1182964907.30663.402.camel@localhost.localdomain> <20070627175123.GC29669@nostromo.devel.redhat.com> <1182968229.30663.416.camel@localhost.localdomain> Message-ID: <20070627184209.GA30383@nostromo.devel.redhat.com> Adam Jackson (ajackson at redhat.com) said: > > Strawman would be if we're supporting N-2, to garbage collect after N-4? > > That sounds reasonable to me. Stride 4 would mean two years to learn a > new name and/or upgrade, which seems plausible. > > Just to be sure we're interpreting this the same way: X was provided by > xorg-x11 in FC-4, but modular packages in FC-5. My interpretation of > N-4 would be that the Prov/Obs for xorg-x11 could then be removed in the > rawhide cycle between F-8 and F-9. My interpretationg would be *after* F-9. I suppose that means I should write something and send it to the PC. Bill From jwboyer at jdub.homelinux.org Wed Jun 27 19:04:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 14:04:20 -0500 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182968148.6652.19.camel@kennedy> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <1182965886.26681.13.camel@aglarond.local> <1182966934.25376.8.camel@weaponx.rchland.ibm.com> <1182968148.6652.19.camel@kennedy> Message-ID: <1182971060.25376.23.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-27 at 14:15 -0400, Brian Pepple wrote: > On Wed, 2007-06-27 at 12:55 -0500, Josh Boyer wrote: > > On Wed, 2007-06-27 at 13:38 -0400, Jeremy Katz wrote: > > > > > > Doesn't mean it can't be discussed within FESCo... just because we > > > discuss doesn't mean there has to be a decision tomorrow. > > > > True. But we're consistently running long on meetings these days. I > > see no need to discuss it during the meeting when it's only been an RFC > > since Monday. > > That's not entirely accurate, since notting sent this item to the FESCo > mailing list last Thursday. FESCo list isn't public. Community people can't comment on what they don't see. josh From jwboyer at jdub.homelinux.org Wed Jun 27 19:04:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 14:04:57 -0500 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182967624.26681.22.camel@aglarond.local> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <1182965886.26681.13.camel@aglarond.local> <1182966934.25376.8.camel@weaponx.rchland.ibm.com> <1182967624.26681.22.camel@aglarond.local> Message-ID: <1182971097.25376.24.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-27 at 14:07 -0400, Jeremy Katz wrote: > On Wed, 2007-06-27 at 12:55 -0500, Josh Boyer wrote: > > On Wed, 2007-06-27 at 13:38 -0400, Jeremy Katz wrote: > > > On Wed, 2007-06-27 at 12:31 -0500, Josh Boyer wrote: > > > > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > > > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > > > > > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > > > > > > > Please pull this one. It's only had two days of commenting on the list. > > > > > > > > Note, this isn't a comment on the draft itself. Just that I don't think > > > > sufficient time has passed for FESCo to really decide anything on it. > > > > > > Doesn't mean it can't be discussed within FESCo... just because we > > > discuss doesn't mean there has to be a decision tomorrow. > > > > True. But we're consistently running long on meetings these days. I > > see no need to discuss it during the meeting when it's only been an RFC > > since Monday. > > Large chunks of what we discuss has only come up within the space of the > previous few days... > > > If FESCo members really have much to say about it, they can respond to > > John's original thread, which has gotten exactly 0 feedback. > > Maybe the silence is due to agreement (not that I really think so, but > still ;-) And this is exactly the sort of new things that we're saying > are in FESCo's arena with the merge... so if we put off talking about > it, then it further decreases the chances of having any sort of coherent > idea of what's going on for Fedora 8. And we _have_ to talk about it in a meeting? What is wrong with email discussion on this list? Seriously, there are two possible outcomes of talking about this now during the meeting itself: 1) We banter back and forth a bit, and then defer it to later because there isn't enough discussion about it in the community yet or some changes need to be made. 2) We banter back and forth a bit and then vote on it, probably doing so too soon, and have to amend it based on feedback from the community. Suck josh From peter at thecodergeek.com Wed Jun 27 19:10:02 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 27 Jun 2007 12:10:02 -0700 (PDT) Subject: portage vs yum In-Reply-To: References: Message-ID: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Kevin Kofler wrote: > Portage: > * parasites upstream projects for tarball downloads by default. Aside from > the > security concerns which have been raised elsewhere in this thread, this also: > - steals bandwidth from upstream projects, > - makes the user dependent on the upstream project's server being up (for > every > single upstream project) and still carrying the file they want (which isn't > always the case, many upstream projects delete old versions, they don't have > infinite webspace nor do they want people to download old buggy versions). > So this really doesn't scale. It also doesn't comply with the GPL when > distributing binaries. SRPMs carry the full source code. Erm; No. Gentoo's portage mirrors have a "distfiles" directory that contains copies of all source tarballs for current versions of Portage packages. When one installs the package (via "emerge app-foo/bar" as root or similar), it attempts to download the tarball from this distfiles mirror. Only if it fails on multiple mirrors (or as is configured otherwise in /etc/make.conf) does it attempt to grab the sources from the upstream download location. > * has only limited support for uninstalling. The biggest problem is that > there's no reverse-dependency tracking, you can unmerge a library and it will > not know there are still programs depending on it which will be broken by the > unmerge. This can be particularly bad on upgrades: when you upgrade a library > to an incompatible version (new soname), it will just do it even when there > are > still packages depending on the old version, breaking those packages. And no, > rebuilding everything (i.e. emerge remerge world) isn't really an efficient > solution to this problem. > Not necessarily; Portage has a tool called "revdep-rebuild" which takes care of rebuilding any package which no longer has proper dynamic library linkage. > RPMs do allow you to build from source, that's what specfiles and SRPMs are > for. Writing your own specfile is not fundamentally different from writing > your own portage recipe. I concur with this. The first few RPM packages that I created were based quite heavily on Gentoo's ebuilds (not "recipes" - those are rPath/Conary) for them. I still use them from time to time to help track weird/unexpected dependencies. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From bpepple at fedoraproject.org Wed Jun 27 19:13:11 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 27 Jun 2007 15:13:11 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182971060.25376.23.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <1182965886.26681.13.camel@aglarond.local> <1182966934.25376.8.camel@weaponx.rchland.ibm.com> <1182968148.6652.19.camel@kennedy> <1182971060.25376.23.camel@weaponx.rchland.ibm.com> Message-ID: <1182971591.6652.22.camel@kennedy> On Wed, 2007-06-27 at 14:04 -0500, Josh Boyer wrote: > On Wed, 2007-06-27 at 14:15 -0400, Brian Pepple wrote: > > On Wed, 2007-06-27 at 12:55 -0500, Josh Boyer wrote: > > > On Wed, 2007-06-27 at 13:38 -0400, Jeremy Katz wrote: > > > > > > > > Doesn't mean it can't be discussed within FESCo... just because we > > > > discuss doesn't mean there has to be a decision tomorrow. > > > > > > True. But we're consistently running long on meetings these days. I > > > see no need to discuss it during the meeting when it's only been an RFC > > > since Monday. > > > > That's not entirely accurate, since notting sent this item to the FESCo > > mailing list last Thursday. > > FESCo list isn't public. Community people can't comment on what they > don't see. I'm aware of that. I was stating that FESCo members have almost had a week to look over that proposal, and we should be able to discuss it. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Wed Jun 27 19:16:36 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 27 Jun 2007 15:16:36 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182971097.25376.24.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <1182965886.26681.13.camel@aglarond.local> <1182966934.25376.8.camel@weaponx.rchland.ibm.com> <1182967624.26681.22.camel@aglarond.local> <1182971097.25376.24.camel@weaponx.rchland.ibm.com> Message-ID: <1182971796.6652.26.camel@kennedy> On Wed, 2007-06-27 at 14:04 -0500, Josh Boyer wrote: > On Wed, 2007-06-27 at 14:07 -0400, Jeremy Katz wrote: > > On Wed, 2007-06-27 at 12:55 -0500, Josh Boyer wrote: > > > On Wed, 2007-06-27 at 13:38 -0400, Jeremy Katz wrote: > > > > On Wed, 2007-06-27 at 12:31 -0500, Josh Boyer wrote: > > > > > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > > > > > /topic FESCO-Meeting -- MISC -- Feature Polict Draft - > > > > > > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > > > > > > > > > Please pull this one. It's only had two days of commenting on the list. > > > > > > > > > > Note, this isn't a comment on the draft itself. Just that I don't think > > > > > sufficient time has passed for FESCo to really decide anything on it. > > > > > > > > Doesn't mean it can't be discussed within FESCo... just because we > > > > discuss doesn't mean there has to be a decision tomorrow. > > > > > > True. But we're consistently running long on meetings these days. I > > > see no need to discuss it during the meeting when it's only been an RFC > > > since Monday. > > > > Large chunks of what we discuss has only come up within the space of the > > previous few days... > > > > > If FESCo members really have much to say about it, they can respond to > > > John's original thread, which has gotten exactly 0 feedback. > > > > Maybe the silence is due to agreement (not that I really think so, but > > still ;-) And this is exactly the sort of new things that we're saying > > are in FESCo's arena with the merge... so if we put off talking about > > it, then it further decreases the chances of having any sort of coherent > > idea of what's going on for Fedora 8. > > And we _have_ to talk about it in a meeting? What is wrong with email > discussion on this list? That people don't respond to them. Just go through the mailing lists, and look at how many threads where input is asked for, are never responded to. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Wed Jun 27 19:21:25 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 Jun 2007 19:21:25 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: Peter Gordon thecodergeek.com> writes: > Erm; No. Gentoo's portage mirrors have a "distfiles" directory that contains > copies of all source tarballs for current versions of Portage packages. When > one installs the package (via "emerge app-foo/bar" as root or similar), it > attempts to download the tarball from this distfiles mirror. Only if it fails > on multiple mirrors (or as is configured otherwise in /etc/make.conf) does > it attempt to grab the sources from the upstream download location. At least Gentoo tries to mirror the sources (still, why not fetch them _only_ from the distfiles mirrors?), other source-based distributions won't even bother doing that. > Not necessarily; Portage has a tool called "revdep-rebuild" which takes care > of rebuilding any package which no longer has proper dynamic library linkage. Oh, I didn't know about that tool. But why do you have to do that by hand? It should be automatic. Yum or apt won't update a library without also updating the applications which depend on it to versions built against the correct library. > I concur with this. The first few RPM packages that I created were based > quite heavily on Gentoo's ebuilds (not "recipes" - those are rPath/Conary) I don't know why I couldn't remember the specific term, I knew it of course. :-) But ebuilds, specfiles etc. are all "recipes". ;-) Kevin Kofler From peter at thecodergeek.com Wed Jun 27 19:29:40 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 27 Jun 2007 12:29:40 -0700 (PDT) Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: <47062.65.223.36.19.1182972580.squirrel@webmail.thecodergeek.com> Kevin Kofler wrote: > Oh, I didn't know about that tool. But why do you have to do that by hand? It > should be automatic. Yum or apt won't update a library without also updating > the applications which depend on it to versions built against the correct > library. IIRC, whereas Yum and other binary-based systems such as APT track literal libraries (e.g., "libfoo.so.42(ABI_TAG)"), Portage only tracks per-package dependencies; so when you update one package it still notes that you have the dependent package installed. (I'm not too familiar with Portage internals though; so I could very well be completely pulling this out of my butt. ^_^) > I don't know why I couldn't remember the specific term, I knew it of > course. :-) But ebuilds, specfiles etc. are all "recipes". ;-) Technicalities of word choice - nothing more. :) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From lightsolphoenix at gmail.com Wed Jun 27 19:37:20 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 27 Jun 2007 15:37:20 -0400 Subject: portage vs yum In-Reply-To: References: Message-ID: <200706271537.20977.lightsolphoenix@gmail.com> On Wednesday, June 27, 2007 2:14 am Thufir wrote: > > The drawback to fedora is, to my mind, rpm and yum. portage is > superior. it's also capable, as sabayon has demonstrated, of > distributing binaries. Portage, superior? Um, no. I ran Sabayon once. Couldn't update the base system to the latest versions of the programs because the system had almost no dependency resolution at all, and I actually had to manually update each package, one at a time, to get it to update properly. If I just tried updating like in Fedora, the system would die after the first three or four packages, reporting a missing dependency the system seemed incapable of doing itself. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From kevin.kofler at chello.at Wed Jun 27 19:50:11 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 Jun 2007 19:50:11 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <47062.65.223.36.19.1182972580.squirrel@webmail.thecodergeek.com> Message-ID: Peter Gordon thecodergeek.com> writes: > IIRC, whereas Yum and other binary-based systems such as APT track literal > libraries (e.g., "libfoo.so.42(ABI_TAG)"), That's how RPM does it (and yum and apt-rpm then compute dependencies based on that information), yes. DPKG doesn't support that, so Debian's solution is to just call the package providing libfoo.so.42 libfoo42, so when libfoo.so.43 comes out, the packages will require libfoo43 and apt will know that libfoo42 is insufficient. Kevin Kofler From caillon at redhat.com Wed Jun 27 20:41:43 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jun 2007 16:41:43 -0400 Subject: Fedora Features Process In-Reply-To: <467FFE30.6090307@redhat.com> References: <467FFE30.6090307@redhat.com> Message-ID: <4682CB87.8040005@redhat.com> John Poelstra wrote: > Based on > https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.html > > > I have drafted a proposed Feature process. I submitted it to the Fedora > Board for a first pass via the wiki page (see inline comments). Now I > am submitting it for additional public review and would like to have it > discussed and ratified at the next FESCo meeting. We need a much better definition of what a feature is. For one, features don't delay the release. For another, things noteworthy enough to call out in the release notes is extremely vague. What I might find noteworthy, others might scoff at. Or vice versa. Further reading the "Definition of a Feature" section, it appears to me that we're trying to answer the question of "Will feature X be in Fedora Y?" This seems to me to be a broken question by design. We are on date-driven release cycles, not feature-driven. Work slips. It happens. Engineering priorities may shift, personal emergencies may occur, the person working on it in his free time may have less free time than anticipated, maybe someone is busy fixing bugs from the previous release. Who knows? There are many reasons why we can't answer this question as long as we are on a date-driven cycle. (After the feature freeze, we can though). The engineering cycle is rather short as it is with the freezes. Rather than take time away from engineering the features that we want to get in, why not simply defer gathering this info until after the feature freeze as we do now? The information gathered will be much more accurate than basing our information off volatile plans during a hard date-driven cycle. From hawat.thufir at gmail.com Wed Jun 27 21:10:57 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 27 Jun 2007 21:10:57 +0000 (UTC) Subject: portage vs yum References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> Message-ID: On Wed, 27 Jun 2007 17:05:54 +0200, Patrice Dumas wrote: > In my opinion the real difference regarding packaging is that the gentoo > ebuilds are much simpler than the specfiles because: > > * there is no package split in gentoo * gento follows upstream even more > closely than fedora, there is no > real integration > > The result is that it is certainly much easier to write ebuilds, that > certainly explains for a part why there are more packages. The number of > packagers and the time they dedicate to building packages would be the > other parameter. These are numbers that is not easily found. Thanks for all the responses, they're quite informative :) Bottom line is that I'd like to see a system which has more packages for the reasons described above. In my experience with portage, I could remove packages easily (although I don't know what actually happened behind the scenes). I'd like to see Fedora consider some form of portage because that would, hopefully, increase the number of packages. All other things being equal, ebuilds are, apparently, easier to write. -Thufir From pertusus at free.fr Wed Jun 27 21:14:47 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Jun 2007 23:14:47 +0200 Subject: portage vs yum In-Reply-To: References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> Message-ID: <20070627211447.GB8013@free.fr> On Wed, Jun 27, 2007 at 09:10:57PM +0000, Thufir wrote: > > I'd like to see Fedora consider some form of portage because that would, There is already something along that, recompiling the srpm with rpmbuild --rebuild, for example. > hopefully, increase the number of packages. All other things being > equal, ebuilds are, apparently, easier to write. No, they aren't. It could be argued that spec file and ebuilds are easier to write than the corresponding debian files, but in my opinion spec files are not harder nor easier to write than ebuilds. What happens is that gentoo ebuilds are written with less care to integration than fedora specfiles, that whats make them easier to write in my opinion. -- Pat From Lam at Lam.pl Wed Jun 27 21:21:01 2007 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 27 Jun 2007 23:21:01 +0200 Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: <1182979261.4523.5.camel@pensja.lam.pl> Dnia 27-06-2007, ?ro o godzinie 19:21 +0000, Kevin Kofler napisa?(a): > Yum or apt won't update a library without also updating > the applications which depend on it to versions built against the correct > library. Apt won't, but yum will without even notifying the user, it does that at least since F7 betas, when I started to use it for yum-presto (we're waiting for deltarpm support in apt). Fedora is one step closer to Gentoo now. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From hawat.thufir at gmail.com Wed Jun 27 21:21:11 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 27 Jun 2007 21:21:11 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: On Wed, 27 Jun 2007 12:10:02 -0700, Peter Gordon wrote: >> * has only limited support for uninstalling. The biggest problem is >> that there's no reverse-dependency tracking, you can unmerge a library >> and it will not know there are still programs depending on it which >> will be broken by the unmerge. This can be particularly bad on >> upgrades: when you upgrade a library to an incompatible version (new >> soname), it will just do it even when there are >> still packages depending on the old version, breaking those packages. >> And no, rebuilding everything (i.e. emerge remerge world) isn't really >> an efficient solution to this problem. >> >> > Not necessarily; Portage has a tool called "revdep-rebuild" which takes > care of rebuilding any package which no longer has proper dynamic > library linkage. If a portage type system can uninstall well, and I believe that to be the case, that seals it for me. The advantages of a portage type system are greater than those of a yum type system. Sabayon may have screwed things up, but a system which compiles most things from source in a portage type way, with a few exceptions which are time intensive, would be easier to maintain and thus larger. Open Office, the kernel, things like that could be prebuilt. I mean this really as food for thought for you guys. FC6 and Fedora 7 greatly improved in terms of the ease of use of yum. However, there's a FC6 yum repo and a Fedora 7 repo. Why? That seems like completely unnecessary duplication which wouldn't occur in a build-from-source package manager. As a user, I hesitate to upgrade because of the lag as third party repos slowly catch up to Fedora versions. Again, thank you for the lively discussion :) -Thufir From pertusus at free.fr Wed Jun 27 21:18:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Jun 2007 23:18:39 +0200 Subject: Upgrade path question In-Reply-To: <20070627175123.GC29669@nostromo.devel.redhat.com> References: <1182964907.30663.402.camel@localhost.localdomain> <20070627175123.GC29669@nostromo.devel.redhat.com> Message-ID: <20070627211839.GC8013@free.fr> On Wed, Jun 27, 2007 at 01:51:23PM -0400, Bill Nottingham wrote: > > Historically, we've supported upgrades from N-2 on the premise that that's > what's reasonable to test and make sure works; moreover, with the slightly > extended lifecycle, someone can be on a maintained FC5 installation when > F7 is released. Anything other than that is gravy. There hasn't been specific > policy about garbage collecting obsoletes, to the the best of my knowledge. > > Strawman would be if we're supporting N-2, to garbage collect after N-4? I think we should not say anything about garbage collecting obsoletes, and let the maintainer do whatever they prefer. We could add to the guidelines that one should support upgrading from N-2, though, this seems reasonable to me. -- Pat From galibert at pobox.com Wed Jun 27 21:43:04 2007 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 27 Jun 2007 23:43:04 +0200 Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: <20070627214303.GA7580@dspnet.fr.eu.org> On Wed, Jun 27, 2007 at 07:21:25PM +0000, Kevin Kofler wrote: > Peter Gordon thecodergeek.com> writes: > > Not necessarily; Portage has a tool called "revdep-rebuild" which takes care > > of rebuilding any package which no longer has proper dynamic library linkage. > > Oh, I didn't know about that tool. But why do you have to do that by hand? It > should be automatic. Yum or apt won't update a library without also updating > the applications which depend on it to versions built against the correct > library. Because you often do not want to do it immediatly after the specific update that changed the library. The main advantage of gentoo over fedora is the continuous upgrade path. You do not need to reinstall everything from scratch every 6 months just to keep up-to-date. The main disadvantage is the difficulty (read, near impossibility) of manipulating a source distribution on a lab scale. OG. From hawat.thufir at gmail.com Wed Jun 27 21:37:43 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 27 Jun 2007 21:37:43 +0000 (UTC) Subject: splix make fails Message-ID: I was posting this on the user list, and it was suggested to perhaps take the thread here. I'm trying to build the splix print driver for a Samsung ML-2510 laser printer. The samsung driver from the website seems to have installed correctly, but won't print. There's a "ml2510 (Default Printer) "/usr/lib/cups/backend/mfp failed"" at in CUPS, which appeared after installing the samsung driver. Here's where I'm at now: [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# cat /etc/fedora-release Fedora release 7 (Moonshine) [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# ll total 112 -rw-r--r-- 1 thufir thufir 47 2007-02-10 06:20 AUTHORS -rw-r--r-- 1 thufir thufir 1809 2007-02-10 06:20 ChangeLog -rw-r--r-- 1 thufir thufir 18009 2007-02-10 06:20 COPYING drwxr-xr-x 2 thufir thufir 4096 2007-02-10 06:20 include -rw-r--r-- 1 thufir thufir 1206 2007-02-10 06:20 INSTALL -rw-r--r-- 1 thufir thufir 735 2007-02-10 06:20 Makefile drwxr-xr-x 3 thufir thufir 4096 2007-02-10 06:20 ppd -rw-r--r-- 1 thufir thufir 18 2007-02-10 06:20 README drwxr-xr-x 2 thufir thufir 4096 2007-06-27 02:56 src -rw-r--r-- 1 thufir thufir 176 2007-02-10 06:20 THANKS -rw-r--r-- 1 thufir thufir 238 2007-02-10 06:20 TODO drwxr-xr-x 2 thufir thufir 4096 2007-02-10 06:20 tools [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# make make[1]: Entering directory `/home/thufir/Download/splix-1.0.1-1/src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/thufir/Download/splix-1.0.1-1/src' make[1]: Entering directory `/home/thufir/Download/splix-1.0.1-1/ppd' ppdpo -o po/fr.po samsung.drv make[1]: ppdpo: Command not found make[1]: *** [po/fr.po] Error 127 make[1]: Leaving directory `/home/thufir/Download/splix-1.0.1-1/ppd' make: *** [ppd] Error 2 [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# wc -l /usr/include/cups/ppd.h 409 /usr/include/cups/ppd.h [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# date Wed Jun 27 14:23:37 PDT 2007 [root at localhost splix-1.0.1-1]# thanks, Thufir From buildsys at redhat.com Wed Jun 27 21:44:25 2007 From: buildsys at redhat.com (Build System) Date: Wed, 27 Jun 2007 17:44:25 -0400 Subject: rawhide report: 20070627 changes Message-ID: <200706272144.l5RLiPtm030683@porkchop.devel.redhat.com> New package libcgi CGI easy as C New package mod_dnssd An Apache HTTPD module which adds Zeroconf support New package pygtksourceview Python bindings for gtksourceview New package stardict-dic Dictionaries for StarDict Removed package autorun Updated Packages: Pyrex-0:0.9.5.1a-1.fc8 ---------------------- * Tue Jun 26 2007 Matthew Barnes - 0:0.9.5.1a-1.fc8 - Update to 0.9.5.1a - Remove Pyrex-0.9.4-fix-indent.patch (fixed upstream). - Remove pyrex-python-2.5.patch (fixed upstream). * Wed Jan 03 2007 David Zeuthen - 0:0.9.4-4.fc8 - include a patch so Pyrex works with python 2.5 * Thu Dec 07 2006 Jeremy Katz - 0:0.9.4-2 - rebuild against python 2.5 agg-2.5-3.fc8 ------------- * Tue Jun 26 2007 Caolan McNamara - 2.5-3 - Resolves: rhbz#245650 -devel Require: freetype-devel * Mon Apr 23 2007 Caolan McNamara - 2.5-2 - Resolves: rhbz#237493 misapplied patch amarok-1.4.6-2.fc8 ------------------ * Wed Jun 27 2007 Aurelien Bompard 1.4.6-2 - add explicit Requires on kdelibs >= 3.5.7 to fix bug 245386 * Mon Jun 18 2007 Aurelien Bompard 1.4.6-1 - version 1.4.6 * Mon Feb 19 2007 Aurelien Bompard 1.4.5-4 - have the visualisation subpackage require libvisual-plugins (bug 229131) arts-8:1.5.7-4.fc8 ------------------ * Wed Jun 27 2007 Rex Dieter 6:1.5.7-4 - own %_includedir/kde (#245909) aspell-bg-50:0.50-16.fc8 ------------------------ * Wed Jun 27 2007 Ivana Varekova - 50:0.50-16 - Resolves: #245257 aspell-bg 50:0.50-15 kills bulgarian.kbd berusky-1.1-5.fc8 ----------------- * Tue Jun 26 2007 Martin Stransky 1.1-5 - added a menu entry and an icon cfengine-2.2.1-3.fc8 -------------------- * Tue Jun 26 2007 Jeff Sheltren 2.2.1-3 - Update hostrange patch * Mon Jun 25 2007 Jeff Sheltren 2.2.1-2 - Fix hostrange bug (patch from SVN r397) control-center-1:2.19.4-5.fc8 ----------------------------- * Wed Jun 27 2007 Matthias Clasen - 2.19.4-5 - Remove some questionable a11y menu items cups-1:1.2.11-2.fc8 ------------------- * Wed Jun 27 2007 Tim Waugh 1:1.2.11-2 - Fixed _cupsAdminSetServerSettings() sharing/shared handling (bug #238057). * Mon Jun 25 2007 Tim Waugh - Fixed permissions on classes.conf in the file manifest (bug #245748). dialog-1.1-1.20070604.fc8 ------------------------- * Wed Jun 27 2007 Harald Hoyer - 1.1-1.20070604.fc8 - dialog-1.1-20070604 * Wed Feb 28 2007 Harald Hoyer - 1.1-1.20070227svn.fc8 - version 1.1-20070227 - added devel subpackage - specfile fixes (bug#225693) - Resolves: rhbz#225693 * Wed Jan 17 2007 Harald Hoyer - 1.0.20060221-1 - version 1.0-20060221 eclipse-1:3.2.2-15.fc8 ---------------------- * Wed Jun 20 2007 Ben Konrath 3.2.2-15 - Add Java-1.7.profile to org.eclipse.osgi for IcedTea. * Thu May 17 2007 Ben Konrath 3.2.2-14 - BR/R tomcat5 >= 5.5.23. - Fix broken symlinks for tomcat5 5.5.23. * Tue May 15 2007 Ben Konrath 3.2.2-13 - Another bug fix for launch-addplatformtotildeeclipse.patch. - Add BR/B tomcat >= 5.5.20 instead of just = 5.5.20. - Resolves: #240025. emacs-22.1-1.fc8 ---------------- * Wed Jun 06 2007 Chip Coldwell - 22.1-1 - move alternatives install to posttrans scriptlet (Resolves: bz239745) - new release tarball from FSF (Resolves: bz245303) - new php-mode 1.2.0 * Wed May 23 2007 Chip Coldwell - 22.0.990-2 - revert all spec file changes since 22.0.95-1 (Resolves: bz239745) - new pretest tarball from FSF (Resolves: bz238234) - restore php-mode (Resolves: bz235941) * Mon May 21 2007 Chip Coldwell - 22.0.990-1 - new pretest tarball from FSF - removed Ulrich Drepper's patch to prevent mmapped pages during dumping removed BuildRequires: glibc >= 2.5.90-22 (bug traced to glibc Resolves: bz239344) - fix alternatives removal scriptlet (Resolves: bz239745) emacs-vm-8.0.0.453-2.fc8 ------------------------ * Tue Jun 26 2007 Jonathan G. Underwood - 8.0.0.453-1 - Ensure files in /usr/bin have exec bit set properly (BZ #245740) exim-4.67-1.fc8 --------------- * Wed Jun 27 2007 David Woodhouse 4.67-1 - Update to 4.67 - Add config example for using a smarthost, with SMTP AUTH. firestarter-1.0.3-16.fc8 ------------------------ * Tue Jun 26 2007 Damien Durand - 1.0.3-16 - Fix BR - Fix active connections status gcc-4.1.2-14 ------------ * Tue Jun 26 2007 Jakub Jelinek 4.1.2-14 - update from gcc-4_1-branch (-r125727:126008) - PRs inline-asm/32109, rtl-optimization/28011, target/32389 - gomp update from gcc-4_2-branch (-r125917:125918) - PR middle-end/32362 - on ppc{,64} when tuning for power6{,x}, try to put the base register as first operand in instructions to improve performance (Peter Bergner, #225425, PR middle-end/28690) - on ppc64 emit nop after a call and disallow sibling calls if the target function is not defined in the same object file (David Edelsohn, #245424) - gomp parallel sections fix and fix for checking whether combined parallel can be used (PR libgomp/32468) gdb-6.6-18.fc8 -------------- * Tue Jun 26 2007 Jan Kratochvil - 6.6-18 - Fix PPC software watchpoints active while stepping atomic instr. (BZ 237572). gdm-1:2.19.3-2.fc8 ------------------ * Wed Jun 27 2007 Matthias Clasen - 1:2.19.3-2 - Drop an unnecessary file dependency geda-docs-20070626-1.fc8 ------------------------ * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release geda-examples-20070626-1.fc8 ---------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release geda-gnetlist-20070626-1.fc8 ---------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel geda-gschem-20070626-1.fc8 -------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel geda-gsymcheck-20070626-1.fc8 ----------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel geda-symbols-20070626-1.fc8 --------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release geda-utils-20070626-1.fc8 ------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 gedit-1:2.19.1-1.fc8 -------------------- * Mon Jun 25 2007 Matthias Clasen - 1:2.19.1-1 - Update to 2.19.1 gmediaserver-0.12.0-10.fc8 -------------------------- * Tue Jun 26 2007 Karol Trzcionka - 0.12.0-10 - Change %pre section and add requires(pre) - Rebuild with new libupnp (v1.6.0) gnome-keyring-manager-2.18.0-2.fc8 ---------------------------------- * Wed Jun 27 2007 Matthias Clasen 2.18.0-2 - Clean up categories in desktop file gutenprint-5.0.1-1.fc8 ---------------------- * Tue Jun 26 2007 Tim Waugh 5.0.1-1 - 5.0.1. httpd-2.2.4-4.1.fc7 ------------------- * Tue Jun 26 2007 Joe Orton 2.2.4-4.1.fc7 - add security fixes for CVE-2007-1863, CVE-2007-3304, and CVE-2006-5752 (#244665) - add security fix for CVE-2007-1862 (#242606) krb5-1.6.1-8.fc8 ---------------- * Wed Jun 27 2007 Nalin Dahyabhai 1.6.1-8 - incorporate fixes for MITKRB5-SA-2007-004 and MITKRB5-SA-2007-005 * Mon Jun 25 2007 Nalin Dahyabhai 1.6.1-7 - reintroduce missing %postun for the non-split_workstation case * Mon Jun 25 2007 Nalin Dahyabhai 1.6.1-6 - rebuild ksensors-0.7.3-8.fc8 -------------------- * Tue Jun 26 2007 Ville Skytt?? - 0.7.3-8 - Update Debian patchset to -14 for additional fixes and translations; drop our hddtemp detection patch in favour of the one included in it. - Drop Application and X-Fedora categories from .desktop file, add GenericName. - Make autostart checkbox effective again (#242570). - Convert docs to UTF-8. ktechlab-0.3.69-2.20070626svn.fc8 --------------------------------- * Tue Jun 26 2007 Chitlesh Goorah - 0.3.69-2.20070626svn - dropped ktechlab-0.3-ppc-includes.patch (fix in upstream) * Tue Jun 26 2007 Chitlesh Goorah - 0.3.69-1.20070626svn - New svn snapshot * Sun Jun 17 2007 Chitlesh Goorah - 0.3.69-1.20070617svn - New svn snapshot less-406-10.fc8 --------------- * Tue Jun 26 2007 Ivana Varekova - 406-1 - update to 406 * Mon Jun 04 2007 Ivana Varekova - 394-10 - Resolves: #242077 remove "-" option from lesspipe.sh script * Tue Feb 20 2007 Ivana Varekova - 394-9 - change /etc/profile.d script's permissions libXfont-1.2.9-2.fc8 -------------------- * Tue Jun 26 2007 Kristian H??gsberg - 1.2.9-2 - Put in stop-gap patch to fix comparing links with no attributes. * Fri Jun 22 2007 Kristian H??gsberg - 1.2.9-1 - Pull 1.2.9 down to get the catalogue feature. * Fri Apr 06 2007 Adam Jackson 1.2.8-1 - libXfont 1.2.8. libgeda-20070626-1.fc8 ---------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - New upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-2 - dump release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release - dropped useless -doc package libselinux-2.0.23-1.fc8 ----------------------- * Tue Jun 26 2007 Dan Walsh - 2.0.23-1 - Fix semanage segfault on x86 platform libsemanage-2.0.3-4.fc8 ----------------------- * Tue Jun 26 2007 Dan Walsh - 2.0.3-4 - Rebuild to fix segfault on x86 platforms, swigify on each build libstroke-0.5.1-15.fc8 ---------------------- * Tue Jun 26 2007 Chitlesh Goorah - 0.5.1-15 - patch for multilib #241448 liferea-1.2.17-1.fc8 -------------------- * Sat Jun 16 2007 Brian Pepple - 1.2.17-1 - Update to 1.2.17. lightning-1.2-6.fc8 ------------------- * Tue Jun 26 2007 Jochen Schmitt 1.2-6 - Downgrade because compiling issues * Thu Jun 21 2007 Jochen Schmitt 1.2a-4 - Increase release number * Mon May 21 2007 Jochen Schmitt 1.2a-3 - Changing summary of the Package (#240230) man-pages-2.55-3.fc8 -------------------- * Tue Jun 26 2007 Ivana Varekova - 2.55-3 - remove ncsa_auth.8 ntfs-config-1.0-0.4.rc5.fc8 --------------------------- * Tue Jun 26 2007 Xavier Lamien - 1.0-0.4.rc5 - Udpated Release. openoffice.org-1:2.2.1-18.4.fc8 ------------------------------- * Tue Jun 26 2007 Caolan McNamara - 1:2.2.1-18.4 - require new hunspell-ar for arabic langpack - Resolves: rhbz#244656 overlapping glyphs in pdf export * Mon Jun 18 2007 Caolan McNamara - 1:2.2.1-18.3 - add ppc64 uno bridge (workspace.ppc64one.patch) - Resolves: rhbz#241875 get script detection right for range vs point in drawing objects ooo#72349 - Resolves: rhbz#242692 openoffice.org-2.2.1.oooXXXXX.xmloff.outofrange.patch - Resolves: rhbz#243305 missing xdg file for quickstart restart - Resolves: rhbz#243904 add openoffice.org-2.2.1.ooo78383.vcl.printxerror.patch - update stocmerge patch - add openoffice.org-2.2.1.ooo78392.sixtyfour.tools.patch - extend selinux patch for ppc64 and sparc * Fri Jun 15 2007 Caolan McNamara - 1:2.2.1-18.2 - ppc64 test pciutils-2.2.6-1.fc8 -------------------- * Wed Jun 27 2007 Harald Hoyer - 2.2.6-1 - version 2.2.6 - fixed URL in update-pciids.sh perl-CPANPLUS-0.80-1.fc8 ------------------------ * Tue Jun 26 2007 Steven Pritchard 0.80-1 - Update to 0.80. - BR Test::Harness, Test::More, and version when running tests. perl-Cairo-1.041-1.fc8 ---------------------- * Tue Jun 26 2007 Jose Pedro Oliveira - 1.041-1 - Update to 1.041. perl-Module-ScanDeps-0.75-1.fc8 ------------------------------- * Wed Jun 27 2007 Jose Pedro Oliveira - 0.75-1 - Update to 0.75. pydict-0.3.0-11.fc8 ------------------- * Wed Jun 27 2007 Hu Zheng - 0.3.0-11 - add encoding tag and fix desktop file. pyicq-t-0.8-4.a.fc8 ------------------- * Wed Jun 27 2007 Jeffrey C. Ollie - 0.8-4.a - Update to 0.8a reciteword-0.8.3-4.fc8 ---------------------- * Wed Jun 27 2007 Hu Zheng - 0.8.3-4 - Fix no .mo file problem. redhat-menus-8.9.10-5.fc8 ------------------------- * Wed Jun 27 2007 Matthias Clasen - 8.9.10-5 - Clean up use of categories in menu files * Tue Jun 26 2007 Ray Strode - 8.9.10-4 - hide screensavers from menus (bug 241058) rhythmbox-0.11.1-1.fc8 ---------------------- * Wed Jun 27 2007 - Bastien Nocera - 0.11.1-1 - Update to 0.11.1 - Drop obsolete patches - Work-around a possible buggy GStreamer plugin * Mon Jun 04 2007 - Bastien Nocera - 0.11.0-5 - Add patch to not ignore tags with trailing white spaces rpm-4.4.2.1-0.2.rc1 ------------------- * Tue Jun 26 2007 Panu Matilainen 4.4.2.1-0.2.rc1 - patch popt version to 1.10.2.1 for clean upgrade path - popt release follows main package release again * Mon Jun 25 2007 Panu Matilainen 4.4.2.1-0.1.rc1 - update to 4.4.2.1-rc1 - patch shuffle, most have been merged upstream - drop mono-scripts, it comes from upstream now - popt isn't upgrading here so it needs its own release * Tue Jun 19 2007 Panu Matilainen - 4.4.2-47 - spec / package (review) cleanups: - use find_lang instead of manually listing translations - remove useless rpm 3.x upgrade check from preinstall script - use Fedora recommended buildroot - don't include useless, ancient GPG keys - add rpm, db and file licenses to docs - use scriptlet dependency markers instead of PreReq - post scriptlet requires coreutils - main package doesn't require patch, rpm-build does - buildrequire doxygen once more to resurrect apidocs - remove useless/doubly packaged files from /usr/lib/rpm - fix bunch of file permissions samba-0:3.0.25b-2.fc8 --------------------- * Tue Jun 26 2007 Simo Sorce 3.0.25b-2.fc8 - update to 3.0.25b - better error codes for init scripts: #244823 - handle cases defined in #243766 scim-1.4.7-1.fc8 ---------------- * Wed Jun 27 2007 Jens Petersen - 1.4.7-1 - update to 1.4.7 release * Fri Jun 22 2007 Jens Petersen - 1.4.6-6 - make Cangjie3 the default input method for Hong Kong and disable Cangjie by default instead of Cangjie3 and Cangjie5 (Roy Chan, #245121) * Thu Jun 21 2007 Jens Petersen - 1.4.6-5 - add scim-lang-* meta packages to aid yum package group handling of scim core packages so they no longer need to be installed by default scim-pinyin-0.5.91-19.fc8 ------------------------- * Wed Jun 27 2007 Huang Peng - 0.5.91-19 - Drop line `Patch1: scim-pinyin-shuangpin.patch' in spec file. - Remove ChangeLog from rpm package. * Wed Jun 27 2007 Jens Petersen - remove the with_libstdc_preview macro selinux-policy-3.0.1-1.fc8 -------------------------- * Fri May 25 2007 Dan Walsh 3.0.1-1 - Remove ifdef strict policy from upstream * Fri May 18 2007 Dan Walsh 2.6.5-3 - Remove ifdef strict to allow user_u to login shadow-utils-2:4.0.18.1-16.fc8 ------------------------------ * Tue Jun 26 2007 Peter Vrabec 2:4.0.18.1-16 - fix "CAVEATS" section of groupadd man page (#245590) system-config-date-1.9.1-1.fc8 ------------------------------ * Wed Jun 27 2007 Nils Philippsen 1.9.1 - fix desktop file category (#245891) system-config-display-1.0.51-2.fc8 ---------------------------------- * Wed Jun 27 2007 Matthias Clasen 1.0.51-2 - Fix up categories in desktop file system-config-nfs-1.3.26-1.fc8 ------------------------------ * Wed Jun 27 2007 Nils Philippsen 1.3.26 - fix desktop file category (#245889) * Mon Apr 30 2007 Nils Philippsen - mark dummy dialog title as non-translatable, use xgettext directly on glade files instead of gladestrings file (#238409) system-config-samba-1.2.44-1.fc8 -------------------------------- * Wed Jun 27 2007 Nils Philippsen - 1.2.44 - use gtk.FileChooseDialog instead of gtk.FileSelection (#245916, patch by Adel Gadllah) * Wed Jun 27 2007 Nils Philippsen - 1.2.43 - fix desktop file category (#245890) system-config-services-0.9.9-1.fc8 ---------------------------------- * Wed Jun 27 2007 Nils Philippsen - 0.9.9 - fix desktop file category (#245891) system-config-users-1.2.59-1.fc8 -------------------------------- * Wed Jun 27 2007 Nils Philippsen - 1.2.59 - fix desktop file category (#245876) * Tue Jun 26 2007 Nils Philippsen - try not to barf if encountering inconsistencies between /etc/passwd, /etc/group, /etc/shadow and /etc/gshadow * Wed Jun 13 2007 Nils Philippsen - fix English language oddity tasks-0.9-1.fc8 --------------- * Tue Jun 26 2007 Dan Young - 0.9-1 - New upstream release udev-113-1.fc8 -------------- * Tue Jun 26 2007 Harald Hoyer - 113-1 - version 113 - added rule for SD cards in a TI FlashMedia slot (#217070) * Tue Jun 26 2007 Harald Hoyer - 106-4.1 - fixed modprobedebug option - removed snd-powermac from the default modules (#200585) ushare-0.9.10-3.fc8 ------------------- * Sat May 05 2007 Eric Tanguy - 0.9.10-3 - Rebuild for libupnp-1.6.0 vim-2:7.1.12-1.fc8 ------------------ * Wed Jun 27 2007 Karsten Hopp 7.1.12-1 - Patchlevel 12 * Mon Jun 04 2007 Karsten Hopp 7.1.2-1 - vim 7.1 - drop 240 patches * Tue May 22 2007 Karsten Hopp 7.0.235-1 - Don't wake up system with blinking gvim cursor: http://www.linuxpowertop.org/known.php xorg-x11-drv-mga-1.4.6.1-5.fc8 ------------------------------ * Wed Jun 27 2007 Adam Jackson 1.4.6.1-5 - Use %{?_smp_mflags}. xorg-x11-drv-nv-2.1.0-2.fc8 --------------------------- * Tue Jun 26 2007 Adam Jackson 2.1.0-2 - %doc for COPYING and README.G80. Broken deps for i386 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 geda-gattrib - 20070216-1.fc7.i386 requires libgeda.so.28 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) geda-gattrib - 20070216-1.fc7.x86_64 requires libgeda.so.28()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 geda-gattrib - 20070216-1.fc7.ppc requires libgeda.so.28 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) geda-gattrib - 20070216-1.fc7.ppc64 requires libgeda.so.28()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From chitlesh at fedoraproject.org Wed Jun 27 21:51:06 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 27 Jun 2007 23:51:06 +0200 Subject: rawhide report: 20070627 changes In-Reply-To: <200706272144.l5RLiPtm030683@porkchop.devel.redhat.com> References: <200706272144.l5RLiPtm030683@porkchop.devel.redhat.com> Message-ID: <13dbfe4f0706271451t1b0e36d0h30cab29f0a83dddf@mail.gmail.com> On 6/27/07, Build System wrote: > vim-2:7.1.12-1.fc8 > ------------------ > * Wed Jun 27 2007 Karsten Hopp 7.1.12-1 > - Patchlevel 12 > > * Mon Jun 04 2007 Karsten Hopp 7.1.2-1 > - vim 7.1 > - drop 240 patches Wow 240 patches ! From jos at xos.nl Wed Jun 27 21:59:30 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 27 Jun 2007 23:59:30 +0200 Subject: portage vs yum In-Reply-To: ; from hawat.thufir@gmail.com on Wed, Jun 27, 2007 at 09:21:11PM +0000 References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: <20070627235930.A7970@xos037.xos.nl> On Wed, Jun 27, 2007 at 09:21:11PM +0000, Thufir wrote: > If a portage type system can uninstall well, and I believe that to be the > case, that seals it for me. The advantages of a portage type system are > greater than those of a yum type system. I think I can't disagree more. > Sabayon may have screwed things up, but a system which compiles most > things from source in a portage type way, with a few exceptions which are > time intensive, would be easier to maintain and thus larger. Open > Office, the kernel, things like that could be prebuilt. Easier to maintain, for whom? The package/distro builders? Certainly not for an average end-user. Reading opinions like these, I have the impression that most people only think of individual, hacker-type users, not about, say, system administrators maintaining large networks of systems, having to support those systems (and users) easily, etc. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From galibert at pobox.com Wed Jun 27 22:01:38 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 28 Jun 2007 00:01:38 +0200 Subject: portage vs yum In-Reply-To: <20070627211447.GB8013@free.fr> References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> <20070627211447.GB8013@free.fr> Message-ID: <20070627220138.GB7580@dspnet.fr.eu.org> On Wed, Jun 27, 2007 at 11:14:47PM +0200, Patrice Dumas wrote: > What happens is that gentoo ebuilds are written with less care to > integration than fedora specfiles, that whats make them easier to > write in my opinion. Oh puh-leeze. "Fedora has less packages than Gentoo because the gentoo developers do a crappy job" is kindergarden-level justification. I use both gentoo and fedora on a regular basis and they're both integrated, only differently. How many packages are available is a function of: - infrastructure capability (a source distribution does not need a compile cluster) - developers responsiveness (reviewing, QA, ...) - apparent ease of adding new packages for new potential contributors If you want more packages in Fedora (which is not a given), act on these points and especially the last two. OG. From skvidal at linux.duke.edu Wed Jun 27 21:30:07 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 27 Jun 2007 17:30:07 -0400 Subject: portage vs yum In-Reply-To: <1182979261.4523.5.camel@pensja.lam.pl> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <1182979261.4523.5.camel@pensja.lam.pl> Message-ID: <1182979807.2890.20.camel@hodge> On Wed, 2007-06-27 at 23:21 +0200, Leszek Matok wrote: > Dnia 27-06-2007, ?ro o godzinie 19:21 +0000, Kevin Kofler napisa?(a): > > Yum or apt won't update a library without also updating > > the applications which depend on it to versions built against the correct > > library. > Apt won't, but yum will without even notifying the user, it does that at > least since F7 betas, when I started to use it for yum-presto (we're > waiting for deltarpm support in apt). Fedora is one step closer to > Gentoo now. > It doesn't notify you that it is 'updating for dependencies'? Can you give me a test case so I can look at it? Thanks, -sv From pertusus at free.fr Wed Jun 27 22:00:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Jun 2007 00:00:00 +0200 Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: <20070627220000.GE8013@free.fr> On Wed, Jun 27, 2007 at 09:21:11PM +0000, Thufir wrote: > > I mean this really as food for thought for you guys. FC6 and Fedora 7 > greatly improved in terms of the ease of use of yum. However, there's a > FC6 yum repo and a Fedora 7 repo. Why? That seems like completely > unnecessary duplication which wouldn't occur in a build-from-source > package manager. As a user, I hesitate to upgrade because of the lag as > third party repos slowly catch up to Fedora versions. Whether the spec file should be different on F6 or F7 is left to the packager. I guess portage also knows about releases. It is also possible that Gentoo is slower to change things in the packaging practices, while in fedora things change rapidly, and this would be in line with gentoo packaging being minor. Once again the difference lie more in the distro scope and target than in the packaging system used. If you come with a rpm based distro with a gentoo like packaging (meaning no split, no integration) then all you say above will still be relevant. So rpm vs portage is not the issue here. -- Pat From galibert at pobox.com Wed Jun 27 22:08:05 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 28 Jun 2007 00:08:05 +0200 Subject: portage vs yum In-Reply-To: <20070627235930.A7970@xos037.xos.nl> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627235930.A7970@xos037.xos.nl> Message-ID: <20070627220805.GC7580@dspnet.fr.eu.org> On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote: > Reading opinions like these, I have the impression that most people > only think of individual, hacker-type users, not about, say, system > administrators maintaining large networks of systems, having to > support those systems (and users) easily, etc. Well, Fedora is becoming more and more hostile to the sysadmin population as time goes too, so... OG. From pertusus at free.fr Wed Jun 27 22:09:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Jun 2007 00:09:30 +0200 Subject: splix make fails In-Reply-To: References: Message-ID: <20070627220930.GF8013@free.fr> On Wed, Jun 27, 2007 at 09:37:43PM +0000, Thufir wrote: > I was posting this on the user list, and it was suggested to perhaps take > the thread here. I'm trying to build the splix print driver for a I am not sure this is the right list, but anyway. > make[1]: Entering directory `/home/thufir/Download/splix-1.0.1-1/ppd' > ppdpo -o po/fr.po samsung.drv > make[1]: ppdpo: Command not found Didn't you see that: ppdpo: Command not found After googling a bit it seems to be in CUPS Driver Development Kit cupsddk: http://www.cups.org/ddk/index.php I guess this package isn't in Fedora yet, but I also guess anybody can submit it -- providing it fits in fedora (it is free software). -- Pat From hawat.thufir at gmail.com Wed Jun 27 22:03:02 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 27 Jun 2007 22:03:02 +0000 (UTC) Subject: portage vs yum References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> <20070627211447.GB8013@free.fr> Message-ID: On Wed, 27 Jun 2007 23:14:47 +0200, Patrice Dumas wrote: > What happens is that gentoo ebuilds are written with less care to > integration than fedora specfiles, that whats make them easier to write > in my opinion. aha. thanks for explaining :) Not to flog a dead horse, but isn't loose integration preferable to tight integration? Unless you're trying to squeeze a millisecond out of something, I don't see the advantage. Of course, I don't build rpm's either. -thufir From rayvd at bludgeon.org Wed Jun 27 22:40:11 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 27 Jun 2007 15:40:11 -0700 Subject: portage vs yum In-Reply-To: <20070627235930.A7970@xos037.xos.nl> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627235930.A7970@xos037.xos.nl> Message-ID: <20070627224011.GA20161@bludgeon.org> > > Sabayon may have screwed things up, but a system which compiles most > > things from source in a portage type way, with a few exceptions which are > > time intensive, would be easier to maintain and thus larger. Open > > Office, the kernel, things like that could be prebuilt. > > Easier to maintain, for whom? The package/distro builders? > Certainly not for an average end-user. > > Reading opinions like these, I have the impression that most people > only think of individual, hacker-type users, not about, say, system > administrators maintaining large networks of systems, having to > support those systems (and users) easily, etc. I think that's the crux of it... not many of us running many servers enjoy the idea of our machines chugging away CPU cycles compiling all sorts of new packages. Seems like the main issue here is wanting/needing more packages available for Fedora rather than whether yum vs portage is appropriate. So pitch in and help package or make some suggestions on streamlining the process... asking Fedora to switch to portage is just not a very realistic thing to ask for IMO. :) Ray From pertusus at free.fr Wed Jun 27 22:37:57 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Jun 2007 00:37:57 +0200 Subject: portage vs yum In-Reply-To: <20070627220138.GB7580@dspnet.fr.eu.org> References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> <20070627211447.GB8013@free.fr> <20070627220138.GB7580@dspnet.fr.eu.org> Message-ID: <20070627223757.GG8013@free.fr> On Thu, Jun 28, 2007 at 12:01:38AM +0200, Olivier Galibert wrote: > On Wed, Jun 27, 2007 at 11:14:47PM +0200, Patrice Dumas wrote: > > What happens is that gentoo ebuilds are written with less care to > > integration than fedora specfiles, that whats make them easier to > > write in my opinion. > > Oh puh-leeze. "Fedora has less packages than Gentoo because the > gentoo developers do a crappy job" is kindergarden-level Less integration doesn't mean "crappy job", nor is it necessarily inferior. It is just another choice. > justification. I use both gentoo and fedora on a regular basis and > they're both integrated, only differently. Of course it depends on what you mean by 'integration'. In gentoo ebuilds there are less change/additions to upstream than in fedora. > How many packages are > available is a function of: > > - infrastructure capability (a source distribution does not need a > compile cluster) > > - developers responsiveness (reviewing, QA, ...) > > - apparent ease of adding new packages for new potential contributors > > If you want more packages in Fedora (which is not a given), act on > these points and especially the last two. There are certainly also many other determinants to the number of packages available. But without looking at the reasons why there is a given number of packages, it is roughly: time to do a package * number of packager * time devoted per packager (the three terms are correlated, and the first one depends on the package so that's not a simple mean). -- Pat From mspevack at redhat.com Wed Jun 27 22:41:33 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 27 Jun 2007 18:41:33 -0400 (EDT) Subject: Fedora 8's FUDCon Message-ID: Yesterday the Fedora Board made the decision not to hold an in-person FUDCon for F8. Like you, I'm a disappointed, but I'm also excited for us to try out an organized, weekend-long virtual hackfest (more below). The Board also began planning for the F9 FUDCon, which would be held around January or February 2008. This earlier planning should give us time to resolve the kinds of problems we've faced with this short-notice FUDCon. There's a couple of reasons for the cancellation of the Fedora 8 FUDCon. The first is the most obvious of all -- we have been unable to secure a location that could offer us a place for both a FUDCon and a hackfest. Additionally, the administrative overhead for putting on a FUDCon is very high. Becoming a FUDCon event planner becomes a full time job for a couple of people in order to make the event happen. Especially this late, just getting the logistics for a FUDCon worked out would take up lots of people's time that we can't really afford. Also a factor is the financial cost of a FUDCon. With the comparatively smaller scope of Fedora 8, it seems wise to save money now by not going through the whole FUDCon process, and allowing the financial and budget planners to have more opportunity to make a larger commitment to Fedora 9. Fedora 9 will be a bigger release, and I'd rather have one really good FUDCon and hackfest then, than try to do two of them on the cheap. The feature list for Fedora 8 is coming together very well, and we're planning over the next few weeks how we can do a virtual hackfest for F8. The idea is to pick some days, probably the same weekend (4, 5 August), and organize energy around people having an IRC-based hackfest that weekend. We can capture some of the energy that would come from a hackfest, but in a way that has significantly less overhead and organizational costs. Part of the danger of trying to plan and discuss things in public from the very beginning is that when you're forced to pull the plug on something, you have to send out emails like this. I'm willing to accept that, because overall I think we get a bretter experience for everyone by doing our planning in the open. Sorry, folks, for the short notice coming and going! We really appreciate your understanding, flexibility, good ideas, and patience. --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From katzj at redhat.com Wed Jun 27 22:50:36 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 27 Jun 2007 18:50:36 -0400 Subject: Fedora Features Process In-Reply-To: <4682CB87.8040005@redhat.com> References: <467FFE30.6090307@redhat.com> <4682CB87.8040005@redhat.com> Message-ID: <1182984636.30797.7.camel@aglarond.local> On Wed, 2007-06-27 at 16:41 -0400, Christopher Aillon wrote: > The engineering cycle is rather short as it is with the freezes. Rather > than take time away from engineering the features that we want to get > in, why not simply defer gathering this info until after the feature > freeze as we do now? The information gathered will be much more > accurate than basing our information off volatile plans during a hard > date-driven cycle. But if everyone just goes off and does their own thing, then we end up with no coordination and just a pile of bits. The idea of having things defined up front is many-fold 1) You have an idea of things that people are working on. This can help in getting feedback or suggestions that could improve it 2) You get people interested in it. And perhaps even helping out 3) You get some idea of areas that are going to need testing so that testers can build up experience and knowledge about the area 4) You generate some excitement around what's being worked on All of these are important. And yes, some things that are planned aren't/won't make it. That's fine. By tracking them, we should be able to know _sooner_ that they're in trouble so that others can either jump in to help out or so that we can not have expectations set that something is happening when it's not. Jeremy From kevin.kofler at chello.at Wed Jun 27 22:44:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 Jun 2007 22:44:08 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <1182979261.4523.5.camel@pensja.lam.pl> Message-ID: Leszek Matok Lam.pl> writes: > Dnia 27-06-2007, ?ro o godzinie 19:21 +0000, Kevin Kofler napisa?(a): > > Yum or apt won't update a library without also updating > > the applications which depend on it to versions built against the correct > > library. > Apt won't, but yum will without even notifying the user, it does that at > least since F7 betas, when I started to use it for yum-presto (we're > waiting for deltarpm support in apt). Fedora is one step closer to > Gentoo now. That's a bug then. Probably the "yum doesn't resolve dependencies properly" bug in 3.2.0 which is already fixed in 3.2.1 (which should be out as an F7 update shortly). Kevin Kofler From poelstra at redhat.com Wed Jun 27 22:56:12 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 27 Jun 2007 15:56:12 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-JUN-25 Message-ID: <4682EB0C.2050608@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jun-25 Please make corrections and clarifications to the wiki page. == Fedora 5 EOL == * Fedora 5 goes EOL end of this month, not very far away. Decision: jkeating will create a wiki page to track the various tasks releng needs to accomplish to shut down Fedora 5 updates. Various tasks will be assigned to various releng folks and an announcement will be sent regarding the tasks and timing of the shutdown. == Automatic promotion of updates == * FESCo couldn't agree on anything so they approved the general concept of doing automatic promotion of upgrades. It's up to releng and QA to create a framework around how it should work. === Agreed upon Constraints === * autopromotion of updates default to off, checkbox can be clicked to turn it on, delay defaults to 7 days. * Ability for (at least) other maintainers to block or ''stop'' an update is a pre-requisite to enabling auto-promotion functionality in our update system. From kevin.kofler at chello.at Wed Jun 27 22:46:42 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 Jun 2007 22:46:42 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627214303.GA7580@dspnet.fr.eu.org> Message-ID: Olivier Galibert pobox.com> writes: > Because you often do not want to do it immediatly after the specific > update that changed the library. You want broken apps instead?! > The main advantage of gentoo over fedora is the continuous upgrade > path. You do not need to reinstall everything from scratch every 6 > months just to keep up-to-date. You don't need to do that with Fedora either, that's what Anaconda's upgrade mode is for. You can even upgrade with yum or apt (not really supported though). Kevin Kofler From peter at thecodergeek.com Wed Jun 27 22:59:47 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 27 Jun 2007 15:59:47 -0700 (PDT) Subject: portage vs yum In-Reply-To: <20070627223757.GG8013@free.fr> References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> <20070627211447.GB8013@free.fr> <20070627220138.GB7580@dspnet.fr.eu.org> <20070627223757.GG8013@free.fr> Message-ID: <17520.65.223.36.19.1182985187.squirrel@webmail.thecodergeek.com> Patrice Dumas wrote: > There are certainly also many other determinants to the number of > packages available. But without looking at the reasons why there is > a given number of packages, it is roughly: > time to do a package * number of packager * time devoted per packager > (the three terms are correlated, and the first one depends on the > package so that's not a simple mean). > I agree. However, I feel that a source-based system such as Portage is much less developer-friendly. For example, when I create a VM and use it to test my packages for an earlier release before I submit them to the build system, I know for certain that I am running the _exact_ same binaries as my users will be: same code paths, same compilation options, same library dependencies, same drivers, et al. This means that when I test it, I know for certain that my package will function on end-users' computers exactly as it does in my testing. When something goes wrong and someone posts a bug report, I can more precisely reproduce the backtrace or any other appropriate issue. On the other hand, Gentoo's USE flags, compilation settings, optional dependencies, and linker flag combinations (among other build choices) mean that a Gentoo maintainer cannot ever fully test his package, as he cannot be sure what options the end-user will have enabled or not. (I remember a thread discussing something similar on the gentoo-dev mailing list not long ago. I don't remember who said it, but one of the developers posted that, with all combinations of _only_ USE flags , the amount of package combinations possible was something like 1000 times larger than the estimated age of the universe in seconds. Quite drastic, sure; but I wouldn't be surprised if that really were the case...) Of course, there are those among users who rebuild their system or various component packages of it differently than what is shipped "by default" in Fedora; but they are likely much more sparse than those of Gentoo, and capable of tweaking other packages as needed to suit their systems. :) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From tcallawa at redhat.com Wed Jun 27 23:13:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 27 Jun 2007 18:13:34 -0500 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182961567.6652.7.camel@kennedy> References: <1182961567.6652.7.camel@kennedy> Message-ID: <1182986014.4044.37.camel@localhost.localdomain> On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: Brian, can you add an item: * All new packages (including compat packages) must be reviewed before cvs import. I'd like FESCo to ratify that, or at least, argue about it. Thanks, ~spot From bpepple at fedoraproject.org Wed Jun 27 23:27:57 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 27 Jun 2007 19:27:57 -0400 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182986014.4044.37.camel@localhost.localdomain> References: <1182961567.6652.7.camel@kennedy> <1182986014.4044.37.camel@localhost.localdomain> Message-ID: <1182986877.11379.2.camel@kennedy> On Wed, 2007-06-27 at 18:13 -0500, Tom "spot" Callaway wrote: > On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: > > Please find below the list of topics that are likely to come up in the > > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > > in #fedora-meeting on irc.freenode.org: > > Brian, can you add an item: > > * All new packages (including compat packages) must be reviewed before > cvs import. > > I'd like FESCo to ratify that, or at least, argue about it. Done. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Wed Jun 27 23:19:39 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 27 Jun 2007 19:19:39 -0400 Subject: Upgrade path question In-Reply-To: <20070627211839.GC8013@free.fr> References: <1182964907.30663.402.camel@localhost.localdomain> <20070627175123.GC29669@nostromo.devel.redhat.com> <20070627211839.GC8013@free.fr> Message-ID: <1182986379.30663.420.camel@localhost.localdomain> On Wed, 2007-06-27 at 23:18 +0200, Patrice Dumas wrote: > On Wed, Jun 27, 2007 at 01:51:23PM -0400, Bill Nottingham wrote: > > > > Historically, we've supported upgrades from N-2 on the premise that that's > > what's reasonable to test and make sure works; moreover, with the slightly > > extended lifecycle, someone can be on a maintained FC5 installation when > > F7 is released. Anything other than that is gravy. There hasn't been specific > > policy about garbage collecting obsoletes, to the the best of my knowledge. > > > > Strawman would be if we're supporting N-2, to garbage collect after N-4? > > I think we should not say anything about garbage collecting obsoletes, > and let the maintainer do whatever they prefer. That's effectively equivalent to saying "garbage collect at N-2", since _some_ maintainer will do so, which then means the rest of the system might as well too since any update over a stride larger than that will have to be manual anyway. - ajax From hawat.thufir at gmail.com Wed Jun 27 23:31:27 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 27 Jun 2007 23:31:27 +0000 (UTC) Subject: splix make fails References: <20070627220930.GF8013@free.fr> Message-ID: On Thu, 28 Jun 2007 00:09:30 +0200, Patrice Dumas wrote: > Didn't you see that: > ppdpo: Command not found > > After googling a bit it seems to be in CUPS Driver Development Kit > cupsddk: > http://www.cups.org/ddk/index.php I did see it, but didn't know how to interpret it. So, basically, install (make) cupsddk in order to make splix? thanks, Thufir From galibert at pobox.com Wed Jun 27 23:39:14 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 28 Jun 2007 01:39:14 +0200 Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627214303.GA7580@dspnet.fr.eu.org> Message-ID: <20070627233914.GA16551@dspnet.fr.eu.org> On Wed, Jun 27, 2007 at 10:46:42PM +0000, Kevin Kofler wrote: > Olivier Galibert pobox.com> writes: > > Because you often do not want to do it immediatly after the specific > > update that changed the library. > > You want broken apps instead?! Please re-engage your brain. I usually update all the *other* applications and libraries that need to be compiled because of a new version and *then* I ask revdep-rebuild to recompile what is still broken. revdep-rebuild always recompiles the same version than what is currently installed, not the most up-to-date available one. > > The main advantage of gentoo over fedora is the continuous upgrade > > path. You do not need to reinstall everything from scratch every 6 > > months just to keep up-to-date. > > You don't need to do that with Fedora either, that's what Anaconda's upgrade > mode is for. You can even upgrade with yum or apt (not really supported > though). Everything is in that "not really supported though". I'm not too enthusiastic about having to go in front of and reboot the 200+ computers we manage one by one with a usb key just to run anaconda upgrade. Someday, maybe, anaconda will be able to do an install/upgrade from a running installation. Not sure it's anywhere in the plans though. Is the code to test if the pid is not too high still there? Meanwhile, I've already done complete gentoo installations in a chroot of a mounted external usb disk, which worked beautifully once installed in the recieving laptop. That were painless HD upgrades. OG. From buytenh at wantstofly.org Wed Jun 27 23:45:27 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 28 Jun 2007 01:45:27 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1181662311.25228.42.camel@pmac.infradead.org> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> Message-ID: <20070627234527.GA16821@xi.wantstofly.org> On Tue, Jun 12, 2007 at 04:31:51PM +0100, David Woodhouse wrote: > Binutils at least should be relatively easy. Here's a patch against > binutils/F-7 which lets me: > make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc I've had to change two things to make cross-gcc happy with this: 1. Change the location of the sysroot. /usr/%{target} is not the right place to put the sysroot, as binutils/gcc use it to store target-specific binaries, etc. (binutils stores things like 'as' in /usr/%{target}/bin, which gcc expects to find there.) If you use the default sysroot path (i.e. --with-sysroot=yes), the sysroot gets put in /usr/%{target}/sys-root. That seems like a sane default to me. 2. Do package /usr/%{target}, as the subsequently built gcc depends on (see #1) having 'as' in /usr/%{target}/bin and such. Here's a new version (beware: against a locally modified tree) with these changes. Seems to work OK for me. Index: SPECS/binutils.spec =================================================================== --- SPECS.orig/binutils.spec +++ SPECS/binutils.spec @@ -1,5 +1,13 @@ +%if "%{?binutils_target}" == "" +%define binutils_target %{_target_platform} +%define isnative 1 +%else +%define cross %{binutils_target}- +%define isnative 0 +%endif + Summary: A GNU collection of binary utilities. -Name: binutils +Name: %{?cross}binutils Version: 2.17.50.0.12 Release: 4.fa1 License: GPL @@ -55,7 +63,7 @@ have a stable ABI. Developers starting to consider using libelf instead of BFD. %prep -%setup -q +%setup -q -n binutils-%{version} %patch1 -p0 -b .ltconfig-multilib~ %patch2 -p0 -b .ppc64-pie~ %patch3 -p0 -b .place-orphan~ @@ -70,7 +78,7 @@ to consider using libelf instead of BFD. %patch8 -p0 -b .osabi~ %patch9 -p0 -b .rh235747~ -# On ppc64 we might use 64K pages +# On ppc64 we might use 64KiB pages sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c # LTP sucks perl -pi -e 's/i\[3-7\]86/i[34567]86/g' */conf* @@ -82,24 +90,36 @@ sed -i -e 's/^libbfd_la_LDFLAGS = /&-Wl, sed -i -e 's/^libopcodes_la_LDFLAGS = /&-Wl,-Bsymbolic-functions /' opcodes/Makefile.{am,in} fi touch */configure +sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' */configure %build -mkdir build-%{_target_platform} -cd build-%{_target_platform} +mkdir build-%{binutils_target} +cd build-%{binutils_target} CARGS= -%ifarch sparc ppc s390 -CARGS=--enable-64-bit-bfd -%endif -%ifarch ia64 -CARGS=--enable-targets=i386-linux +case %{binutils_target} in + sparc*|ppc*|s390*) + CARGS=--enable-64-bit-bfd + ;; + ia64*) + CARGS=--enable-targets=i386-linux + ;; +esac +%if %isnative + SHAREDARGS=--enable-shared + TARGET=%{binutils_target} + SYSROOT= +%else + SHAREDARGS=--disable-shared + TARGET="--target %{binutils_target} --host %{_target_platform}" + SYSROOT="--with-sysroot=yes" %endif CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags}" ../configure \ - %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ + $TARGET --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} \ - --infodir=%{_infodir} --enable-shared $CARGS --disable-werror + --infodir=%{_infodir} $SHAREDARGS $CARGS --disable-werror $SYSROOT make %{_smp_mflags} tooldir=%{_prefix} all make %{_smp_mflags} tooldir=%{_prefix} info make -k check < /dev/null > check.log 2>&1 || : @@ -111,8 +131,9 @@ cd .. %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_prefix} -cd build-%{_target_platform} +cd build-%{binutils_target} %makeinstall +%if %isnative make prefix=%{buildroot}%{_prefix} infodir=%{buildroot}%{_infodir} install-info gzip -q9f %{buildroot}%{_infodir}/*.info* @@ -134,10 +155,6 @@ rm -f %{buildroot}%{_prefix}/%{_lib}/lib # Remove libtool files, which reference the .so libs rm -f %{buildroot}%{_prefix}/%{_lib}/lib{bfd,opcodes}.la -# This one comes from gcc -rm -f %{buildroot}%{_infodir}/dir -rm -rf %{buildroot}%{_prefix}/%{_target_platform} - %ifarch %{ix86} x86_64 ppc ppc64 s390 s390x sparc sparc64 sed -i -e '/^#include "ansidecl.h"/{p;s~^.*$~#include ~;}' \ %ifarch %{ix86} x86_64 @@ -155,22 +172,36 @@ sed -i -e '/^#include "ansidecl.h"/{p;s~ %endif touch -r ../bfd/bfd-in2.h %{buildroot}%{_prefix}/include/bfd.h +%else # native +# For cross-binutils we drop the documentation. +rm -rf %{buildroot}%{_infodir} +#rm -rf %{buildroot}%{_prefix}/share/locale +#rm -rf %{buildroot}%{_mandir} +rm -rf %{buildroot}%{_prefix}/%{_lib}/libiberty.a +%endif # native + +# This one comes from gcc +rm -f %{buildroot}%{_infodir}/dir +#rm -rf %{buildroot}%{_prefix}/%{binutils_target} + + cd .. -%find_lang binutils -%find_lang opcodes -%find_lang bfd -%find_lang gas -%find_lang ld -%find_lang gprof -cat opcodes.lang >> binutils.lang -cat bfd.lang >> binutils.lang -cat gas.lang >> binutils.lang -cat ld.lang >> binutils.lang -cat gprof.lang >> binutils.lang +%find_lang %{?cross}binutils +%find_lang %{?cross}opcodes +%find_lang %{?cross}bfd +%find_lang %{?cross}gas +%find_lang %{?cross}ld +%find_lang %{?cross}gprof +cat %{?cross}opcodes.lang >> %{?cross}binutils.lang +cat %{?cross}bfd.lang >> %{?cross}binutils.lang +cat %{?cross}gas.lang >> %{?cross}binutils.lang +cat %{?cross}ld.lang >> %{?cross}binutils.lang +cat %{?cross}gprof.lang >> %{?cross}binutils.lang %clean rm -rf %{buildroot} +%if %isnative %post /sbin/ldconfig /sbin/install-info --info-dir=%{_infodir} %{_infodir}/as.info.gz @@ -201,12 +232,16 @@ exit 0 if [ $1 = 0 ] ;then /sbin/install-info --delete --info-dir=%{_infodir} %{_infodir}/bfd.info.gz || : fi +%endif # native -%files -f binutils.lang +%files -f %{?cross}binutils.lang %defattr(-,root,root) %doc README %{_prefix}/bin/* %{_mandir}/man1/* +%if !%isnative +%{_prefix}/%{binutils_target} +%else %{_prefix}/%{_lib}/lib*.so %{_infodir}/[^b]*info* %{_infodir}/binutils*info* @@ -216,6 +251,7 @@ fi %{_prefix}/include/* %{_prefix}/%{_lib}/lib*.a %{_infodir}/bfd*info* +%endif # native %changelog * Sat Apr 14 2007 Jakub Jelinek 2.17.50.0.12-4 From kevin.kofler at chello.at Wed Jun 27 23:56:57 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 27 Jun 2007 23:56:57 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627214303.GA7580@dspnet.fr.eu.org> <20070627233914.GA16551@dspnet.fr.eu.org> Message-ID: Olivier Galibert pobox.com> writes: > Please re-engage your brain. I usually update all the *other* > applications and libraries that need to be compiled because of a new > version and *then* I ask revdep-rebuild to recompile what is still > broken. revdep-rebuild always recompiles the same version than what > is currently installed, not the most up-to-date available one. Then you should do those updates in one transaction, and the automatic revdep-rebuild should happen at the end of the transaction, not in the middle. (Of course, it gets more complicated because apps which are needed for the remaining upgrades need to be working, so they might need a rebuild even during the transaction, but that can be figured out programmatically too.) > Everything is in that "not really supported though". I'm not too > enthusiastic about having to go in front of and reboot the 200+ > computers we manage one by one with a usb key just to run anaconda > upgrade. Edit your /etc/apt/sources.list and/or /etc/apt/sources.list.d/*.list to point to the newer Fedora, then run: apt-get update apt-get dist-upgrade and you're running the new Fedora version. That can even be scripted for your 200+ computers (just use sed, cat and/or rm for the sources.list editing, then apt-get update && apt-get -y dist-upgrade). Kevin Kofler From hawat.thufir at gmail.com Thu Jun 28 00:01:12 2007 From: hawat.thufir at gmail.com (Thufir) Date: Thu, 28 Jun 2007 00:01:12 +0000 (UTC) Subject: splix make fails References: <20070627220930.GF8013@free.fr> Message-ID: On Thu, 28 Jun 2007 00:09:30 +0200, Patrice Dumas wrote: > Didn't you see that: > ppdpo: Command not found > > After googling a bit it seems to be in CUPS Driver Development Kit > cupsddk: > http://www.cups.org/ddk/index.php What I downloaded had an rpm in it, which seems to have installed. Yet that doesn't resolve that the ppdpo wasn't found. Did I miss something? [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# pwd /home/thufir/Download/misc/cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# ll total 1744 -rw-r--r-- 1 thufir thufir 181157 2007-03-20 07:37 cupsddk-1.1.1- linux-2.6-intel.rpm -rw-r--r-- 1 thufir thufir 1074297 2007-03-20 07:37 cupsddk-drivers-1.1.1- linux-2.6-intel.rpm -r-xr-xr-x 1 thufir thufir 224468 2007-03-20 07:35 setup -r--r--r-- 1 thufir thufir 43072 2006-08-29 07:44 setup.xpm -r-xr-xr-x 1 thufir thufir 216188 2007-03-20 07:35 uninst [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# rpm cupsddk- drivers-1.1.1-linux-2.6-intel.rpm -ihv error: Failed dependencies: libcrypto.so.4 is needed by cupsddk-drivers-1.1.1-0.i386 libssl.so.4 is needed by cupsddk-drivers-1.1.1-0.i386 [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# yum -y install libcrypto.so.4 libssl.so.4 Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/releases/7/ Everything/i386/os/repodata/repomd.xml: [Errno 12] Timeout: Trying other mirror. fedora 100% |=========================| 2.1 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 freshrpms 100% |=========================| 2.1 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package openssl097a.i386 0:0.9.7a-9 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: openssl097a i386 0.9.7a-9 fedora 824 k Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 824 k Downloading Packages: (1/1): openssl097a-0.9.7a 100% |=========================| 824 kB 00:09 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: openssl097a ######################### [1/1] error: %post(openssl097a-0.9.7a-9.i386) scriptlet failed, exit status 1 Installed: openssl097a.i386 0:0.9.7a-9 Complete! [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# rpm cupsddk- drivers-1.1.1-linux-2.6-intel.rpm -ihv Preparing... ########################################### [100%] 1:cupsddk-drivers ########################################### [100%] [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# cd .. [root at localhost misc]# cd .. [root at localhost Download]# [root at localhost splix-1.0.1-1]# cd /home/thufir/Download/splix-1.0.1-1/ [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# ll total 112 -rw-r--r-- 1 thufir thufir 47 2007-02-10 06:20 AUTHORS -rw-r--r-- 1 thufir thufir 1809 2007-02-10 06:20 ChangeLog -rw-r--r-- 1 thufir thufir 18009 2007-02-10 06:20 COPYING drwxr-xr-x 2 thufir thufir 4096 2007-02-10 06:20 include -rw-r--r-- 1 thufir thufir 1206 2007-02-10 06:20 INSTALL -rw-r--r-- 1 thufir thufir 735 2007-02-10 06:20 Makefile drwxr-xr-x 3 thufir thufir 4096 2007-02-10 06:20 ppd -rw-r--r-- 1 thufir thufir 18 2007-02-10 06:20 README drwxr-xr-x 2 thufir thufir 4096 2007-06-27 02:56 src -rw-r--r-- 1 thufir thufir 176 2007-02-10 06:20 THANKS -rw-r--r-- 1 thufir thufir 238 2007-02-10 06:20 TODO drwxr-xr-x 2 thufir thufir 4096 2007-02-10 06:20 tools [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# make make[1]: Entering directory `/home/thufir/Download/splix-1.0.1-1/src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/thufir/Download/splix-1.0.1-1/src' make[1]: Entering directory `/home/thufir/Download/splix-1.0.1-1/ppd' ppdpo -o po/fr.po samsung.drv make[1]: ppdpo: Command not found make[1]: *** [po/fr.po] Error 127 make[1]: Leaving directory `/home/thufir/Download/splix-1.0.1-1/ppd' make: *** [ppd] Error 2 [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# date Wed Jun 27 16:54:57 PDT 2007 [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# thanks, Thufir From hawat.thufir at gmail.com Thu Jun 28 00:08:27 2007 From: hawat.thufir at gmail.com (Thufir) Date: Thu, 28 Jun 2007 00:08:27 +0000 (UTC) Subject: splix make fails References: <20070627220930.GF8013@free.fr> Message-ID: On Thu, 28 Jun 2007 00:01:12 +0000, Thufir wrote: > What I downloaded had an rpm in it, which seems to have installed. Yet > that doesn't resolve that the ppdpo wasn't found. Did I miss something? Yes, I did. doh. there were two rpm's: [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# pwd /home/thufir/Download/misc/cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# rpm cupsddk-1.1.1-linux-2.6-intel.rpm -ihv Preparing... ########################################### [100%] 1:cupsddk ########################################### [100%] [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# ll total 1744 -rw-r--r-- 1 thufir thufir 181157 2007-03-20 07:37 cupsddk-1.1.1- linux-2.6-intel.rpm -rw-r--r-- 1 thufir thufir 1074297 2007-03-20 07:37 cupsddk-drivers-1.1.1- linux-2.6-intel.rpm -r-xr-xr-x 1 thufir thufir 224468 2007-03-20 07:35 setup -r--r--r-- 1 thufir thufir 43072 2006-08-29 07:44 setup.xpm -r-xr-xr-x 1 thufir thufir 216188 2007-03-20 07:35 uninst [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# rpm cupsddk- drivers-1.1.1-linux-2.6-intel.rpm -ihv Preparing... ########################################### [100%] package cupsddk-drivers-1.1.1-0 is already installed [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# ./setup [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# date Wed Jun 27 17:06:55 PDT 2007 [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# [root at localhost cupsddk-1.1.1-linux-2.6-intel.rpm.tgz_FILES]# cd /home/ thufir/Download/splix-1.0.1-1/ [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# make make[1]: Entering directory `/home/thufir/Download/splix-1.0.1-1/src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/thufir/Download/splix-1.0.1-1/src' make[1]: Entering directory `/home/thufir/Download/splix-1.0.1-1/ppd' ppdpo -o po/fr.po samsung.drv ppdpo -o po/it.po samsung.drv ppdpo -o po/de.po samsung.drv ppdc -c po/fr.po -l fr -d po samsung.drv for filename in ml1510 ml1520 ml1610 ml1710 ml1740 ml1750 ml2010 ml2150 ml2250 ml2550 clp300 clp500 clp510 clp600 xerox-phaser6100; do \ mv po/`echo $filename`.ppd `echo $filename`fr.ppd; \ done ppdc -c po/it.po -l it -d po samsung.drv for filename in ml1510 ml1520 ml1610 ml1710 ml1740 ml1750 ml2010 ml2150 ml2250 ml2550 clp300 clp500 clp510 clp600 xerox-phaser6100; do \ mv po/`echo $filename`.ppd `echo $filename`it.ppd; \ done ppdc -c po/de.po -l de -d po samsung.drv for filename in ml1510 ml1520 ml1610 ml1710 ml1740 ml1750 ml2010 ml2150 ml2250 ml2550 clp300 clp500 clp510 clp600 xerox-phaser6100; do \ mv po/`echo $filename`.ppd `echo $filename`de.ppd; \ done make[1]: Leaving directory `/home/thufir/Download/splix-1.0.1-1/ppd' [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# date Wed Jun 27 17:07:18 PDT 2007 [root at localhost splix-1.0.1-1]# [root at localhost splix-1.0.1-1]# thanks, Thufir From packages at amiga-hardware.com Thu Jun 28 00:53:07 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 28 Jun 2007 01:53:07 +0100 Subject: portage vs yum In-Reply-To: References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> Message-ID: <46830673.4080000@amiga-hardware.com> Thufir wrote: > I'd like to see Fedora consider some form of portage because that would, > hopefully, increase the number of packages. All other things being > equal, ebuilds are, apparently, easier to write. Well from what I've seen of this discussion, "all other things being equal" isn't the case, hence why writing ebuilds is easier. -- Ian Chapman. From packages at amiga-hardware.com Thu Jun 28 01:03:59 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 28 Jun 2007 02:03:59 +0100 Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> Message-ID: <468308FF.9030204@amiga-hardware.com> Thufir wrote: > Sabayon may have screwed things up, but a system which compiles most > things from source in a portage type way, with a few exceptions which are > time intensive, would be easier to maintain and thus larger. Seriously, how can something where I have to compile most things from source be easier to maintain? You have an extra layer of complexity. In addition to satisfying dependancies at the install, you also have to satisfy dependancies for compiling. Personally I'd rather just install binaries and get on with things rather than waiting for things to compile. I know a guy who's a big Gentoo fan and he has a particular dislike of redhat/fedora. I asked him what he particularly liked about Gentoo and he said Portage and the fact that he can compile stuff from source and tweak the compile options to optimise it, so it runs faster. Fair enough, sounds kinda reasonable until he admitted he waited 11 days for X to compile on his 486. And for what, the chance of it starting up 2 seconds quicker? I know extreme example, but... :-) Each to their own, I suppose. -- Ian Chapman. From packages at amiga-hardware.com Thu Jun 28 01:11:19 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 28 Jun 2007 02:11:19 +0100 Subject: portage vs yum In-Reply-To: References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> <20070627211447.GB8013@free.fr> Message-ID: <46830AB7.4090407@amiga-hardware.com> Thufir wrote: > Not to flog a dead horse, but isn't loose integration preferable to tight > integration? I guess that may be down to personal preference, but I'd opt for tight integration. > Unless you're trying to squeeze a millisecond out of > something, I don't see the advantage. Isnt that often a reason touted by Gentoo users as to why they love portage because they can shave a few milliseconds by rolling their own? -- Ian Chapman. From jkeating at redhat.com Thu Jun 28 01:09:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 21:09:45 -0400 Subject: portage vs yum In-Reply-To: References: <20070627211447.GB8013@free.fr> Message-ID: <200706272109.45689.jkeating@redhat.com> On Wednesday 27 June 2007 18:03:02 Thufir wrote: > Unless you're trying to squeeze a millisecond out of > something, I don't see the advantage. ?Of course, I don't build rpm's > either. "Integration" isn't about speed. It's about ensuring that the software works together, that it has been built with the right options to enable the desired features, that the features /work/ as expected, etc... It's the kind of work we do to work towards a single dictionary system instead of one for each app (still working on this...) It's the kind of work we do to try and make each desktop application use the same file selection tools, themes, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at thecodergeek.com Thu Jun 28 01:33:08 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 27 Jun 2007 18:33:08 -0700 Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <47062.65.223.36.19.1182972580.squirrel@webmail.thecodergeek.com> Message-ID: <1182994388.3313.1.camel@tuxhugs> On Wed, 2007-06-27 at 19:50 +0000, Kevin Kofler wrote: > DPKG doesn't support that, so Debian's solution is to just call the package > providing libfoo.so.42 libfoo42, so when libfoo.so.43 comes out, the packages > will require libfoo43 and apt will know that libfoo42 is insufficient. Great; thank you for the clarification. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hawat.thufir at gmail.com Thu Jun 28 01:47:09 2007 From: hawat.thufir at gmail.com (Thufir) Date: Thu, 28 Jun 2007 01:47:09 +0000 (UTC) Subject: portage vs yum References: <1182940222.4126.11.camel@defender> <20070627150554.GB4394@free.fr> <20070627211447.GB8013@free.fr> <46830AB7.4090407@amiga-hardware.com> Message-ID: On Thu, 28 Jun 2007 02:11:19 +0100, Ian Chapman wrote: >> Unless you're trying to squeeze a millisecond out of >> something, I don't see the advantage. > > Isnt that often a reason touted by Gentoo users as to why they love > portage because they can shave a few milliseconds by rolling their own? Gentoo evolved, to my understanding, partly because there was a gcc which compiled something faster. So, when gentoo was first on the scene, that gcc compiled ______ better than other distro's, which gave better performance. Now everyone uses the same gcc and that benefit isn't really there anymore. -Thufir From spng.yang at gmail.com Thu Jun 28 01:45:14 2007 From: spng.yang at gmail.com (Ken YANG) Date: Thu, 28 Jun 2007 09:45:14 +0800 Subject: glibmm24 & gtkmm24 make vmware6 fail Message-ID: <468312AA.2010008@gmail.com> hi all: the glibmm24 and gtkmm24 in rawhide make vmware6 failed: glibmm24-2.13.6-2.fc8.i386: /usr/lib/vmware/bin/vmplayer: symbol lookup error: /usr/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol: _ZN4Glib9ValueBase4initEm gtkmm24-2.11.3-1.fc8.i386: /usr/lib/vmware/bin/vmplayer: symbol lookup error: /usr/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol: _ZN3Gtk19TreeModelColumnBaseC2Em From jwboyer at jdub.homelinux.org Thu Jun 28 01:46:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 20:46:34 -0500 Subject: glibmm24 & gtkmm24 make vmware6 fail In-Reply-To: <468312AA.2010008@gmail.com> References: <468312AA.2010008@gmail.com> Message-ID: <1182995194.23776.0.camel@vader.jdub.homelinux.org> On Thu, 2007-06-28 at 09:45 +0800, Ken YANG wrote: > hi all: > > the glibmm24 and gtkmm24 in rawhide make vmware6 failed: Tell VMWare josh From hawat.thufir at gmail.com Thu Jun 28 01:51:31 2007 From: hawat.thufir at gmail.com (Thufir) Date: Thu, 28 Jun 2007 01:51:31 +0000 (UTC) Subject: portage vs yum References: <20070627211447.GB8013@free.fr> <200706272109.45689.jkeating@redhat.com> Message-ID: On Wed, 27 Jun 2007 21:09:45 -0400, Jesse Keating wrote: > "Integration" isn't about speed. It's about ensuring that the software > works together, that it has been built with the right options to enable > the desired features, that the features /work/ as expected, etc... > > It's the kind of work we do to work towards a single dictionary system > instead of one for each app (still working on this...) > > It's the kind of work we do to try and make each desktop application use > the same file selection tools, themes, etc... thanks for clarifying. This is getting close to naysaying, but I'd prefer more packages, easier to upgrade from fedora N to N+1, than integration. My personal preference. Going back to expediency, ebuild ease of creation versus rpm ease of creation: e-builds are easier due to the looser integration? What are other factors, please? thanks, Thufir From spng.yang at gmail.com Thu Jun 28 01:56:34 2007 From: spng.yang at gmail.com (Ken YANG) Date: Thu, 28 Jun 2007 09:56:34 +0800 Subject: glibmm24 & gtkmm24 make vmware6 fail In-Reply-To: <1182995194.23776.0.camel@vader.jdub.homelinux.org> References: <468312AA.2010008@gmail.com> <1182995194.23776.0.camel@vader.jdub.homelinux.org> Message-ID: <46831552.5010805@gmail.com> Josh Boyer wrote: > On Thu, 2007-06-28 at 09:45 +0800, Ken YANG wrote: >> hi all: >> >> the glibmm24 and gtkmm24 in rawhide make vmware6 failed: > > Tell VMWare but glibmm24-2.12.8-1.fc7.i386 and gtkmm24-2.10.10-1.fc7.i386 can make vmware6 work well without error, i am not familiar with glibmm24 & gtkmm24, if the problems is truly belong to vmware, i will report a bug to vmware > > josh > From sberry at northlc.com Thu Jun 28 02:27:19 2007 From: sberry at northlc.com (Scott Berry) Date: Wed, 27 Jun 2007 21:27:19 -0500 Subject: Fedora 8's FUDCon References: Message-ID: <007601c7b92b$dd1212f0$c701a8c0@yellobow> Max, Where would I find the list of suggestions for F8. I would be interested in reading what you have planned so far. Scott ----- Original Message ----- From: "Max Spevack" To: Sent: Wednesday, June 27, 2007 5:41 PM Subject: Fedora 8's FUDCon > Yesterday the Fedora Board made the decision not to hold an in-person > FUDCon for F8. Like you, I'm a disappointed, but I'm also excited for us > to try out an organized, weekend-long virtual hackfest (more below). > > The Board also began planning for the F9 FUDCon, which would be held > around January or February 2008. This earlier planning should give us > time to resolve the kinds of problems we've faced with this short-notice > FUDCon. > > There's a couple of reasons for the cancellation of the Fedora 8 FUDCon. > > The first is the most obvious of all -- we have been unable to secure a > location that could offer us a place for both a FUDCon and a hackfest. > Additionally, the administrative overhead for putting on a FUDCon is very > high. Becoming a FUDCon event planner becomes a full time job for a > couple of people in order to make the event happen. Especially this late, > just getting the logistics for a FUDCon worked out would take up lots of > people's time that we can't really afford. > > Also a factor is the financial cost of a FUDCon. With the comparatively > smaller scope of Fedora 8, it seems wise to save money now by not going > through the whole FUDCon process, and allowing the financial and budget > planners to have more opportunity to make a larger commitment to Fedora 9. > Fedora 9 will be a bigger release, and I'd rather have one really good > FUDCon and hackfest then, than try to do two of them on the cheap. > > The feature list for Fedora 8 is coming together very well, and we're > planning over the next few weeks how we can do a virtual hackfest for F8. > The idea is to pick some days, probably the same weekend (4, 5 August), > and organize energy around people having an IRC-based hackfest that > weekend. > > We can capture some of the energy that would come from a hackfest, but in > a way that has significantly less overhead and organizational costs. > > Part of the danger of trying to plan and discuss things in public from the > very beginning is that when you're forced to pull the plug on something, > you have to send out emails like this. I'm willing to accept that, > because overall I think we get a bretter experience for everyone by doing > our planning in the open. > > Sorry, folks, for the short notice coming and going! We really appreciate > your understanding, flexibility, good ideas, and patience. > > --Max > > -- > Max Spevack > + http://fedoraproject.org/wiki/MaxSpevack > + gpg key -- http://spevack.org/max.asc > + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: > 269.9.10/875 - Release Date: 6/27/2007 9:08 PM > > From jkeating at redhat.com Thu Jun 28 02:37:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 22:37:52 -0400 Subject: Fedora 8's FUDCon In-Reply-To: <007601c7b92b$dd1212f0$c701a8c0@yellobow> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> Message-ID: <200706272237.52870.jkeating@redhat.com> On Wednesday 27 June 2007 22:27:19 Scott Berry wrote: > Max, > > Where would I find the list of suggestions for F8. ?I would be interested > in reading what you have planned so far. http://fedoraproject.org/wiki/Releases/8/FeatureList -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Jun 28 02:15:53 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 28 Jun 2007 02:15:53 +0000 (UTC) Subject: portage vs yum References: <20070627211447.GB8013@free.fr> <200706272109.45689.jkeating@redhat.com> Message-ID: Thufir gmail.com> writes: > thanks for clarifying. This is getting close to naysaying, but I'd > prefer more packages, easier to upgrade from fedora N to N+1, than > integration. My personal preference. Then I'd say you picked the wrong distribution. There are distributions out there for people with your preferences, you cited one already (Gentoo), why do you want Fedora to change to suit you? I believe the integration work done in Fedora is essential, it's no use having thousands of packages if 10% of them don't run at all (because they used to work when they got submitted, but changes in libraries broke them, or worse, because they weren't tested at all due to "quantity over quality" mentality), 20% have bugs due to e.g. expecting files to be located in different places than they actually are in the distribution, half of them only work if you pick some specific USE flags or library versions which break the other half etc. Now, the actual numbers of problem packages in Gentoo might be much lower than that, but all those problems do exist in Gentoo or any other loosely-integrated distribution. The less integration work a distribution does, the worse the mess you end up with gets. Kevin Kofler From lightsolphoenix at gmail.com Thu Jun 28 02:52:05 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 27 Jun 2007 22:52:05 -0400 Subject: portage vs yum In-Reply-To: References: <200706272109.45689.jkeating@redhat.com> Message-ID: <200706272252.06557.lightsolphoenix@gmail.com> On Wednesday, June 27, 2007 9:51 pm Thufir wrote: > Going back to expediency, ebuild ease of creation versus rpm ease of > creation: e-builds are easier due to the looser integration? What are > other factors, please? I don't know about ebuilds, but RPM's are insanely easy to build if you know how. I mean, you can tear off a huge collection of RPM's in a very short time with a bit of knowledge of the spec file, and technically generating your own RPM's = compiling from source anyway (I did 5 packages yesterday in half an hour, though I doubt they'd fit the project's guidelines...). I much prefer RPM to other systems I've used to handle this sort of thing, because they're easy to make and easy to use. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From sberry at northlc.com Thu Jun 28 03:33:27 2007 From: sberry at northlc.com (Scott Berry) Date: Wed, 27 Jun 2007 22:33:27 -0500 Subject: Fedora 8's FUDCon References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> Message-ID: <00d401c7b935$1c9aa2d0$c701a8c0@yellobow> Thanks Jesse, That was informative. Scott ----- Original Message ----- From: "Jesse Keating" To: Sent: Wednesday, June 27, 2007 9:37 PM Subject: Re: Fedora 8's FUDCon > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.10/875 - Release Date: 6/27/2007 9:08 PM From fedora at leemhuis.info Thu Jun 28 05:12:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 Jun 2007 07:12:15 +0200 Subject: EPEL branching if Fedora maintainer does not react (was: Re: Plan for tomorrows (20070628) FESCO meeting) In-Reply-To: <1182961567.6652.7.camel@kennedy> References: <1182961567.6652.7.camel@kennedy> Message-ID: <4683432F.4010000@leemhuis.info> On 27.06.2007 18:26, Brian Pepple wrote: > [...] > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule [...] The EPEL SIG in its yesterday meeting discussed something that FESCo likely explicitly should discuss once: There are some EPEL maintainers that want to see some packages in EPEL that are owned by other people. The EPEL contributors are willing to maintain those packagers theirselfs in EPEL if the Fedora owner doesn't want to -- but they don't want to step on anybody toes, so they normally ask the Fedora maintainers first. Some don't answer; we likely need some kind of semi-official way to get those packages into EPEL anyway. The comaintainership-proposal has some things about it already (e.g. the Fedora maintainer can't say "no, I don't want my package to become part of EPEL" iirc), but a standard-procedure might be best for all. I'd suggest something like this: ---- If a EPEL maintainer wants to get a Fedora package into EPEL he should checks the ContributorStatus document, located in the wiki at http://fedoraproject.org/wiki/EPEL/ContributorStatus If the Fedora maintainer of the package issued to not participate in EPEL then the EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently; best to CC the Fedora maintainer, so he knows that the package is maintained in EPEL as well). If it's unclear if the Fedora maintainer of the package participates in EPEL then the EPEL maintainer should just mail the Fedora maintainer and ask him for his plans for EPEL in general and the package at hand. If there is no answer within seven days the EPEL contributor is free to request the EPEL branch (CC the Fedora maintainer here as well). If the Fedora maintainer sooner or later wants to participate in EPEL then the EPEL maintainer of the package should hand primary per release maintainership back to the Fedora maintainer (and become comaintainer, if interested) ---- Does that sound sane and acceptable for FESCo (and of course those reading this mail)? Sure, one week if a short timeframe, but EPEL should be known by know and at least have updated http://fedoraproject.org/wiki/EPEL/ContributorStatus ; I'd further like to have some quick procedure, because everything longer then one or two weeks would slow EPEL down; and, as written, the Fedora maintainer can get his package back later if he wants. CU thl From Lam at Lam.pl Thu Jun 28 05:55:02 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 28 Jun 2007 07:55:02 +0200 Subject: portage vs yum In-Reply-To: <1182979807.2890.20.camel@hodge> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <1182979261.4523.5.camel@pensja.lam.pl> <1182979807.2890.20.camel@hodge> Message-ID: <1183010102.4453.6.camel@pensja.lam.pl> Dnia 27-06-2007, ?ro o godzinie 17:30 -0400, seth vidal napisa?(a): > It doesn't notify you that it is 'updating for dependencies'? Can you > give me a test case so I can look at it? I was talking about upgrading a library and breaking dependencies. Kevin's right, though, it's fixed in 3.2.1, I haven't upgraded my Rawhide for few days now, so I stand corrected. An open question: is there a way to make yum update my rawhide, when there are broken dependencies in the repos? Apt gives me "upgrade" which upgrades only packages that can be upgraded, leaving out a small subset of packages with broken interdependencies. Apt also gives me "dist-upgrade", which removes packages that would otherwise keep others from upgrading, depending on older versions. Not to mention apt-shell, where I can decide on a per-package basis. Yum, OTOH, simply refuses to upgrade at all, spitting some depsolving errors. Going for "yum install " isn't an option, you know :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From david at lovesunix.net Thu Jun 28 06:08:22 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 28 Jun 2007 08:08:22 +0200 Subject: portage vs yum In-Reply-To: References: Message-ID: <1183010902.2865.21.camel@dawkins> ons, 27 06 2007 kl. 06:14 +0000, skrev Thufir: > Please switch to something like portage, which builds from source. This > would eliminate, or at least, significantly reduce, the need for me to do > things like build lshw from source because, and correct me if I'm wrong, > it'd be easier to leave "in" and would require less maintenance. That is the single least QA friendly thing I've ever heard uttered. By not just allowing but encouraging users to mix and match compiler and linker settings you make it entirely impossible to do proper QA on the software as things stand. We need a fixed point of reference to do our job. As someone with a lengthy past in the Gentoo world I will be happy to provide you a list of the kinds of bug reports that would cause but let's not embarrass anyone with the horror stories. If such a model was ever adopted in Fedora I would be the first to leave as it would make my continued contribution to the project impossibly hard, it's tough enough to keep up with the small area I have to do testing on already as it is. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From pmatilai at laiskiainen.org Thu Jun 28 06:26:23 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 28 Jun 2007 09:26:23 +0300 (EEST) Subject: portage vs yum In-Reply-To: References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <47062.65.223.36.19.1182972580.squirrel@webmail.thecodergeek.com> Message-ID: On Wed, 27 Jun 2007, Kevin Kofler wrote: > Peter Gordon thecodergeek.com> writes: >> IIRC, whereas Yum and other binary-based systems such as APT track literal >> libraries (e.g., "libfoo.so.42(ABI_TAG)"), > > That's how RPM does it (and yum and apt-rpm then compute dependencies > based on that information), yes. > > DPKG doesn't support that, so Debian's solution is to just call the package > providing libfoo.so.42 libfoo42, so when libfoo.so.43 comes out, the packages > will require libfoo43 and apt will know that libfoo42 is insufficient. DPKG does support virtual provides/requires (which the soname dependencies essentially are) just fine, and .deb build can be told to extract automatic soname dependencies. The difference there is that the soname dependencies are resolved to package names at *build* time, not runtime like normally in rpm world. This means dramatically less junk for depsolver to handle, but it also means much, much stricter packaging policies must be used. Like the library package naming you mention, and that packages can't be split without rebuilding depending packages etc. - Panu - From tla at rasmil.dk Thu Jun 28 07:07:50 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Thu, 28 Jun 2007 09:07:50 +0200 Subject: Glade3 [was: glade3 in fedora 7] In-Reply-To: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> References: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> Message-ID: <46835E46.9090404@rasmil.dk> SmootherFrOgZ wrote: > Well, > Glade3 has been packaged for fedora 7 (for now) with some improvment > and fix. > Before request a review for this package, i need to make some > additionnal test. > > I think that there were some question about the both work of glade2 > and glade3 together (tell if i'm wrong) > currently, the both isntalled work well. > > If someone if interessting to test it also, i'll glad to point it > where he can get it. > > > Cheers, > > -- > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB I would like to test it too. Tim From petersen at redhat.com Thu Jun 28 08:30:07 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 28 Jun 2007 18:30:07 +1000 Subject: [announcement] Fedora I18n IRC meeting Message-ID: <4683718F.9060204@redhat.com> We would have a first open meeting of the Fedora I18n Project on IRC next week: Place: #fedora-i18n on Freenode Time: 2007-07-02 06:00 UTC [1] Agenda: - desktop input method install defaults and configuration - i18n comps - renaming of fonts-* to reflect upstream projects - plans for next meeting - open discussion Jens [1] $ date -d "2007-07-02 06:00 UTC" or http://www.timeanddate.com/worldclock/fixedtime.html?month=7&day=2&year=2007&hour=6&min=0 Probably we will do the next meeting at a different time which will make it easier for people in different timezones to join. From m-lists at biscuit.org.uk Thu Jun 28 08:47:42 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 28 Jun 2007 09:47:42 +0100 (BST) Subject: fedora for ARM In-Reply-To: <46661F43.8060904@marvell.com> References: <20070602032955.GC16918@xi.wantstofly.org> <20070604154744.543b041d.zaitcev@redhat.com> <46661F43.8060904@marvell.com> Message-ID: > The ARM distro will also be unlike x86 distros in that it wont be of much use > to have ISOs. That depends on what hardware you're using. For example, I have one of these http://www.iyonix.com/ which Fedora could support (if there was a Linux 2.6 port to that hardware) which would benefit from ISOs. I haven't yet made ISOs for my ARM port of Slackware, but people ask where they are -- some people prefer to download something in its entirety and scribble the distribution name and number onto a CD. Lennert it's great to see your Fedora ARM work getting attention now: there appears to me that a number of important Debian fixes tend to stay local - it'll be great to see your work be pushed upstream. s. -- Stuart Winter www.armedslack.org From j.w.r.degoede at hhs.nl Thu Jun 28 09:10:59 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 28 Jun 2007 11:10:59 +0200 Subject: Fedora 8's FUDCon In-Reply-To: <200706272237.52870.jkeating@redhat.com> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> Message-ID: <46837B23.40301@hhs.nl> Jesse Keating wrote: > On Wednesday 27 June 2007 22:27:19 Scott Berry wrote: >> Max, >> >> Where would I find the list of suggestions for F8. I would be interested >> in reading what you have planned so far. > > http://fedoraproject.org/wiki/Releases/8/FeatureList > FYI: I've been running a single man (sofar) attempt to get internet / easy access keys to work out of the box with F-8, not sure if this counts as a feature, see: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02236.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245576 I can create a wiki page for this if you want. Regards, Hans From mlichvar at redhat.com Thu Jun 28 09:25:48 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 28 Jun 2007 11:25:48 +0200 Subject: utmp and friends In-Reply-To: <20070627122524.GD23234@nostromo.devel.redhat.com> References: <20070626163237.GE7258@localhost> <20070626222639.GB8397@nostromo.devel.redhat.com> <20070627082200.GB21279@localhost> <20070627122524.GD23234@nostromo.devel.redhat.com> Message-ID: <20070628092548.GD21279@localhost> On Wed, Jun 27, 2007 at 08:25:24AM -0400, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > > The entire idea of utempter is so that the terminal *doesn't* need to be > > > setgid - if it's setgid, what's the point of a helper? > > > > Well, the terminal doesn't need to be setgid utmp, but only utempter. > > Setgid utempter allows only adding/removing entries in utmp while > > setgid utmp allows unrestricted access. > > Only if it's coded wrong (doesn't drop privs, etc.). By adding a > setgid to the binary, you're making the point of separating it > merely a code-sharing issue, as opposed to any huge security gains. > > I'd remove the block on the directory - basically, you're intentionally > breaking user's environments for illusory security. Ok, I've filed a bug report to drop the requirement in libutempter (#246063). -- Miroslav Lichvar From david at lovesunix.net Thu Jun 28 09:33:54 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 28 Jun 2007 11:33:54 +0200 Subject: Fedora 8's FUDCon In-Reply-To: <46837B23.40301@hhs.nl> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> <46837B23.40301@hhs.nl> Message-ID: <1183023234.2865.28.camel@dawkins> tor, 28 06 2007 kl. 11:10 +0200, skrev Hans de Goede: > Jesse Keating wrote: > > On Wednesday 27 June 2007 22:27:19 Scott Berry wrote: > >> Max, > >> > >> Where would I find the list of suggestions for F8. I would be interested > >> in reading what you have planned so far. > > > > http://fedoraproject.org/wiki/Releases/8/FeatureList > > > > FYI: I've been running a single man (sofar) attempt to get internet / easy > access keys to work out of the box with F-8, not sure if this counts as a > feature, see: > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02236.html > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245576 > > I can create a wiki page for this if you want. Feats of heroism would count as features. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From fedora at leemhuis.info Thu Jun 28 10:01:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 Jun 2007 12:01:27 +0200 Subject: Fedora 8's FUDCon In-Reply-To: <46837B23.40301@hhs.nl> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> <46837B23.40301@hhs.nl> Message-ID: <468386F7.7030102@leemhuis.info> On 28.06.2007 11:10, Hans de Goede wrote: > Jesse Keating wrote: >> On Wednesday 27 June 2007 22:27:19 Scott Berry wrote: >>> Max, >>> >>> Where would I find the list of suggestions for F8. I would be interested >>> in reading what you have planned so far. >> http://fedoraproject.org/wiki/Releases/8/FeatureList >> > > FYI: I've been running a single man (sofar) attempt to get internet / easy > access keys to work out of the box with F-8, not sure if this counts as a > feature, see: > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02236.html > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245576 > > I can create a wiki page for this if you want. /me is confused What about those pages: http://fedoraproject.org/wiki/SIGs/Laptop/HotKeys And how is your project related to that effort and what Florian wrote in https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02262.html Just wondering. CU thl From sundaram at fedoraproject.org Thu Jun 28 10:39:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 16:09:52 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <1182968641.5337.1.camel@metroid.rdu.redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <1182968641.5337.1.camel@metroid.rdu.redhat.com> Message-ID: <46838FF8.8080601@fedoraproject.org> Will Woods wrote: > On Wed, 2007-06-27 at 21:37 +0530, Rahul Sundaram wrote: >> Christopher Aillon wrote: >>> Martin Sourada wrote: >>>> 1. How's the work on xulrunner going (if there is someone who works on >>>> it)? >>> Good. >>> >>>> 2. Is it targeted on F8 or not? >>> Yes. >>> >>>> 3. Why is it not mentioned on wiki[1]? >>> Shrug. >> It would be better to write down the details in the wiki rather than >> shrugging it off. We would like to depend on it for the release notes >> for example rather than trying to parse change logs to get the important >> changes from thousands of packages as being done currently. > > If you've got time to chide the maintainer about it, you've got time to > help the maintainer and write down the details in the wiki yourself. > > Just a thought. How am I supposed to guess what the plans are? If maintainers don't tell anyone else there is no chance for anyone else to participate or give feedback. Rahul From sundaram at fedoraproject.org Thu Jun 28 10:42:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 16:12:26 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <4682A26F.7070104@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> <4682A26F.7070104@redhat.com> Message-ID: <46839092.7000608@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Christopher Aillon wrote: >> >>> That makes no sense. Are you seriously telling me that you ratify >>> changes that may be sub-par with the intent that they can be changed? >> >> No but policies can be ratified with the understanding that they are >> not written in stone. >> >>> Sounds like you need to revise your ratification process (or lack >>> thereof) before people should feel comfortable following anything >>> that gets "voted" on. >> >> That's a FESCo decision that I am not involved with. > > I wonder if I'm the only person that got the impression you were > invovled with it based on your comments. Don't try to strongarm people > into following _draft_ policies based on the fact that you personally > _expect_ it to be ratified. I am not personally involved with it. The policy is mostly documenting the process that we have followed even in the previous release so I do expect maintainers to take an effort to describe what the plans are. Rahul From sundaram at fedoraproject.org Thu Jun 28 10:43:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 16:13:49 +0530 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182967074.25376.11.camel@weaponx.rchland.ibm.com> References: <1182961567.6652.7.camel@kennedy> <1182965507.25376.5.camel@weaponx.rchland.ibm.com> <4682A05B.6020001@fedoraproject.org> <1182967074.25376.11.camel@weaponx.rchland.ibm.com> Message-ID: <468390E5.5040904@fedoraproject.org> Josh Boyer wrote: > On Wed, 2007-06-27 at 23:07 +0530, Rahul Sundaram wrote: >> Josh Boyer wrote: >>> On Wed, 2007-06-27 at 12:26 -0400, Brian Pepple wrote: >>>> /topic FESCO-Meeting -- MISC -- Feature Polict Draft - >>>> http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft >>> Please pull this one. It's only had two days of commenting on the list. >> Do you want to define how long you want to wait? > > Yes. More than 2 days. You got to be more specific. How many days? Rahul From sundaram at fedoraproject.org Thu Jun 28 10:45:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 16:15:50 +0530 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <1182966629.26681.17.camel@aglarond.local> References: <1182961567.6652.7.camel@kennedy> <4682A242.7020806@fedoraproject.org> <1182966629.26681.17.camel@aglarond.local> Message-ID: <4683915E.3030302@fedoraproject.org> Jeremy Katz wrote: > On Wed, 2007-06-27 at 23:15 +0530, Rahul Sundaram wrote: >> I would like FESCo to look at making the changes necessary in enabling >> some form of live upgrades in Fedora. Does a package like this with >> maybe modifications to Anaconda to point to the next release directly >> instead of having to feed the URL's make sense? > > FESCo discussing it doesn't help. What needs to happen is that somebody > needs to actually write the code. Which yes, will require anaconda > changes and thus will require sending patches to anaconda-devel-list. A contributor waiting with a spec file has asked whether he can submit it and got no response. Wouldn't FESCo be willing to answer that? Rahul From jochen.schlick at comsoft.de Thu Jun 28 11:01:25 2007 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Thu, 28 Jun 2007 13:01:25 +0200 Subject: portage vs yum In-Reply-To: <200706272252.06557.lightsolphoenix@gmail.com> References: <200706272109.45689.jkeating@redhat.com> <200706272252.06557.lightsolphoenix@gmail.com> Message-ID: <46839505.5050401@comsoft.de> Kelly wrote: > On Wednesday, June 27, 2007 9:51 pm Thufir wrote: >> Going back to expediency, ebuild ease of creation versus rpm ease of >> creation: e-builds are easier due to the looser integration? What are >> other factors, please? > > I don't know about ebuilds, but RPM's are insanely easy to build if you know > how. I mean, you can tear off a huge collection of RPM's in a very short > time with a bit of knowledge of the spec file, and technically generating > your own RPM's = compiling from source anyway (I did 5 packages yesterday in > half an hour, though I doubt they'd fit the project's guidelines...). > > I much prefer RPM to other systems I've used to handle this sort of thing, > because they're easy to make and easy to use. > There is !no! difference in complexity of ebuild creation or rpm-spec creation. If you have a broken source tar-file and want to create an ebuild or a rpm-spec you have the !same! problems with your rpm-spec-file as with your ebuild file. You have nearly the same pre/post(un)install scripts to write and the runtime/buildtime dependency hell is also the same (ebuild:RDEPEND/DEPEND, spec:Requires/BuildRequires...) Therefore I can't see that ebuilds are looser integrated. Perhaps you must be a better shell programmer when you want to create your own ebuilds - that's all. best regards -- --------------------------------------------------------------------------- Jochen Schlick From opensource at till.name Thu Jun 28 11:02:09 2007 From: opensource at till.name (Till Maas) Date: Thu, 28 Jun 2007 13:02:09 +0200 Subject: Plan for tomorrows (20070628) FESCO meeting In-Reply-To: <468390E5.5040904@fedoraproject.org> References: <1182961567.6652.7.camel@kennedy> <1182967074.25376.11.camel@weaponx.rchland.ibm.com> <468390E5.5040904@fedoraproject.org> Message-ID: <200706281302.10838.opensource@till.name> On Do Juni 28 2007, Rahul Sundaram wrote: > You got to be more specific. How many days? Imho it should be at least 8 days, this way everyone, who only works on Fedora on a specific day of the week has a chance to comment on this. Regards, Till From buildsys at fedoraproject.org Thu Jun 28 11:08:27 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 28 Jun 2007 07:08:27 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-28 Message-ID: <20070628110827.584F7152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 28 asymptote-1.31-1.fc6 berusky-1.1-5.fc6 c-ares-1.4.0-1.fc6 NEW crystal-project-20070620-3.fc6 : Crystal Project KDE Icon set em8300-kmod-0.16.2-2.2.6.20_1.2962.fc6 emacs-vm-8.0.0.453-2.fc6.1 fatsort-0.9.7.1-1.fc6 geda-docs-20070626-1.fc6 geda-examples-20070626-1.fc6 geda-gattrib-20070626-1.fc6 geda-gnetlist-20070626-1.fc6 geda-gschem-20070626-1.fc6 geda-gsymcheck-20070626-1.fc6 geda-symbols-20070626-1.fc6 geda-utils-20070626-1.fc6 gnonlin-0.10.8-1.fc6 NEW libcgi-1.0-5.fc6 : CGI easy as C libgeda-20070626-1.fc6 NEW mod_dnssd-0.5-2.fc6 : An Apache HTTPD module which adds Zeroconf support ntfs-config-1.0-0.4.rc5.fc6 ntfsprogs-1.13.1-4.fc6 NEW perl-CGI-FormBuilder-3.0501-4.fc6 : Easily generate and process stateful forms NEW perl-CGI-Prototype-0.9053-4.fc6 : Create a CGI application by subclassing NEW perl-CGI-Session-4.20-2.fc6 : Persistent session data in CGI applications pyicq-t-0.8-4.a.fc6 NEW re2c-0.12.1-2.fc6 : Tool for generating C-based recognizers from regular expressions reciteword-0.8.3-4.fc6 SimGear-0.3.10-4.fc6.1 Packages built and released for Fedora Extras 5: 12 c-ares-1.4.0-1.fc5 geda-docs-20070626-1.fc5 geda-examples-20070626-1.fc5 geda-gattrib-20070626-1.fc5 geda-gnetlist-20070626-1.fc5 geda-gschem-20070626-1.fc5 geda-gsymcheck-20070626-1.fc5 geda-symbols-20070626-1.fc5 geda-utils-20070626-1.fc5 libgeda-20070626-1.fc5 ntfsprogs-1.13.1-4.fc5 NEW perl-CGI-Prototype-0.9053-4.fc5 : Create a CGI application by subclassing Changes in Fedora Extras 6: asymptote-1.31-1.fc6 -------------------- * Wed Jun 27 2007 Jose Pedro Oliveira - 1.31-1 - Update to 1.31. berusky-1.1-5.fc6 ----------------- * Tue Jun 26 2007 Martin Stransky 1.1-5 - added a menu entry and an icon c-ares-1.4.0-1.fc6 ------------------ * Wed Jun 27 2007 Tom "spot" Callaway 1.4.0-1 - bump to 1.4.0 (resolves bugzilla 243591) - get rid of static library (.a) crystal-project-20070620-3.fc6 ------------------------------ * Tue Jun 26 2007 Chitlesh Goorah 20070620-3 - removed annoying linspire logo from konqueror * Mon Jun 25 2007 Chitlesh Goorah 20070620-2 - set 644 permissions on icons * Thu Jun 21 2007 Chitlesh Goorah 20070620-1 - Initial Package em8300-kmod-0.16.2-2.2.6.20_1.2962.fc6 -------------------------------------- * Tue Jun 26 2007 Ville Skytt? - Rebuild for kernel 2.6.20-1.2962.fc6. emacs-vm-8.0.0.453-2.fc6.1 -------------------------- * Wed Jun 27 2007 Jonathan G. Underwood - 8.0.0.453-2.1 - Fix typo * Tue Jun 26 2007 Jonathan G. Underwood - 8.0.0.453-2 - Ensure all files in /usr/bin have exec bit set (BZ #245740) - Correct a date of the pgg*.el CVS checkout in the comments - Fix changelog typo * Tue Jun 19 2007 Jonathan G. Underwood - 8.0.0.453-1 - Update to version 8.0.0 devo 453 which removes the need for the vmrf patch - No longer need to bundle vcard stuff as that is included upstream - Spec file cleanups - No longer use separate pixmaps fatsort-0.9.7.1-1.fc6 --------------------- * Sun May 06 2007 Till Maas - 0.9.7.1-1 - new version (fatsort supports >4GB filesystems now) geda-docs-20070626-1.fc6 ------------------------ * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release geda-examples-20070626-1.fc6 ---------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release geda-gattrib-20070626-1.fc6 --------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-gnetlist-20070626-1.fc6 ---------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 - dropped patch geda-gnetlist-20061020-backend-list.patch geda-gschem-20070626-1.fc6 -------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-gsymcheck-20070626-1.fc6 ----------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-symbols-20070626-1.fc6 --------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release geda-utils-20070626-1.fc6 ------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 gnonlin-0.10.8-1.fc6 -------------------- * Wed Jun 27 2007 Brian Pepple - 0.10.8-1 - Update to 0.10.8. - Bump gstreamer version required. - Add dist tag. libcgi-1.0-5.fc6 ---------------- * Tue Jun 26 2007 Jose Pedro Oliveira - 1.0-5 - make install: override LIBDIR in order to support /usr/lib64. * Tue Jun 26 2007 Jose Pedro Oliveira - 1.0-4 - Install the header files in %{_includedir}/%{name}. libgeda-20070626-1.fc6 ---------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - New upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-2 - dump release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release - dropped useless -doc package * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 mod_dnssd-0.5-2.fc6 ------------------- * Mon Jun 25 2007 Ignacio Vazquez-Abrams 0.5-2 - Add LoadModule to the config file * Mon Jun 18 2007 Ignacio Vazquez-Abrams 0.5-1 - Initial RPM release ntfs-config-1.0-0.4.rc5.fc6 --------------------------- * Tue Jun 26 2007 Xavier Lamien - 1.0-0.4.rc5 - Udpated Release. ntfsprogs-1.13.1-4.fc6 ---------------------- * Wed Jun 27 2007 Tom "spot" Callaway 1.13.1-4 - fix packaging mistake (resolve bz 245329) perl-CGI-FormBuilder-3.0501-4.fc6 --------------------------------- * Wed Jun 20 2007 Jeffrey C. Ollie - 3.0501-4 - Trim the description to something reasonable. - Delete odd .orig file * Fri Jun 15 2007 Jeffrey C. Ollie - 3.0501-3 - BR perl(CGI::FastTemplate) * Fri Jun 15 2007 Jeffrey C. Ollie - 3.0501-2 - Don't BR perl or perl-devel, instead BR specific Perl modules needed to build. - Proper license tag * Fri Jun 01 2007 Jeffrey C. Ollie - 3.0501-1 - First version for Fedora perl-CGI-Prototype-0.9053-4.fc6 ------------------------------- * Thu May 03 2007 Chris Weyl 0.9053-4 - bump perl-CGI-Session-4.20-2.fc6 --------------------------- * Sat Mar 17 2007 Andreas Thienemann 4.20-2 - Fixed perl-devel req pyicq-t-0.8-4.a.fc6 ------------------- * Wed Jun 27 2007 Jeffrey C. Ollie - 0.8-4.a - Update to 0.8a * Fri Dec 08 2006 Jeffrey C. Ollie - 0.8-3 - Fix up requires for mysql subpackage. * Fri Dec 08 2006 Jeffrey C. Ollie - 0.8-2 - Bump release and rebuild for Python 2.5 - Use macro for path to standard library - Eliminate provides/obsoletes pyicqt re2c-0.12.1-2.fc6 ----------------- * Wed Jun 20 2007 Matthias Saou 0.12.1-2 - Fix license tag to "Public Domain". - Update description with most recent text from the website. * Wed Jun 20 2007 Matthias Saou 0.12.1-1 - Spec file changes. reciteword-0.8.3-4.fc6 ---------------------- * Wed Jun 27 2007 Hu Zheng - 0.8.3-4 - Fix no .mo file problem. SimGear-0.3.10-4.fc6.1 ---------------------- * Wed Jun 27 2007 Tom "spot" Callaway 0.3.10-4.1 - fix bugzilla 245320 Changes in Fedora Extras 5: c-ares-1.4.0-1.fc5 ------------------ * Wed Jun 27 2007 Tom "spot" Callaway 1.4.0-1 - bump to 1.4.0 (resolves bugzilla 243591) - get rid of static library (.a) geda-docs-20070626-1.fc5 ------------------------ * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - fix ownership of /usr/share/gEDA/docs - #233792 * Sun Sep 10 2006 Chitlesh Goorah - 20061020-1 - New upstream release * Sun Sep 10 2006 Chitlesh Goorah - 20060906-2 - Rebuilt for FC-6 devel geda-examples-20070626-1.fc5 ---------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Sun Apr 01 2007 Chitlesh Goorah - 20070216-2 - TwoStageAmp bug fixes * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-gattrib-20070626-1.fc5 --------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-gnetlist-20070626-1.fc5 ---------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 - dropped patch geda-gnetlist-20061020-backend-list.patch * Mon Jan 08 2007 Chitlesh Goorah - 20061020-2 - rebuilt under compat-guile-16 - gnetlist patch that adds "-g help" option - added groff to BR geda-gschem-20070626-1.fc5 -------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 * Sun Feb 04 2007 Chitlesh Goorah - 20061020-3 - Fixed presence on Gnome menu * Mon Jan 08 2007 Chitlesh Goorah - 20061020-2 - rebuilt under compat-guile-16 geda-gsymcheck-20070626-1.fc5 ----------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 * Mon Jan 08 2007 Chitlesh Goorah - 20061020-2 - rebuilt under compat-guile-16 * Thu Nov 02 2006 Chitlesh Goorah - 20061020-1 - Upstream release 20061020 geda-symbols-20070626-1.fc5 --------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Mon Mar 12 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-utils-20070626-1.fc5 ------------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - new upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Mon Jan 08 2007 Chitlesh Goorah - 20061020-2 - rebuilt under compat-guile-16 libgeda-20070626-1.fc5 ---------------------- * Wed Jun 27 2007 Chitlesh Goorah - 20070626-1 - New upstream release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-2 - dump release * Thu Jun 14 2007 Chitlesh Goorah - 20070526-1 - new upstream release - dropped useless -doc package * Tue Apr 03 2007 Chitlesh Goorah - 20070216-3 - rebuild for fc6 and devel * Tue Apr 03 2007 Chitlesh Goorah - 20070216-2 - new upstream release on 2007 02 16 support for FC-5 * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 - bugfix: #233861 - unowned %{_datadir}/gEDA/ directory * Sat Jan 06 2007 Mamoru Tasaka - 20061020-3 - Fix the replacement for guile 1.6 * Thu Dec 07 2006 Chitlesh Goorah - 20061020-2 - Downgraded to guile-1.6 for BR * Wed Nov 01 2006 Chitlesh Goorah - 20061020-1 - New upstream release ntfsprogs-1.13.1-4.fc5 ---------------------- * Wed Jun 27 2007 Tom "spot" Callaway 1.13.1-4 - fix packaging mistake (resolve bz 245329) perl-CGI-Prototype-0.9053-4.fc5 ------------------------------- * Thu May 03 2007 Chris Weyl 0.9053-4 - bump For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From opensource at till.name Thu Jun 28 11:14:35 2007 From: opensource at till.name (Till Maas) Date: Thu, 28 Jun 2007 13:14:35 +0200 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706011139.04795.jkeating@redhat.com> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <1180708542.12595.295.camel@mccallum.corsepiu.local> <200706011139.04795.jkeating@redhat.com> Message-ID: <200706281314.37033.opensource@till.name> On Fr Juni 1 2007, Jesse Keating wrote: > We could get rid of buildsys-build by making a perhaps 'hidden' group > within comps that is the buildsys-build group, since mock can easily do a > groupinstall instead of a package install to populate the buildroot. These > two things together would obviate the need for a separate repo all > together. What is the progress here? Is there a bug / wiki page / whatever where the progress is tracked? Is there no way to sign the current rpms in buildgroups until this is solved this way? A ticket for the Infrastructure Team is open for 132 days now: https://admin.fedoraproject.org/tickets/customer.pl?Action=CustomerTicketZoom&TicketID=907 Regards, Till From j.w.r.degoede at hhs.nl Thu Jun 28 11:25:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 28 Jun 2007 13:25:16 +0200 Subject: Fedora 8's FUDCon In-Reply-To: <468386F7.7030102@leemhuis.info> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> <46837B23.40301@hhs.nl> <468386F7.7030102@leemhuis.info> Message-ID: <46839A9C.1020308@hhs.nl> Thorsten Leemhuis wrote: > On 28.06.2007 11:10, Hans de Goede wrote: >> Jesse Keating wrote: >>> On Wednesday 27 June 2007 22:27:19 Scott Berry wrote: >>>> Max, >>>> >>>> Where would I find the list of suggestions for F8. I would be interested >>>> in reading what you have planned so far. >>> http://fedoraproject.org/wiki/Releases/8/FeatureList >>> >> FYI: I've been running a single man (sofar) attempt to get internet / easy >> access keys to work out of the box with F-8, not sure if this counts as a >> feature, see: >> https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02236.html >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245576 >> >> I can create a wiki page for this if you want. > > /me is confused > > What about those pages: > http://fedoraproject.org/wiki/SIGs/Laptop/HotKeys > I didn't know about those pages, it seems that our efforts pretty much overlaps, I do believe however that filing this under laptop is (very) wrong, as many normal keyboards also have extra keys. > And how is your project related to that effort and what Florian wrote in > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02262.html > What Florian wrote there, can be summarized as: "I agree", we seem to both be thinking very much in the same direction. I've send him the mail address of Stanislav Brabec in private, as he wanted to coordinate his efforts with Stanislav's . Regards, Hans From jkeating at redhat.com Thu Jun 28 11:45:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 07:45:01 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706281314.37033.opensource@till.name> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706011139.04795.jkeating@redhat.com> <200706281314.37033.opensource@till.name> Message-ID: <200706280745.04308.jkeating@redhat.com> On Thursday 28 June 2007 07:14:35 Till Maas wrote: > What is the progress here? Is there a bug / wiki page / whatever where the > progress is tracked? Is there no way to sign the current rpms in > buildgroups until this is solved this way? A ticket for the Infrastructure > Team is open for 132 days now: > https://admin.fedoraproject.org/tickets/customer.pl?Action=CustomerTicketZo >om&TicketID=907 Progress is waiting for a 'round to-it cycle to come about. This is something that would happen in rawhide first, and would probably only be useful to you once F8 goes out. I don't really want to play with out Fedora 7 is going since it's already been released. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Thu Jun 28 12:36:35 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 28 Jun 2007 14:36:35 +0200 Subject: Eclipse plugin version 320v20060603 is badly formatted Message-ID: <13dbfe4f0706280536o17256668ref5f2ce5f8632ccc@mail.gmail.com> Hello there, I'm trying to rpmbuild "ivi". However, the "ant" fails with /ivi-1.0.2_1-src/configure.xml:40: plugin version 320v20060603 is badly formatted: java.lang.NumberFormatException: invalid character at position 4 in 320v20060603 Is that ok with the "v" in the version of /usr/share/eclipse/plugins/org.eclipse.core.runtime_3.2.0.v20060603.jar ? Chitlesh -- http://clunixchit.blogspot.com From pertusus at free.fr Thu Jun 28 12:32:47 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Jun 2007 14:32:47 +0200 Subject: portage vs yum In-Reply-To: <46839505.5050401@comsoft.de> References: <200706272109.45689.jkeating@redhat.com> <200706272252.06557.lightsolphoenix@gmail.com> <46839505.5050401@comsoft.de> Message-ID: <20070628123247.GC15974@free.fr> On Thu, Jun 28, 2007 at 01:01:25PM +0200, Jochen Schlick wrote: > spec:Requires/BuildRequires...) Therefore I can't see that ebuilds > are looser integrated. It isn't the ebuilds per se that are less integrated, but the gentoo packaging. If you want an example you can have a look at the wdm packaging (this is something I know because I maintain it in fedora). In gentoo it is simply installed, in Fedora I try to use a fedora background, an Xsession script that is the same than for gdm/kdm/..., and pre post-scripts that are the same than xdm, and lastly allow to use /usr/share/xsessions/ for the window manager lists. -- Pat From pertusus at free.fr Thu Jun 28 12:36:27 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Jun 2007 14:36:27 +0200 Subject: Upgrade path question In-Reply-To: <1182986379.30663.420.camel@localhost.localdomain> References: <1182964907.30663.402.camel@localhost.localdomain> <20070627175123.GC29669@nostromo.devel.redhat.com> <20070627211839.GC8013@free.fr> <1182986379.30663.420.camel@localhost.localdomain> Message-ID: <20070628123627.GD15974@free.fr> On Wed, Jun 27, 2007 at 07:19:39PM -0400, Adam Jackson wrote: > On Wed, 2007-06-27 at 23:18 +0200, Patrice Dumas wrote: > > On Wed, Jun 27, 2007 at 01:51:23PM -0400, Bill Nottingham wrote: > > > > > > Historically, we've supported upgrades from N-2 on the premise that that's > > > what's reasonable to test and make sure works; moreover, with the slightly > > > extended lifecycle, someone can be on a maintained FC5 installation when > > > F7 is released. Anything other than that is gravy. There hasn't been specific > > > policy about garbage collecting obsoletes, to the the best of my knowledge. > > > > > > Strawman would be if we're supporting N-2, to garbage collect after N-4? > > > > I think we should not say anything about garbage collecting obsoletes, > > and let the maintainer do whatever they prefer. > > That's effectively equivalent to saying "garbage collect at N-2", since > _some_ maintainer will do so, which then means the rest of the system > might as well too since any update over a stride larger than that will > have to be manual anyway. I think you misinterpreted what I said, what I want is to avoid having garbage collecting been seen as mandatory, such that those who want to maintain old cruft still can. It may be for some packages only, but still be interesting for the maintainer, a obvious reason being, for example, to avoid diverging with an EPEL version. -- Pat From opensource at till.name Thu Jun 28 12:44:09 2007 From: opensource at till.name (Till Maas) Date: Thu, 28 Jun 2007 14:44:09 +0200 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706280745.04308.jkeating@redhat.com> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706281314.37033.opensource@till.name> <200706280745.04308.jkeating@redhat.com> Message-ID: <200706281444.09995.opensource@till.name> On Do Juni 28 2007, Jesse Keating wrote: > useful to you once F8 goes out. I don't really want to play with out > Fedora 7 is going since it's already been released. What should go wrong when someone with the gpg key signs the rpms? And the rpms are really trivial, so it is easy to verify them once. And afaik they are not updated very often, so it is not much work. Regards, Till From jkeating at redhat.com Thu Jun 28 12:55:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 08:55:14 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706281444.09995.opensource@till.name> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706280745.04308.jkeating@redhat.com> <200706281444.09995.opensource@till.name> Message-ID: <200706280855.14567.jkeating@redhat.com> On Thursday 28 June 2007 08:44:09 Till Maas wrote: > What should go wrong when someone with the gpg key signs the rpms? And the > rpms are really trivial, so it is easy to verify them once. And afaik they > are not updated very often, so it is not much work. The answer isn't to sign these rpms which don't exist anywhere else in the distribution. The answer is to add a "buildsys-build" group or other such named group to the comps file and define what packages should be in there that way, and have mock just do a 'groupinstall buildsys-build', which would pull from the shipped repos. This does away with the need of a 'buildgroups' repo all together, relies upon the shipped / signed rpms, and existing method of defining groups. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Thu Jun 28 13:06:08 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 28 Jun 2007 09:06:08 -0400 Subject: Fedora 8's FUDCon In-Reply-To: <46837B23.40301@hhs.nl> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> <46837B23.40301@hhs.nl> Message-ID: <1183035968.4378.2.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-06-28 at 11:10 +0200, Hans de Goede wrote: > FYI: I've been running a single man (sofar) attempt to get internet / easy > access keys to work out of the box with F-8, not sure if this counts as a > feature, see: You may work in isolation, but you are certainly not the only one trying to improve the keyboard situation recently. I guess it would be better to get in touch with other people who are looking at keyboard problems, otherwise you are only setting yourself up for failure and duplicate work... From rc040203 at freenet.de Thu Jun 28 13:13:29 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 28 Jun 2007 15:13:29 +0200 Subject: OpenSceneGraph Message-ID: <1183036409.24184.72.camel@mccallum.corsepiu.local> Hi, I've several times been asked to upgrade OpenSceneGraph to OpenSceneGraph-2.0 (on rawhide and may-be FC7) So far, there remain a couple of details unclear to me, I'd like to see clarified: * OpenSceneGraph-2.0 is completely incompatible to OpenSceneGraph-1.x! * Packaging, features and all SONAME have changed! Questions: * Is there anybody out there who is actively using (esp. developing for) OpenSceneGraph-1? * Is there anybody out there who is actively using Producer or who has a package which depends on (OSG-1's) Producer (OpenSceneGraph-2 has dropped Producer). Should you answer to any of the questions above with "yes", please speak up ASAP. TIA. Ralf From lxtnow at gmail.com Thu Jun 28 13:18:59 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Thu, 28 Jun 2007 09:18:59 -0400 Subject: Glade3 [was: glade3 in fedora 7] In-Reply-To: <46835E46.9090404@rasmil.dk> References: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> <46835E46.9090404@rasmil.dk> Message-ID: <62bc09df0706280618k6f93b30esfc9ac30a4a30b36b@mail.gmail.com> You could catch it here: http://download.tuxfamily.org/lxtnow/fedora/testing Only available for F-7_i386 (for now), if someone wanted to test it on x86_64, just ask ;-) some feedback has already reported to me about resize of widgets that don't really work well. Feel free to report all stuff that need to be fix. -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Thu Jun 28 13:22:26 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 28 Jun 2007 15:22:26 +0200 Subject: Fedora 8's FUDCon In-Reply-To: <468386F7.7030102@leemhuis.info> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> <46837B23.40301@hhs.nl> <468386F7.7030102@leemhuis.info> Message-ID: <4683B612.4000009@gmail.com> Thorsten Leemhuis wrote: > On 28.06.2007 11:10, Hans de Goede wrote: > >> Jesse Keating wrote: >> >>> On Wednesday 27 June 2007 22:27:19 Scott Berry wrote: >>> >>>> Max, >>>> >>>> Where would I find the list of suggestions for F8. I would be interested >>>> in reading what you have planned so far. >>>> >>> http://fedoraproject.org/wiki/Releases/8/FeatureList >>> >>> >> FYI: I've been running a single man (sofar) attempt to get internet / easy >> access keys to work out of the box with F-8, not sure if this counts as a >> feature, see: >> https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02236.html >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245576 >> >> I can create a wiki page for this if you want. >> > > /me is confused > > What about those pages: > http://fedoraproject.org/wiki/SIGs/Laptop/HotKeys > > And how is your project related to that effort and what Florian wrote in > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02262.html > > Just wondering. > > CU > thl > > > > http://people.freedesktop.org/~hughsient/quirk/ From denis at poolshark.org Thu Jun 28 13:35:35 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 28 Jun 2007 15:35:35 +0200 Subject: glibmm24 & gtkmm24 make vmware6 fail In-Reply-To: <1182995194.23776.0.camel@vader.jdub.homelinux.org> References: <468312AA.2010008@gmail.com> <1182995194.23776.0.camel@vader.jdub.homelinux.org> Message-ID: <4683B927.4030900@poolshark.org> Josh Boyer wrote: > On Thu, 2007-06-28 at 09:45 +0800, Ken YANG wrote: >> hi all: >> >> the glibmm24 and gtkmm24 in rawhide make vmware6 failed: > > Tell VMWare General note: dry responses like this are uncalled for. Because VMWare trips this problem doesn't necessarily mean its their fault. This is a known ABI breakage in Glib 2.13. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245634 Matthias, any word on adding the patch (in SVN already) ? cheers, -denis From denis at poolshark.org Thu Jun 28 13:38:10 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 28 Jun 2007 15:38:10 +0200 Subject: glibmm24 & gtkmm24 make vmware6 fail In-Reply-To: <1182995194.23776.0.camel@vader.jdub.homelinux.org> References: <468312AA.2010008@gmail.com> <1182995194.23776.0.camel@vader.jdub.homelinux.org> Message-ID: <4683B9C2.6000002@poolshark.org> Josh Boyer wrote: > On Thu, 2007-06-28 at 09:45 +0800, Ken YANG wrote: >> hi all: >> >> the glibmm24 and gtkmm24 in rawhide make vmware6 failed: > > Tell VMWare General note: dry responses like this are uncalled for. Because VMWare trips this problem doesn't necessarily mean its their fault. This is a known ABI breakage in Glib 2.13. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245634 Matthias, any word on adding the patch (in SVN already) ? cheers, -denis From mclasen at redhat.com Thu Jun 28 13:38:40 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 28 Jun 2007 09:38:40 -0400 Subject: glibmm24 & gtkmm24 make vmware6 fail In-Reply-To: <4683B9C2.6000002@poolshark.org> References: <468312AA.2010008@gmail.com> <1182995194.23776.0.camel@vader.jdub.homelinux.org> <4683B9C2.6000002@poolshark.org> Message-ID: <1183037920.4378.4.camel@dhcp83-186.boston.redhat.com> On Thu, 2007-06-28 at 15:38 +0200, Denis Leroy wrote: > Josh Boyer wrote: > > On Thu, 2007-06-28 at 09:45 +0800, Ken YANG wrote: > >> hi all: > >> > >> the glibmm24 and gtkmm24 in rawhide make vmware6 failed: > > > > Tell VMWare > > General note: dry responses like this are uncalled for. Because VMWare > trips this problem doesn't necessarily mean its their fault. > > This is a known ABI breakage in Glib 2.13. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245634 > > Matthias, any word on adding the patch (in SVN already) ? > It'll be fixed in the next devel snapshot, hopefully before the end of the week. From sheltren at cs.ucsb.edu Thu Jun 28 13:46:26 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 28 Jun 2007 09:46:26 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: <200706280855.14567.jkeating@redhat.com> References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706280745.04308.jkeating@redhat.com> <200706281444.09995.opensource@till.name> <200706280855.14567.jkeating@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 28, 2007, at 8:55 AM, Jesse Keating wrote: > On Thursday 28 June 2007 08:44:09 Till Maas wrote: >> What should go wrong when someone with the gpg key signs the rpms? >> And the >> rpms are really trivial, so it is easy to verify them once. And >> afaik they >> are not updated very often, so it is not much work. > > The answer isn't to sign these rpms which don't exist anywhere else > in the > distribution. The answer is to add a "buildsys-build" group or > other such > named group to the comps file and define what packages should be in > there > that way, and have mock just do a 'groupinstall buildsys-build', > which would > pull from the shipped repos. This does away with the need of a > 'buildgroups' > repo all together, relies upon the shipped / signed rpms, and > existing method > of defining groups. > This is how mock used to work (albeit using yumgruops.xml instead of comps.xml), and it was decided (on fedora-buildsys-list, IIRC) that it would be better to use an RPM to define the base buildroot packages. Personally, I feel that having an external 'buildgroups' repo lends itself well to those of us that may wish to modify the packages which get installed by mock by default. If Fedora does change how mock reads in this information, I would hope that it remains configureable in some way -- for example, if there is a 'groups' repo listed in a mock config, then use that instead of what's defined in comps. - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGg7uyKe7MLJjUbNMRAlanAKCM1T2DH7Oqq0iVZ8m7FxLVet1YLACbBfl2 5Jpaj5f3WfizV3rlWE97770= =nttK -----END PGP SIGNATURE----- From selinux at gmail.com Thu Jun 28 13:48:10 2007 From: selinux at gmail.com (Tom London) Date: Thu, 28 Jun 2007 06:48:10 -0700 Subject: glibmm24 & gtkmm24 make vmware6 fail In-Reply-To: <4683B9C2.6000002@poolshark.org> References: <468312AA.2010008@gmail.com> <1182995194.23776.0.camel@vader.jdub.homelinux.org> <4683B9C2.6000002@poolshark.org> Message-ID: <4c4ba1530706280648l4b3271bbk9a8d61f64c734b86@mail.gmail.com> On 6/28/07, Denis Leroy wrote: > Josh Boyer wrote: > > On Thu, 2007-06-28 at 09:45 +0800, Ken YANG wrote: > >> hi all: > >> > >> the glibmm24 and gtkmm24 in rawhide make vmware6 failed: > > > > Tell VMWare > > General note: dry responses like this are uncalled for. Because VMWare > trips this problem doesn't necessarily mean its their fault. > > This is a known ABI breakage in Glib 2.13. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245634 > > Matthias, any word on adding the patch (in SVN already) ? > > cheers, > -denis As per BZ entry, you can work around this until fixed by: VMWARE_USE_SHIPPED_GTK=yes vmware tom -- Tom London From skvidal at linux.duke.edu Thu Jun 28 13:50:03 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 28 Jun 2007 09:50:03 -0400 Subject: portage vs yum In-Reply-To: <1183010102.4453.6.camel@pensja.lam.pl> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <1182979261.4523.5.camel@pensja.lam.pl> <1182979807.2890.20.camel@hodge> <1183010102.4453.6.camel@pensja.lam.pl> Message-ID: <1183038603.2890.25.camel@hodge> On Thu, 2007-06-28 at 07:55 +0200, Leszek Matok wrote: > Dnia 27-06-2007, ?ro o godzinie 17:30 -0400, seth vidal napisa?(a): > > It doesn't notify you that it is 'updating for dependencies'? Can you > > give me a test case so I can look at it? > I was talking about upgrading a library and breaking dependencies. > Kevin's right, though, it's fixed in 3.2.1, I haven't upgraded my > Rawhide for few days now, so I stand corrected. > > An open question: is there a way to make yum update my rawhide, when > there are broken dependencies in the repos? Apt gives me "upgrade" which > upgrades only packages that can be upgraded, leaving out a small subset > of packages with broken interdependencies. Apt also gives me > "dist-upgrade", which removes packages that would otherwise keep others > from upgrading, depending on older versions. Not to mention apt-shell, > where I can decide on a per-package basis. Yum, OTOH, simply refuses to > upgrade at all, spitting some depsolving errors. Going for "yum install > " isn't an option, you know :) > look at the skip-broken plugin, it is packaged in f7 and rawhide. -sv From j.w.r.degoede at hhs.nl Thu Jun 28 13:49:05 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 28 Jun 2007 15:49:05 +0200 Subject: Fedora 8's FUDCon In-Reply-To: <1183035968.4378.2.camel@dhcp83-186.boston.redhat.com> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> <46837B23.40301@hhs.nl> <1183035968.4378.2.camel@dhcp83-186.boston.redhat.com> Message-ID: <4683BC51.8090102@hhs.nl> Matthias Clasen wrote: > On Thu, 2007-06-28 at 11:10 +0200, Hans de Goede wrote: > >> FYI: I've been running a single man (sofar) attempt to get internet / easy >> access keys to work out of the box with F-8, not sure if this counts as a >> feature, see: > > You may work in isolation, but you are certainly not the only one trying > to improve the keyboard situation recently. I guess it would be better > to get in touch with other people who are looking at keyboard problems, > otherwise you are only setting yourself up for failure and duplicate > work... > I know I'm not the only one, I've already been in contact about this with many people. See the links in my previous mail for a thorough description of what I've been working on and with whom I've talked about this. Regards, Hans From jkeating at redhat.com Thu Jun 28 14:07:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 10:07:26 -0400 Subject: http://buildsys.fedoraproject.org/buildgroups/7 ? In-Reply-To: References: <1180628241.12595.182.camel@mccallum.corsepiu.local> <200706280855.14567.jkeating@redhat.com> Message-ID: <200706281007.29851.jkeating@redhat.com> On Thursday 28 June 2007 09:46:26 Jeff Sheltren wrote: > Personally, I feel that having an external 'buildgroups' repo lends > itself well to those of us that may wish to modify the packages which > get installed by mock by default. ?If Fedora does change how mock > reads in this information, I would hope that it remains configureable > in some way -- for example, if there is a 'groups' repo listed in a > mock config, then use that instead of what's defined in comps. Mock wouldn't lose it's ability to use a package instead of a group, so if you wanted to easily override what Fedora does for buildroots you could just twiddle that config and point it at your build package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Thu Jun 28 15:15:47 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 28 Jun 2007 11:15:47 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <46839092.7000608@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> <4682A26F.7070104@redhat.com> <46839092.7000608@fedoraproject.org> Message-ID: <4683D0A3.9030507@redhat.com> Rahul Sundaram wrote: > Christopher Aillon wrote: >> Rahul Sundaram wrote: >>> Christopher Aillon wrote: >>> >>>> That makes no sense. Are you seriously telling me that you ratify >>>> changes that may be sub-par with the intent that they can be changed? >>> >>> No but policies can be ratified with the understanding that they are >>> not written in stone. >>> >>>> Sounds like you need to revise your ratification process (or lack >>>> thereof) before people should feel comfortable following anything >>>> that gets "voted" on. >>> >>> That's a FESCo decision that I am not involved with. >> >> I wonder if I'm the only person that got the impression you were >> invovled with it based on your comments. Don't try to strongarm >> people into following _draft_ policies based on the fact that you >> personally _expect_ it to be ratified. > > I am not personally involved with it. The policy is mostly documenting > the process that we have followed even in the previous release so I do > expect maintainers to take an effort to describe what the plans are. This is not a big enough change to warrant that IMO though. It won't be any more newsworthy than any other firefox release. It will be done sooner rather than later. Probably by next week, although having to send my status updates on a tiny project like this isn't helping me get it done faster. From jspaleta at gmail.com Thu Jun 28 15:43:24 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jun 2007 07:43:24 -0800 Subject: XULRunner - will be or won't be? In-Reply-To: <4683D0A3.9030507@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> <4682A26F.7070104@redhat.com> <46839092.7000608@fedoraproject.org> <4683D0A3.9030507@redhat.com> Message-ID: <604aa7910706280843m74880c8ay57fc035b22d041de@mail.gmail.com> On 6/28/07, Christopher Aillon wrote: > This is not a big enough change to warrant that IMO though. It won't be > any more newsworthy than any other firefox release. Every firefox release is newsworthy, don't be so modest. How many applications do firefox security updates end up breaking through library dependencies? End-users definitely notice when a firefox updates go out.... its always big news. More seriously, the above quoted text gets to the heart of the problem with a 'features' documentation policy. At the end of the day, the group of people who define something as feature-worthy are going to need to be the ones who keep the feature-level text updated. If a maintainer doesn't 'see' this as feature worthy then expecting the maintainer to keep that additional text updated will cause some friction. Personally I disagree with you about xulrunner. Several application packages which currently depend on libraries inside firefox are going to be positively impacted by the inclusion of xulrunner. Enough of them to make xulrunner a big enough deal to make a little fuss over in the next fedora release from an end-user perspective. -jef From buildsys at redhat.com Thu Jun 28 15:47:57 2007 From: buildsys at redhat.com (Build System) Date: Thu, 28 Jun 2007 11:47:57 -0400 Subject: rawhide report: 20070628 changes Message-ID: <200706281547.l5SFlvBl028560@porkchop.devel.redhat.com> From rdieter at math.unl.edu Thu Jun 28 15:09:02 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 28 Jun 2007 10:09:02 -0500 Subject: Upgrade path question References: <1182964907.30663.402.camel@localhost.localdomain> Message-ID: Adam Jackson wrote: > The received wisdom seems to be "Only care about upgrades with stride <= > 2", meaning, FC5 to F7 should work, but FC1 to F7 is madness. Is this > written down anywhere, or just tribal knowledge? > > I ask because there's a fair bit of cruft in the X packages to handle > things like Obsoletes: XFree86. We haven't shipped that since FC2, so > it's hard to still care. Recall, I recommended omitting such cruft in the mesa-libGLw Review, http://bugzilla.redhat.com/188974 but mharris felt strongly otherwise: "They should IMHO not be removed ever.". *shrug*. In the end, it's ulimately your (as maintainer) call to make, and, fwiw, I see no harm is removing the old Obsoletes now. -- Rex From jkeating at redhat.com Thu Jun 28 15:47:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 11:47:44 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <604aa7910706280843m74880c8ay57fc035b22d041de@mail.gmail.com> References: <1182953296.3253.33.camel@pc-notebook> <4683D0A3.9030507@redhat.com> <604aa7910706280843m74880c8ay57fc035b22d041de@mail.gmail.com> Message-ID: <200706281147.44484.jkeating@redhat.com> On Thursday 28 June 2007 11:43:24 Jeff Spaleta wrote: > Personally I disagree with you about xulrunner. Several application > packages which currently depend on libraries inside firefox are going > to be positively impacted by the inclusion of xulrunner. ?Enough of > them to make xulrunner a big enough deal to make a little fuss over in > the next fedora release from an end-user perspective. This is also another case where Fedora may be the first to "incur the pain" of reworking our software for Xulrunner, and identifying things that need to be change, potentially upstream. We need to be more proactive about touting these things where we break ground and other distros just follow us through. We often are the suckers who take all the pain and punishment, the other distros just follow us through and say "look at how much better ours is!" -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Jun 28 16:05:31 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Jun 2007 18:05:31 +0200 Subject: Upgrade path question In-Reply-To: References: <1182964907.30663.402.camel@localhost.localdomain> Message-ID: <20070628160531.GG15974@free.fr> On Thu, Jun 28, 2007 at 10:09:02AM -0500, Rex Dieter wrote: > > In the end, it's ulimately your (as maintainer) call to make, and, fwiw, I Agreed. > see no harm is removing the old Obsoletes now. I think it is acceptable, but I see also some interest in having them, it may help upgrades from old distros, even though it is not supported, and it is a very convenient way of documenting the history of a package. -- Pat From rnorwood at redhat.com Thu Jun 28 16:07:21 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 28 Jun 2007 12:07:21 -0400 Subject: perl-devel will be removed from the f8 buildroots Message-ID: Hi, On Monday, perl-devel will be removed from the f8 buildroots. This means that if you try to build a perl-* package that uses the perl build tools, you will need to add those tools to the BuildRequires for the package. The most common will be: BuildRequires: perl(ExtUtils::MakeMaker) But you should also watch the build output to make sure tests aren't being skipped due to other missing modules. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From sundaram at fedoraproject.org Thu Jun 28 16:26:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 21:56:11 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <4683D0A3.9030507@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> <4682A26F.7070104@redhat.com> <46839092.7000608@fedoraproject.org> <4683D0A3.9030507@redhat.com> Message-ID: <4683E123.3070105@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Christopher Aillon wrote: >>> Rahul Sundaram wrote: >>>> Christopher Aillon wrote: >>>> >>>>> That makes no sense. Are you seriously telling me that you ratify >>>>> changes that may be sub-par with the intent that they can be changed? >>>> >>>> No but policies can be ratified with the understanding that they are >>>> not written in stone. >>>> >>>>> Sounds like you need to revise your ratification process (or lack >>>>> thereof) before people should feel comfortable following anything >>>>> that gets "voted" on. >>>> >>>> That's a FESCo decision that I am not involved with. >>> >>> I wonder if I'm the only person that got the impression you were >>> invovled with it based on your comments. Don't try to strongarm >>> people into following _draft_ policies based on the fact that you >>> personally _expect_ it to be ratified. >> >> I am not personally involved with it. The policy is mostly documenting >> the process that we have followed even in the previous release so I do >> expect maintainers to take an effort to describe what the plans are. > > This is not a big enough change to warrant that IMO though. It won't be > any more newsworthy than any other firefox release. It will be done > sooner rather than later. Probably by next week, although having to > send my status updates on a tiny project like this isn't helping me get > it done faster. This goes to the heart of the problem. You don't consider the changes important but it is. Firefox related changes are BIG news. How many times were we asked when Firefox 2 was going to be in Fedora Core 6? I must have answered it atleast half a dozen times. So many that I had to write down a explanation on why and point users from several places to http://fedoraproject.org/wiki/Firefox2. I also remember seeing posts in this list including the one which started this discussion and other places asking about XULRunner. I myself have done in fedora-maintainers list before. XULRunner is going to affect about 50 applications in Fedora which uses Firefox for the browser engine. We are likely the first distribution to do so and hence would require explicit testing. I think that makes it a pretty major change. Rahul From caillon at redhat.com Thu Jun 28 16:26:12 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 28 Jun 2007 12:26:12 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <200706281147.44484.jkeating@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <4683D0A3.9030507@redhat.com> <604aa7910706280843m74880c8ay57fc035b22d041de@mail.gmail.com> <200706281147.44484.jkeating@redhat.com> Message-ID: <4683E124.7080805@redhat.com> Jesse Keating wrote: > On Thursday 28 June 2007 11:43:24 Jeff Spaleta wrote: >> Personally I disagree with you about xulrunner. Several application >> packages which currently depend on libraries inside firefox are going >> to be positively impacted by the inclusion of xulrunner. Enough of >> them to make xulrunner a big enough deal to make a little fuss over in >> the next fedora release from an end-user perspective. > > This is also another case where Fedora may be the first to "incur the pain" of > reworking our software for Xulrunner, and identifying things that need to be > change, potentially upstream. We need to be more proactive about touting > these things where we break ground and other distros just follow us through. > We often are the suckers who take all the pain and punishment, the other > distros just follow us through and say "look at how much better ours is!" > Actually, I think the other big ones have taken the lead here and gotten most of the work done. Pretty much all the apps that depend on it have gotten fixed upstream already, and all I expect is for packagers to switch from BuildRequires: gecko-devel = 1.8.0.13 to BuildRequires: gecko-devel = 1.9. From galibert at pobox.com Thu Jun 28 16:56:02 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 28 Jun 2007 18:56:02 +0200 Subject: XULRunner - will be or won't be? In-Reply-To: <200706281147.44484.jkeating@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <4683D0A3.9030507@redhat.com> <604aa7910706280843m74880c8ay57fc035b22d041de@mail.gmail.com> <200706281147.44484.jkeating@redhat.com> Message-ID: <20070628165602.GA84138@dspnet.fr.eu.org> On Thu, Jun 28, 2007 at 11:47:44AM -0400, Jesse Keating wrote: > This is also another case where Fedora may be the first to "incur the pain" of > reworking our software for Xulrunner, and identifying things that need to be > change, potentially upstream. We need to be more proactive about touting > these things where we break ground and other distros just follow us through. > We often are the suckers who take all the pain and punishment, the other > distros just follow us through and say "look at how much better ours is!" Maybe not this time. Xulrunner has bee in gentoo for a little while now and is getting more and more generalized. So hopefully the worst is already behind. OG. From jkeating at redhat.com Thu Jun 28 16:56:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 12:56:05 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <20070628165602.GA84138@dspnet.fr.eu.org> References: <1182953296.3253.33.camel@pc-notebook> <200706281147.44484.jkeating@redhat.com> <20070628165602.GA84138@dspnet.fr.eu.org> Message-ID: <200706281256.09042.jkeating@redhat.com> On Thursday 28 June 2007 12:56:02 Olivier Galibert wrote: > Maybe not this time. ?Xulrunner has bee in gentoo for a little while > now and is getting more and more generalized. ?So hopefully the worst > is already behind. Granted, so while not this time, it /does/ happen, and it's good to be a bit more wordy about it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Jun 28 17:02:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 22:32:44 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <20070628165602.GA84138@dspnet.fr.eu.org> References: <1182953296.3253.33.camel@pc-notebook> <4683D0A3.9030507@redhat.com> <604aa7910706280843m74880c8ay57fc035b22d041de@mail.gmail.com> <200706281147.44484.jkeating@redhat.com> <20070628165602.GA84138@dspnet.fr.eu.org> Message-ID: <4683E9B4.2030609@fedoraproject.org> Olivier Galibert wrote: > On Thu, Jun 28, 2007 at 11:47:44AM -0400, Jesse Keating wrote: >> This is also another case where Fedora may be the first to "incur the pain" of >> reworking our software for Xulrunner, and identifying things that need to be >> change, potentially upstream. We need to be more proactive about touting >> these things where we break ground and other distros just follow us through. >> We often are the suckers who take all the pain and punishment, the other >> distros just follow us through and say "look at how much better ours is!" > > Maybe not this time. Xulrunner has bee in gentoo for a little while > now and is getting more and more generalized. So hopefully the worst > is already behind. Merely being in the repository does not really count. Does other apps like liferea built against it by default when you try to emerge them? Rahul From mschwendt.tmp0701.nospam at arcor.de Thu Jun 28 17:04:09 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 28 Jun 2007 19:04:09 +0200 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> Message-ID: <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> On Thu, 28 Jun 2007 12:04:27 -0400, Jeroen van Meeuwen (kanarip) wrote: > Author: kanarip > > Update of /cvs/pkgs/rpms/revisor/F-7 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10220/F-7 > > Modified Files: > revisor.spec sources > Log Message: > 2.0.3.12-2 > -BuildArch: noarch > +BuildArch: noarch ppc ppc64 You seem to be confused about why your "%ifnarch" usage in the spec doesn't work. It is because you build "noarch", where the arch doesn't matter. It is an arch-independent build. Unless the compose tool is broken, it would still ship the noarch build for ppc/ppc64. Apparently, you now want to hack the buildarch parameter and create multiple builds of the package: noarch with Requires livecd-tools, and arch-specific ppc/ppc64 without Requires livecd-tools. This is something that has been a topic before. A "noarch" package which depends on arch-specific packages, which are not available for all arches, cannot really be noarch or should use ExcludeArch properly (which is another ugly hack). The only alternative with current RPM is to not build "noarch". Then you can get your ifarch/ifnarch to work. From vonbrand at inf.utfsm.cl Thu Jun 28 15:40:27 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 28 Jun 2007 11:40:27 -0400 Subject: portage vs yum In-Reply-To: <20070627220805.GC7580@dspnet.fr.eu.org> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627235930.A7970@xos037.xos.nl> <20070627220805.GC7580@dspnet.fr.eu.org> Message-ID: <200706281540.l5SFeRH4005191@laptop13.inf.utfsm.cl> Olivier Galibert wrote: > On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote: > > Reading opinions like these, I have the impression that most people > > only think of individual, hacker-type users, not about, say, system > > administrators maintaining large networks of systems, having to > > support those systems (and users) easily, etc. > Well, Fedora is becoming more and more hostile to the sysadmin > population as time goes too, so... If so, that is a (meta)bug well worth fixing... Details, please? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jwboyer at jdub.homelinux.org Thu Jun 28 17:08:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 28 Jun 2007 12:08:35 -0500 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1183050515.10172.25.camel@weaponx.rchland.ibm.com> On Thu, 2007-06-28 at 19:04 +0200, Michael Schwendt wrote: > On Thu, 28 Jun 2007 12:04:27 -0400, Jeroen van Meeuwen (kanarip) wrote: > > > Author: kanarip > > > > Update of /cvs/pkgs/rpms/revisor/F-7 > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10220/F-7 > > > > Modified Files: > > revisor.spec sources > > Log Message: > > 2.0.3.12-2 > > > -BuildArch: noarch > > +BuildArch: noarch ppc ppc64 > > You seem to be confused about why your "%ifnarch" usage in the spec > doesn't work. It is because you build "noarch", where the arch doesn't > matter. It is an arch-independent build. Unless the compose tool is > broken, it would still ship the noarch build for ppc/ppc64. > Apparently, you now want to hack the buildarch parameter and create > multiple builds of the package: noarch with Requires livecd-tools, and > arch-specific ppc/ppc64 without Requires livecd-tools. > > This is something that has been a topic before. A "noarch" package > which depends on arch-specific packages, which are not available for > all arches, cannot really be noarch or should use ExcludeArch properly > (which is another ugly hack). The only alternative with current RPM is > to not build "noarch". Then you can get your ifarch/ifnarch to work. As an aside, why doesn't livecd-tools work on ppc/ppc64? Yaboot foo? josh From katzj at redhat.com Thu Jun 28 17:12:47 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Jun 2007 13:12:47 -0400 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <1183050515.10172.25.camel@weaponx.rchland.ibm.com> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> <1183050515.10172.25.camel@weaponx.rchland.ibm.com> Message-ID: <1183050767.30797.18.camel@aglarond.local> On Thu, 2007-06-28 at 12:08 -0500, Josh Boyer wrote: > As an aside, why doesn't livecd-tools work on ppc/ppc64? Yaboot foo? It's a matter of cleanly merging in the changes to abstract out the arch-dependent bits (which ends up being the bootloader and mkisofs invocation). dwmw2 sent a patch but given where we were in the F7 cycle, it wasn't a good time to merge it and risk destabilizing the tool. Will get to it pre-test1, just not the thing that needs the most runway that I'm looking at for F8. Jeremy From jkeating at redhat.com Thu Jun 28 17:14:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 13:14:16 -0400 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706281314.17302.jkeating@redhat.com> On Thursday 28 June 2007 13:04:09 Michael Schwendt wrote: > You seem to be confused about why your "%ifnarch" usage in the spec > doesn't work. It is because you build "noarch", where the arch doesn't > matter. It is an arch-independent build. Unless the compose tool is > broken, it would still ship the noarch build for ppc/ppc64. > > > This is something that has been a topic before. A "noarch" package > which depends on arch-specific packages, which are not available for > all arches, cannot really be noarch or should use ExcludeArch properly > (which is another ugly hack). Just to clarify, the (F7+ at least, not sure about Extras) compose tools do honor Exclude/ExclusiveArch on noarch packages. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Jun 28 17:17:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 28 Jun 2007 12:17:00 -0500 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <1183050767.30797.18.camel@aglarond.local> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> <1183050515.10172.25.camel@weaponx.rchland.ibm.com> <1183050767.30797.18.camel@aglarond.local> Message-ID: <1183051020.10172.27.camel@weaponx.rchland.ibm.com> On Thu, 2007-06-28 at 13:12 -0400, Jeremy Katz wrote: > On Thu, 2007-06-28 at 12:08 -0500, Josh Boyer wrote: > > As an aside, why doesn't livecd-tools work on ppc/ppc64? Yaboot foo? > > It's a matter of cleanly merging in the changes to abstract out the > arch-dependent bits (which ends up being the bootloader and mkisofs > invocation). dwmw2 sent a patch but given where we were in the F7 > cycle, it wasn't a good time to merge it and risk destabilizing the > tool. > > Will get to it pre-test1, just not the thing that needs the most runway > that I'm looking at for F8. Want help? Have ppc/ppc64, will test. :) josh From sundaram at fedoraproject.org Thu Jun 28 17:17:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 22:47:59 +0530 Subject: media support in Pirut and yum Message-ID: <4683ED47.10705@fedoraproject.org> Hi Is this planned to be done for Fedora 8? It is a commonly requested feature. Would be nice to have this working by default instead of having to configure it manually. Would also require adding support for switching CD's. Rahul From mschwendt.tmp0701.nospam at arcor.de Thu Jun 28 17:32:43 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 28 Jun 2007 19:32:43 +0200 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <200706281314.17302.jkeating@redhat.com> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> <200706281314.17302.jkeating@redhat.com> Message-ID: <20070628193243.318f4928.mschwendt.tmp0701.nospam@arcor.de> On Thu, 28 Jun 2007 13:14:16 -0400, Jesse Keating wrote: > On Thursday 28 June 2007 13:04:09 Michael Schwendt wrote: > > You seem to be confused about why your "%ifnarch" usage in the spec > > doesn't work. It is because you build "noarch", where the arch doesn't > > matter. It is an arch-independent build. Unless the compose tool is > > broken, it would still ship the noarch build for ppc/ppc64. > > > > > > > > > This is something that has been a topic before. A "noarch" package > > which depends on arch-specific packages, which are not available for > > all arches, cannot really be noarch or should use ExcludeArch properly > > (which is another ugly hack). > > Just to clarify, the (F7+ at least, not sure about Extras) compose tools do > honor Exclude/ExclusiveArch on noarch packages. Extras supports ExcludeArch for noarch src.rpms, too, but that's not the topic here. Re-read the quote. The spec does BuildArch: noarch ppc ppc64 without ExcludeArch. That would publish the noarch build for ppc/ppc64, too, wouldn't it? From katzj at redhat.com Thu Jun 28 17:38:46 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Jun 2007 13:38:46 -0400 Subject: media support in Pirut and yum In-Reply-To: <4683ED47.10705@fedoraproject.org> References: <4683ED47.10705@fedoraproject.org> Message-ID: <1183052326.30797.22.camel@aglarond.local> On Thu, 2007-06-28 at 22:47 +0530, Rahul Sundaram wrote: > Is this planned to be done for Fedora 8? It is a commonly requested > feature. Would be nice to have this working by default instead of having > to configure it manually. Would also require adding support for > switching CD's. The support for switching CDs should pretty much be there.[1] The missing piece is preservation of information about "how you installed" ==> "installed system repos". Accepting patches... I can only write so much code :-) Jeremy [1] Modulo there might be some bugs as the testing has been on the light side. From jkeating at redhat.com Thu Jun 28 17:46:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 13:46:23 -0400 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <20070628193243.318f4928.mschwendt.tmp0701.nospam@arcor.de> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <200706281314.17302.jkeating@redhat.com> <20070628193243.318f4928.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200706281346.23639.jkeating@redhat.com> On Thursday 28 June 2007 13:32:43 Michael Schwendt wrote: > Extras supports ExcludeArch for noarch src.rpms, too, but that's not the > topic here. Re-read the quote. The spec does > > ? BuildArch: noarch ppc ppc64 > > without ExcludeArch. That would publish the noarch build for ppc/ppc64, > too, wouldn't it? Yes it would, and that's not what I was posting about. I just wanted to clarify what the compose tools actually supported as it wasn't clear (to me) from your email. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jun 28 17:52:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 13:52:56 -0400 Subject: Doing away with 'groups' repo in mock Message-ID: <200706281352.57015.jkeating@redhat.com> Currently mock configs make use of a 'groups' repo to provide a 'buildsys-build' meta-package. This meta-package has a set of Requires: that are used to create the 'minimal buildroot' mock uses to start builds. This repo also provides a 'buildsys-macros' package. Historically this package would define things like the %dist tag and post-build actions. Today, in rawhide, fedora-release provides the %dist like macro definitions. The post-build definition can be moved to redhat-rpm-config as well. This would obviate the need for buildsys-macros. That would just leave the meta-package to populate the buildroot. Since mock supports installing a group rather than a (meta)package, I propose we define the buildsys-build group in the comps group directly. This would obviate the need for a single point of failure within mock building, the 'groups' repo. Here is the change I would make to comps: diff -u -r1.28 comps-f8.xml.in --- comps-f8.xml.in 27 Jun 2007 20:47:51 -0000 1.28 +++ comps-f8.xml.in 28 Jun 2007 17:27:19 -0000 @@ -486,6 +486,33 @@ + buildsys-build + <_name>Buildsystem building group + <_description/> + false + false + + bash + bzip2 + coreutils + cpio + diffutils + fedora-release + gcc + gcc-c++ + gzip + make + patch + perl + redhat-rpm-config + rpm-build + sed + tar + unzip + which + + + bulgarian-support <_name>Bulgarian Support <_description/> The comps change can be made at any time, however changes to mock need to be coordinated with the maintainer for redhat-rpm-config. I'd also like to move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the packages already being pulled into the buildroot (redhat-rpm-config perhaps, since it will be referencing it?), and thus we'll need to coordinate with the rpmdevtools maintainer. We wouldn't be doing away with mock's ability to just use a meta-package to populate the root, so those that want to alter what goes into the buildroot can (just like before) build your own buildsys-build package and host it for your mock, or define your own comps grouping, etc... Comments? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From galibert at pobox.com Thu Jun 28 18:05:41 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 28 Jun 2007 20:05:41 +0200 Subject: portage vs yum In-Reply-To: <200706281540.l5SFeRH4005191@laptop13.inf.utfsm.cl> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627235930.A7970@xos037.xos.nl> <20070627220805.GC7580@dspnet.fr.eu.org> <200706281540.l5SFeRH4005191@laptop13.inf.utfsm.cl> Message-ID: <20070628180541.GB84138@dspnet.fr.eu.org> On Thu, Jun 28, 2007 at 11:40:27AM -0400, Horst H. von Brand wrote: > Olivier Galibert wrote: > > On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote: > > > Reading opinions like these, I have the impression that most people > > > only think of individual, hacker-type users, not about, say, system > > > administrators maintaining large networks of systems, having to > > > support those systems (and users) easily, etc. > > > Well, Fedora is becoming more and more hostile to the sysadmin > > population as time goes too, so... > > If so, that is a (meta)bug well worth fixing... Details, please? Well, from my point of view from a part-time sysadmin in a lab with 200+ computers to handle, the two main problems are: - 6-months release cycle, with reinstall needed - loss of Core I'm going to expand on that a little. My users need an installation which is reasonably up-to-date (recent firefox and openoffice for a start) and which does not require them to change their habits too much. I need an installation I can put semi-automatically on a computer with a minimum of handholding and which includes 99% of what all my users will ever need (hard drives are cheaper than my time). One solution is to have a local package repository with a good coverage, and a boot+kickstart that does an everything install of that repository, configures things locally, but still asks for things like partitioning, keyboard type, ip addresses or root password. And points yum at the repository for updates. Then the question becomes "what do I put in the repository", "how do I update it", and "how often do I have to go back in front of the computer to do a full reinstall". For the first two questions, "Core" was a godsend, and "Prime" is nowhere near it. Core was a set of packages you could install without conflicts in in reasonable space (12G for fc5 on amd64) and, once added a small number of packages from extras, pbone and local compiles it provided enough choice to my users to be happy (decent KDE, decent Gnome, other less-known wms) and do their work. Prime is a live-cd, hence much smaller no matter what happens, which is already talking about removing KDE, and from which is rather annoying to extract a usable repository base. Also Core had specific updates which also did not conflict and merging them in was relatively easy. Now I'm going to have to find a way to make a list of packages we want in the repository and ensure they don't conflict and cover what my users need. "Not happy" doesn't even begin to cover it. Oh, before you start saying that I should give my users the choice of what to install, don't forget two things: - most of them don't *want* to choose, they have other things to do with their lives, they'd just like to have what they need when they need it - only 15-20% of the computers are desktop, rest is servers of one kind or another And on top of that, you add the 6-months release cycle. Let's see what it gives, for, say Fedora 7: - june 2007, f7 is out. Wait for it to stabilize, give it two months - august 2007, try to build a working installation repository and local configuration, that's easily going to take a month since it's definitively not the only thing one has to do - september 2007, install f7 on the desktop of 2-3 volunteers,give them some time to find out all that's missing - october 2007, all the missing packages have been added, the kinks fixed, start installing f7 on some servers (secondary but used file server, things like that). See how it goes. - november 2007, f8 is out, the installation is already becoming obsolete - december 2007, several emails with lkml/autofs/whatever later the kinks are out on the server installs and scsi, nfs, autofs work correctly again. Start installing on more servers, using the winter vacations in order not to be too blocking - january 2008, start installing on the desktops. Add the missing packages the users find out. - february 2008, reinstall the clusters (yes, plural), fight with oscar until it behaves - april 2008, f9 is out - june 2008, f7 is EOLed, no more updates, including security At fc3 or fc5 time, the delay before eol-ing was two years and not one, and the presence of core made the "I'm missing a package" kinks much rarer. It *was* annoying, but less. OG. From ville.skytta at iki.fi Thu Jun 28 18:05:38 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 28 Jun 2007 21:05:38 +0300 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281352.57015.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> Message-ID: <200706282105.38609.ville.skytta@iki.fi> On Thursday 28 June 2007, Jesse Keating wrote: > I'd also like to > move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the > packages already being pulled into the buildroot (redhat-rpm-config > perhaps, since it will be referencing it?), and thus we'll need to > coordinate with the rpmdevtools maintainer. I'm very much fine with that. In fact, I filed a RFE about it a couple of days ago: https://bugzilla.redhat.com/245639 From galibert at pobox.com Thu Jun 28 18:13:08 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 28 Jun 2007 20:13:08 +0200 Subject: XULRunner - will be or won't be? In-Reply-To: <4683E9B4.2030609@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <4683D0A3.9030507@redhat.com> <604aa7910706280843m74880c8ay57fc035b22d041de@mail.gmail.com> <200706281147.44484.jkeating@redhat.com> <20070628165602.GA84138@dspnet.fr.eu.org> <4683E9B4.2030609@fedoraproject.org> Message-ID: <20070628181308.GA97813@dspnet.fr.eu.org> On Thu, Jun 28, 2007 at 10:32:44PM +0530, Rahul Sundaram wrote: > Merely being in the repository does not really count. Does other apps > like liferea built against it by default when you try to emerge them? *checking*, hmmm, supported but not compiled with it by default. Damn. Too bad. OG. From jkeating at redhat.com Thu Jun 28 18:11:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 14:11:43 -0400 Subject: portage vs yum In-Reply-To: <20070628180541.GB84138@dspnet.fr.eu.org> References: <200706281540.l5SFeRH4005191@laptop13.inf.utfsm.cl> <20070628180541.GB84138@dspnet.fr.eu.org> Message-ID: <200706281411.43886.jkeating@redhat.com> On Thursday 28 June 2007 14:05:41 Olivier Galibert wrote: > Well, from my point of view from a part-time sysadmin in a lab with > 200+ computers to handle, the two main problems are: > - 6-months release cycle, with reinstall needed > - loss of Core > > I'm going to expand on that a little. ?My users need an installation > which is reasonably up-to-date (recent firefox and openoffice for a > start) and which does not require them to change their habits too > much. ?I need an installation I can put semi-automatically on a > computer with a minimum of handholding and which includes 99% of what > all my users will ever need (hard drives are cheaper than my time). > > One solution is to have a local package repository with a good > coverage, and a boot+kickstart that does an everything install of that > repository, configures things locally, but still asks for things like > partitioning, keyboard type, ip addresses or root password. ?And > points yum at the repository for updates. > > Then the question becomes "what do I put in the repository", "how do I > update it", and "how often do I have to go back in front of the > computer to do a full reinstall". > > For the first two questions, "Core" was a godsend, and "Prime" is > nowhere near it. ?Core was a set of packages you could install without > conflicts in in reasonable space (12G for fc5 on amd64) and, once > added a small number of packages from extras, pbone and local compiles > it provided enough choice to my users to be happy (decent KDE, decent > Gnome, other less-known wms) and do their work. ?Prime is a live-cd, > hence much smaller no matter what happens, which is already talking > about removing KDE, and from which is rather annoying to extract a > usable repository base. > > Also Core had specific updates which also did not conflict and merging > them in was relatively easy. I think you need to look closer. Prime went away around Test2 perhaps. Now there is the "Fedora" spin, which isn't a LiveCD at all, it's in fact very close to what "Core" used to be. As for updates, I'm really not sure why you don't mirror the updates in their entirety so that not only what you install, but what your users may install after the fact will be able to be updated. Yes we've had some broken deps in F7 updates thus far, but we're working to shore up those gaps in the tools. > Now I'm going to have to find a way to make a list of packages we want > in the repository and ensure they don't conflict and cover what my > users need. ?"Not happy" doesn't even begin to cover it. As stated, look at the Fedora spin. > Oh, before you start saying that I should give my users the choice of > what to install, don't forget two things: > > - most of them don't *want* to choose, they have other things to do > ? with their lives, they'd just like to have what they need when they > ? need it > > - only 15-20% of the computers are desktop, rest is servers of one > ? kind or another > > > And on top of that, you add the 6-months release cycle. ?Let's see > what it gives, for, say Fedora 7: > > - june 2007, f7 is out. ?Wait for it to stabilize, give it two months That's just silly and a waste of time. > - august 2007, try to build a working installation repository and > ? local configuration, that's easily going to take a month since it's > ? definitively not the only thing one has to do > > - september 2007, install f7 on the desktop of 2-3 volunteers,give > ? them some time to find out all that's missing > > - october 2007, all the missing packages have been added, the kinks > ? fixed, start installing f7 on some servers (secondary but used file > ? server, things like that). ?See how it goes. Complete hyperbole. Start with Fedora spin, it's probably exactly what you want. Could have that done in early July. > - november 2007, f8 is out, the installation is already becoming > ? obsolete > > - december 2007, several emails with lkml/autofs/whatever later the > ? kinks are out on the server installs and scsi, nfs, autofs work > ? correctly again. ?Start installing on more servers, using the winter > ? vacations in order not to be too blocking > > - january 2008, start installing on the desktops. ?Add the missing > ? packages the users find out. > > - february 2008, reinstall the clusters (yes, plural), fight with > ? oscar until it behaves > > - april 2008, f9 is out > > - june 2008, f7 is EOLed, no more updates, including security > > At fc3 or fc5 time, the delay before eol-ing was two years and not > one, and the presence of core made the "I'm missing a package" kinks > much rarer. ?It *was* annoying, but less. It was /not/ 2 years. FC3 went EOL when FC5 Test2 came out. There was Legacy, but that never really lived up to what I promised. Now we've made the "official" lifespan even longer than before. A month's time to prepare for a new release + 12~ months of updates is pretty reasonable. Anything longer and you really are looking at RHEL like timelines. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Thu Jun 28 18:28:01 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 28 Jun 2007 14:28:01 -0400 Subject: XULRunner - will be or won't be? In-Reply-To: <4683E123.3070105@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> <4682A26F.7070104@redhat.com> <46839092.7000608@fedoraproject.org> <4683D0A3.9030507@redhat.com> <4683E123.3070105@fedoraproject.org> Message-ID: <4683FDB1.7080905@redhat.com> Rahul Sundaram wrote: >> This is not a big enough change to warrant that IMO though. It won't >> be any more newsworthy than any other firefox release. It will be >> done sooner rather than later. Probably by next week, although having >> to send my status updates on a tiny project like this isn't helping me >> get it done faster. > > This goes to the heart of the problem. You don't consider the changes > important but it is. Firefox related changes are BIG news. Please stop misinterpreting things. I never said it was not important. I am saying that it is not any more important than going from 2.0.0.0 to 2.0.0.4. It will require an equivalent amount of work: this is essentially just a version upgrade. Almost all the upstreams I know that care about this have already been supporting XULrunner for well over a year now, and Novell has shipped an alpha version in their experimental branches, and Gentoo and I think Ubuntu has shipped it, and believe it or not, upstream has been rather good about helping projects work with XULRunner. It's finally in a state where I'm ready to say it will cause little damage and that is why it is going into Fedora now. > How many > times were we asked when Firefox 2 was going to be in Fedora Core 6? I > must have answered it atleast half a dozen times. So many that I had to > write down a explanation on why and point users from several places to > http://fedoraproject.org/wiki/Firefox2. And how many complaints have we had about metacity not doing enough to suit people's uber configuration needs? Or about someone not liking a theme or artwork? People will always find something to complain about but I'm glad that I was at least able to help fulfill your wiki page writing desires. So fine. You win. Please put up a wiki page that says that XULRunner will be included in the next week or so. My real deadline is July 12, which is the day before I leave for GUADEC but I expect it sooner. That's really all I have to say about it right now and I'd rather spend time doing the work than writing up about it or wasting another second on this thread. From mschwendt.tmp0701.nospam at arcor.de Thu Jun 28 18:35:25 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 28 Jun 2007 20:35:25 +0200 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <200706281346.23639.jkeating@redhat.com> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <200706281314.17302.jkeating@redhat.com> <20070628193243.318f4928.mschwendt.tmp0701.nospam@arcor.de> <200706281346.23639.jkeating@redhat.com> Message-ID: <20070628203525.4b136676.mschwendt.tmp0701.nospam@arcor.de> On Thu, 28 Jun 2007 13:46:23 -0400, Jesse Keating wrote: > On Thursday 28 June 2007 13:32:43 Michael Schwendt wrote: > > Extras supports ExcludeArch for noarch src.rpms, too, but that's not the > > topic here. Re-read the quote. The spec does > > > > ? BuildArch: noarch ppc ppc64 > > > > without ExcludeArch. That would publish the noarch build for ppc/ppc64, > > too, wouldn't it? > > Yes it would, and that's not what I was posting about. I just wanted to > clarify what the compose tools actually supported as it wasn't clear (to me) > from your email. Well, my mail specifically mentioned "ExcludeArch" as one solution, albeit called it "another ugly hack" [*]. Btw, revisor previously had used ExcludeArch. The context of my mail is the most recent revisor.spec changeset. -- [*] Which is because ExcludeArch info is only stored in the src rpm. From oliver at linux-kernel.at Thu Jun 28 18:53:20 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 28 Jun 2007 20:53:20 +0200 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281352.57015.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> Message-ID: <468403A0.2050202@linux-kernel.at> Jesse Keating schrieb: > Currently mock configs make use of a 'groups' repo to provide > a 'buildsys-build' meta-package. This meta-package has a set of Requires: > that are used to create the 'minimal buildroot' mock uses to start builds. > This repo also provides a 'buildsys-macros' package. Historically this > package would define things like the %dist tag and post-build actions. > > Today, in rawhide, fedora-release provides the %dist like macro definitions. > The post-build definition can be moved to redhat-rpm-config as well. This > would obviate the need for buildsys-macros. That would just leave the > meta-package to populate the buildroot. > > Since mock supports installing a group rather than a (meta)package, I propose > we define the buildsys-build group in the comps group directly. This would > obviate the need for a single point of failure within mock building, > the 'groups' repo. > > Here is the change I would make to comps: > > diff -u -r1.28 comps-f8.xml.in > --- comps-f8.xml.in 27 Jun 2007 20:47:51 -0000 1.28 > +++ comps-f8.xml.in 28 Jun 2007 17:27:19 -0000 > @@ -486,6 +486,33 @@ > > > > + buildsys-build > + <_name>Buildsystem building group > + <_description/> > + false > + false > + > + bash > + bzip2 > + coreutils > + cpio > + diffutils > + fedora-release > + gcc > + gcc-c++ > + gzip > + make > + patch > + perl > + redhat-rpm-config > + rpm-build > + sed > + tar > + unzip > + which > + > + > + > bulgarian-support > <_name>Bulgarian Support > <_description/> > > The comps change can be made at any time, however changes to mock need to be > coordinated with the maintainer for redhat-rpm-config. I'd also like to > move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the > packages already being pulled into the buildroot (redhat-rpm-config perhaps, > since it will be referencing it?), and thus we'll need to coordinate with the > rpmdevtools maintainer. > > We wouldn't be doing away with mock's ability to just use a meta-package to > populate the root, so those that want to alter what goes into the buildroot > can (just like before) build your own buildsys-build package and host it for > your mock, or define your own comps grouping, etc... > > Comments? +1 For default mocks this makes sense. -of From sundaram at fedoraproject.org Thu Jun 28 19:14:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 00:44:53 +0530 Subject: portage vs yum In-Reply-To: <20070628180541.GB84138@dspnet.fr.eu.org> References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627235930.A7970@xos037.xos.nl> <20070627220805.GC7580@dspnet.fr.eu.org> <200706281540.l5SFeRH4005191@laptop13.inf.utfsm.cl> <20070628180541.GB84138@dspnet.fr.eu.org> Message-ID: <468408AD.1080304@fedoraproject.org> Olivier Galibert wrote: > On Thu, Jun 28, 2007 at 11:40:27AM -0400, Horst H. von Brand wrote: >> Olivier Galibert wrote: >>> On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote: >>>> Reading opinions like these, I have the impression that most people >>>> only think of individual, hacker-type users, not about, say, system >>>> administrators maintaining large networks of systems, having to >>>> support those systems (and users) easily, etc. >>> Well, Fedora is becoming more and more hostile to the sysadmin >>> population as time goes too, so... >> If so, that is a (meta)bug well worth fixing... Details, please? > > Well, from my point of view from a part-time sysadmin in a lab with > 200+ computers to handle, the two main problems are: > - 6-months release cycle, with reinstall needed 6 month release cycles are not a new change and shouldn't be cited as "increasingly hostile". If you consider shorter release cycles as not appropriate for you, Fedora has always been that way. Reinstall is not needed. You can do upgrades via Anaconda. Upgrades via the package managers might not be official supported but it is definitely doable and I have done for several releases successfully. > For the first two questions, "Core" was a godsend, and "Prime" is > nowhere near it. Actually the renamed "Prime" spin which is called "Fedora" spin is very close to what "Core" was. That is explicitly the purpose of that spin. > At fc3 or fc5 time, the delay before eol-ing was two years and not > one, Incorrect. Fedora updates cycle was about 9 months and extended to about 13 months before the release of Fedora 7. Rahul From jeff at ocjtech.us Thu Jun 28 19:15:27 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 28 Jun 2007 14:15:27 -0500 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281352.57015.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> Message-ID: <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> On Thu, 2007-06-28 at 13:52 -0400, Jesse Keating wrote: > Currently mock configs make use of a 'groups' repo to provide > a 'buildsys-build' meta-package. This meta-package has a set of Requires: > that are used to create the 'minimal buildroot' mock uses to start builds. > This repo also provides a 'buildsys-macros' package. Historically this > package would define things like the %dist tag and post-build actions. > > Today, in rawhide, fedora-release provides the %dist like macro definitions. > The post-build definition can be moved to redhat-rpm-config as well. This > would obviate the need for buildsys-macros. That would just leave the > meta-package to populate the buildroot. > > Since mock supports installing a group rather than a (meta)package, I propose > we define the buildsys-build group in the comps group directly. This would > obviate the need for a single point of failure within mock building, > the 'groups' repo. ISTR that we were populating the mock buildroot by installing a comps.xml group before, and then we switched to a meta-package[1]. In fact, you (Jesse) were in favor of the idea[2]. What's changed in the last year that you'd like to go *back* to using comps.xml and groupinstall? I'm in favor of eliminating the groups repo and hosting the buildsys-build RPM in the regular package CVS & mirrors but I'm not in favor of going back to using comps.xml groups unless there's a good explanation of why we should switch back... [1] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00016.html [2] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00022.html Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From williams at redhat.com Thu Jun 28 19:15:26 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 28 Jun 2007 14:15:26 -0500 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281352.57015.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> Message-ID: <468408CE.4080802@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > Currently mock configs make use of a 'groups' repo to provide > a 'buildsys-build' meta-package. This meta-package has a set of Requires: > that are used to create the 'minimal buildroot' mock uses to start builds. > This repo also provides a 'buildsys-macros' package. Historically this > package would define things like the %dist tag and post-build actions. > > Today, in rawhide, fedora-release provides the %dist like macro definitions. > The post-build definition can be moved to redhat-rpm-config as well. This > would obviate the need for buildsys-macros. That would just leave the > meta-package to populate the buildroot. > > Since mock supports installing a group rather than a (meta)package, I propose > we define the buildsys-build group in the comps group directly. This would > obviate the need for a single point of failure within mock building, > the 'groups' repo. > > Here is the change I would make to comps: > > diff -u -r1.28 comps-f8.xml.in > --- comps-f8.xml.in 27 Jun 2007 20:47:51 -0000 1.28 > +++ comps-f8.xml.in 28 Jun 2007 17:27:19 -0000 > @@ -486,6 +486,33 @@ > > > > + buildsys-build > + <_name>Buildsystem building group > + <_description/> > + false > + false > + > + bash > + bzip2 > + coreutils > + cpio > + diffutils > + fedora-release > + gcc > + gcc-c++ > + gzip > + make > + patch > + perl > + redhat-rpm-config > + rpm-build > + sed > + tar > + unzip > + which > + > + > + > bulgarian-support > <_name>Bulgarian Support > <_description/> > > The comps change can be made at any time, however changes to mock need to be > coordinated with the maintainer for redhat-rpm-config. I'd also like to > move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the > packages already being pulled into the buildroot (redhat-rpm-config perhaps, > since it will be referencing it?), and thus we'll need to coordinate with the > rpmdevtools maintainer. > > We wouldn't be doing away with mock's ability to just use a meta-package to > populate the root, so those that want to alter what goes into the buildroot > can (just like before) build your own buildsys-build package and host it for > your mock, or define your own comps grouping, etc... > > Comments? > Works for me. I still use the buildsys-build RPM locally, but as long as we keep that ability around I'm fine. +1 Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGhAjNHyuj/+TTEp0RAgv1AKCZVaqMbCX1H/ZZSV4zA3CYSV0cgQCfVIaM t56WFWRZADIBmGcQDdxfGco= =qbHx -----END PGP SIGNATURE----- From oliver at linux-kernel.at Thu Jun 28 19:28:16 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 28 Jun 2007 21:28:16 +0200 Subject: Doing away with 'groups' repo in mock In-Reply-To: <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> References: <200706281352.57015.jkeating@redhat.com> <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> Message-ID: <46840BD0.9020400@linux-kernel.at> Hi Jeff! Jeffrey C. Ollie schrieb: > On Thu, 2007-06-28 at 13:52 -0400, Jesse Keating wrote: >> Currently mock configs make use of a 'groups' repo to provide >> a 'buildsys-build' meta-package. This meta-package has a set of Requires: >> that are used to create the 'minimal buildroot' mock uses to start builds. >> This repo also provides a 'buildsys-macros' package. Historically this >> package would define things like the %dist tag and post-build actions. >> >> Today, in rawhide, fedora-release provides the %dist like macro definitions. >> The post-build definition can be moved to redhat-rpm-config as well. This >> would obviate the need for buildsys-macros. That would just leave the >> meta-package to populate the buildroot. >> >> Since mock supports installing a group rather than a (meta)package, I propose >> we define the buildsys-build group in the comps group directly. This would >> obviate the need for a single point of failure within mock building, >> the 'groups' repo. > > ISTR that we were populating the mock buildroot by installing a > comps.xml group before, and then we switched to a meta-package[1]. In > fact, you (Jesse) were in favor of the idea[2]. What's changed in the > last year that you'd like to go *back* to using comps.xml and > groupinstall? > > I'm in favor of eliminating the groups repo and hosting the > buildsys-build RPM in the regular package CVS & mirrors but I'm not in > favor of going back to using comps.xml groups unless there's a good > explanation of why we should switch back... > > [1] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00016.html > [2] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00022.html I think Jesse wasn't talking about changing anything in the buildsys, only add default buildsys-build group to default comps.xml, for default mocks. And fp.o does no longer need to host the groups repo somewhere. Something that isn't needed for koji. koji does provide it's own buildsys-build pkg, which is recreated every time a new repo is created; Also a new comps.xml is created every time... And it's maintained via koji group stuff... So for the buildsys, it doesn't matter.... Correct me Jesse, if Jeff interpreted it correctly and I did not :-) -of From florin at andrei.myip.org Thu Jun 28 19:36:56 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 28 Jun 2007 12:36:56 -0700 Subject: Sunbird in devel Message-ID: <46840DD8.4020303@andrei.myip.org> Anybody working to include Mozilla Sunbird in devel? http://www.mozilla.org/projects/calendar/sunbird/ -- Florin Andrei http://florin.myip.org/ From Michael_E_Brown at dell.com Thu Jun 28 19:55:40 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 28 Jun 2007 14:55:40 -0500 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281352.57015.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> Message-ID: <20070628195540.GB11615@humbolt.us.dell.com> On Thu, Jun 28, 2007 at 01:52:56PM -0400, Jesse Keating wrote: > Since mock supports installing a group rather than a (meta)package, I propose > we define the buildsys-build group in the comps group directly. This would > obviate the need for a single point of failure within mock building, > the 'groups' repo. +1 from the mock co-maintainer. -- Michael From Michael_E_Brown at dell.com Thu Jun 28 20:03:44 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 28 Jun 2007 15:03:44 -0500 Subject: Doing away with 'groups' repo in mock In-Reply-To: <468408CE.4080802@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <468408CE.4080802@redhat.com> Message-ID: <20070628200343.GC11615@humbolt.us.dell.com> On Thu, Jun 28, 2007 at 02:15:26PM -0500, Clark Williams wrote: > Jesse Keating wrote: > > > > Comments? > > > > > Works for me. I still use the buildsys-build RPM locally, but as long as we keep that > ability around I'm fine. Since this is set up in: config_opts['chroot_setup_cmd'] = 'install buildsys-build' I don't see the ability to Have It Your Way(TM) going away any time soon. In the new mock configs using the new comps file, we just change that to 'groupinstall buildsys-build' and be done with it. SQOTD(*) for Jesse: How does yum find the comps file? I dont see where in yum it initializes the comps file, and I need to know this for my local yum setup. I see that comps-f7.xml is in repodata, but I dont see how it is found/initialized. -- Michael (*) Stupid Question Of The Day From opensource at till.name Thu Jun 28 20:07:05 2007 From: opensource at till.name (Till Maas) Date: Thu, 28 Jun 2007 22:07:05 +0200 Subject: Doing away with 'groups' repo in mock In-Reply-To: <20070628200343.GC11615@humbolt.us.dell.com> References: <200706281352.57015.jkeating@redhat.com> <468408CE.4080802@redhat.com> <20070628200343.GC11615@humbolt.us.dell.com> Message-ID: <200706282207.06565.opensource@till.name> On Do Juni 28 2007, Michael E Brown wrote: > SQOTD(*) for Jesse: > How does yum find the comps file? I dont see where in yum it > initializes the comps file, and I need to know this for my local yum > setup. I see that comps-f7.xml is in repodata, but I dont see how it is > found/initialized. It is referenced in repomd.xml Regards, Till From jonathan.underwood at gmail.com Thu Jun 28 20:08:36 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 28 Jun 2007 21:08:36 +0100 Subject: Sunbird in devel In-Reply-To: <46840DD8.4020303@andrei.myip.org> References: <46840DD8.4020303@andrei.myip.org> Message-ID: <645d17210706281308s4a9459ffkfa3911677c862bb2@mail.gmail.com> On 28/06/07, Florin Andrei wrote: > Anybody working to include Mozilla Sunbird in devel? > > http://www.mozilla.org/projects/calendar/sunbird/ > Would love to see Lightning too, though I suspect that will have to wait for Xulrunner. http://www.mozilla.org/projects/calendar/lightning/ From Michael_E_Brown at dell.com Thu Jun 28 20:22:54 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 28 Jun 2007 15:22:54 -0500 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706282207.06565.opensource@till.name> References: <200706281352.57015.jkeating@redhat.com> <468408CE.4080802@redhat.com> <20070628200343.GC11615@humbolt.us.dell.com> <200706282207.06565.opensource@till.name> Message-ID: <20070628202254.GD11615@humbolt.us.dell.com> On Thu, Jun 28, 2007 at 10:07:05PM +0200, Till Maas wrote: > On Do Juni 28 2007, Michael E Brown wrote: > > > SQOTD(*) for Jesse: > > How does yum find the comps file? I dont see where in yum it > > initializes the comps file, and I need to know this for my local yum > > setup. I see that comps-f7.xml is in repodata, but I dont see how it is > > found/initialized. > > It is referenced in repomd.xml Cool. Thanks. I tried grep, but the output was... unhelpful. -- Michael From florin at andrei.myip.org Thu Jun 28 20:42:05 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 28 Jun 2007 13:42:05 -0700 Subject: Sunbird in devel In-Reply-To: <645d17210706281308s4a9459ffkfa3911677c862bb2@mail.gmail.com> References: <46840DD8.4020303@andrei.myip.org> <645d17210706281308s4a9459ffkfa3911677c862bb2@mail.gmail.com> Message-ID: <46841D1D.6080001@andrei.myip.org> Jonathan Underwood wrote: > > Would love to see Lightning too Definitely. -- Florin Andrei http://florin.myip.org/ From lightsolphoenix at gmail.com Thu Jun 28 21:07:56 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Thu, 28 Jun 2007 17:07:56 -0400 Subject: Sunbird in devel In-Reply-To: <46841D1D.6080001@andrei.myip.org> References: <46840DD8.4020303@andrei.myip.org> <645d17210706281308s4a9459ffkfa3911677c862bb2@mail.gmail.com> <46841D1D.6080001@andrei.myip.org> Message-ID: <200706281707.57230.lightsolphoenix@gmail.com> On Thursday, June 28, 2007 4:42 pm Florin Andrei wrote: > Jonathan Underwood wrote: > > Would love to see Lightning too > > Definitely. > > -- > Florin Andrei > > http://florin.myip.org/ Um, Lightning is just an extension for Thunderbird... Does it need to be packaged? Oh, and if there's enough interest, I'll package Sunbird for Fedora. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From kanarip at kanarip.com Thu Jun 28 21:12:56 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 28 Jun 2007 23:12:56 +0200 Subject: rpms/revisor/F-7 revisor.spec,1.7,1.8 sources,1.8,1.9 In-Reply-To: <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> References: <200706281604.l5SG4Rvk010345@cvs-int.fedora.redhat.com> <20070628190409.4109dd5e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46842458.6020103@kanarip.com> Michael Schwendt wrote: > On Thu, 28 Jun 2007 12:04:27 -0400, Jeroen van Meeuwen (kanarip) wrote: > >> Author: kanarip >> >> Update of /cvs/pkgs/rpms/revisor/F-7 >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10220/F-7 >> >> Modified Files: >> revisor.spec sources >> Log Message: >> 2.0.3.12-2 > >> -BuildArch: noarch >> +BuildArch: noarch ppc ppc64 > > You seem to be confused about why your "%ifnarch" usage in the spec > doesn't work. It is because you build "noarch", where the arch doesn't > matter. It is an arch-independent build. Unless the compose tool is > broken, it would still ship the noarch build for ppc/ppc64. > Apparently, you now want to hack the buildarch parameter and create > multiple builds of the package: noarch with Requires livecd-tools, and > arch-specific ppc/ppc64 without Requires livecd-tools. > > This is something that has been a topic before. A "noarch" package > which depends on arch-specific packages, which are not available for > all arches, cannot really be noarch or should use ExcludeArch properly > (which is another ugly hack). The only alternative with current RPM is > to not build "noarch". Then you can get your ifarch/ifnarch to work. > Thanks, that figures. ExcludeArch is back in, %if(n)arch magic is out. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Thu Jun 28 21:16:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 17:16:33 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <46840BD0.9020400@linux-kernel.at> References: <200706281352.57015.jkeating@redhat.com> <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> <46840BD0.9020400@linux-kernel.at> Message-ID: <200706281716.34204.jkeating@redhat.com> On Thursday 28 June 2007 15:28:16 Oliver Falk wrote: > koji does provide it's own buildsys-build pkg, which is recreated every > time a new repo is created; Also a new comps.xml is created every > time... And it's maintained via koji group stuff... So for the buildsys, > it doesn't matter.... > > Correct me Jesse, if Jeff interpreted it correctly and I did not :-) Well, koji doesn't create a buildsys-build package, instead each tag can have group information, and that group information is used at repo creation time for said tag and defines a build group that is installed into the chroot. But it is all managed within Koji itself. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Jun 28 21:19:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 17:19:49 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> References: <200706281352.57015.jkeating@redhat.com> <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> Message-ID: <200706281719.49449.jkeating@redhat.com> On Thursday 28 June 2007 15:15:27 Jeffrey C. Ollie wrote: > ISTR that we were populating the mock buildroot by installing a > comps.xml group before, and then we switched to a meta-package[1]. ?In > fact, you (Jesse) were in favor of the idea[2]. ?What's changed in the > last year that you'd like to go *back* to using comps.xml and > groupinstall? I'm pretty sure that around this time comps format was changing, and it had to be managed outside the Fedora comps. Now I'm talking about doing it within Fedora comps so that most users don't have to mess with it at all, and things like yum are much more stable with comps. We can't introduce comps changes that yum can't cope with (which may mean bumping yum, but that's fine) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mladen.kuntner at triera.net Thu Jun 28 21:47:27 2007 From: mladen.kuntner at triera.net (Mladen Kuntner) Date: Thu, 28 Jun 2007 23:47:27 +0200 Subject: FC7 and firewire Message-ID: <1183067247.2735.26.camel@localhost.nox> I have problems with firewire since FC7 test1. Tried to get help or help debugging on this list two times http://www.redhat.com/archives/fedora-devel-list/2007-February/msg00540.html http://www.redhat.com/archives/rhl-devel-list/2007-April/msg01377.html but with no answers. This is third time. Problems with firewire on FC7: 1. as normal user no program ( testlibraw , dvcont, dvgrab ) is finding the camera, as root see below: 2. with on board firewire controler 01:0a.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01) (prog-if 10 [OHCI]) Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard Flags: bus master, medium devsel, latency 32, IRQ 18 Memory at f8004000 (32-bit, non-prefetchable) [size=2K] Memory at f8000000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 - testlibraw is OK - dvcont ( play and stop not working , status working 50% ) - dvgrab ( unable to start camera, if camera is playing capture is ok in 50% , other 50% camera is not found ) 3. with PCI VIA firewire card 01:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 43) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at f8000000 (32-bit, non-prefetchable) [size=2K] I/O ports at c000 [size=128] Capabilities: [50] Power Management version 2 - testlibraw is OK - dvcont ( play, stop, status all ok ) - dvgrab gives Found AV/C device with GUID 0x0080880100a306bb Message from syslogd@ at Thu Jun 28 23:02:11 2007 ... localhost kernel: Oops: 0000 [2] SMP Message from syslogd@ at Thu Jun 28 23:02:11 2007 ... localhost kernel: CR2: ffffffffffffffea and dmesg shows kernel oops , capture is not working. Otherwise happy FEDORA user since FC1. Keep up the good work. Mladen Kuntner From tcallawa at redhat.com Thu Jun 28 21:58:29 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 28 Jun 2007 16:58:29 -0500 Subject: gl debugging help requested Message-ID: <1183067909.4044.88.camel@localhost.localdomain> I'm trying to clean up vamos (a GL realistic automotive simulator), but while I can get it to build on my rawhide box, it segfaults upon execution. When I run it through gdb, it says it is segfaulting on: 0x00002aaaac0d2c0b in glGenTextures () from /usr/lib64/libGL.so.1 (gdb) bt #0 0x00002aaaac0d2c0b in glGenTextures () from /usr/lib64/libGL.so.1 #1 0x00002aaaab5818d2 in Vamos_Media::Texture_Image::initialize (this=0x7fff31cc9e30, smooth=false, mip_map=false, texture_wrap=10497) at Texture_Image.cc:94 #2 0x00002aaaab581c34 in Texture_Image (this=0x7fff31cc9e30, file_name=, smooth=false, mip_map=false, width=1, height=1, texture_wrap=10497) at Texture_Image.cc:74 #3 0x0000000000404bb7 in main (argc=1, argv=0x7fff31cca318) at vamos.cc:214 #4 0x00002aaaad397aa4 in __libc_start_main () from /lib64/libc.so.6 #5 0x00000000004023c9 in _start () I don't know the first thing about writing GL apps, nor has googling imparted me with any useful tidbits. The latest SRPM is here: http://www.auroralinux.org/people/spot/review/vamos-0.5.7-1.fc8.src.rpm Any and all patches or advice is welcomed. Thanks in advance, ~spot From dmalcolm at redhat.com Thu Jun 28 22:35:08 2007 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 28 Jun 2007 18:35:08 -0400 Subject: gl debugging help requested In-Reply-To: <1183067909.4044.88.camel@localhost.localdomain> References: <1183067909.4044.88.camel@localhost.localdomain> Message-ID: <1183070108.23819.49.camel@cassandra.boston.redhat.com> On Thu, 2007-06-28 at 16:58 -0500, Tom "spot" Callaway wrote: > I'm trying to clean up vamos (a GL realistic automotive simulator), but > while I can get it to build on my rawhide box, it segfaults upon > execution. > > When I run it through gdb, it says it is segfaulting on: > > 0x00002aaaac0d2c0b in glGenTextures () from /usr/lib64/libGL.so.1 > (gdb) bt > #0 0x00002aaaac0d2c0b in glGenTextures () from /usr/lib64/libGL.so.1 Try installing debuginfo for /usr/lib64/libGL.so.1 and rerunning. This is just a hunch but is the second argument to glGenTextures a valid non-NULL pointer? (maybe a wrong size assumption 32 vs 64-bit in the Vamos_Media::Texture_Image implementation?) See: http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/gentextures.html [snip] Hope this helps Dave From orion at cora.nwra.com Thu Jun 28 22:46:58 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jun 2007 16:46:58 -0600 Subject: koji appears to be down Message-ID: <46843A62.5070500@cora.nwra.com> Status? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jkeating at redhat.com Thu Jun 28 23:46:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 19:46:22 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT Message-ID: <200706281946.25821.jkeating@redhat.com> O U T A G E R E P O R T F O R M =================================== Incident Date: 6/28/07 Incident Time: 6:00PM EDT Elapsed Time of Incident: Ongoing People/Groups Impacted: Package builders / update tool / koji web services Site Affected: koji.fedoraproject.org Description: The koji.fedoraproject.org server is experiencing very high load. Attempts to login and address the load issue are under way. Future Recommendations: Continue investigating process issues with httpd (if that proves to be the culprit once more). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Fri Jun 29 01:42:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 21:42:06 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706281946.25821.jkeating@redhat.com> References: <200706281946.25821.jkeating@redhat.com> Message-ID: <200706282142.06239.jkeating@redhat.com> On Thursday 28 June 2007 19:46:22 Jesse Keating wrote: > O U T A G E R E P O R T F O R M > =================================== > > Incident Date: > 6/28/07 > > Incident Time: > 6:00PM EDT > > Elapsed Time of Incident: > Ongoing > > People/Groups Impacted: > Package builders / update tool / koji web services > > Site Affected: > koji.fedoraproject.org > > Description: > The koji.fedoraproject.org server is experiencing very high load. Attempts > to login and address the load issue are under way. > > Future Recommendations: > Continue investigating process issues with httpd (if that proves to be the > culprit once more). Outage is now over. Future Recommendations: Properly document location of koji server and instructions on how to power cycle. Grant access to admins in multiple timezones for "round the clock" coverage. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From spng.yang at gmail.com Fri Jun 29 02:44:25 2007 From: spng.yang at gmail.com (Ken YANG) Date: Fri, 29 Jun 2007 10:44:25 +0800 Subject: glibmm24 & gtkmm24 make vmware6 fail In-Reply-To: <1183037920.4378.4.camel@dhcp83-186.boston.redhat.com> References: <468312AA.2010008@gmail.com> <1182995194.23776.0.camel@vader.jdub.homelinux.org> <4683B9C2.6000002@poolshark.org> <1183037920.4378.4.camel@dhcp83-186.boston.redhat.com> Message-ID: <46847209.6070303@gmail.com> Matthias Clasen wrote: > On Thu, 2007-06-28 at 15:38 +0200, Denis Leroy wrote: >> Josh Boyer wrote: >>> On Thu, 2007-06-28 at 09:45 +0800, Ken YANG wrote: >>>> hi all: >>>> >>>> the glibmm24 and gtkmm24 in rawhide make vmware6 failed: >>> Tell VMWare >> General note: dry responses like this are uncalled for. Because VMWare >> trips this problem doesn't necessarily mean its their fault. >> >> This is a known ABI breakage in Glib 2.13. >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245634 >> >> Matthias, any word on adding the patch (in SVN already) ? >> > > It'll be fixed in the next devel snapshot, hopefully before the end of > the week. thank you very much > From sundaram at fedoraproject.org Fri Jun 29 02:54:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 08:24:45 +0530 Subject: RFE: Use generic names in packages Message-ID: <46847475.6000405@fedoraproject.org> Hi A recent discussion in EPEL about whether README.Fedora would be confusing to EPEL users has brought into forefront what I consider a good packaging guideline for Fedora to follow which is to avoid using the "Fedora" name as much as possible in package names and files with exceptions like "Fedora directory server" and recommend using generic names wherever possible. This would certainly help in being a better upstream for distribution and other efforts that are based on Fedora including RHEL, EPEL or OLPC. In this specific instance I believe the guidelines should be mandating README.distribution instead. Refer to https://www.redhat.com/archives/epel-devel-list/2007-June/msg00064.html for the discussion. Rahul From jkeating at redhat.com Fri Jun 29 02:51:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 22:51:25 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <46847475.6000405@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> Message-ID: <200706282251.30065.jkeating@redhat.com> On Thursday 28 June 2007 22:54:45 Rahul Sundaram wrote: > Hi > > A recent discussion in EPEL about whether README.Fedora would be > confusing to EPEL users has brought into forefront what I consider a > good packaging guideline for Fedora to follow which is to avoid using > the "Fedora" name as much as possible in package names and files with > exceptions like "Fedora directory server" and recommend using generic > names wherever possible. > > This would certainly help in being a better upstream for distribution > and other efforts that are based on Fedora including RHEL, EPEL or OLPC. > > In this specific instance I believe the guidelines should be mandating > README.distribution instead. > > Refer to > https://www.redhat.com/archives/epel-devel-list/2007-June/msg00064.html > for the discussion. > > Rahul At what point does this become silly though? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 29 03:05:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 08:35:32 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <200706282251.30065.jkeating@redhat.com> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> Message-ID: <468476FC.9020300@fedoraproject.org> Jesse Keating wrote: > On Thursday 28 June 2007 22:54:45 Rahul Sundaram wrote: >> Hi >> >> A recent discussion in EPEL about whether README.Fedora would be >> confusing to EPEL users has brought into forefront what I consider a >> good packaging guideline for Fedora to follow which is to avoid using >> the "Fedora" name as much as possible in package names and files with >> exceptions like "Fedora directory server" and recommend using generic >> names wherever possible. >> >> This would certainly help in being a better upstream for distribution >> and other efforts that are based on Fedora including RHEL, EPEL or OLPC. >> >> In this specific instance I believe the guidelines should be mandating >> README.distribution instead. >> >> Refer to >> https://www.redhat.com/archives/epel-devel-list/2007-June/msg00064.html >> for the discussion. >> >> Rahul > > At what point does this become silly though? Do you want me to define silly or give an example where I consider it silly? I think trying to rename Fedora Directory Server at this point would be silly as opposed to the above request which I consider valid. Do you disagree with that request or the general idea or both? Rahul From jkeating at redhat.com Fri Jun 29 03:00:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 23:00:32 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <468476FC.9020300@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> Message-ID: <200706282300.33107.jkeating@redhat.com> On Thursday 28 June 2007 23:05:32 Rahul Sundaram wrote: > Do you want me to define silly or give an example where I consider it > silly? I think trying to rename Fedora Directory Server at this point > would be silly as opposed to the above request which I consider valid. > Do you disagree with that request or the general idea or both? I think it should be examined at a case by case basis. If the content of a file is not "Fedora" specific then maybe it should be named generically. But if it /is/ Fedora specific, well then... I don't think we should be putting a lot of effort into disguising the fact that these things are derived from Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 29 03:07:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Jun 2007 23:07:22 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <200706282300.33107.jkeating@redhat.com> References: <46847475.6000405@fedoraproject.org> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> Message-ID: <200706282307.23137.jkeating@redhat.com> On Thursday 28 June 2007 23:00:32 Jesse Keating wrote: > I don't think we should be putting a lot of effort into disguising the fact > that these things are derived from Fedora. And more to the point obfuscating ourselves out of a brand. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Jun 29 03:16:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 08:46:57 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <200706282300.33107.jkeating@redhat.com> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> Message-ID: <468479A9.4050000@fedoraproject.org> Jesse Keating wrote: > On Thursday 28 June 2007 23:05:32 Rahul Sundaram wrote: >> Do you want me to define silly or give an example where I consider it >> silly? I think trying to rename Fedora Directory Server at this point >> would be silly as opposed to the above request which I consider valid. >> Do you disagree with that request or the general idea or both? > > I think it should be examined at a case by case basis. If the content of a > file is not "Fedora" specific then maybe it should be named generically. But > if it /is/ Fedora specific, well then... Right but Fedora directory server isn't really Fedora specific. I can very well run it under any distribution. > I don't think we should be putting a lot of effort into disguising the fact > that these things are derived from Fedora. That is not what I am requesting. Rahul From gmaxwell at gmail.com Fri Jun 29 03:18:47 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 28 Jun 2007 23:18:47 -0400 Subject: Red Hat CEO Says He Talked Patents with Microsoft (Reuters) Message-ID: http://www.eweek.com/article2/0,1759,2151908,00.asp In an interview with Reuters, Szulik declined to say whether his company is now in negotiations with Microsoft over signing such a patent agreement. "I can't answer the question," he said. From sundaram at fedoraproject.org Fri Jun 29 03:31:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 09:01:21 +0530 Subject: Red Hat CEO Says He Talked Patents with Microsoft (Reuters) In-Reply-To: References: Message-ID: <46847D09.4060801@fedoraproject.org> Gregory Maxwell wrote: > http://www.eweek.com/article2/0,1759,2151908,00.asp > > In an interview with Reuters, Szulik declined to say whether his > company is now in negotiations with Microsoft over signing such a > patent agreement. > > "I can't answer the question," he said. I don't see how this is on topic in this. At any rate Red Hat has already clarified it's position on both the interoperability and patent fronts several times now. http://www.redhat.com/promo/believe/ http://linux.slashdot.org/article.pl?sid=07/06/19/1720201 http://www.computing.co.uk/vnunet/news/2189545/red-hat-sets-limits-microsoft Rahul From caillon at redhat.com Fri Jun 29 04:24:12 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 29 Jun 2007 00:24:12 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <468479A9.4050000@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> Message-ID: <4684896C.3020604@redhat.com> Rahul Sundaram wrote: > Right but Fedora directory server isn't really Fedora specific. I can > very well run it under any distribution. And is it so bad that people see the name Fedora? I for one would love to see its brand grow. From sundaram at fedoraproject.org Fri Jun 29 04:34:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 10:04:34 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <4683FDB1.7080905@redhat.com> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> <4682A26F.7070104@redhat.com> <46839092.7000608@fedoraproject.org> <4683D0A3.9030507@redhat.com> <4683E123.3070105@fedoraproject.org> <4683FDB1.7080905@redhat.com> Message-ID: <46848BDA.1030808@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >>> This is not a big enough change to warrant that IMO though. It won't >>> be any more newsworthy than any other firefox release. It will be >>> done sooner rather than later. Probably by next week, although >>> having to send my status updates on a tiny project like this isn't >>> helping me get it done faster. >> >> This goes to the heart of the problem. You don't consider the changes >> important but it is. Firefox related changes are BIG news. > > Please stop misinterpreting things. I never said it was not important. > I am saying that it is not any more important than going from 2.0.0.0 > to 2.0.0.4. It will require an equivalent amount of work: this is > essentially just a version upgrade. This is amply different from being merely a version upgrade. That should be evident by the amount of discussions within Fedora and in Mozilla. People will always find something to complain about > but I'm glad that I was at least able to help fulfill your wiki page > writing desires. There will be always people critical of our work but that in many cases helps us understand the things we need to change. No thanks to you for demotivating sarcasm on efforts that were taken in part from helping you avoid answering repetitive questions but let me clarify that I have no inherent desires to write wiki pages. > So fine. You win. Please put up a wiki page that says that XULRunner > will be included in the next week or so. It was never about me winning. It was about having a planned and transparent feature list. http://fedoraproject.org/wiki/Releases/XULRunner http://fedoraproject.org/wiki/Releases/8/FeatureList It happened to be "wiki pages" after all. I would appreciate if you can quickly verify and make any changes required to the feature page. Rahul From sundaram at fedoraproject.org Fri Jun 29 04:55:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 10:25:07 +0530 Subject: XULRunner - will be or won't be? In-Reply-To: <46848BDA.1030808@fedoraproject.org> References: <1182953296.3253.33.camel@pc-notebook> <46827DCB.2010009@redhat.com> <46828B3B.2070408@fedoraproject.org> <46828B54.804@redhat.com> <468291B7.4030405@fedoraproject.org> <46829295.8000309@redhat.com> <4682963F.1030301@fedoraproject.org> <1182962924.4165.7.camel@dhcp83-186.boston.redhat.com> <4682978C.2080205@fedoraproject.org> <1182963529.4165.9.camel@dhcp83-186.boston.redhat.com> <46829B8C.6080200@fedoraproject.org> <46829D76.8060704@redhat.com> <46829F33.3070701@fedoraproject.org> <4682A26F.7070104@redhat.com> <46839092.7000608@fedoraproject.org> <4683D0A3.9030507@redhat.com> <4683E123.3070105@fedoraproject.org> <4683FDB1.7080905@redhat.com> <46848BDA.1030808@fedoraproject.org> Message-ID: <468490AB.6040705@fedoraproject.org> Rahul Sundaram wrote: > Christopher Aillon wrote: >> Rahul Sundaram wrote: >>>> This is not a big enough change to warrant that IMO though. It >>>> won't be any more newsworthy than any other firefox release. It >>>> will be done sooner rather than later. Probably by next week, >>>> although having to send my status updates on a tiny project like >>>> this isn't helping me get it done faster. >>> >>> This goes to the heart of the problem. You don't consider the changes >>> important but it is. Firefox related changes are BIG news. >> >> Please stop misinterpreting things. I never said it was not >> important. I am saying that it is not any more important than going >> from 2.0.0.0 to 2.0.0.4. It will require an equivalent amount of >> work: this is essentially just a version upgrade. > > This is amply different from being merely a version upgrade. That should > be evident by the amount of discussions within Fedora and in Mozilla. > > People will always find something to complain about >> but I'm glad that I was at least able to help fulfill your wiki page >> writing desires. > > There will be always people critical of our work but that in many cases > helps us understand the things we need to change. No thanks to you for > demotivating sarcasm on efforts that were taken in part from helping you > avoid answering repetitive questions but let me clarify that I have no > inherent desires to write wiki pages. > >> So fine. You win. Please put up a wiki page that says that XULRunner >> will be included in the next week or so. > > It was never about me winning. It was about having a planned and > transparent feature list. > > http://fedoraproject.org/wiki/Releases/XULRunner This has been renamed to FeatureXULRunner for consistency. Rahul From sundaram at fedoraproject.org Fri Jun 29 05:00:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Jun 2007 10:30:56 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <4684896C.3020604@redhat.com> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> Message-ID: <46849208.1050103@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Right but Fedora directory server isn't really Fedora specific. I can >> very well run it under any distribution. > > And is it so bad that people see the name Fedora? I for one would love > to see its brand grow. It's fine where it does not present any problems but it can. Think about Fedora trademarks for example. If I patch Fedora Directory Server can I call it by that name anymore? We consolidated our branding even in RHEL where some of requests or patches came in from rebuilders like CentOS. Do you know that we get mails from confused users who mail us about their Apache problems because of the Fedora branding in the default Apache page or the amount of support calls in RHEL on the same topic? These cost us time, effort and money. In the case of README files there is genuine advantages to have generic names. You have less changes to take care off when you branch off to RHEL, EPEL or OLPC. Maybe other distributions can be encouraged to use README.distribution too. Rahul From a.badger at gmail.com Fri Jun 29 05:24:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 28 Jun 2007 22:24:41 -0700 Subject: RFE: Use generic names in packages In-Reply-To: <46849208.1050103@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> Message-ID: <1183094681.21296.37.camel@localhost.localdomain> On Fri, 2007-06-29 at 10:30 +0530, Rahul Sundaram wrote: > In the case of README files there is genuine advantages to have generic > names. You have less changes to take care off when you branch off to > RHEL, EPEL or OLPC. Maybe other distributions can be encouraged to use > README.distribution too. That would be unfortunate. README.suse != README.fedora != README.ubuntu.... README.distribution is worse for Fedora users than README.Fedora because it's not telling them that they should read it to understand something specific to the package as it exists on their system. It could just as easily have come from upstream's tarball and be written for upstream's distro as by the Fedora Maintainer for the Fedora audience. The whole point of the file is to tell the user "Hey! I was written specifically for this distribution by the package maintainer to tell you anything special about this software as packaged here." How much better is README.[generic] for EPEL users and, as Jesse asks, "Do we really want to disguise the fact that these other distributions are Fedora derivatives" are the real questions. I'm leaning towards no on the latter question. As Till Maas notes in the thread you cite, we brand it as Fedora EPEL in bugzilla.... (If I wasn't leaning towards no, I'd probably point out that there are other names that are less generic than "distribution" but encompass both Fedora and RHEL. README.redhat, README.rpm, README.fedoraderivative :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From oliver at linux-kernel.at Fri Jun 29 07:08:43 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Jun 2007 09:08:43 +0200 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281716.34204.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> <46840BD0.9020400@linux-kernel.at> <200706281716.34204.jkeating@redhat.com> Message-ID: <4684AFFB.2020706@linux-kernel.at> On 06/28/2007 11:16 PM, Jesse Keating wrote: > On Thursday 28 June 2007 15:28:16 Oliver Falk wrote: >> koji does provide it's own buildsys-build pkg, which is recreated every >> time a new repo is created; Also a new comps.xml is created every >> time... And it's maintained via koji group stuff... So for the buildsys, >> it doesn't matter.... >> >> Correct me Jesse, if Jeff interpreted it correctly and I did not :-) > > Well, koji doesn't create a buildsys-build package, fyi. [oliver at tuborg ~]$ for i in /mnt/koji/repos/dist-f8-build/47?; do ls -ld $i $i/alpha/RPMS/buildsys-build*; done drwxr-xr-x 4 apache apache 4096 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470 -rw-r--r-- 2 apache apache 1612 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470/alpha/RPMS/buildsys-build-1-1.noarch.rpm drwxr-xr-x 4 apache apache 4096 2007-06-29 02:48 /mnt/koji/repos/dist-f8-build/471 -rw-r--r-- 2 apache apache 1612 2007-06-29 02:48 /mnt/koji/repos/dist-f8-build/471/alpha/RPMS/buildsys-build-1-1.noarch.rpm drwxr-xr-x 4 apache apache 4096 2007-06-29 08:43 /mnt/koji/repos/dist-f8-build/472 -rw-r--r-- 2 apache apache 1612 2007-06-29 08:43 /mnt/koji/repos/dist-f8-build/472/alpha/RPMS/buildsys-build-1-1.noarch.rpm drwxr-xr-x 4 apache apache 4096 2007-06-29 09:00 /mnt/koji/repos/dist-f8-build/473 -rw-r--r-- 2 apache apache 1612 2007-06-29 09:01 /mnt/koji/repos/dist-f8-build/473/alpha/RPMS/buildsys-build-1-1.noarch.rpm > instead each tag can have > group information, and that group information is used at repo creation time > for said tag and defines a build group that is installed into the chroot. > But it is all managed within Koji itself. -of From nicolas.mailhot at laposte.net Fri Jun 29 07:34:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 29 Jun 2007 09:34:47 +0200 (CEST) Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281719.49449.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <1183058127.3809.18.camel@lt21223.campus.dmacc.edu> <200706281719.49449.jkeating@redhat.com> Message-ID: <60596.192.54.193.51.1183102487.squirrel@rousalka.dyndns.org> Le Jeu 28 juin 2007 23:19, Jesse Keating a ?crit : > We can't introduce comps changes > that yum can't cope with (which may mean bumping yum, but that's fine) Can we have *one* package in the distro ship what a comps file is supposed to look like at any time (in DTD/xml-schema/relax-ng)? Pretty please? With comments about what each part does even? Makes it so much easier to identify where's the problem when a comps makes apps fail. -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Fri Jun 29 08:14:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Jun 2007 10:14:14 +0200 Subject: gl debugging help requested In-Reply-To: <1183067909.4044.88.camel@localhost.localdomain> References: <1183067909.4044.88.camel@localhost.localdomain> Message-ID: <4684BF56.2040005@hhs.nl> Tom "spot" Callaway wrote: > I'm trying to clean up vamos (a GL realistic automotive simulator), but > while I can get it to build on my rawhide box, it segfaults upon > execution. > > When I run it through gdb, it says it is segfaulting on: > > 0x00002aaaac0d2c0b in glGenTextures () from /usr/lib64/libGL.so.1 > (gdb) bt > #0 0x00002aaaac0d2c0b in glGenTextures () from /usr/lib64/libGL.so.1 > #1 0x00002aaaab5818d2 in Vamos_Media::Texture_Image::initialize > (this=0x7fff31cc9e30, smooth=false, mip_map=false, > texture_wrap=10497) at Texture_Image.cc:94 > #2 0x00002aaaab581c34 in Texture_Image (this=0x7fff31cc9e30, > file_name=, smooth=false, mip_map=false, > width=1, height=1, texture_wrap=10497) at Texture_Image.cc:74 > #3 0x0000000000404bb7 in main (argc=1, argv=0x7fff31cca318) at > vamos.cc:214 > #4 0x00002aaaad397aa4 in __libc_start_main () from /lib64/libc.so.6 > #5 0x00000000004023c9 in _start () > > I don't know the first thing about writing GL apps, nor has googling > imparted me with any useful tidbits. > > The latest SRPM is here: > http://www.auroralinux.org/people/spot/review/vamos-0.5.7-1.fc8.src.rpm > > Any and all patches or advice is welcomed. > > Thanks in advance, > > ~spot > I've seen many glGenTextures crashes in games I've packaged, esp. on 64 bit. Usually the problem is that glGenTextures gets called before a glContext has been created. All proprietary GL implementations are fine with this, but Mesa will crash, esp on 64 bit (but I've seen this on 32 bit too). Let me know if you need more help. Regards, Hans From hawat.thufir at gmail.com Fri Jun 29 08:25:43 2007 From: hawat.thufir at gmail.com (Thufir) Date: Fri, 29 Jun 2007 08:25:43 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627235930.A7970@xos037.xos.nl> <20070627220805.GC7580@dspnet.fr.eu.org> <200706281540.l5SFeRH4005191@laptop13.inf.utfsm.cl> <20070628180541.GB84138@dspnet.fr.eu.org> Message-ID: On Thu, 28 Jun 2007 20:05:41 +0200, Olivier Galibert wrote: > - 6-months release cycle, with reinstall needed As the OP, I feel entitled to bitch "me too". However, I'm learning a lot about yum, almost all good :) The re-install part is or is not related to yum and tight integration? -Thufir From hawat.thufir at gmail.com Fri Jun 29 08:34:47 2007 From: hawat.thufir at gmail.com (Thufir) Date: Fri, 29 Jun 2007 08:34:47 +0000 (UTC) Subject: portage vs yum References: <1183010902.2865.21.camel@dawkins> Message-ID: On Thu, 28 Jun 2007 08:08:22 +0200, David Nielsen wrote: > As someone with a lengthy past in the Gentoo world I will be happy to > provide you a list of the kinds of bug reports that would cause but > let's not embarrass anyone with the horror stories. I admit to great ignorance as the actual coding involved, and was giving my impression. However, leaving aside my particular solution, do you see the same problem (s) as me? constantly adding third party yum repository's, which are always behind, and repeatedly having to go outside of yum to install stuff? Surely there *must* be something better than yum. what? I meant my post, yes, as a direct challenge to the status quoue, but in a good spirit; in which spirit it seems to have been taken. -Thufir From hawat.thufir at gmail.com Fri Jun 29 08:43:26 2007 From: hawat.thufir at gmail.com (Thufir) Date: Fri, 29 Jun 2007 08:43:26 +0000 (UTC) Subject: portage vs yum References: <200706272109.45689.jkeating@redhat.com> <200706272252.06557.lightsolphoenix@gmail.com> <46839505.5050401@comsoft.de> <20070628123247.GC15974@free.fr> Message-ID: On Thu, 28 Jun 2007 14:32:47 +0200, Patrice Dumas wrote: >> spec:Requires/BuildRequires...) Therefore I can't see that ebuilds are >> looser integrated. > > It isn't the ebuilds per se that are less integrated, but the gentoo > packaging. Perhaps my last post in the topic! :) to clarify: gentoo: loose integration greater quantity of packages fedora: tight integration lesser quantity of packages However, if it's about the same quantity of labor to create an e-build as to create an RPM, I'm not sure *why* the quantity of ebuilds is greater... So, isn't some form of, perhaps, tightly integrated build-from source type packaging, the best of both worlds? (binaries for GNOME, and so forth, at request a la sabayon.) -Thufir From debarshi.ray at gmail.com Fri Jun 29 08:49:23 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 29 Jun 2007 14:19:23 +0530 Subject: Sunbird in devel In-Reply-To: <200706281707.57230.lightsolphoenix@gmail.com> References: <46840DD8.4020303@andrei.myip.org> <645d17210706281308s4a9459ffkfa3911677c862bb2@mail.gmail.com> <46841D1D.6080001@andrei.myip.org> <200706281707.57230.lightsolphoenix@gmail.com> Message-ID: <3170f42f0706290149m39c9de40r9afb764986ce613f@mail.gmail.com> > Oh, and if there's enough interest, I'll package Sunbird for Fedora. What are you waiting for? Cheerio, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Fri Jun 29 08:51:22 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 29 Jun 2007 14:21:22 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <46847475.6000405@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> Message-ID: <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> > good packaging guideline for Fedora to follow which is to avoid using > the "Fedora" name as much as possible in package names and files with > exceptions like "Fedora directory server" and recommend using generic > names wherever possible. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245649 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245826 I have a couple of review requests which may be affected by the outcome of this discussion. Specifically whether one should append "fedora-" to the names of the *.desktop files or use the "X-Fedora" category in the *.desktop files installed by these packages in /usr/share/applications ? I have seen: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061026 http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles but not sure what the final decision is. These seem to drafts or "decisions to be taken". Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From david at lovesunix.net Fri Jun 29 09:14:10 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 29 Jun 2007 11:14:10 +0200 Subject: portage vs yum In-Reply-To: References: <1183010902.2865.21.camel@dawkins> Message-ID: <1183108450.2832.16.camel@dawkins> fre, 29 06 2007 kl. 08:34 +0000, skrev Thufir: > On Thu, 28 Jun 2007 08:08:22 +0200, David Nielsen wrote: > > > As someone with a lengthy past in the Gentoo world I will be happy to > > provide you a list of the kinds of bug reports that would cause but > > let's not embarrass anyone with the horror stories. > > I admit to great ignorance as the actual coding involved, and was giving > my impression. > > However, leaving aside my particular solution, do you see the same problem > (s) as me? constantly adding third party yum repository's, which are > always behind, and repeatedly having to go outside of yum to install > stuff? Surely there *must* be something better than yum. what? > > I meant my post, yes, as a direct challenge to the status quoue, but in a > good spirit; in which spirit it seems to have been taken. As for 3rd part repos I use the Fedora one and Livna. If an application you need is missing then you can add it to the wishlist on the wiki and we'll get around to packaging it (bearing legality of course). I use the Development branch and even in that setting I rarely experience problems with dependencies. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From buildsys at redhat.com Fri Jun 29 10:03:19 2007 From: buildsys at redhat.com (Build System) Date: Fri, 29 Jun 2007 06:03:19 -0400 Subject: rawhide report: 20070629 changes Message-ID: <200706291003.l5TA3JsH018673@porkchop.devel.redhat.com> Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 rtorrent - 0.6.4-2.fc7.i386 requires libtorrent.so.9 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 wvdial - 1.54.0-5.2.2.1.i386 requires libwvbase.so.4.2 wvdial - 1.54.0-5.2.2.1.i386 requires libwvutils.so.4.2 wvdial - 1.54.0-5.2.2.1.i386 requires libwvstreams.so.4.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 rtorrent - 0.6.4-2.fc7.x86_64 requires libtorrent.so.9()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) wvdial - 1.54.0-5.2.2.1.x86_64 requires libwvstreams.so.4.2()(64bit) wvdial - 1.54.0-5.2.2.1.x86_64 requires libwvbase.so.4.2()(64bit) wvdial - 1.54.0-5.2.2.1.x86_64 requires libwvutils.so.4.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgnomedb - 1:3.0.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools rtorrent - 0.6.4-2.fc7.ppc requires libtorrent.so.9 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 wvdial - 1.54.0-5.2.2.1.ppc requires libwvbase.so.4.2 wvdial - 1.54.0-5.2.2.1.ppc requires libwvutils.so.4.2 wvdial - 1.54.0-5.2.2.1.ppc requires libwvstreams.so.4.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgnomedb - 1:3.0.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.12-1.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) rtorrent - 0.6.4-2.fc7.ppc64 requires libtorrent.so.9()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) wvdial - 1.54.0-5.2.2.1.ppc64 requires libwvstreams.so.4.2()(64bit) wvdial - 1.54.0-5.2.2.1.ppc64 requires libwvbase.so.4.2()(64bit) wvdial - 1.54.0-5.2.2.1.ppc64 requires libwvutils.so.4.2()(64bit) From P at draigBrady.com Fri Jun 29 10:24:45 2007 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Fri, 29 Jun 2007 11:24:45 +0100 Subject: summary of package upgrade process Message-ID: <4684DDED.4010100@draigBrady.com> I've updated my "linux project release process" document, to include the changes required for koji and bodhi. Hopefully it will be of use to someone else. http://www.pixelbeat.org/docs/linux_project_release_process/ cheers, P?draig. From jonathan.underwood at gmail.com Fri Jun 29 11:09:28 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 29 Jun 2007 12:09:28 +0100 Subject: Sunbird in devel In-Reply-To: <200706281707.57230.lightsolphoenix@gmail.com> References: <46840DD8.4020303@andrei.myip.org> <645d17210706281308s4a9459ffkfa3911677c862bb2@mail.gmail.com> <46841D1D.6080001@andrei.myip.org> <200706281707.57230.lightsolphoenix@gmail.com> Message-ID: <645d17210706290409of52c8fbm65b1bb5ccbf89f01@mail.gmail.com> On 28/06/07, Kelly wrote: > Um, Lightning is just an extension for Thunderbird... > > Does it need to be packaged? Yes - the extension package on the Mozilla site is not compatible with the Fedora build of Thunderbird. From dr.diesel at gmail.com Fri Jun 29 11:30:47 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 29 Jun 2007 06:30:47 -0500 Subject: Compiz Fusion? Message-ID: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> Any plans to incorporate into rawhide? -- On Tap: HopZilla and a Belgian Tripel Fermentating: Imperial English Pale Ale Fermentating: Guinness Extra Extra Imperial Stout Fermentating: Belgian Tripel Dry Next: Brutal Blackend Bitter From drago01 at gmail.com Fri Jun 29 11:35:09 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 29 Jun 2007 13:35:09 +0200 Subject: Compiz Fusion? In-Reply-To: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> Message-ID: On 6/29/07, Dr. Diesel wrote: > > Any plans to incorporate into rawhide? was about to ask the same? what are the compiz plans for f8? will compiz-fusion replace compiz and berly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Fri Jun 29 11:36:23 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 29 Jun 2007 13:36:23 +0200 Subject: portage vs yum In-Reply-To: References: <200706272109.45689.jkeating@redhat.com> <200706272252.06557.lightsolphoenix@gmail.com> <46839505.5050401@comsoft.de> <20070628123247.GC15974@free.fr> Message-ID: <20070629113623.GC3137@free.fr> On Fri, Jun 29, 2007 at 08:43:26AM +0000, Thufir wrote: > > to clarify: > > gentoo: > loose integration > greater quantity of packages > > fedora: > tight integration > lesser quantity of packages > > However, if it's about the same quantity of labor to create an e-build as > to create an RPM, I'm not sure *why* the quantity of ebuilds is greater... It is more labor to create an integrated package than to have less integration. But also the community may have different size and time. > So, isn't some form of, perhaps, tightly integrated build-from source > type packaging, the best of both worlds? (binaries for GNOME, and so > forth, at request a la sabayon.) I don't think that the fact that Fedora isn't built from source affect in any way the number of packages available. What affects it is the number of people working on fedora and the difficulties of packaging. -- Pat From pertusus at free.fr Fri Jun 29 11:40:32 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 29 Jun 2007 13:40:32 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <46847475.6000405@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> Message-ID: <20070629114032.GD3137@free.fr> On Fri, Jun 29, 2007 at 08:24:45AM +0530, Rahul Sundaram wrote: > Hi > > In this specific instance I believe the guidelines should be mandating > README.distribution instead. I personnally like the idea, but the file name should, in my opinion be more specific such that it is obvious at first sight that it has been added by the package maintainer. And in my opinion README.distribution isn't precise enough. I don't have a precise idea on what it could be in order to be kept short, but something along README.package_specific -- Pat From dr.diesel at gmail.com Fri Jun 29 11:54:12 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 29 Jun 2007 06:54:12 -0500 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> Message-ID: <2a28d2ab0706290454h14e014b6xb844ccb0c5cf22ab@mail.gmail.com> On 6/29/07, dragoran wrote: > > > On 6/29/07, Dr. Diesel wrote: > > Any plans to incorporate into rawhide? > > was about to ask the same? what are the compiz plans for f8? will > compiz-fusion replace compiz and berly? > > > Beryl's web site says the name Beryl is done. Everything forth has been ported to the Compiz name with their merger. Looks like the core package is still just compiz but some of the extra stuff is compiz-fusion. From jeevanullas at gmail.com Fri Jun 29 11:51:22 2007 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Fri, 29 Jun 2007 17:21:22 +0530 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> Message-ID: <1183117882.22649.0.camel@localhost.localdomain> I am not sure about rawhide but it has a private repo as if now for Fedora7. http://blog.kagesenshi.org for more info. On Fri, 2007-06-29 at 13:35 +0200, dragoran wrote: > > > On 6/29/07, Dr. Diesel wrote: > Any plans to incorporate into rawhide? > > was about to ask the same? what are the compiz plans for f8? will > compiz-fusion replace compiz and berly? > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- http://freeshells.ch/~source/ From dr.diesel at gmail.com Fri Jun 29 12:00:29 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 29 Jun 2007 07:00:29 -0500 Subject: Compiz Fusion? In-Reply-To: <1183117882.22649.0.camel@localhost.localdomain> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> Message-ID: <2a28d2ab0706290500w442a1aesd678c4d39aec490@mail.gmail.com> On 6/29/07, Deependra Singh Shekhawat wrote: > I am not sure about rawhide but it has a private repo as if now for > Fedora7. http://blog.kagesenshi.org for more info. > > On Fri, 2007-06-29 at 13:35 +0200, dragoran wrote: > > > > > > On 6/29/07, Dr. Diesel wrote: > > Any plans to incorporate into rawhide? > > > > was about to ask the same? what are the compiz plans for f8? will > > compiz-fusion replace compiz and berly? > > > > You'll have to compile it yourself due to the libwnck-1.so.18 dependency. Rawhide is currently at .22 something. From jkeating at redhat.com Fri Jun 29 12:22:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 08:22:38 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <4684AFFB.2020706@linux-kernel.at> References: <200706281352.57015.jkeating@redhat.com> <200706281716.34204.jkeating@redhat.com> <4684AFFB.2020706@linux-kernel.at> Message-ID: <200706290822.44576.jkeating@redhat.com> On Friday 29 June 2007 03:08:43 Oliver Falk wrote: > fyi. > > [oliver at tuborg ~]$ for i in /mnt/koji/repos/dist-f8-build/47?; do ls -ld > $i $i/alpha/RPMS/buildsys-build*; done > drwxr-xr-x 4 apache apache 4096 2007-06-29 02:44 > /mnt/koji/repos/dist-f8-build/470 > -rw-r--r-- 2 apache apache 1612 2007-06-29 02:44 > /mnt/koji/repos/dist-f8-build/470/alpha/RPMS/buildsys-build-1-1.noarch.rpm Hrm, Perhaps I slightly misunderstood what koji was doing with the group info, but this still happens behind the scenes and is managed by koji itself. The repodata that koji creates has the buildsys-build group information as well, so perhaps the creation of the buildsys-build package is a carryover from early iterations of koji. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 29 12:23:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 08:23:29 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <60596.192.54.193.51.1183102487.squirrel@rousalka.dyndns.org> References: <200706281352.57015.jkeating@redhat.com> <200706281719.49449.jkeating@redhat.com> <60596.192.54.193.51.1183102487.squirrel@rousalka.dyndns.org> Message-ID: <200706290823.29533.jkeating@redhat.com> On Friday 29 June 2007 03:34:47 Nicolas Mailhot wrote: > Can we have *one* package in the distro ship what a comps file is > supposed to look like at any time ?(in DTD/xml-schema/relax-ng)? > Pretty please? With comments about what each part does even? > > Makes it so much easier to identify where's the problem when a comps > makes apps fail. Care to create one? We could drop it in as a %doc or example somewhere. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 29 12:36:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 08:36:54 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706290822.44576.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <4684AFFB.2020706@linux-kernel.at> <200706290822.44576.jkeating@redhat.com> Message-ID: <200706290836.54323.jkeating@redhat.com> On Friday 29 June 2007 08:22:38 Jesse Keating wrote: > ?The > repodata that koji creates has the buildsys-build group information Erm, make that 'build' group information. $ cat /mnt/koji/static-repos/dist-f8-build-current/i386/repodata/comps.xml build build None false true bash bzip2 coreutils cpio diffutils fedora-release gcc gcc-c++ gzip make patch perl perl-devel redhat-rpm-config rpm-build sed tar unzip which -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Jun 29 12:47:56 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 29 Jun 2007 14:47:56 +0200 (CEST) Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706290823.29533.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <200706281719.49449.jkeating@redhat.com> <60596.192.54.193.51.1183102487.squirrel@rousalka.dyndns.org> <200706290823.29533.jkeating@redhat.com> Message-ID: <64820.192.54.193.51.1183121276.squirrel@rousalka.dyndns.org> Le Ven 29 juin 2007 14:23, Jesse Keating a ?crit : > On Friday 29 June 2007 03:34:47 Nicolas Mailhot wrote: >> Can we have *one* package in the distro ship what a comps file is >> supposed to look like at any time (in DTD/xml-schema/relax-ng)? >> Pretty please? With comments about what each part does even? >> >> Makes it so much easier to identify where's the problem when a comps >> makes apps fail. > > Care to create one? I wouldn't ask for one if I knew exactly what each comps tag is supposed to mean. notting stealthily dumped a comps dtd in our cvs so I suppose it's "official" and could be bundled with rpm/yum (or whatever package is supposed to own the comps format). It's not as nice as a modern annotated xml/relax-ng schema but it's a beginning. > We could drop it in as a %doc or example somewhere. I'd rather it was registered properly in the system xml catalogs so xml tools (vim/emacs/libxml...) just know the comps structure. -- Nicolas Mailhot From buytenh at wantstofly.org Fri Jun 29 12:56:49 2007 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Fri, 29 Jun 2007 14:56:49 +0200 Subject: Fedora and Cross Compiling In-Reply-To: <1182952795.24184.36.camel@mccallum.corsepiu.local> References: <46686D85.5000603@redhat.com> <4669B459.5070401@redhat.com> <1181377214.2801.54.camel@pmac.infradead.org> <466DC1C7.6070303@redhat.com> <1181662311.25228.42.camel@pmac.infradead.org> <20070627135414.GA13164@xi.wantstofly.org> <1182952795.24184.36.camel@mccallum.corsepiu.local> Message-ID: <20070629125649.GC27892@xi.wantstofly.org> On Wed, Jun 27, 2007 at 03:59:55PM +0200, Ralf Corsepius wrote: > > There's a couple of issues: > > - There's also two issues with building libstdc++ - > > > ... it install target installs various target files > > not in the sysroot but in the host's directory space. > > --enable-version-specific-runtime-libs Thanks, that worked. Here is a new version of the Fedora -> Fedora gcc cross patch. It results in a working C/C++ cross compiler (at least, it manages to cross-compile several programs for ARM, and manages to cross-compile a native ARM gcc from sources.) There's a couple of issues left: - The current cross-libgcc and cross-libstdc++ packages put their libraries in the sysroot (/usr/%{target}/sys-root), since they are target libraries, but this might collide with installed native versions of the same packages down the road. - rpm's %ifarch handling doesn't go together with cross-compiling very well, neither does handling of macros such as %{__strip}, %{__objdump}. Find a proper solution for this. Again, I don't know whether adding cross support to the main gcc package is the best idea. Maybe splitting the cross bits out into a separate source package is a better option, I'm not sure. Comments? Ideas? Index: SPECS/gcc41.spec =================================================================== --- SPECS.orig/gcc41.spec +++ SPECS/gcc41.spec @@ -1,9 +1,25 @@ +%if "%{?gcc_target}" == "" +%define gcc_target %{_target_platform} +%define isnative 1 +%else +%define isnative 0 +%define cross %{gcc_target}- +%define __strip %{gcc_target}-strip +%endif + %define DATE 20070503 %define gcc_version 4.1.2 %define gcc_release 12 %define _unpackaged_files_terminate_build 0 -%define multilib_64_archs sparc64 ppc64 s390x x86_64 %define include_gappletviewer 1 +%if !%{isnative} +%define build_ada 0 +%define build_fortran 0 +%define build_java 0 +%define build_objc 0 +%define run_tests 0 +%else +%define multilib_64_archs sparc64 ppc64 s390x x86_64 %ifarch %{ix86} x86_64 ia64 ppc alpha %define build_ada 1 %else @@ -25,8 +41,9 @@ %ifarch x86_64 %define multilib_32_arch i386 %endif +%endif Summary: Various compilers (C, C++, Objective-C, Java, ...) -Name: gcc +Name: %{?cross}gcc Version: %{gcc_version} Release: %{gcc_release}.fa1 License: GPL @@ -44,7 +61,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version # Need binutils which support --hash-style=gnu >= 2.17.50.0.2-7 # Need binutils which support mffgpr and mftgpr >= 2.17.50.0.2-8 # Need binutils which support 2-argument .movsp >= 2.17.50.0.5 -BuildRequires: binutils >= 2.17.50.0.5 +BuildRequires: %{?cross}binutils >= 2.17.50.0.5 BuildRequires: zlib-devel, gettext, dejagnu, bison, flex, texinfo, sharutils %if %{build_java} BuildRequires: gcc-java, libgcj, /usr/share/java/eclipse-ecj.jar, zip, unzip @@ -52,7 +69,7 @@ BuildRequires: gcc-java, libgcj, /usr/sh # Make sure pthread.h doesn't contain __thread tokens # Make sure glibc supports stack protector # Make sure glibc supports DT_GNU_HASH -BuildRequires: glibc-devel >= 2.4.90-13 +BuildRequires: %{?cross}glibc-devel >= 2.4.90-13 BuildRequires: elfutils-devel >= 0.72 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double @@ -69,7 +86,7 @@ BuildRequires: gcc-gnat >= 3.1, libgnat %ifarch ia64 BuildRequires: libunwind >= 0.98 %endif -Requires: cpp = %{version}-%{release} +Requires: %{?cross}cpp = %{version}-%{release} # Need .eh_frame ld optimizations # Need proper visibility support # Need -pie support @@ -80,25 +97,29 @@ Requires: cpp = %{version}-%{release} # Need binutils that supports --hash-style=gnu # Need binutils that support mffgpr/mftgpr # Need binutils that support 2-argument .movsp >= 2.17.50.0.5 -Requires: binutils >= 2.17.50.0.5 +Requires: %{?cross}binutils >= 2.17.50.0.5 # Make sure gdb will understand DW_FORM_strp -Conflicts: gdb < 5.1-2 -Requires: glibc-devel >= 2.2.90-12 +Conflicts: %{?cross}gdb < 5.1-2 +Requires: %{?cross}glibc-devel >= 2.2.90-12 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double -Requires: glibc >= 2.3.90-35 +Requires: %{?cross}glibc >= 2.3.90-35 %endif -Requires: libgcc >= %{version}-%{release} +Requires: %{?cross}libgcc >= %{version}-%{release} +%if %{isnative} Requires: libgomp = %{version}-%{release} +%endif +%if %{isnative} Obsoletes: gcc3 Obsoletes: egcs +%endif %ifarch sparc -Obsoletes: gcc-sparc32 -Obsoletes: gcc-c++-sparc32 +Obsoletes: %{?cross}gcc-sparc32 +Obsoletes: %{?cross}gcc-c++-sparc32 %endif %ifarch ppc -Obsoletes: gcc-ppc32 -Obsoletes: gcc-c++-ppc32 +Obsoletes: %{?cross}gcc-ppc32 +Obsoletes: %{?cross}gcc-c++-ppc32 %endif Obsoletes: gcc-chill %if !%{build_ada} @@ -160,6 +181,7 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch %{arm} %define _gnu %{nil} %endif +%if "%{?gcc_target}" == "" %ifarch sparc %define gcc_target_platform sparc64-%{_vendor}-%{_target_os} %endif @@ -169,30 +191,33 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch sparc ppc %define gcc_target_platform %{_target_platform} %endif +%else +%define gcc_target_platform %{gcc_target} +%endif %description The gcc package contains the GNU Compiler Collection version 4.1. You'll need this package in order to compile C code. -%package -n libgcc +%package -n %{?cross}libgcc Summary: GCC version 4.1 shared support library Group: System Environment/Libraries Autoreq: false -%description -n libgcc +%description -n %{?cross}libgcc This package contains GCC shared support library which is needed e.g. for exception handling support. %package c++ Summary: C++ support for GCC Group: Development/Languages -Requires: gcc = %{version}-%{release} -Requires: libstdc++ = %{version}-%{release} -Requires: libstdc++-devel = %{version}-%{release} -Obsoletes: gcc3-c++ -Obsoletes: gcc34-c++ -Obsoletes: gcc35-c++ -Obsoletes: gcc4-c++ +Requires: %{?cross}gcc = %{version}-%{release} +Requires: %{?cross}libstdc++ = %{version}-%{release} +Requires: %{?cross}libstdc++-devel = %{version}-%{release} +Obsoletes: %{?cross}gcc3-c++ +Obsoletes: %{?cross}gcc34-c++ +Obsoletes: %{?cross}gcc35-c++ +Obsoletes: %{?cross}gcc4-c++ Autoreq: true %description c++ @@ -200,26 +225,26 @@ This package adds C++ support to the GNU It includes support for most of the current C++ specification, including templates and exception handling. -%package -n libstdc++ +%package -n %{?cross}libstdc++ Summary: GNU Standard C++ Library Group: System Environment/Libraries -Obsoletes: libstdc++3 -Obsoletes: libstdc++34 +Obsoletes: %{?cross}libstdc++3 +Obsoletes: %{?cross}libstdc++34 Autoreq: true -%description -n libstdc++ +%description -n %{?cross}libstdc++ The libstdc++ package contains a rewritten standard compliant GCC Standard C++ Library. -%package -n libstdc++-devel +%package -n %{?cross}libstdc++-devel Summary: Header files and libraries for C++ development Group: Development/Libraries -Requires: libstdc++ = %{version}-%{release}, %{_prefix}/%{_lib}/libstdc++.so.6 -Obsoletes: libstdc++3-devel +Requires: %{?cross}libstdc++ = %{version}-%{release}, %{_prefix}/%{_lib}/libstdc++.so.6 +Obsoletes: %{?cross}libstdc++3-devel Obsoletes: libstdc++34-devel Autoreq: true -%description -n libstdc++-devel +%description -n %{?cross}libstdc++-devel This is the GNU implementation of the standard C++ libraries. This package includes the header files and libraries needed for C++ development. This includes rewritten implementation of STL. @@ -382,7 +407,7 @@ Autoreq: true %description -n libgcj-src The Java(tm) runtime library sources for use in Eclipse. -%package -n cpp +%package -n %{?cross}cpp Summary: The C Preprocessor. Group: Development/Languages Prereq: /sbin/install-info @@ -391,7 +416,7 @@ Obsoletes: gnupro %endif Autoreq: true -%description -n cpp +%description -n %{?cross}cpp Cpp is the GNU C-Compatible Compiler Preprocessor. Cpp is a macro processor which is used automatically by the C compiler to transform your program before actual @@ -583,6 +608,7 @@ case "$OPT_FLAGS" in ../gcc/Makefile.in ;; esac +%if %{isnative} CC="$CC" CFLAGS="$OPT_FLAGS" CXXFLAGS="$OPT_FLAGS" XCFLAGS="$OPT_FLAGS" TCFLAGS="$OPT_FLAGS" \ GCJFLAGS="$OPT_FLAGS" \ ../configure --prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \ @@ -663,6 +689,20 @@ rm -rf testlogs-%{_target_platform}-%{ve # Make protoize make -C gcc CC="./xgcc -B ./ -O2" proto +%else +CC="$CC" CFLAGS="-O2 -g" CXXFLAGS="-O2 -g" XCFLAGS="-O2 -g" TCFLAGS="-O2 -g" \ + GCJFLAGS="-O2 -g" \ + ../configure --prefix=%{_prefix} --mandir=%{_mandir} \ + --infodir=%{_infodir} --enable-shared --enable-threads=posix \ + --enable-checking=release --with-system-zlib --enable-__cxa_atexit \ + --disable-libunwind-exceptions --enable-languages=c,c++ \ + --disable-libgcj --disable-libssp --disable-libgomp \ + --disable-libmudflap --with-sysroot=yes \ + --enable-version-specific-runtime-libs \ + --target=%{gcc_target_platform} + +GCJFLAGS="-O2 -g" make %{?_smp_mflags} BOOT_CFLAGS="-O2 -g" +%endif # Make generated man pages even if Pod::Man is not new enough perl -pi -e 's/head3/head2/' ../contrib/texi2pod.pl @@ -730,8 +770,6 @@ fi export PATH=`pwd`/java_hacks${PATH:+:$PATH} %endif -TARGET_PLATFORM=%{gcc_target_platform} - # There are some MP bugs in libstdc++ Makefiles make -C %{gcc_target_platform}/libstdc++-v3 @@ -748,15 +786,19 @@ FULLPATH=$RPM_BUILD_ROOT%{_prefix}/lib/g FULLEPATH=$RPM_BUILD_ROOT%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} # fix some things +%if %{isnative} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/cc mkdir -p $RPM_BUILD_ROOT/lib ln -sf ..%{_prefix}/bin/cpp $RPM_BUILD_ROOT/lib/cpp +%endif %if %{build_fortran} ln -sf gfortran $RPM_BUILD_ROOT%{_prefix}/bin/f95 %endif rm -f $RPM_BUILD_ROOT%{_infodir}/dir gzip -9 $RPM_BUILD_ROOT%{_infodir}/*.info* +%if %{build_ada} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/gnatgcc +%endif cxxconfig="`find %{gcc_target_platform}/libstdc++-v3/include -name c++config.h`" for i in `find %{gcc_target_platform}/[36]*/libstdc++-v3/include -name c++config.h 2>/dev/null`; do @@ -818,11 +860,26 @@ sed -i -e 's/lib: /&%%{static:%%eJava pr $FULLPATH/libgcj.spec %endif +%if %{isnative} mkdir -p $RPM_BUILD_ROOT/%{_lib} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcc_s.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 chmod 755 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 ln -sf libgcc_s-%{gcc_version}-%{DATE}.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s.so.1 ln -sf /%{_lib}/libgcc_s.so.1 $FULLPATH/libgcc_s.so +%else +mkdir -p $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/lib +mv -f $FULLPATH/libgcc_s.so.1 $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 +chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 +ln -sf libgcc_s-%{gcc_version}-%{DATE}.so.1 $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s.so.1 +ln -sf ../../../../%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s.so.1 $FULLPATH/libgcc_s.so + +mkdir -p $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include +mv -f $FULLPATH/include/c++ $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/ +ln -sf ../../../../../%{gcc_target_platform}/sys-root/%{_prefix}/include/c++ $FULLPATH/include/c++ + +mkdir -p $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/%{_lib} +mv $FULLPATH/libstdc++.so.* $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/%{_lib}/ +%endif %ifarch sparc ppc ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64/libgcc_s.so %endif @@ -830,8 +887,10 @@ ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64 ln -sf /lib/libgcc_s.so.1 $FULLPATH/32/libgcc_s.so %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.spec $FULLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/include/omp.h $FULLPATH/include/ +%endif %if %{build_ada} mv -f $FULLPATH/adalib/libgnarl-*.so $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ @@ -859,13 +918,19 @@ if [ "%{_lib}" = "lib" ]; then %if %{build_objc} ln -sf ../../../libobjc.so.1 libobjc.so %endif +%if %{isnative} ln -sf ../../../libstdc++.so.6.* libstdc++.so +%else +ln -sf ../../../../%{gcc_target}/sys-root/%{_prefix}/%{_lib}/libstdc++.so.6.* libstdc++.so +%endif %if %{build_fortran} ln -sf ../../../libgfortran.so.1.* libgfortran.so %endif +%if %{isnative} ln -sf ../../../libgomp.so.1.* libgomp.so ln -sf ../../../libmudflap.so.0.* libmudflap.so ln -sf ../../../libmudflapth.so.0.* libmudflapth.so +%endif %if %{build_java} ln -sf ../../../libgcj.so.8rh.* libgcj.so ln -sf ../../../libgcj-tools.so.8rh.* libgcj-tools.so @@ -907,8 +972,10 @@ fi %if %{build_java} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcj_bc.so $FULLLPATH/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libstdc++.*a $FULLLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libsupc++.*a . +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortranbegin.*a . @@ -916,9 +983,11 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.*a . %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/include/mf-runtime.h include/ +%endif %ifarch sparc ppc %if %{build_objc} @@ -928,9 +997,11 @@ ln -sf ../`echo ../../../../lib/libstdc+ %if %{build_fortran} ln -sf ../`echo ../../../../lib/libgfortran.so.1.* | sed s~/lib/~/lib64/~` 64/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib/libgomp.so.1.* | sed s~/lib/~/lib64/~` 64/libgomp.so ln -sf ../`echo ../../../../lib/libmudflap.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflap.so ln -sf ../`echo ../../../../lib/libmudflapth.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib/libgcj.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj.so ln -sf ../`echo ../../../../lib/libgcj-tools.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj-tools.so @@ -946,8 +1017,10 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/li %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libobjc.*a 64/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgomp.*a 64/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libmudflap{,th}.*a 64/ +%endif ln -sf lib32/libstdc++.a libstdc++.a ln -sf ../lib64/libstdc++.a 64/libstdc++.a %endif @@ -960,9 +1033,11 @@ ln -sf ../`echo ../../../../lib64/libstd %if %{build_fortran} ln -sf ../`echo ../../../../lib64/libgfortran.so.1.* | sed s~/../lib64/~/~` 32/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib64/libgomp.so.1.* | sed s~/../lib64/~/~` 32/libgomp.so ln -sf ../`echo ../../../../lib64/libmudflap.so.0.* | sed s~/../lib64/~/~` 32/libmudflap.so ln -sf ../`echo ../../../../lib64/libmudflapth.so.0.* | sed s~/../lib64/~/~` 32/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib64/libgcj.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj.so ln -sf ../`echo ../../../../lib64/libgcj-tools.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj-tools.so @@ -976,9 +1051,11 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libg %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libobjc.*a 32/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgomp.*a 32/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libmudflap{,th}.*a 32/ %endif +%endif %ifarch sparc64 ppc64 ln -sf ../lib32/libstdc++.a 32/libstdc++.a ln -sf lib64/libstdc++.a libstdc++.a @@ -996,15 +1073,17 @@ ln -sf ../../../%{multilib_32_arch}-%{_v %endif # Strip debug info from Fortran/ObjC/Java static libraries -strip -g `find . \( -name libgfortran.a -o -name libobjc.a -o -name libgomp.a \ +%{__strip} -g `find . \( -name libgfortran.a -o -name libobjc.a -o -name libgomp.a \ -o -name libmudflap.a -o -name libmudflapth.a \ -o -name libgcc.a -o -name libgcov.a \) -a -type f` popd %if %{build_fortran} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.so.1.* %endif +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.so.1.* chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.so.0.* +%endif %if %{build_objc} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.so.1.* %endif @@ -1022,7 +1101,11 @@ for h in `find $FULLPATH/include -name \ fi done +%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c89 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c89 <<"EOF" +%endif #!/bin/sh fl="-std=c89" for opt; do @@ -1034,7 +1117,11 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c99 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c99 <<"EOF" +%endif #!/bin/sh fl="-std=c99" for opt; do @@ -1046,17 +1133,25 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/c?9 +%else +chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c?9 +%endif +%if %{isnative} %ifnarch %{arm} mkdir -p $RPM_BUILD_ROOT%{_prefix}/sbin gcc -static -Os %{SOURCE1} -o $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade -strip $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade +%{__strip} $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade +%endif %endif cd .. -%find_lang %{name} -%find_lang cpplib +%if %{isnative} +%find_lang %{?cross}%{name} +%find_lang %{?cross}cpplib +%endif # Remove binaries we will not be including, so that they don't end up in # gcc-debuginfo @@ -1102,11 +1197,11 @@ if [ $1 = 0 ]; then --info-dir=%{_infodir} %{_infodir}/gcc.info.gz || : fi -%post -n cpp +%post -n %{?cross}cpp /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || : -%preun -n cpp +%preun -n %{?cross}cpp if [ $1 = 0 ]; then /sbin/install-info --delete \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || : @@ -1150,16 +1245,18 @@ if [ $1 = 0 ]; then --info-dir=%{_infodir} %{_infodir}/gnat-style.info.gz || : fi +%if %{isnative} %ifnarch %{arm} # Because glibc Prereq's libgcc and /sbin/ldconfig # comes from glibc, it might not exist yet when # libgcc is installed -%post -n libgcc -p %{_prefix}/sbin/libgcc_post_upgrade +%post -n %{?cross}libgcc -p %{_prefix}/sbin/libgcc_post_upgrade %endif -%post -n libstdc++ -p /sbin/ldconfig +%post -n %{?cross}libstdc++ -p /sbin/ldconfig -%postun -n libstdc++ -p /sbin/ldconfig +%postun -n %{?cross}libstdc++ -p /sbin/ldconfig +%endif %post -n libobjc -p /sbin/ldconfig @@ -1194,8 +1291,13 @@ fi %postun -n libmudflap -p /sbin/ldconfig +%if %{isnative} %files -f %{name}.lang +%else +%files +%endif %defattr(-,root,root) +%if %{isnative} %{_prefix}/bin/cc %{_prefix}/bin/c89 %{_prefix}/bin/c99 @@ -1203,6 +1305,11 @@ fi %{_prefix}/bin/gcov %{_prefix}/bin/protoize %{_prefix}/bin/unprotoize +%else +%{_prefix}/bin/%{gcc_target_platform}-c89 +%{_prefix}/bin/%{gcc_target_platform}-c99 +%{_prefix}/bin/%{gcc_target_platform}-gcov +%endif %ifarch sparc ppc %{_prefix}/bin/%{_target_platform}-gcc %endif @@ -1213,11 +1320,16 @@ fi %{_prefix}/bin/ppc-%{_vendor}-%{_target_os}-gcc %endif %{_prefix}/bin/%{gcc_target_platform}-gcc +%if %{isnative} %{_mandir}/man1/gcc.1* %{_mandir}/man1/gcov.1* %{_mandir}/man1/protoize.1* %{_mandir}/man1/unprotoize.1* %{_infodir}/gcc* +%else +%{_mandir}/man1/%{gcc_target_platform}-gcc.1* +%{_mandir}/man1/%{gcc_target_platform}-gcov.1* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} @@ -1225,7 +1337,9 @@ fi %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/SYSCALLS.c.X +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stddef.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stdarg.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/varargs.h @@ -1235,6 +1349,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/iso646.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/syslimits.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/unwind.h +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/omp.h %ifarch %{ix86} x86_64 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mmintrin.h @@ -1254,6 +1369,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/altivec.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/spe.h %endif +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/README %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/collect2 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/crt*.o @@ -1261,6 +1377,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcov.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_eh.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_s.so +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.spec %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.so @@ -1284,36 +1401,54 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.so %endif +%endif %dir %{_prefix}/libexec/getconf %{_prefix}/libexec/getconf/default %doc gcc/README* rpm.doc/changelogs/gcc/ChangeLog* gcc/COPYING* +%if %{isnative} %files -n cpp -f cpplib.lang +%else +%files -n %{?cross}cpp +%endif %defattr(-,root,root) +%if %{isnative} /lib/cpp %{_prefix}/bin/cpp %{_mandir}/man1/cpp.1* %{_infodir}/cpp* +%else +%{_prefix}/bin/%{gcc_target_platform}-cpp +%{_mandir}/man1/%{gcc_target_platform}-cpp.1* +%endif %dir %{_prefix}/libexec/gcc %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/cc1 -%files -n libgcc +%files -n %{?cross}libgcc %defattr(-,root,root) +%if %{isnative} /%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 /%{_lib}/libgcc_s.so.1 %ifnarch %{arm} %{_prefix}/sbin/libgcc_post_upgrade %endif -%doc gcc/COPYING.LIB +%else +/%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 +/%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s.so.1 +%endif %files c++ %defattr(-,root,root) %{_prefix}/bin/%{gcc_target_platform}-*++ +%if %{isnative} %{_prefix}/bin/g++ %{_prefix}/bin/c++ %{_mandir}/man1/g++.1* +%else +%{_mandir}/man1/%{gcc_target_platform}-g++.1* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} @@ -1342,20 +1477,32 @@ fi %endif %doc rpm.doc/changelogs/gcc/cp/ChangeLog* -%files -n libstdc++ +%files -n %{?cross}libstdc++ %defattr(-,root,root) +%if %{isnative} %{_prefix}/%{_lib}/libstdc++.so.6* +%else +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/%{_lib}/libstdc++.so.6* +%endif -%files -n libstdc++-devel +%files -n %{?cross}libstdc++-devel %defattr(-,root,root) +%if %{isnative} %dir %{_prefix}/include/c++ %dir %{_prefix}/include/c++/%{gcc_version} %{_prefix}/include/c++/%{gcc_version}/[^gjos]* %{_prefix}/include/c++/%{gcc_version}/os* %{_prefix}/include/c++/%{gcc_version}/s[^u]* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} +%if !%{isnative} +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/c++/[^gjos]* +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/c++/os* +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/c++/s[^u]* +%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/c++ +%endif %ifarch sparc ppc %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/lib32 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/lib32/libstdc++.a @@ -1619,6 +1766,7 @@ fi %{_prefix}/%{_lib}/libgnarl-*.so %endif +%if %{isnative} %files -n libgomp %defattr(-,root,root) %{_prefix}/%{_lib}/libgomp.so.1* @@ -1655,6 +1803,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflapth.so %endif %doc rpm.doc/changelogs/libmudflap/ChangeLog* +%endif %changelog * Thu May 3 2007 Jakub Jelinek 4.1.2-12 From jkeating at redhat.com Fri Jun 29 13:18:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 09:18:39 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <64820.192.54.193.51.1183121276.squirrel@rousalka.dyndns.org> References: <200706281352.57015.jkeating@redhat.com> <200706290823.29533.jkeating@redhat.com> <64820.192.54.193.51.1183121276.squirrel@rousalka.dyndns.org> Message-ID: <200706290918.39248.jkeating@redhat.com> On Friday 29 June 2007 08:47:56 Nicolas Mailhot wrote: > I wouldn't ask for one if I knew exactly what each comps tag is > supposed to mean. notting stealthily dumped a comps dtd in our cvs so > I suppose it's "official" and could be bundled with rpm/yum (or > whatever package is supposed to own the comps format). It's not as > nice as a modern annotated xml/relax-ng schema but it's a beginning. > > > We could drop it in as a %doc or example somewhere. > > I'd rather it was registered properly in the system xml catalogs so > xml tools (vim/emacs/libxml...) just know the comps structure. Again, I'm XML ignorant so all these words... mean not much to me. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Fri Jun 29 13:34:21 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 29 Jun 2007 08:34:21 -0500 Subject: gl debugging help requested In-Reply-To: <4684BF56.2040005@hhs.nl> References: <1183067909.4044.88.camel@localhost.localdomain> <4684BF56.2040005@hhs.nl> Message-ID: <1183124061.3384.5.camel@localhost.localdomain> On Fri, 2007-06-29 at 10:14 +0200, Hans de Goede wrote: > I've seen many glGenTextures crashes in games I've packaged, esp. on 64 bit. > Usually the problem is that glGenTextures gets called before a glContext has > been created. All proprietary GL implementations are fine with this, but Mesa > will crash, esp on 64 bit (but I've seen this on 32 bit too). > > Let me know if you need more help. The code in question looks like this: unsigned char* data = read_png_file (m_file_name); GLuint texture_id; glGenTextures (1, &texture_id); glBindTexture (GL_TEXTURE_2D, texture_id); set_gl_parameters (data, smooth, mip_map, texture_wrap); m_texture_name = texture_id; delete [] data; ms_image_cache [m_file_name] = Cached_Image (m_texture_name, m_width_pixels, m_height_pixels); All of the reference code I could find on google seemed to be similar, declare the GLuint variable, then initialize it with glGenTextures. Is there something obviously wrong here? Any help is appreciated, ~spot From mclasen at redhat.com Fri Jun 29 13:31:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 29 Jun 2007 09:31:34 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> References: <46847475.6000405@fedoraproject.org> <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> Message-ID: <1183123894.6299.4.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-06-29 at 14:21 +0530, Debarshi 'Rishi' Ray wrote: > > good packaging guideline for Fedora to follow which is to avoid using > > the "Fedora" name as much as possible in package names and files with > > exceptions like "Fedora directory server" and recommend using generic > > names wherever possible. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245649 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245826 > > I have a couple of review requests which may be affected by the > outcome of this discussion. Specifically whether one should append > "fedora-" to the names of the *.desktop files or use the "X-Fedora" > category in the *.desktop files installed by these packages in > /usr/share/applications ? The menu files we are shipping make no use of the X-Fedora category (and the X-Red-Hat ones are being phased out too), so adding it will not make any difference. From nicolas.mailhot at laposte.net Fri Jun 29 13:44:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 29 Jun 2007 15:44:01 +0200 (CEST) Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706290918.39248.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <200706290823.29533.jkeating@redhat.com> <64820.192.54.193.51.1183121276.squirrel@rousalka.dyndns.org> <200706290918.39248.jkeating@redhat.com> Message-ID: <40914.192.54.193.51.1183124641.squirrel@rousalka.dyndns.org> Le Ven 29 juin 2007 15:18, Jesse Keating a ?crit : > On Friday 29 June 2007 08:47:56 Nicolas Mailhot wrote: >> I wouldn't ask for one if I knew exactly what each comps tag is >> supposed to mean. notting stealthily dumped a comps dtd in our cvs >> so >> I suppose it's "official" and could be bundled with rpm/yum (or >> whatever package is supposed to own the comps format). It's not as >> nice as a modern annotated xml/relax-ng schema but it's a beginning. >> >> > We could drop it in as a %doc or example somewhere. >> >> I'd rather it was registered properly in the system xml catalogs so >> xml tools (vim/emacs/libxml...) just know the comps structure. > > Again, I'm XML ignorant so all these words... mean not much to me. Just means you decide one package is the owner of the comps format, and have it drop a format definition in /usr/share/xml (in DTD/XML-schema/relax-ng format, probably DTD since notting put a dtd in cvs), and you use the xml tools to register this format definition file in /etc/xml/catalog.xml (like the docbook schema package does) And then suddenly all the well-behaved XML distro tools know how a comps file is supposed to be structured and can flag errors. (though you'd probably need one schema for comps.xml and another for comps.xml.in since they do not use the same tag names) -- Nicolas Mailhot From jwilson at redhat.com Fri Jun 29 13:45:26 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 29 Jun 2007 09:45:26 -0400 Subject: Compiz Fusion? In-Reply-To: <1183117882.22649.0.camel@localhost.localdomain> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> Message-ID: <46850CF6.4080206@redhat.com> Deependra Singh Shekhawat wrote: > I am not sure about rawhide but it has a private repo as if now for > Fedora7. http://blog.kagesenshi.org for more info. A few of us (the current beryl maintainers, compiz maintainers and the individual responsible for the above packages) just started discussing the path forward earlier this week. > On Fri, 2007-06-29 at 13:35 +0200, dragoran wrote: >> >> On 6/29/07, Dr. Diesel wrote: >> Any plans to incorporate into rawhide? >> >> was about to ask the same? what are the compiz plans for f8? will >> compiz-fusion replace compiz and berly? -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Fri Jun 29 13:46:12 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 29 Jun 2007 15:46:12 +0200 Subject: gl debugging help requested In-Reply-To: <1183124061.3384.5.camel@localhost.localdomain> References: <1183067909.4044.88.camel@localhost.localdomain> <4684BF56.2040005@hhs.nl> <1183124061.3384.5.camel@localhost.localdomain> Message-ID: <46850D24.1060608@hhs.nl> Tom "spot" Callaway wrote: > On Fri, 2007-06-29 at 10:14 +0200, Hans de Goede wrote: > >> I've seen many glGenTextures crashes in games I've packaged, esp. on 64 bit. >> Usually the problem is that glGenTextures gets called before a glContext has >> been created. All proprietary GL implementations are fine with this, but Mesa >> will crash, esp on 64 bit (but I've seen this on 32 bit too). >> >> Let me know if you need more help. > > The code in question looks like this: > > unsigned char* data = read_png_file (m_file_name); > > GLuint texture_id; > glGenTextures (1, &texture_id); > glBindTexture (GL_TEXTURE_2D, texture_id); > set_gl_parameters (data, smooth, mip_map, texture_wrap); > m_texture_name = texture_id; > delete [] data; > ms_image_cache [m_file_name] = > Cached_Image (m_texture_name, m_width_pixels, m_height_pixels); > > All of the reference code I could find on google seemed to be similar, > declare the GLuint variable, then initialize it with glGenTextures. > > Is there something obviously wrong here? > Not obviously no, let me try to rephrase my earlier hint. No (none whatsover) libGL functions (including glGenTextures) may be called before an OpenGL context has been created, iow before a window suitable for openGL rendering has been created. So if this apps tries to loads the textures above before creating its window, then that will crash with Mesa. The trick is to look at the sequence in which window creation (for example SDL _setVideoMode() with OPENGL flag, and the glGenTextures get called. 99% of all crashes which in the BT point to glGenTextures() are because of glGenTextures getting called before the window + openGL context is created. I hope that helps, if not please repost the URL to the srpm and I'll take a look as time permits. Regards, Hans From jima at beer.tclug.org Fri Jun 29 13:51:45 2007 From: jima at beer.tclug.org (Jima) Date: Fri, 29 Jun 2007 08:51:45 -0500 (CDT) Subject: portage vs yum In-Reply-To: References: <200706272109.45689.jkeating@redhat.com> <200706272252.06557.lightsolphoenix@gmail.com> <46839505.5050401@comsoft.de> <20070628123247.GC15974@free.fr> Message-ID: On Fri, 29 Jun 2007, Thufir wrote: > On Thu, 28 Jun 2007 14:32:47 +0200, Patrice Dumas wrote: >> It isn't the ebuilds per se that are less integrated, but the gentoo >> packaging. > > Perhaps my last post in the topic! :) > > to clarify: > > gentoo: > loose integration > greater quantity of packages > > fedora: > tight integration > lesser quantity of packages > > However, if it's about the same quantity of labor to create an e-build as > to create an RPM, I'm not sure *why* the quantity of ebuilds is greater... > > So, isn't some form of, perhaps, tightly integrated build-from source > type packaging, the best of both worlds? (binaries for GNOME, and so > forth, at request a la sabayon.) Whether the packages are binary or built-from-source is irrelevant. We could, if we wanted (for some reason), make lots of not-well-integrated RPMs, achieving the "we have all the packages in teh world!!!11" goal. Alas, the packaging quality wouldn't be much to write home about, and we'd probably have to relax or kill the packaging guidelines. What takes the hard work in Fedora is the tight integration. It has nothing to do with the nature of RPMs or yum. So, for your example, by providing "tightly integrated build-from source type packaging," we'd gain *nothing*. It'd take just as much work to write a tightly-integrated ebuild as it would to write a tightly-integrated spec. (I think, anyway -- people with more advanced experience with ebuilds are welcome to correct me if I'm mistaken.) Jima From markg85 at gmail.com Fri Jun 29 13:47:07 2007 From: markg85 at gmail.com (Mark) Date: Fri, 29 Jun 2007 15:47:07 +0200 Subject: Red Hat CEO Says He Talked Patents with Microsoft (Reuters) In-Reply-To: <46847D09.4060801@fedoraproject.org> References: <46847D09.4060801@fedoraproject.org> Message-ID: <6e24a8e80706290647m36a0e334pf74737b5339eb733@mail.gmail.com> If the CEO of RedHat says "I can't answer the question" than it means that atleast something is going on between RedHat and Microsoft. and i'm not happy about that at all. Fedora is still being "ruled" by redhat so this doesn't affect RedHat alone but also Fedora. At this moment i'm kinda puzzled with what to do with this. it's fine if they make a deal with Microsoft. as long as it's NOT the patent deal. I as a fedora user want to know the truth about this. Anyone in the fedora management team or (better) the redhat management team that can give some clarification about this? 2007/6/29, Rahul Sundaram : > Gregory Maxwell wrote: > > http://www.eweek.com/article2/0,1759,2151908,00.asp > > > > In an interview with Reuters, Szulik declined to say whether his > > company is now in negotiations with Microsoft over signing such a > > patent agreement. > > > > "I can't answer the question," he said. > > I don't see how this is on topic in this. At any rate Red Hat has > already clarified it's position on both the interoperability and patent > fronts several times now. > > http://www.redhat.com/promo/believe/ > http://linux.slashdot.org/article.pl?sid=07/06/19/1720201 > http://www.computing.co.uk/vnunet/news/2189545/red-hat-sets-limits-microsoft > > Rahul > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From opensource at till.name Fri Jun 29 13:56:33 2007 From: opensource at till.name (Till Maas) Date: Fri, 29 Jun 2007 15:56:33 +0200 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706281946.25821.jkeating@redhat.com> References: <200706281946.25821.jkeating@redhat.com> Message-ID: <200706291556.34321.opensource@till.name> On Fr Juni 29 2007, Jesse Keating wrote: > O U T A G E R E P O R T F O R M > =================================== > > Incident Date: > 6/28/07 > > Incident Time: > 6:00PM EDT Can you please change the date format to ISO-style: e.g. 2007-06-28 and the time to 24h, UTC time? Regards, Till From bpepple at fedoraproject.org Fri Jun 29 14:09:21 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 29 Jun 2007 10:09:21 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> References: <46847475.6000405@fedoraproject.org> <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> Message-ID: <1183126161.2845.7.camel@kennedy> On Fri, 2007-06-29 at 14:21 +0530, Debarshi 'Rishi' Ray wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245649 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245826 > > I have a couple of review requests which may be affected by the > outcome of this discussion. Specifically whether one should append > "fedora-" to the names of the *.desktop files or use the "X-Fedora" > category in the *.desktop files installed by these packages in > /usr/share/applications ? The packaging guidelines seem pretty clear to me. For new packages, if upstream uses , leave it intact, otherwise use fedora as . And where in the packaging guidelines does it say that you should be adding the X-Fedora category? http://fedoraproject.org/wiki/Packaging/Guidelines#head-254ddf07aae20a23ced8cecc219d8f73926e9755 Later, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jam at zoidtechnologies.com Fri Jun 29 14:09:55 2007 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Fri, 29 Jun 2007 10:09:55 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291556.34321.opensource@till.name> References: <200706281946.25821.jkeating@redhat.com> <200706291556.34321.opensource@till.name> Message-ID: <200706291009.55937.jam@zoidtechnologies.com> On Friday 29 June 2007 9:56 am, Till Maas wrote: > On Fr Juni 29 2007, Jesse Keating wrote: > > O U T A G E R E P O R T F O R M > > =================================== > > > > Incident Date: > > 6/28/07 > > > > Incident Time: > > 6:00PM EDT > > Can you please change the date format to ISO-style: e.g. 2007-06-28 and the > time to 24h, UTC time? > > Regards, > Till +1 to use ISO-style, but please list UTC *and* local time for the outage. -- Jeff MacDonald, Zoid Technologies "Web Applications That Suck Less" From jkeating at redhat.com Fri Jun 29 14:06:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 10:06:16 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291556.34321.opensource@till.name> References: <200706281946.25821.jkeating@redhat.com> <200706291556.34321.opensource@till.name> Message-ID: <200706291006.16696.jkeating@redhat.com> On Friday 29 June 2007 09:56:33 Till Maas wrote: > Can you please change the date format to ISO-style: e.g. 2007-06-28 and the > time to 24h, UTC time? Sure, why not. I kifed this mail from our internal outage reports which report things in HQ time. We don't have a "formal" outage template yet in Infrastructure, I had wanted to do that at the last meeting but I was otherwise busy. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Fri Jun 29 14:16:32 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 29 Jun 2007 10:16:32 -0400 Subject: Red Hat CEO Says He Talked Patents with Microsoft (Reuters) In-Reply-To: <6e24a8e80706290647m36a0e334pf74737b5339eb733@mail.gmail.com> References: <46847D09.4060801@fedoraproject.org> <6e24a8e80706290647m36a0e334pf74737b5339eb733@mail.gmail.com> Message-ID: <1183126592.2845.13.camel@kennedy> On Fri, 2007-06-29 at 15:47 +0200, Mark wrote: > If the CEO of RedHat says "I can't answer the question" than it means > that atleast something is going on between RedHat and Microsoft. and > i'm not happy about that at all. Fedora is still being "ruled" by > redhat so this doesn't affect RedHat alone but also Fedora. At this > moment i'm kinda puzzled with what to do with this. > it's fine if they make a deal with Microsoft. as long as it's NOT the > patent deal. > > I as a fedora user want to know the truth about this. > Anyone in the fedora management team or (better) the redhat management > team that can give some clarification about this? Please move this discussion elsewhere. This mailing list is for fedora *development* discussions. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Fri Jun 29 14:09:45 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 29 Jun 2007 10:09:45 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <1183126161.2845.7.camel@kennedy> References: <46847475.6000405@fedoraproject.org> <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> <1183126161.2845.7.camel@kennedy> Message-ID: <1183126185.6299.8.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-06-29 at 10:09 -0400, Brian Pepple wrote: > On Fri, 2007-06-29 at 14:21 +0530, Debarshi 'Rishi' Ray wrote: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245649 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245826 > > > > I have a couple of review requests which may be affected by the > > outcome of this discussion. Specifically whether one should append > > "fedora-" to the names of the *.desktop files or use the "X-Fedora" > > category in the *.desktop files installed by these packages in > > /usr/share/applications ? > > The packaging guidelines seem pretty clear to me. For new packages, if > upstream uses , leave it intact, otherwise use fedora as > . > The part that is unclear is that it is not defined anywhere what a vendor prefix is, really. Upstream just happens to ship desktop files that are called gnome-foobar.desktop or kde-powertoy.desktop, and we have to guess that the part up to the first - is the vendor prefix. But what about things like tetex-xdvi.desktop or virt-manager.desktop ? Once again, desktop files prove to be the worst possible implementation of an application registry... From oliver at linux-kernel.at Fri Jun 29 14:25:44 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Jun 2007 16:25:44 +0200 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706290822.44576.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <200706281716.34204.jkeating@redhat.com> <4684AFFB.2020706@linux-kernel.at> <200706290822.44576.jkeating@redhat.com> Message-ID: <46851668.9000600@linux-kernel.at> Jesse Keating schrieb: > On Friday 29 June 2007 03:08:43 Oliver Falk wrote: >> fyi. >> >> [oliver at tuborg ~]$ for i in /mnt/koji/repos/dist-f8-build/47?; do ls -ld >> $i $i/alpha/RPMS/buildsys-build*; done >> drwxr-xr-x 4 apache apache 4096 2007-06-29 02:44 >> /mnt/koji/repos/dist-f8-build/470 >> -rw-r--r-- 2 apache apache 1612 2007-06-29 02:44 >> /mnt/koji/repos/dist-f8-build/470/alpha/RPMS/buildsys-build-1-1.noarch.rpm > > Hrm, Perhaps I slightly misunderstood what koji was doing with the group info, > but this still happens behind the scenes and is managed by koji itself. The > repodata that koji creates has the buildsys-build group information as well, > so perhaps the creation of the buildsys-build package is a carryover from > early iterations of koji. Since I set up koji for AlphaCore, I know it very well now... :-) And you're totally correct, koji also creates a comps.xml in repodata where it provides the same information. Koji does both and I've never tried to find out which way is the faster one - I guess difference could only be measured in milliseconds and nobody should mind :-) Best, Oliver From mcepl at redhat.com Fri Jun 29 14:30:06 2007 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 29 Jun 2007 16:30:06 +0200 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT References: <200706281946.25821.jkeating@redhat.com> <200706291556.34321.opensource@till.name> <200706291009.55937.jam@zoidtechnologies.com> Message-ID: On Fri, 29 Jun 2007 10:09:55 -0400, Jeff MacDonald scripst: > +1 to use ISO-style, but please list UTC *and* local time for the > outage. What local time? Why should EDT matter to me or other people living somewhere else than on the eastern shore of the United States (and maybe in Brazil, I am not sure)? Mat?j From jam at zoidtechnologies.com Fri Jun 29 14:40:40 2007 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Fri, 29 Jun 2007 10:40:40 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: References: <200706281946.25821.jkeating@redhat.com> <200706291009.55937.jam@zoidtechnologies.com> Message-ID: <200706291040.41119.jam@zoidtechnologies.com> On Friday 29 June 2007 10:30 am, Matej Cepl wrote: > What local time? Why should EDT matter to me or other people living > somewhere else than on the eastern shore of the United States (and maybe > in Brazil, I am not sure)? > > Mat?j because not everybody knows what UTC/GMT is, and using it alone will just cause further confusion.. if, however, one can see that UTC is a few hours off of US/Eastern, things might go better. :) at the moment it sounds like the outage notification is being generated by hand, so listing the two different time zones will take a little extra work.. however, if the process is automated, it will be trivial to make a call to "gmtime()" as well as "localtime()". please.. if this issue causes the notifications to *not* be sent, leave it the way it is.. I'd rather get the notifications and have to do math to convert to my local time than not get them at all because there is no agreement on which time zone(s) should be used. regards, -- Jeff MacDonald, Zoid Technologies "Web Applications That Suck Less" From mmcgrath at redhat.com Fri Jun 29 14:53:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 29 Jun 2007 09:53:49 -0500 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291006.16696.jkeating@redhat.com> References: <200706281946.25821.jkeating@redhat.com> <200706291556.34321.opensource@till.name> <200706291006.16696.jkeating@redhat.com> Message-ID: <46851CFD.5050900@redhat.com> Jesse Keating wrote: > > Sure, why not. I kifed this mail from our internal outage reports which > report things in HQ time. We don't have a "formal" outage template yet in > Infrastructure, I had wanted to do that at the last meeting but I was > otherwise busy. > > Actually we do :) http://fedoraproject.org/wiki/Infrastructure/OutageTemplate -Mike From jam at zoidtechnologies.com Fri Jun 29 14:53:43 2007 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Fri, 29 Jun 2007 10:53:43 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: References: <200706281946.25821.jkeating@redhat.com> <200706291009.55937.jam@zoidtechnologies.com> Message-ID: <200706291053.43602.jam@zoidtechnologies.com> On Friday 29 June 2007 10:30 am, Matej Cepl wrote: > On Fri, 29 Jun 2007 10:09:55 -0400, Jeff MacDonald scripst: > > +1 to use ISO-style, but please list UTC *and* local time for the > > outage. > > What local time? Why should EDT matter to me or other people living > somewhere else than on the eastern shore of the United States (and maybe > in Brazil, I am not sure)? > good point.. local time should be the time local to the physical location of the equipment in question. > Mat?j regards, -- Jeff MacDonald, Zoid Technologies "Web Applications That Suck Less" From jwboyer at jdub.homelinux.org Fri Jun 29 14:55:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 29 Jun 2007 09:55:57 -0500 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291053.43602.jam@zoidtechnologies.com> References: <200706281946.25821.jkeating@redhat.com> <200706291009.55937.jam@zoidtechnologies.com> <200706291053.43602.jam@zoidtechnologies.com> Message-ID: <1183128957.30145.30.camel@weaponx.rchland.ibm.com> On Fri, 2007-06-29 at 10:53 -0400, Jeff MacDonald wrote: > On Friday 29 June 2007 10:30 am, Matej Cepl wrote: > > On Fri, 29 Jun 2007 10:09:55 -0400, Jeff MacDonald scripst: > > > +1 to use ISO-style, but please list UTC *and* local time for the > > > outage. > > > > What local time? Why should EDT matter to me or other people living > > somewhere else than on the eastern shore of the United States (and maybe > > in Brazil, I am not sure)? > > > > good point.. local time should be the time local to the physical location of > the equipment in question. And what good does that do? I think just UTC should be fine. josh From opensource at till.name Fri Jun 29 14:57:00 2007 From: opensource at till.name (Till Maas) Date: Fri, 29 Jun 2007 16:57:00 +0200 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291040.41119.jam@zoidtechnologies.com> References: <200706281946.25821.jkeating@redhat.com> <200706291040.41119.jam@zoidtechnologies.com> Message-ID: <200706291657.03873.opensource@till.name> On Fr Juni 29 2007, Jeff MacDonald wrote: > because not everybody knows what UTC/GMT is, and using it alone will just > cause further confusion.. if, however, one can see that UTC is a few hours > off of US/Eastern, things might go better. :) I do not know, what EDT is, either. But I know the offset of my local time to UTC. > at the moment it sounds like the outage notification is being generated by > hand, so listing the two different time zones will take a little extra > work.. however, if the process is automated, it will be trivial to make a Maybe it is enough to mention the offset of EDT to UTC, so everyone in EDT can see what he has to calculate. > please.. if this issue causes the notifications to *not* be sent, leave it > the way it is.. I'd rather get the notifications and have to do math to > convert to my local time than not get them at all because there is no > agreement on which time zone(s) should be used. Even with UTC I still have to convert the time to CEST, but UTC is imho a fair common timezone. Regards, Till From kevin.kofler at chello.at Fri Jun 29 14:58:57 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 Jun 2007 14:58:57 +0000 (UTC) Subject: portage vs yum References: <43244.65.223.36.19.1182971402.squirrel@webmail.thecodergeek.com> <20070627235930.A7970@xos037.xos.nl> <20070627220805.GC7580@dspnet.fr.eu.org> <200706281540.l5SFeRH4005191@laptop13.inf.utfsm.cl> <20070628180541.GB84138@dspnet.fr.eu.org> Message-ID: Thufir gmail.com> writes: > The re-install part is or is not related to yum and tight integration? It's simply wrong. No reinstalls are needed, the installer can do upgrades or you can even just upgrade with yum or apt-rpm (not recommended, but that doesn't mean "impossible"). The fact that you have to upgrade to a new distribution version at all as opposed to getting updated to the next version progressively is a decision which has nothing to do with yum/rpm nor with tight integration. It's perfectly possible to do rolling releases with rpm. For example, Rawhide works that way. It isn't recommended for everyday use though (just like Gentoo ~x86 or ~x86_64 installs). Kevin Kofler From twaugh at redhat.com Fri Jun 29 15:00:12 2007 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 29 Jun 2007 16:00:12 +0100 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <1183128957.30145.30.camel@weaponx.rchland.ibm.com> References: <200706281946.25821.jkeating@redhat.com> <200706291009.55937.jam@zoidtechnologies.com> <200706291053.43602.jam@zoidtechnologies.com> <1183128957.30145.30.camel@weaponx.rchland.ibm.com> Message-ID: <1183129212.5077.13.camel@cyberelk.elk> The 'international-time' package in Fedora can be used to copy and paste local and UTC times of specific events (such as meetings, outages, etc) into emails. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Fri Jun 29 14:51:14 2007 From: opensource at till.name (Till Maas) Date: Fri, 29 Jun 2007 16:51:14 +0200 Subject: Outage Notification - 2007-06-07 04:00 [UTC] In-Reply-To: <46670113.1020102@redhat.com> References: <46670113.1020102@redhat.com> Message-ID: <200706291651.15804.opensource@till.name> On Mi Juni 6 2007, Mike McGrath wrote: > There will be an outage starting at 2007-06-07 04:00 [UTC], which will last When you write "2007-06-07 04:00 UTC" (without the square brackets), then one can easily convert the date with date -d "2007-06-07 04:00 UTC" Regards, Till From jam at zoidtechnologies.com Fri Jun 29 15:10:00 2007 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Fri, 29 Jun 2007 11:10:00 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291657.03873.opensource@till.name> References: <200706281946.25821.jkeating@redhat.com> <200706291040.41119.jam@zoidtechnologies.com> <200706291657.03873.opensource@till.name> Message-ID: <200706291110.00373.jam@zoidtechnologies.com> On Friday 29 June 2007 10:57 am, Till Maas wrote: > On Fr Juni 29 2007, Jeff MacDonald wrote: > > because not everybody knows what UTC/GMT is, and using it alone will just > > cause further confusion.. if, however, one can see that UTC is a few > > hours off of US/Eastern, things might go better. :) > > I do not know, what EDT is, either. But I know the offset of my local time > to UTC. > EDT is "US/Eastern Daylight Time". I should have worded the original reply a bit differently.. not all *Americans* know what UTC/GMT is.. I'm odd because I worked for ans.net for a while, and we did a lot of things using UTC. there's been some replies to this thread showing an easy way to convert to local time (assuming the machine is configured correctly), so I'm ok with the template that was created that uses UTC. > > at the moment it sounds like the outage notification is being generated > > by hand, so listing the two different time zones will take a little extra > > work.. however, if the process is automated, it will be trivial to make a > > Maybe it is enough to mention the offset of EDT to UTC, so everyone in EDT > can see what he has to calculate. > that works for me. > Even with UTC I still have to convert the time to CEST, but UTC is imho a > fair common timezone. > which is why I thought it best to list UTC *and* local time to the equipment in question so that it would be easy for the vast majority of users to figure out what happened and when. > Regards, > Till regards, -- Jeff MacDonald, Zoid Technologies "Web Applications That Suck Less" From caillon at redhat.com Fri Jun 29 15:16:38 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 29 Jun 2007 11:16:38 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291110.00373.jam@zoidtechnologies.com> References: <200706281946.25821.jkeating@redhat.com> <200706291040.41119.jam@zoidtechnologies.com> <200706291657.03873.opensource@till.name> <200706291110.00373.jam@zoidtechnologies.com> Message-ID: <46852256.50701@redhat.com> Jeff MacDonald wrote: > EDT is "US/Eastern Daylight Time". I should have worded the original reply a > bit differently.. not all *Americans* know what UTC/GMT is.. I'm odd because > I worked for ans.net for a while, and we did a lot of things using UTC. Not all Americans are Fedora packagers. I'd say the types of people that package for a Linux distribution would be more likely to know what it is. Or would at least know to google for it. :-) From nicolas.mailhot at laposte.net Fri Jun 29 15:18:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 29 Jun 2007 17:18:03 +0200 (CEST) Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291110.00373.jam@zoidtechnologies.com> References: <200706281946.25821.jkeating@redhat.com> <200706291040.41119.jam@zoidtechnologies.com> <200706291657.03873.opensource@till.name> <200706291110.00373.jam@zoidtechnologies.com> Message-ID: <16104.192.54.193.51.1183130283.squirrel@rousalka.dyndns.org> Le Ven 29 juin 2007 17:10, Jeff MacDonald a ?crit : >> Even with UTC I still have to convert the time to CEST, but UTC is >> imho a >> fair common timezone. >> > > which is why I thought it best to list UTC *and* local time to the > equipment > in question so that it would be easy for the vast majority of users to > figure out what happened and when. ??? The vast majority of users is not in the same timezone as the equipment and many of them do not know the meaning of US timezone abbreviations. If you insist in dual time presentation please use something like the W3C datetime profile, with local timezone defined as an UTC hour offset (see last two examples of http://www.w3.org/TR/NOTE-datetime) -- Nicolas Mailhot From jam at zoidtechnologies.com Fri Jun 29 15:24:07 2007 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Fri, 29 Jun 2007 11:24:07 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <46852256.50701@redhat.com> References: <200706281946.25821.jkeating@redhat.com> <200706291110.00373.jam@zoidtechnologies.com> <46852256.50701@redhat.com> Message-ID: <200706291124.07562.jam@zoidtechnologies.com> On Friday 29 June 2007 11:16 am, Christopher Aillon wrote: > Not all Americans are Fedora packagers. I'd say the types of people > that package for a Linux distribution would be more likely to know what > it is. Or would at least know to google for it. :-) ok.. the issue here is to save time/effort. I get several hundred non-junk emails during the work week. if I have to do a google search or open a terminal to figure out if an outage affected me or not, I might just skip it or get the conversion wrong. if the notifications are not automated, then by no means should an engineer/packager/whatnot be expected to list UTC *and* a local time zone. let's keep it at UTC for now, and *please* use the ISO date format per the template. hey.. at least notifications are being sent out. :) regards, -- Jeff MacDonald, Zoid Technologies "Web Applications That Suck Less" From jkeating at redhat.com Fri Jun 29 15:34:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 11:34:10 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <46851CFD.5050900@redhat.com> References: <200706281946.25821.jkeating@redhat.com> <200706291006.16696.jkeating@redhat.com> <46851CFD.5050900@redhat.com> Message-ID: <200706291134.18114.jkeating@redhat.com> On Friday 29 June 2007 10:53:49 Mike McGrath wrote: > Jesse Keating wrote: > > Sure, why not. I kifed this mail from our internal outage reports which > > report things in HQ time. We don't have a "formal" outage template yet > > in Infrastructure, I had wanted to do that at the last meeting but I was > > otherwise busy. > > Actually we do :) > > http://fedoraproject.org/wiki/Infrastructure/OutageTemplate > > -Mike That's for planned outages. I think we need one for unplanned outages that is organized differently to get the pertinent information to the developers as quickly as possible. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jun 29 15:36:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 11:36:06 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <200706291134.18114.jkeating@redhat.com> References: <200706281946.25821.jkeating@redhat.com> <46851CFD.5050900@redhat.com> <200706291134.18114.jkeating@redhat.com> Message-ID: <200706291136.06955.jkeating@redhat.com> On Friday 29 June 2007 11:34:10 Jesse Keating wrote: > > http://fedoraproject.org/wiki/Infrastructure/OutageTemplate > > > > ? ? -Mike > > That's for planned outages. ?I think we need one for unplanned outages that > is organized differently to get the pertinent information to the developers > as quickly as possible. Although looking at the current template that may work just fine (: I bet we could even create a tool that asks for input and spits out a properly formed email. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From greno at verizon.net Fri Jun 29 16:24:19 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 29 Jun 2007 12:24:19 -0400 Subject: kernel support for VE's (OpenVZ / Linux-vServer) Message-ID: <46853233.3010508@verizon.net> Are there any plans on the roadmap to add kernel support for virtual environments (as opposed to virtual machines). I'm referring to OpenVZ and Linux-vServer here. From jpo at di.uminho.pt Fri Jun 29 16:25:58 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 29 Jun 2007 17:25:58 +0100 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: References: Message-ID: <46853296.60005@di.uminho.pt> Robin Norwood wrote: > Hi, > > On Monday, perl-devel will be removed from the f8 buildroots. This > means that if you try to build a perl-* package that uses the perl build > tools, you will need to add those tools to the BuildRequires for the > package. The most common will be: > > BuildRequires: perl(ExtUtils::MakeMaker) How do I add all perl core modules to the build root? jpo -- Jos? Pedro Oliveira * mailto:jpo at di.uminho.pt * http://gsd.di.uminho.pt/members/jpo/ * From debarshi.ray at gmail.com Fri Jun 29 16:27:48 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 29 Jun 2007 21:57:48 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <1183126161.2845.7.camel@kennedy> References: <46847475.6000405@fedoraproject.org> <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> <1183126161.2845.7.camel@kennedy> Message-ID: <3170f42f0706290927p3f486995xb679cc1944d2e73c@mail.gmail.com> > And where in the packaging guidelines does it say that you should be > adding the X-Fedora category? The gnome-password-generator package in FC6 uses it. Since I am taking it off the list of orphan packages, I continued to use it. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jwboyer at jdub.homelinux.org Fri Jun 29 16:29:49 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 29 Jun 2007 11:29:49 -0500 Subject: kernel support for VE's (OpenVZ / Linux-vServer) In-Reply-To: <46853233.3010508@verizon.net> References: <46853233.3010508@verizon.net> Message-ID: <1183134589.30145.38.camel@weaponx.rchland.ibm.com> On Fri, 2007-06-29 at 12:24 -0400, Gerry Reno wrote: > Are there any plans on the roadmap to add kernel support for virtual > environments (as opposed to virtual machines). I'm referring to OpenVZ > and Linux-vServer here. Most likely not until they are in the upstream kernel. josh From greno at verizon.net Fri Jun 29 16:35:05 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 29 Jun 2007 12:35:05 -0400 Subject: kernel support for VE's (OpenVZ / Linux-vServer) In-Reply-To: <1183134589.30145.38.camel@weaponx.rchland.ibm.com> References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> Message-ID: <468534B9.1030609@verizon.net> Josh Boyer wrote: > On Fri, 2007-06-29 at 12:24 -0400, Gerry Reno wrote: > >> Are there any plans on the roadmap to add kernel support for virtual >> environments (as opposed to virtual machines). I'm referring to OpenVZ >> and Linux-vServer here. >> > > Most likely not until they are in the upstream kernel. > > josh > > Do you know when they will make it in the upstream kernel? From jkeating at redhat.com Fri Jun 29 16:34:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Jun 2007 12:34:58 -0400 Subject: kernel support for VE's (OpenVZ / Linux-vServer) In-Reply-To: <468534B9.1030609@verizon.net> References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> <468534B9.1030609@verizon.net> Message-ID: <200706291234.59009.jkeating@redhat.com> On Friday 29 June 2007 12:35:05 Gerry Reno wrote: > Do you know when they will make it in the upstream kernel? Magic 8 ball says.... Seriously some of these may never make it in. It all depends on the motivations of the teams producing these things. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Fri Jun 29 16:49:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 29 Jun 2007 11:49:58 -0500 Subject: kernel support for VE's (OpenVZ / Linux-vServer) In-Reply-To: <200706291234.59009.jkeating@redhat.com> References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> <468534B9.1030609@verizon.net> <200706291234.59009.jkeating@redhat.com> Message-ID: <1183135798.30145.41.camel@weaponx.rchland.ibm.com> On Fri, 2007-06-29 at 12:34 -0400, Jesse Keating wrote: > On Friday 29 June 2007 12:35:05 Gerry Reno wrote: > > Do you know when they will make it in the upstream kernel? > > Magic 8 ball says.... > > Seriously some of these may never make it in. It all depends on the > motivations of the teams producing these things. Right. It would be better to ask the OpenVZ and Linux-vServer projects when they are going to push for upstream inclusion. Even once that has started, it can take a few months to get accepted, depending on how things go. josh From kevin.kofler at chello.at Fri Jun 29 16:53:04 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 29 Jun 2007 16:53:04 +0000 (UTC) Subject: perl-devel will be removed from the f8 buildroots References: <46853296.60005@di.uminho.pt> Message-ID: Jose Pedro Oliveira di.uminho.pt> writes: > How do I add all perl core modules to the build root? List them all as BuildRequires. Or better, list only those your package actually needs. Kevin Kofler From greno at verizon.net Fri Jun 29 16:53:11 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 29 Jun 2007 12:53:11 -0400 Subject: kernel support for VE's (OpenVZ / Linux-vServer) In-Reply-To: <200706291234.59009.jkeating@redhat.com> References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> <468534B9.1030609@verizon.net> <200706291234.59009.jkeating@redhat.com> Message-ID: <468538F7.7070906@verizon.net> Jesse Keating wrote: > On Friday 29 June 2007 12:35:05 Gerry Reno wrote: > >> Do you know when they will make it in the upstream kernel? >> > > Magic 8 ball says.... > LOL :-) > Seriously some of these may never make it in. It all depends on the > motivations of the teams producing these things. > > I've been trying to follow some of the discussion on 'linux-kernel' about all this 'partitioning' and 'containers' related to openvz and linux-vserver but I couldn't really get a sense of when something might come of this. So I guess I was looking if someone knew of a target date. I couldn't find any. From jpo at di.uminho.pt Fri Jun 29 17:01:21 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 29 Jun 2007 18:01:21 +0100 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: References: <46853296.60005@di.um inho.pt> Message-ID: <46853AE1.9010801@di.uminho.pt> Kevin Kofler wrote: > Jose Pedro Oliveira di.uminho.pt> writes: >> How do I add all perl core modules to the build root? > > List them all as BuildRequires. Or better, list only those your package > actually needs. FYI: more than 700 packages will have to be reviewed due to this change which I consider a waste of packagers time, in particular mine. jpo -- Jos? Pedro Oliveira * mailto:jpo at di.uminho.pt * http://gsd.di.uminho.pt/members/jpo/ * From buc at odusz.so-cdu.ru Fri Jun 29 17:09:47 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 29 Jun 2007 21:09:47 +0400 Subject: Mail accounts in heterogeneous environments Message-ID: <46853CDB.60206@odu.neva.ru> I would like to consider a case where both Linux and Windows computers are in use, but mail servers are completely Linux-oriented (f.e., dovecot + postfix on Fedora hosts). In such a heterogeneous environment, to provide unique authorisation/authentication mechanism, either "OpenLDAP + Samba NT" or "AD + msSFU" solutions are used. It provides uniform accounts and passwords, independent of whether users use Linux or Windows on their desktops. There is one circumstance which can spoil this fine solution a bit. When a windows user creates its mail account (in OE or similar), he/she is compelled to specify login and password "manually". When sometimes the uniform password will be changed (either by Ctrl-Alt-Del from the desktop, or by a system admin), this "manual" specification in the local mail settings will not be changed automatically. The user then is compelled to change its password there too; or sysadmin should use different, seldom-changed account/password set just for mail subsystem... All modern windows mail programs provide an "SPA" option (secure password authentication). Using it, the mail program just uses the current desktop's login/password. This way the situation described above can be effectively avoided. But "SPA" uses NTLM (and spnego?) authentication mechanism, which is not supported properly now neither by dovecot or by postfix (it seems that another MTA and imap servers do not support it properly as well). Yes, I know that both postfix and dovecot actually "supports" NTLM now. But dovecot uses NTLM against a local database only, it cannot authenticate users against the windows domain. Postfix (and other MTA) could use cyrus-sasl library, which has a "ntlm" plugin (capable to do domain auth), but the actual blocker here is the dovecot issues. Since the postfix and friends can do SMTP auth against a dovecot-auth daemon, the solution seems to be focused in dovecot package only. By adding of proper NTLM support to dovecot-auth, we can use "SPA" on windows desktops and can forget about manual filling of login/password form. Samba team strongly recommends to use "ntlm_auth" helper binary and "winbind" daemon (both from the "samba-common" package), which provides a stable way to do "NTLM" and "GSS-SPNEGO" auth types against a windows domain. This way Squid and recently Apache do NTLM now. Hence I think about adding of "ntlm_auth + winbind" support for Dovecot. Before I shall begin it, I would like to ask: - Is this issue a corner case or not? - Are there some another solution for the support of "SPA against domain" by Linux MTA/pop/imap servers in Fedora? - Perhaps someone has already made something of it? At least partially? - Is the solution proposed the best way to solve the issue (for corporate systems etc.)? Regards, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From jspaleta at gmail.com Fri Jun 29 18:32:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 29 Jun 2007 10:32:31 -0800 Subject: Fedora 8's FUDCon In-Reply-To: <46839A9C.1020308@hhs.nl> References: <007601c7b92b$dd1212f0$c701a8c0@yellobow> <200706272237.52870.jkeating@redhat.com> <46837B23.40301@hhs.nl> <468386F7.7030102@leemhuis.info> <46839A9C.1020308@hhs.nl> Message-ID: <604aa7910706291132g2ed8ea7elc7a211fc65f6012e@mail.gmail.com> On 6/28/07, Hans de Goede wrote: > I didn't know about those pages, it seems that our efforts pretty much > overlaps, I do believe however that filing this under laptop is (very) wrong, > as many normal keyboards also have extra keys. Then there are people like me... who use a laptop as the primary device with docks.... so i have at minimum 2 different keyboards with different special keys... so i can't just do a simple keybinding for special operations...because each keyboard uses different extra keycodes for buttons meant to do the same thing. I could definitely use some sort of abstraction layer so that I can setup up the keybindings for each keyboard once in a profile and then switch to that profile (even manually with a simple pref if the profile can't be autodetected) to avoid having to re-config keybindings indivdually by hand. -jef"or i could just continue not using those keys as a living memorial to late 20th century technology...maybe we could even get some funding to create an accurate late 1980's technology town..like colonial Williamsburg...but smaller scale..like an office building cubicle farm with a viewing window."spaleta From pertusus at free.fr Fri Jun 29 19:50:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 29 Jun 2007 21:50:51 +0200 Subject: rpms/samba/devel samba.spec,1.124,1.125 In-Reply-To: <200706291942.l5TJgM08023311@cvs-int.fedora.redhat.com> References: <200706291942.l5TJgM08023311@cvs-int.fedora.redhat.com> Message-ID: <20070629195050.GB2979@free.fr> On Fri, Jun 29, 2007 at 03:42:22PM -0400, Simo Sorce wrote: > + eval testparm -s 2>/dev/null |grep "lock dir" >/dev/null > + if [ $? = 0 ]; then > + echo "Warning: lock dir explicitly set. Not moving tdb files to new default location" Unless I am wrong, echoing anything during updates is not right... -- Pat From ssorce at redhat.com Fri Jun 29 20:04:23 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 29 Jun 2007 16:04:23 -0400 Subject: rpms/samba/devel samba.spec,1.124,1.125 In-Reply-To: <20070629195050.GB2979@free.fr> References: <200706291942.l5TJgM08023311@cvs-int.fedora.redhat.com> <20070629195050.GB2979@free.fr> Message-ID: <1183147463.25772.39.camel@localhost.localdomain> On Fri, 2007-06-29 at 21:50 +0200, Patrice Dumas wrote: > On Fri, Jun 29, 2007 at 03:42:22PM -0400, Simo Sorce wrote: > > + eval testparm -s 2>/dev/null |grep "lock dir" >/dev/null > > + if [ $? = 0 ]; then > > + echo "Warning: lock dir explicitly set. Not moving tdb files to new default location" > > Unless I am wrong, echoing anything during updates is not right... I've seen warning for when files are dropped in as .rpmnew or saved as .rpmsave This is a very similar case, so I think it should be ok, but if not I'd like to know (and know why rpmnew/rpmsave are instead ok) Simo. From benny+usenet at amorsen.dk Fri Jun 29 20:12:34 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 29 Jun 2007 22:12:34 +0200 Subject: kernel support for VE's (OpenVZ / Linux-vServer) References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> <468534B9.1030609@verizon.net> <200706291234.59009.jkeating@redhat.com> <1183135798.30145.41.camel@weaponx.rchland.ibm.com> Message-ID: >>>>> "JB" == Josh Boyer writes: JB> Right. It would be better to ask the OpenVZ and Linux-vServer JB> projects when they are going to push for upstream inclusion. Even JB> once that has started, it can take a few months to get accepted, JB> depending on how things go. OpenVZ is pushing the network bits already. The reception on the linux-networking list has not been overly enthusiastic. /Benny From a.badger at gmail.com Fri Jun 29 20:16:28 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 Jun 2007 13:16:28 -0700 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <1183128957.30145.30.camel@weaponx.rchland.ibm.com> References: <200706281946.25821.jkeating@redhat.com> <200706291009.55937.jam@zoidtechnologies.com> <200706291053.43602.jam@zoidtechnologies.com> <1183128957.30145.30.camel@weaponx.rchland.ibm.com> Message-ID: <1183148188.21296.75.camel@localhost.localdomain> On Fri, 2007-06-29 at 09:55 -0500, Josh Boyer wrote: > On Fri, 2007-06-29 at 10:53 -0400, Jeff MacDonald wrote: > > > > good point.. local time should be the time local to the physical location of > > the equipment in question. > > And what good does that do? I think just UTC should be fine. > It can have some use for the relatively few admins who were not present for the event but are subsequently working on the box to further develop what happened. Log files are generally written out in localtime. For the rest of the population receiving the email... not so much. Note: It might be a better idea to turn "localtime" into UTC on the equipment instead.... -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ajackson at redhat.com Fri Jun 29 20:52:22 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 29 Jun 2007 16:52:22 -0400 Subject: rpms/samba/devel samba.spec,1.124,1.125 In-Reply-To: <1183147463.25772.39.camel@localhost.localdomain> References: <200706291942.l5TJgM08023311@cvs-int.fedora.redhat.com> <20070629195050.GB2979@free.fr> <1183147463.25772.39.camel@localhost.localdomain> Message-ID: <1183150342.10197.41.camel@localhost.localdomain> On Fri, 2007-06-29 at 16:04 -0400, Simo Sorce wrote: > On Fri, 2007-06-29 at 21:50 +0200, Patrice Dumas wrote: > > On Fri, Jun 29, 2007 at 03:42:22PM -0400, Simo Sorce wrote: > > > + eval testparm -s 2>/dev/null |grep "lock dir" >/dev/null > > > + if [ $? = 0 ]; then > > > + echo "Warning: lock dir explicitly set. Not moving tdb files to new default location" > > > > Unless I am wrong, echoing anything during updates is not right... > > I've seen warning for when files are dropped in as .rpmnew or saved > as .rpmsave > This is a very similar case, so I think it should be ok, but if not I'd > like to know (and know why rpmnew/rpmsave are instead ok) That warning is issued from RPM itself. Which means there's probably a hook to do something with that information from a GUI tool. Messages from the scriptlet itself just get ignored, since the vast majority of packages do not have eyes looking at their stdout. - ajax From bruno at wolff.to Fri Jun 29 15:32:38 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 29 Jun 2007 10:32:38 -0500 Subject: Red Hat CEO Says He Talked Patents with Microsoft (Reuters) In-Reply-To: <46847D09.4060801@fedoraproject.org> References: <46847D09.4060801@fedoraproject.org> Message-ID: <20070629153238.GC4430@wolff.to> On Fri, Jun 29, 2007 at 09:01:21 +0530, Rahul Sundaram wrote: > Gregory Maxwell wrote: > >http://www.eweek.com/article2/0,1759,2151908,00.asp > > > >In an interview with Reuters, Szulik declined to say whether his > >company is now in negotiations with Microsoft over signing such a > >patent agreement. > > > >"I can't answer the question," he said. > > I don't see how this is on topic in this. At any rate Red Hat has > already clarified it's position on both the interoperability and patent > fronts several times now. The article seemed to be pretty slanted as well. There was no reason given why not making a patent deal with Microsoft should cause people to jump to Novell. In my biased experience the comments I have seen have indicated that people were more likely to drop SUSE for RHEL because of this rather than the other way around. From buildsys at fedoraproject.org Fri Jun 29 22:26:16 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 29 Jun 2007 18:26:16 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-06-29 Message-ID: <20070629222616.CEDF5152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 14 babel-0.8-3.fc6 cvs2svn-1.5.1-2.fc6 emacs-vm-8.0.1.465-1.fc6 fslint-2.22-1.fc6 NEW gerbv-1.0.2-2.fc6 : Gerber file viewer from the gEDA toolkit gutenprint-5.0.1-1.fc6 HelixPlayer-1.0.7-6.fc6 NEW innotop-1.4.2-4.fc6 : A MySQL and InnoDB monitor program nagios-2.9-1.fc6 pitivi-0.10.3-2.fc6 python-feedparser-4.1-3.fc6 NEW seaview-0-0.1.20070615.fc6 : Graphical multiple sequence alignment editor sysprof-kmod-1.0.8-1.2.6.20_1.2962.fc6 zabbix-1.4-3.fc6 Packages built and released for Fedora Extras 5: 5 clamav-0.88.7-3.fc5 fslint-2.22-1.fc5 sysprof-kmod-1.0.8-1.2.6.20_1.2320.fc5 xfce4-session-4.2.4-1.fc5 xffm-4.2.4-1.fc5 Changes in Fedora Extras 6: babel-0.8-3.fc6 --------------- * Fri Jun 29 2007 Jeffrey C. Ollie - 0.8-3 - Replace patch with one that actually applies. * Fri Jun 29 2007 Jeffrey C. Ollie - 0.8-2 - Apply upstream patch to rename command line script to "pybabel" - BZ#246208 cvs2svn-1.5.1-2.fc6 ------------------- * Thu Jun 28 2007 Konstantin Ryabitsev - 1.5.1-2 - Include cvs2svn-example.options in docs (#241533) emacs-vm-8.0.1.465-1.fc6 ------------------------ * Thu Jun 28 2007 Jonathan G. Underwood - 8.0.1.465-1 - Update to bugfix release 8.0.1 (fixes BZ #245780) fslint-2.22-1.fc6 ----------------- * Thu Jun 28 2007 P?draig Brady

- 2.22-1 - Update to 2.22 gerbv-1.0.2-2.fc6 ----------------- * Thu Jun 28 2007 Chitlesh Goorah - 1.0.2-2 - remove gdk-pixbuf-devel as BR gutenprint-5.0.1-1.fc6 ---------------------- * Fri Jun 29 2007 Tim Waugh 5.0.1-1 - Don't add extra compiler flags. - Package the CUPS driver in sbindir and put a symlink in the CUPS ServerBin directory to work around bug #231015. - Disable libgutenprintui (GTK+ 1.2 library). Build requires gtk2-devel, not gtk+-devel. - No longer need PPDs sub-packages: CUPS driver is included in the cups sub-package. - Don't change SELinux file context of installed PPDs (bug #246067). - 5.0.1. HelixPlayer-1.0.7-6.fc6 ----------------------- * Thu Jun 28 2007 Aurelien Bompard 1:1.0.7-6 - fix bug 245838 (CVE-2007-3410) innotop-1.4.2-4.fc6 ------------------- * Fri Jun 29 2007 Michael Fleming 1.4.2-4 - First import into Fedora * Sun Jun 17 2007 Michael Fleming 1.4.2-3.mf - Fix BuildRequires. - Explict Requires for DBD::mysql and Term::Readkey as RPM is not smart enough to pick them up on it's own. nagios-2.9-1.fc6 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 pitivi-0.10.3-2.fc6 ------------------- * Wed Jun 27 2007 Jeffrey C. Ollie - 0.10.3-2 - Add versioned requires for gnonlin. (BZ#245981) python-feedparser-4.1-3.fc6 --------------------------- * Thu Jun 28 2007 Konstantin Ryabitsev - 4.1-3 - Ghostbusting (#205413). - Remove manual python-abi Requires. - Appease rpmlint. * Sat Dec 23 2006 Jason L Tibbitts III - 4.1-2 - Rebuild for new Python. seaview-0-0.1.20070615.fc6 -------------------------- * Thu Jun 28 2007 Christian Iseli 0-0.1.20070615 - New upstream tarball. - Add desktop file and icon. * Wed Jun 13 2007 Christian Iseli 0-0.1.20070515 - Actually follow pre-release strategy for version/release... - New upstream "version". sysprof-kmod-1.0.8-1.2.6.20_1.2962.fc6 -------------------------------------- * Tue Jan 02 2007 Gianluca Sforna - rebuild for kernel 2.6.18-1.2869 zabbix-1.4-3.fc6 ---------------- * Fri Jun 29 2007 Jarod Wilson 1.4-3 - Install correct sql init files (#244991) - Add Requires: php-bcmath to zabbix-web (#245767) Changes in Fedora Extras 5: clamav-0.88.7-3.fc5 ------------------- * Thu May 31 2007 Enrico Scholz - 0.88.7-3 - [SECURITY] fixed CVE-2007-2650 (OLE2 list loop) and Clamav bug #515 (broken OOM handling) fslint-2.22-1.fc5 ----------------- * Thu Jun 28 2007 P?draig Brady

- 2.22-1 - Update to 2.22 sysprof-kmod-1.0.8-1.2.6.20_1.2320.fc5 -------------------------------------- * Sat Dec 23 2006 Gianluca Sforna 1.0.8-1 - version update to 1.0.8 - rebuild for kernel 2.6.18-1.2257 xfce4-session-4.2.4-1.fc5 ------------------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Disaple rpaths - disable-static instead of removing .a files xffm-4.2.4-1.fc5 ---------------- * Wed Jun 20 2007 Christoph Wickert - 4.2.4-1 - Update to 4.2.4 - Update rpath patch - Split out devel package - Require xfce-mcs-manager - Run ldconfig and gtk-update-icon-cache in %post and %postun For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From hawat.thufir at gmail.com Fri Jun 29 22:26:46 2007 From: hawat.thufir at gmail.com (Thufir) Date: Fri, 29 Jun 2007 22:26:46 +0000 (UTC) Subject: printer works in FC3 Message-ID: Just thought I'd ask in a different way. My Samsung ML-2510 driver installed fine in FC3, and works fine from FC3. Because it's a proprietary driver, there's no way to really say why it won't work in Fedora 7 and a different driver must be used? It's basically "refer to samsung" for using their printer driver? else use splix, for example? Changing distro's wouldn't resolve whatever "broke" the samsung printer, I'm assuming, unless similarly old versions are run. -Thufir From hughsient at gmail.com Fri Jun 29 22:29:05 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 29 Jun 2007 23:29:05 +0100 Subject: printer works in FC3 In-Reply-To: References: Message-ID: <1183156145.30954.0.camel@work> On Fri, 2007-06-29 at 22:26 +0000, Thufir wrote: > Just thought I'd ask in a different way. My Samsung ML-2510 driver installed > fine in FC3, and works fine from FC3. Because it's a proprietary driver, > there's no way to really say why it won't work in Fedora 7 and a different > driver must be used? It's basically "refer to samsung" for using their printer > driver? else use splix, for example? Changing distro's wouldn't resolve > whatever "broke" the samsung printer, I'm assuming, unless similarly old > versions are run. Is this a question or a statement? Richard. From tcallawa at redhat.com Fri Jun 29 22:39:39 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 29 Jun 2007 17:39:39 -0500 Subject: gl debugging help requested In-Reply-To: <46850D24.1060608@hhs.nl> References: <1183067909.4044.88.camel@localhost.localdomain> <4684BF56.2040005@hhs.nl> <1183124061.3384.5.camel@localhost.localdomain> <46850D24.1060608@hhs.nl> Message-ID: <1183156779.3908.1.camel@localhost.localdomain> On Fri, 2007-06-29 at 15:46 +0200, Hans de Goede wrote: > Not obviously no, let me try to rephrase my earlier hint. > > No (none whatsover) libGL functions (including glGenTextures) may be called > before an OpenGL context has been created, iow before a window suitable for > openGL rendering has been created. So if this apps tries to loads the textures > above before creating its window, then that will crash with Mesa. > > The trick is to look at the sequence in which window creation (for example SDL > _setVideoMode() with OPENGL flag, and the glGenTextures get called. 99% of all > crashes which in the BT point to glGenTextures() are because of glGenTextures > getting called before the window + openGL context is created. > > I hope that helps, if not please repost the URL to the srpm and I'll take a > look as time permits. That does help! I figured out what was going wrong and now it works on x86_64. Thanks! ~spot From thomas at apestaart.org Fri Jun 29 23:45:04 2007 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 30 Jun 2007 01:45:04 +0200 Subject: python-twisted needs a newer version In-Reply-To: <57127b5f0706171910g3b9715cdp57b3f3588c592f31@mail.gmail.com> References: <1181472701.8369.3.camel@localhost.localdomain> <57127b5f0706100511i49c640f5oeed5b7690cea6d11@mail.gmail.com> <1182097544.28924.8.camel@level.fluendo.lan> <57127b5f0706171910g3b9715cdp57b3f3588c592f31@mail.gmail.com> Message-ID: <1183160704.19930.0.camel@ana.amantes> On Mon, 2007-06-18 at 07:40 +0530, Deependra Shekhawat wrote: > Where can I get a .spec file to do the compilation stuff. In CVS, as with any extras package. Thomas -- If that's the way it is then that's the way it is -- Flumotion - the only way to stream! http://www.flumotion.net/ From sundaram at fedoraproject.org Sat Jun 30 01:01:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 30 Jun 2007 06:31:17 +0530 Subject: FC7 and firewire In-Reply-To: <1183067247.2735.26.camel@localhost.nox> References: <1183067247.2735.26.camel@localhost.nox> Message-ID: <4685AB5D.6020202@fedoraproject.org> Mladen Kuntner wrote: > I have problems with firewire since FC7 test1. > Tried to get help or help debugging on this list two times > > http://www.redhat.com/archives/fedora-devel-list/2007-February/msg00540.html > http://www.redhat.com/archives/rhl-devel-list/2007-April/msg01377.html > > but with no answers. > > This is third time. > You probably need to file bug reports. That would be better to keep track of any (potential) issues. Thanks. Rahul From katzj at redhat.com Sat Jun 30 03:12:11 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 29 Jun 2007 23:12:11 -0400 Subject: rpms/samba/devel samba.spec,1.124,1.125 In-Reply-To: <1183150342.10197.41.camel@localhost.localdomain> References: <200706291942.l5TJgM08023311@cvs-int.fedora.redhat.com> <20070629195050.GB2979@free.fr> <1183147463.25772.39.camel@localhost.localdomain> <1183150342.10197.41.camel@localhost.localdomain> Message-ID: <1183173131.10801.2.camel@aglarond.local> On Fri, 2007-06-29 at 16:52 -0400, Adam Jackson wrote: > On Fri, 2007-06-29 at 16:04 -0400, Simo Sorce wrote: > > On Fri, 2007-06-29 at 21:50 +0200, Patrice Dumas wrote: > > > On Fri, Jun 29, 2007 at 03:42:22PM -0400, Simo Sorce wrote: > > > > + eval testparm -s 2>/dev/null |grep "lock dir" >/dev/null > > > > + if [ $? = 0 ]; then > > > > + echo "Warning: lock dir explicitly set. Not moving tdb files to new default location" > > > > > > Unless I am wrong, echoing anything during updates is not right... > > > > I've seen warning for when files are dropped in as .rpmnew or saved > > as .rpmsave > > This is a very similar case, so I think it should be ok, but if not I'd > > like to know (and know why rpmnew/rpmsave are instead ok) > > That warning is issued from RPM itself. Which means there's probably a > hook to do something with that information from a GUI tool. Actually, there's not. So this case is no better or worse Jeremy From tgl at redhat.com Sat Jun 30 04:59:34 2007 From: tgl at redhat.com (Tom Lane) Date: Sat, 30 Jun 2007 00:59:34 -0400 Subject: Red Hat CEO Says He Talked Patents with Microsoft (Reuters) In-Reply-To: <20070629153238.GC4430@wolff.to> References: <46847D09.4060801@fedoraproject.org> <20070629153238.GC4430@wolff.to> Message-ID: <13272.1183179574@sss.pgh.pa.us> Bruno Wolff III writes: >>>> In an interview with Reuters, Szulik declined to say whether his >>>> company is now in negotiations with Microsoft over signing such a >>>> patent agreement. >>>> >>>> "I can't answer the question," he said. >> >> I don't see how this is on topic in this. At any rate Red Hat has >> already clarified it's position on both the interoperability and patent >> fronts several times now. > The article seemed to be pretty slanted as well. What I noticed was that it did not give the exact wording of the question that Matthew declined to answer. I've been around Red Hat for five years now, and as far as I've seen Matthew Szulik is as straight a shooter as you'll find in a CEO. If he refused to answer a question, I suppose it's because there was some aspect of it that he wished he could clear with Red Hat's legal department; and there was nothing in that article to suggest what it was that raised his hackles. As for Red Hat making a separate peace with Microsoft, the OP clearly has no clue how ridiculous an idea that is. Matthew would never do it, and the entire engineering department would resign tomorrow if he did. regards, tom lane From hawat.thufir at gmail.com Sat Jun 30 05:32:02 2007 From: hawat.thufir at gmail.com (Thufir) Date: Sat, 30 Jun 2007 05:32:02 +0000 (UTC) Subject: printer works in FC3 References: <1183156145.30954.0.camel@work> Message-ID: On Fri, 29 Jun 2007 23:29:05 +0100, Richard Hughes wrote: [...] > Is this a question or a statement? > > Richard. Yes. More of gripe, assuming I have the facts correct. I found it exhausting just getting FC3 installed to confirm that the printer even works, and needed to vent some. I wish I understood why the printer behaves this way, it's very opaque. In retrospect, I wish I hadn't posted the gripe. -Thufir From vnpenguin at vnoss.org Sat Jun 30 06:34:01 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sat, 30 Jun 2007 08:34:01 +0200 Subject: rpm-4.4.2-46.fc7 package : DOC in LaTeX src ? Message-ID: In /usr/share/doc/rpm-4.4.2 of rpm-4.4.2-46.fc7, almost doc here are in LaTeX/TeX source, it's normal ? Please ship ONLY plain text here, No LaTeX/TeX src, no PDF, no HTML please !!! Thanks -- http://vnoss.org From dgboles at gmail.com Sat Jun 30 07:06:34 2007 From: dgboles at gmail.com (David Boles) Date: Sat, 30 Jun 2007 00:06:34 -0700 Subject: printer works in FC3 In-Reply-To: References: <1183156145.30954.0.camel@work> Message-ID: <468600FA.6060807@gmail.com> on 6/29/2007 10:32 PM, Thufir wrote: > On Fri, 29 Jun 2007 23:29:05 +0100, Richard Hughes wrote: > > [...] >> Is this a question or a statement? >> >> Richard. > > Yes. > > > > More of gripe, assuming I have the facts correct. I found it exhausting > just getting FC3 installed to confirm that the printer even works, and > needed to vent some. I wish I understood why the printer behaves this > way, it's very opaque. In retrospect, I wish I hadn't posted the gripe. > > > -Thufir > This list is not where you should be reporting your problem. I would recommend that you should post a very clear, concise Bugzilla report. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mladen.kuntner at triera.net Sat Jun 30 07:26:35 2007 From: mladen.kuntner at triera.net (Mladen Kuntner) Date: Sat, 30 Jun 2007 09:26:35 +0200 Subject: FC7 and firewire In-Reply-To: <4685AB5D.6020202@fedoraproject.org> References: <1183067247.2735.26.camel@localhost.nox> <4685AB5D.6020202@fedoraproject.org> Message-ID: <1183188395.7657.4.camel@localhost.nox> On Sat, 2007-06-30 at 06:31 +0530, Rahul Sundaram wrote: > Mladen Kuntner wrote: > > I have problems with firewire since FC7 test1. > > Tried to get help or help debugging on this list two times > > > > http://www.redhat.com/archives/fedora-devel-list/2007-February/msg00540.html > > http://www.redhat.com/archives/rhl-devel-list/2007-April/msg01377.html > > > > but with no answers. > > > > This is third time. > > > > You probably need to file bug reports. That would be better to keep > track of any (potential) issues. Thanks. > > Rahul > Sorry forget to mention: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243081 my intention really was to grab some of Kristian H?gsberg - s attention. Maybe it is not right that is filled under dvgrab, but i did not know then that libraw1394 is supposed to hide all kernel changes to user space programs. Thanks Mladen From drago01 at gmail.com Sat Jun 30 07:30:49 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 30 Jun 2007 09:30:49 +0200 Subject: FC7 and firewire In-Reply-To: <1183188395.7657.4.camel@localhost.nox> References: <1183067247.2735.26.camel@localhost.nox> <4685AB5D.6020202@fedoraproject.org> <1183188395.7657.4.camel@localhost.nox> Message-ID: <468606A9.80303@gmail.com> Mladen Kuntner wrote: > On Sat, 2007-06-30 at 06:31 +0530, Rahul Sundaram wrote: > >> Mladen Kuntner wrote: >> >>> I have problems with firewire since FC7 test1. >>> Tried to get help or help debugging on this list two times >>> >>> http://www.redhat.com/archives/fedora-devel-list/2007-February/msg00540.html >>> http://www.redhat.com/archives/rhl-devel-list/2007-April/msg01377.html >>> >>> but with no answers. >>> >>> This is third time. >>> >>> >> You probably need to file bug reports. That would be better to keep >> track of any (potential) issues. Thanks. >> >> Rahul >> >> > > Sorry forget to mention: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243081 > > my intention really was to grab some of Kristian H?gsberg - s attention. > > cc him on your bugreport. From dwmw2 at infradead.org Sat Jun 30 07:49:11 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 30 Jun 2007 08:49:11 +0100 Subject: printer works in FC3 In-Reply-To: References: Message-ID: <1183189751.1170.380.camel@pmac.infradead.org> On Fri, 2007-06-29 at 22:26 +0000, Thufir wrote: > Just thought I'd ask in a different way. My Samsung ML-2510 driver installed > fine in FC3, and works fine from FC3. Because it's a proprietary driver, > there's no way to really say why it won't work in Fedora 7 and a different > driver must be used? That's not entirely true. You _could_ attempt to debug it and work how/why it behaves differently on F7. But you've little chance of actually _fixing_ it. You might get away with running it in a chroot with the bits of FC3 you need, perhaps. If you use non-free software, you should _expect_ it to break. Have you tried the GDI driver? http://openprinting.org/show_driver.cgi?driver=gdi&fromprinter=Samsung-ML-2510 -- dwmw2 From jonathan.underwood at gmail.com Sat Jun 30 07:54:53 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 30 Jun 2007 08:54:53 +0100 Subject: rpm-4.4.2-46.fc7 package : DOC in LaTeX src ? In-Reply-To: References: Message-ID: <645d17210706300054s381b6ee5q43250bc0898f2fb1@mail.gmail.com> On 30/06/07, Vnpenguin wrote: > In /usr/share/doc/rpm-4.4.2 of rpm-4.4.2-46.fc7, almost doc here are > in LaTeX/TeX source, it's normal ? > > Please ship ONLY plain text here, No LaTeX/TeX src, no PDF, no HTML please !!! http://bugzilla.redhat.com From vnpenguin at vnoss.org Sat Jun 30 08:01:49 2007 From: vnpenguin at vnoss.org (Vnpenguin) Date: Sat, 30 Jun 2007 10:01:49 +0200 Subject: rpm-4.4.2-46.fc7 package : DOC in LaTeX src ? In-Reply-To: <645d17210706300054s381b6ee5q43250bc0898f2fb1@mail.gmail.com> References: <645d17210706300054s381b6ee5q43250bc0898f2fb1@mail.gmail.com> Message-ID: On 6/30/07, Jonathan Underwood wrote: > On 30/06/07, Vnpenguin wrote: > > In /usr/share/doc/rpm-4.4.2 of rpm-4.4.2-46.fc7, almost doc here are > > in LaTeX/TeX source, it's normal ? > > > > Please ship ONLY plain text here, No LaTeX/TeX src, no PDF, no HTML please !!! > > http://bugzilla.redhat.com > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246318 -- http://vnoss.org From buildsys at redhat.com Sat Jun 30 09:55:10 2007 From: buildsys at redhat.com (Build System) Date: Sat, 30 Jun 2007 05:55:10 -0400 Subject: rawhide report: 20070630 changes Message-ID: <200706300955.l5U9tAsR012343@porkchop.devel.redhat.com> New package ecryptfs-utils The eCryptfs mount helper and support libraries New package innotop A MySQL and InnoDB monitor program New package seaview Graphical multiple sequence alignment editor Updated Packages: babel-0.8-3.fc8 --------------- bigboard-0.4.8-2.fc8 -------------------- * Fri Jun 29 2007 Colin Walters - 0.4.8-2 - update - disable schemas install * Thu Jun 28 2007 Colin Walters - 0.4.7-1 - update - add gconf goo - require latest mugshot cpanspec-1.71-1.fc8 ------------------- * Fri Jun 29 2007 Steven Pritchard 1.71-1 - Update to 1.71. - Remove "Extras" from the description. - Use the __perl macro instead of calling perl directly. cups-1:1.2.11-3.fc8 ------------------- * Fri Jun 29 2007 Tim Waugh 1:1.2.11-3 - Applied patch to fix group handling in PPDs (bug #186231, STR #2408). deskbar-applet-2.19.3-3.fc8 --------------------------- * Fri Jun 29 2007 Luke Macken - 2.19.3-3 - Add deskbar-applet-gdmclient.patch to fix a nonfatal traceback on startup. (Upstream bug #452256) ekg-1.7-1.fc8 ------------- * Fri Jun 29 2007 Dominik Mierzejewski 1.7-1 - 1.7 final - enable voip support (gsm is in Fedora now) - remove redundant BR: autoconf - support giflib - fixes CVE-2007-166{3,4,5} (bug #246034) evolution-sharp-0.13-2.fc8 -------------------------- * Fri Jun 29 2007 Matthew Barnes - 0.13.1-2.fc8 - Add alpha to ExclusiveArch (RH bug #246204). * Tue Jun 19 2007 Matthew Barnes - 0.13-1-1.fc8 - Update to 0.13 * Fri May 18 2007 Matthew Barnes - 0.12.4-1.fc8 - Update to 0.12.4 freetype-2.3.4-4.fc8 -------------------- * Fri Jun 29 2007 Adam Jackson 2.3.4-4 - Fix builds/unix/libtool to not emit rpath into binaries. (#225770) glib2-2.13.6-1.fc8 ------------------ * Fri Jun 29 2007 Matthias Clasen - 2.13.6-1 - Update to 2.13.6 - Drop an ancient Conflict gpm-1.20.1-85.fc8 ----------------- * Fri Jun 29 2007 Tomas Janousek - 1.20.1-85 - applied patch for #246219, fixing segfault with vsyslog on x86_64 gv-3.6.3-1.fc8 -------------- * Fri Jun 29 2007 Orion Poplawski 3.6.3-1 - Update to 3.6.3 hippo-canvas-0.2.20-1.fc8 ------------------------- * Fri Jun 29 2007 Colin Walters - 0.2.20-1 - 0.2.20 - add doc - match new pkgconfig name - remove upstreamed patch hplip-2.7.6-1.fc8 ----------------- * Fri Jun 29 2007 Tim Waugh 2.7.6-1 - 2.7.6. hunspell-1.1.6-1.fc8 -------------------- * Fri Jun 29 2007 Caolan McNamara - 1.1.6-1 - latest version - drop integrated hunspell-1.1.4-defaultdictfromlang.patch - drop integrated hunspell-1.1.5-badheader.patch - drop integrated hunspell-1.1.5.encoding.patch hunspell-pl-0.20070629-1.fc8 ---------------------------- kernel-2.6.21-1.3242.fc8 ------------------------ * Fri Jun 29 2007 Dave Jones - 2.6.22-rc6-git3 libgnomedb-1:3.0.0-2.fc8 ------------------------ * Fri Jun 29 2007 Hans de Goede 1:3.0.0-2 - Rebuild for new gtksourceview (bz 246202) libtomoe-gtk-0.6.0-1.fc8 ------------------------ * Fri Jun 29 2007 Jens Petersen - 0.6.0-1 - update to 0.6.0 - add %pkgname for new upstream package name tomoe-gtk mugshot-1.1.46-1.fc8 -------------------- * Thu Jun 28 2007 Colin Walters - 1.1.46-1 - 1.1.46 nagios-2.9-1.fc8 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 openldap-2.3.34-4.fc8 --------------------- * Mon Jun 25 2007 Jan Safranek 2.3.34-4.fc8 - Fix initscript return codes (#242667) - Provide overlays (as modules; #246036, #245896) - Add available modules to config file perl-Test-MockObject-1.08-1.fc8 ------------------------------- * Fri Jun 29 2007 Jose Pedro Oliveira - 1.08-1 - Update to 1.08. perl-Text-WikiFormat-0.79-1.fc8 ------------------------------- * Fri Jun 29 2007 Jose Pedro Oliveira - 0.79-1 - Update to 0.79. python-dateutil-1.2-1.fc8 ------------------------- * Thu Jun 28 2007 Orion Poplawski 1.2-1 - Update to 1.2 python-feedparser-4.1-3.fc8 --------------------------- * Thu Jun 28 2007 Konstantin Ryabitsev - 4.1-3 - Ghostbusting (#205413). - Remove manual python-abi Requires. - Appease rpmlint. revisor-2.0.3.12-5.fc8 ---------------------- * Sun Jun 24 2007 Jeroen van Meeuwen 2.0.3.12-5 - Rebuild with ExcludeArch because %if(n)arch magic is not going to work rtorrent-0.7.4-2.fc8 -------------------- * Thu Jun 28 2007 Chris Chabot - 0.7.4-2 - Fixed BR * Thu Jun 28 2007 Chris Chabot - 0.7.4-1 - New upstream release samba-0:3.0.25b-3.fc8 --------------------- * Fri Jun 29 2007 Simo Sorce 3.0.25b-3.fc8 - handle cases defined in #243766 sylpheed-2.4.3-1 ---------------- * Fri Jun 29 2007 Michael Schwendt - 2.4.3-1 - Update to 2.4.3. tomoe-0.6.0-1.fc8 ----------------- * Fri Jun 29 2007 Jens Petersen - 0.6.0-1 - update to 0.6.0 - tomoe-modules-noversion.patch no longer needed - buildrequire perl-XML-Parser for intltool and python vsftpd-2.0.5-17.fc8 ------------------- * Fri Jun 29 2007 Maros Barabas - 2.0.5-17 - Fix pasv dot after pasv response (RFC 959 page 40) wvdial-1.56-1.fc8 ----------------- * Thu Jun 28 2007 Harald Hoyer - 1.56-1 - version 1.56 * Wed Apr 18 2007 Harald Hoyer - 1.54.0-6 - specfile review xterm-227-1.fc8 --------------- * Fri Jun 29 2007 Miroslav Lichvar 227-1 - update to 227 zabbix-1.4-3.fc8 ---------------- * Fri Jun 29 2007 Jarod Wilson 1.4-3 - Install correct sql init files (#244991) - Add Requires: php-bcmath to zabbix-web (#245767) zisofs-tools-1.0.8-1.fc8 ------------------------ * Fri Jun 29 2007 Harald Hoyer - 1.0.8-1.fc8 - version 1.0.8 * Fri Mar 23 2007 Harald Hoyer - 1.0.7-1.fc8 - version 1.0.7 * Fri Mar 23 2007 Harald Hoyer - 1.0.6-4.fc8 - specfile cleanup Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 revisor - 2.0.3.12-5.fc8.noarch requires livecd-tools ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display revisor - 2.0.3.12-5.fc8.noarch requires livecd-tools rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From nigel.metheringham at dev.intechnology.co.uk Sat Jun 30 10:22:02 2007 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Sat, 30 Jun 2007 11:22:02 +0100 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> Message-ID: <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> On 6/21/07, Alan Cox wrote: > On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote: >> I'm thinking about getting a new box anyway (it's an old >> not-quite-C3 with some odd Biblean-sounding codename, chugging >> along at 800MHz). With less than 40 users, it's just not worth >> it. I'm surprised though, I thought VIA was more popular than >> that. > It is a good deal more popular than that (although the 686 > compatible but not gcc 686 compatible ones are the older ones > generally) > Unless Dave can publish data sets and a methodology for his count > (and given even the big marketing companies can't do it I want to > see this) we should assume he made up a number to justify killing it > cos he finds it a hassle to maintain. Having watched from the sidelines I updated my VIA mini-ITX system yesterday. Its an original 800 MHz model. Fedora installs for an i586 on it - 586 kernel etc. However, at least post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at http://smolt.fedoraproject.org/show?UUID=99ad2cb0-5524-4d7e- b145-1c502ba58e62 For those that prefer raw data the /proc/cpuinfo is:- processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 800.065 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow up bogomips : 1601.17 clflush size : 32 However it will not boot a current i686 kernel - resets immediately. There are 264 (0.4%) CentaurHauls CPUs in Smolt right now (and obviously upgraders like me would not appear there unless we make the effort). Its not much of a proportion, but there are more users than the i586 figures suggest. Cheers Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From dcbw at redhat.com Sat Jun 30 11:54:09 2007 From: dcbw at redhat.com (Dan Williams) Date: Sat, 30 Jun 2007 07:54:09 -0400 Subject: kernel support for VE's (OpenVZ / Linux-vServer) In-Reply-To: <200706291234.59009.jkeating@redhat.com> References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> <468534B9.1030609@verizon.net> <200706291234.59009.jkeating@redhat.com> Message-ID: <1183204449.29568.12.camel@xo-13-A4-25.localdomain> On Fri, 2007-06-29 at 12:34 -0400, Jesse Keating wrote: > On Friday 29 June 2007 12:35:05 Gerry Reno wrote: > > Do you know when they will make it in the upstream kernel? > > Magic 8 ball says.... > > Seriously some of these may never make it in. It all depends on the > motivations of the teams producing these things. The vserver guys have tried in the past to get it in, but they got some pushback on some things, and they now seem completely uninterested taking the time needed to clean their stuff up and actually get it into the kernel. I wouldn't hold out much hope unless something changes dramatically. Dan From trever.adams at gmail.com Sat Jun 30 12:25:45 2007 From: trever.adams at gmail.com (Trever L. Adams) Date: Sat, 30 Jun 2007 06:25:45 -0600 Subject: Mail accounts in heterogeneous environments In-Reply-To: <46853CDB.60206@odu.neva.ru> References: <46853CDB.60206@odu.neva.ru> Message-ID: <1183206337.4870.0.camel@aragorn> Dmitry Butskoy wrote: > - Are there some another solution for the support of "SPA against > domain" by Linux MTA/pop/imap servers in Fedora? > > Regards, > Dmitry Butskoy Thank you for asking all of these questions. I am looking at doing a lot of these and have not yet asked these. It seems a lot of software (server) works with much of this, however, I would like to see (hopefully in F8) the ability to do SPA like stuff on everything (client and servers). Particularly, I would like to see the ability to have a REAL cifs implementation. Right now, everything is done as the one who mounted (or --user) the fs. Can we get an AD version of this so that permissions get used and mapped as much as possible to Linux fs permissions and so that the user who requests the operation is the user used, not root, not --user, etc.? I will mention more of these wishes later when I can be more specific and succinct. Trever -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Sat Jun 30 12:50:40 2007 From: greno at verizon.net (Gerry Reno) Date: Sat, 30 Jun 2007 08:50:40 -0400 Subject: kernel support for VE's (OpenVZ / Linux-vServer) In-Reply-To: <1183204449.29568.12.camel@xo-13-A4-25.localdomain> References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> <468534B9.1030609@verizon.net> <200706291234.59009.jkeating@redhat.com> <1183204449.29568.12.camel@xo-13-A4-25.localdomain> Message-ID: <468651A0.3080202@verizon.net> Dan Williams wrote: > On Fri, 2007-06-29 at 12:34 -0400, Jesse Keating wrote: > >> On Friday 29 June 2007 12:35:05 Gerry Reno wrote: >> >>> Do you know when they will make it in the upstream kernel? >>> >> Magic 8 ball says.... >> >> Seriously some of these may never make it in. It all depends on the >> motivations of the teams producing these things. >> > > The vserver guys have tried in the past to get it in, but they got some > pushback on some things, and they now seem completely uninterested > taking the time needed to clean their stuff up and actually get it into > the kernel. I wouldn't hold out much hope unless something changes > dramatically. > > Dan > I think the best approach would be to provide a VE framework in the kernel with an API that both OpenVZ and Linux-vServer (and anybody else) could use. Keep particular implementation details outside in loadable modules. From rvinyard at cs.nmsu.edu Sat Jun 30 14:17:33 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Sat, 30 Jun 2007 08:17:33 -0600 Subject: OpenSceneGraph In-Reply-To: <1183036409.24184.72.camel@mccallum.corsepiu.local> References: <1183036409.24184.72.camel@mccallum.corsepiu.local> Message-ID: <468665FD.4080407@cs.nmsu.edu> Ralf Corsepius wrote: > Hi, > > I've several times been asked to upgrade OpenSceneGraph to > OpenSceneGraph-2.0 (on rawhide and may-be FC7) > > So far, there remain a couple of details unclear to me, I'd like to see > clarified: > > * OpenSceneGraph-2.0 is completely incompatible to OpenSceneGraph-1.x! > * Packaging, features and all SONAME have changed! > > Questions: > > * Is there anybody out there who is actively using (esp. developing for) > OpenSceneGraph-1? > Yes. In fact I was getting ready to submit packages for the VTP from http://vterrain.org (initially including the libraries, VTBuilder and Enviro). I've contacted the author to find out what the plans for OSG-2.0 support are, and will follow up when I know more. In addition to that, I have vtgtkmm which is a library of VTP widgets for Gtkmm (similar to the WX widgets included in libvtui from VTP). > * Is there anybody out there who is actively using Producer or who has a > package which depends on (OSG-1's) Producer > (OpenSceneGraph-2 has dropped Producer). > I also have osgtkmm which is dependent upon Producer. However, a move to OSG-2.0 wouldn't bother me at all. I'd much rather target OSG-2.0 anyway. > > Should you answer to any of the questions above with "yes", please speak > up ASAP. > > TIA. > Ralf > > > Just another side note on OSG examples... I noticed that none of the data files are included so they run without textures, etc. From rvinyard at cs.nmsu.edu Sat Jun 30 14:19:29 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Sat, 30 Jun 2007 08:19:29 -0600 Subject: Glade3 [was: glade3 in fedora 7] In-Reply-To: <62bc09df0706280618k6f93b30esfc9ac30a4a30b36b@mail.gmail.com> References: <62bc09df0706270823s51218989wc15ac6f19d674575@mail.gmail.com> <46835E46.9090404@rasmil.dk> <62bc09df0706280618k6f93b30esfc9ac30a4a30b36b@mail.gmail.com> Message-ID: <46866671.8090708@cs.nmsu.edu> SmootherFrOgZ wrote: > You could catch it here: > http://download.tuxfamily.org/lxtnow/fedora/testing > Only available for F-7_i386 (for now), if someone wanted to test it on > x86_64, just ask ;-) > Perhaps you could post the srpm and/or the spec so we can test on other architectures? From rvinyard at cs.nmsu.edu Sat Jun 30 14:31:54 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Sat, 30 Jun 2007 08:31:54 -0600 Subject: VTP (Virtual Terrain Project) on Fedora Message-ID: <4686695A.2020509@cs.nmsu.edu> I have nearly completed a set of VTP packages for Fedora. To get VTP packaged and into the official Fedora distribution I have also packaged Mini, quikgrid and minizip (replacing the unzip library distributed with VTP). If anyone is interested in testing let me know and I'll post the srpms for Mini, quikgrid and minizip along with the current VTP patch that I'm working on. From jkeating at redhat.com Sat Jun 30 14:55:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Jun 2007 10:55:46 -0400 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <46853AE1.9010801@di.uminho.pt> References: <46853AE1.9010801@di.uminho.pt> Message-ID: <200706301055.46506.jkeating@redhat.com> On Friday 29 June 2007 13:01:21 Jose Pedro Oliveira wrote: > FYI: more than 700 packages will have to be reviewed due to this change > which I consider a waste of packagers time, in particular mine. Clearly we should just do full installs into buildroots so that nobody has to bother with tracking what is actually needed to build their packages. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwizart at gmail.com Sat Jun 30 15:08:17 2007 From: kwizart at gmail.com (KH KH) Date: Sat, 30 Jun 2007 17:08:17 +0200 Subject: VTP (Virtual Terrain Project) on Fedora In-Reply-To: <4686695A.2020509@cs.nmsu.edu> References: <4686695A.2020509@cs.nmsu.edu> Message-ID: 2007/6/30, Rick L Vinyard Jr : > I have nearly completed a set of VTP packages for Fedora. > > To get VTP packaged and into the official Fedora distribution I have > also packaged Mini, quikgrid and minizip (replacing the unzip library > distributed with VTP). > > If anyone is interested in testing let me know and I'll post the srpms > for Mini, quikgrid and minizip along with the current VTP patch that I'm > working on. I'm interested in it! I'm student in architecture so i think that software can be interesting in visualisation at some point...?! Do you already have submitted bugzilla review so i can take a look ? Nicolas (kwizart) > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From kagesenshi.87 at gmail.com Sat Jun 30 15:24:27 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Sat, 30 Jun 2007 23:24:27 +0800 Subject: Compiz Fusion? In-Reply-To: <46850CF6.4080206@redhat.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> Message-ID: On 6/29/07, Jarod Wilson wrote: > Deependra Singh Shekhawat wrote: > > I am not sure about rawhide but it has a private repo as if now for > > Fedora7. http://blog.kagesenshi.org for more info. > > A few of us (the current beryl maintainers, compiz maintainers and the > individual responsible for the above packages) just started discussing > the path forward earlier this week. > Hi there, I'm the person responsible for those packages ( I have plenty of aliases :P ) .. the packages are still not good imo .. compiz fusion introduced lots of changes in the core compiz packages and some stuff, like desktop-effects, simply breaks .. these are several issues that I believe need to be resolved .. and I need ur opinion about them .. - desktop-effects menu does not JustWork(tm) .. - which configuration plugin to use? gconf or ccp? the previous compiz uses gconf .. if we are going to use ccp, desktop-effects needs a rewrite .. - the default installation provides several plugins that might pull more dependencies eg: fuse. to_split or not to_split I just built today git checkout and they are available here http://devel.foss.org.my/~kagesenshi/repo/private/testing/ feel free to play around with them .. about desktop-effects .. for systems with AIGLX, an environment var need to be exported before launching it to make it work export LIBGL_ALWAYS_INDIRECT=1 -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From drago01 at gmail.com Sat Jun 30 16:03:48 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 30 Jun 2007 18:03:48 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> Message-ID: On 6/30/07, Hikaru Amano wrote: > > On 6/29/07, Jarod Wilson wrote: > > Deependra Singh Shekhawat wrote: > > > I am not sure about rawhide but it has a private repo as if now for > > > Fedora7. http://blog.kagesenshi.org for more info. > > > > A few of us (the current beryl maintainers, compiz maintainers and the > > individual responsible for the above packages) just started discussing > > the path forward earlier this week. > > > > Hi there, I'm the person responsible for those packages ( I have > plenty of aliases :P ) .. the packages are still not good imo .. > > compiz fusion introduced lots of changes in the core compiz packages > and some stuff, like desktop-effects, simply breaks .. these are several issues that I believe need to be resolved .. and I > need ur opinion about them .. > > - desktop-effects menu does not JustWork(tm) .. > - which configuration plugin to use? gconf or ccp? the previous compiz > uses gconf .. if we are going to use ccp, desktop-effects needs a > rewrite .. I think ccp would be better, it also have a gconf-backend. about desktop-effects: there is not much that need to be changed there... if we decide on what to use I can provide patches if needed ;) - the default installation provides several plugins that might pull > more dependencies eg: fuse. to_split or not to_split do you have a list of this deps? we could split it into compiz-fusion-plugins and compiz-fusion-plugins-extras I just built today git checkout and they are available here > > http://devel.foss.org.my/~kagesenshi/repo/private/testing/ > > feel free to play around with them .. thx, will look at them about desktop-effects .. for systems with AIGLX, an environment var > need to be exported before launching it to make it work > > export LIBGL_ALWAYS_INDIRECT=1 this should then be added to gnome-wm to because on login desktop-effects is not inolved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Tanguy at univ-nantes.fr Sat Jun 30 16:17:57 2007 From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY) Date: Sat, 30 Jun 2007 18:17:57 +0200 (CEST) Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> <60715.193.52.109.12.1182865565.squirrel@webmail.univ-nantes.fr> Message-ID: <1247.195.132.94.46.1183220277.squirrel@webmail.univ-nantes.fr> >> On Mon, 25 Jun 2007 13:34:30 -0400, Eric Tanguy (tanguy) wrote: >> >>> Author: tanguy >>> >>> Update of /cvs/extras/rpms/libupnp/FC-6 >> >>> %changelog >>> +* Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 >>> +- Update to version 1.6.0 >>> + >> >> Blacklisted for now together with ushare. >> It breaks dependencies in several packages. >> >> Run "repoquery --whatrequires libupnp.so.2", use rpmdev-diff, announce >> such ABI breakage on fedora-maintainers list, and if such a version >> upgrade is really necessary, coordinate rebuilds appropriately. >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > I just announce this on fedora-maintainers list with copy to the owners > concerned. All seem to be agree to rebuild their packages against this new > lib but we have some questions about this : > > we tried to rebuild our packages (ushare and gmediaserver) for F-7 but the > build system does not see the new libupnp which is in update-testing. What > to do ? > > When we will be ready how to push all the packages at the same time ? And > how to synchronize this with livna ? > > Thanks > > Eric > > Now gmediaserver is rebuilt for FC6 and non branched for FC5. So could you make their available ? Eric From mmcgrath at redhat.com Sat Jun 30 16:57:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 30 Jun 2007 11:57:39 -0500 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> Message-ID: <46868B83.5030006@redhat.com> Nigel Metheringham wrote: > Having watched from the sidelines I updated my VIA mini-ITX system > yesterday. Its an original 800 MHz model. > > Fedora installs for an i586 on it - 586 kernel etc. However, at least > post F7 upgrade (meaning I didn't check beforehand) uname -m and arch > report i686. Smolt also sees this as an i686 - in fact the complete > profile is at Whats the right way to determine the arch of the box? -Mike From alex at tvtransilvania.ro Sat Jun 30 17:05:28 2007 From: alex at tvtransilvania.ro (Alexandru Ciobanu) Date: Sat, 30 Jun 2007 20:05:28 +0300 Subject: VTP (Virtual Terrain Project) on Fedora In-Reply-To: References: <4686695A.2020509@cs.nmsu.edu> Message-ID: <46868D58.1090105@tvtransilvania.ro> KH KH wrote: >> If anyone is interested in testing let me know and I'll post the srpms >> for Mini, quikgrid and minizip along with the current VTP patch that I'm >> working on. > > I'm interested in it! +1 From alan at redhat.com Sat Jun 30 17:40:07 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 30 Jun 2007 13:40:07 -0400 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <46868B83.5030006@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> Message-ID: <20070630174007.GA3405@devserv.devel.redhat.com> On Sat, Jun 30, 2007 at 11:57:39AM -0500, Mike McGrath wrote: > >post F7 upgrade (meaning I didn't check beforehand) uname -m and arch > >report i686. Smolt also sees this as an i686 - in fact the complete > >profile is at > Whats the right way to determine the arch of the box? uname -m However for the "gcc 686" as opposed to "Intel/AMD 686" you must also check that cmov is available. Basically smolt is right gcc is wrong 8) Alan From mmcgrath at redhat.com Sat Jun 30 18:51:48 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 30 Jun 2007 13:51:48 -0500 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070630174007.GA3405@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> <20070630174007.GA3405@devserv.devel.redhat.com> Message-ID: <4686A644.2040700@redhat.com> Alan Cox wrote: > On Sat, Jun 30, 2007 at 11:57:39AM -0500, Mike McGrath wrote: > >>> post F7 upgrade (meaning I didn't check beforehand) uname -m and arch >>> report i686. Smolt also sees this as an i686 - in fact the complete >>> profile is at >>> >> Whats the right way to determine the arch of the box? >> > > uname -m > > However for the "gcc 686" as opposed to "Intel/AMD 686" you must also check > that cmov is available. Basically smolt is right gcc is wrong 8) > I guess I could look at it another way, what info can I grab so its useful to the developers to make decisions about this stuff :) -Mike From tcallawa at redhat.com Sat Jun 30 21:10:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 30 Jun 2007 16:10:27 -0500 Subject: rpms/samba/devel samba.spec,1.124,1.125 In-Reply-To: <1183173131.10801.2.camel@aglarond.local> References: <200706291942.l5TJgM08023311@cvs-int.fedora.redhat.com> <20070629195050.GB2979@free.fr> <1183147463.25772.39.camel@localhost.localdomain> <1183150342.10197.41.camel@localhost.localdomain> <1183173131.10801.2.camel@aglarond.local> Message-ID: <1183237828.6701.2.camel@localhost.localdomain> On Fri, 2007-06-29 at 23:12 -0400, Jeremy Katz wrote: > On Fri, 2007-06-29 at 16:52 -0400, Adam Jackson wrote: > > On Fri, 2007-06-29 at 16:04 -0400, Simo Sorce wrote: > > > On Fri, 2007-06-29 at 21:50 +0200, Patrice Dumas wrote: > > > > On Fri, Jun 29, 2007 at 03:42:22PM -0400, Simo Sorce wrote: > > > > > + eval testparm -s 2>/dev/null |grep "lock dir" >/dev/null > > > > > + if [ $? = 0 ]; then > > > > > + echo "Warning: lock dir explicitly set. Not moving tdb files to new default location" > > > > > > > > Unless I am wrong, echoing anything during updates is not right... > > > > > > I've seen warning for when files are dropped in as .rpmnew or saved > > > as .rpmsave > > > This is a very similar case, so I think it should be ok, but if not I'd > > > like to know (and know why rpmnew/rpmsave are instead ok) > > > > That warning is issued from RPM itself. Which means there's probably a > > hook to do something with that information from a GUI tool. > > Actually, there's not. So this case is no better or worse Strictly speaking, we've never said that you can't echo things. It's pointless, really, but we've never forbidden it. Now, interactive prompting? That's forbidden. ~spot From a.badger at gmail.com Sat Jun 30 21:43:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 30 Jun 2007 14:43:34 -0700 Subject: FESCo voting system Message-ID: <1183239814.15601.27.camel@localhost.localdomain> Hello all, According to FESCo's Election Policy [1]_ the upcoming FESCo election was supposed to use a variation of range voting [2]_. However, with the Fedora Project Board implementing a new voting method (approval voting[3]_) for the first time and the two elections being held so close together several contributors and FESCo members would like to use the same method to elect FESCo as used to elect the Board. This change would be aimed at reducing confusion over changing the voting method twice in such a short time. FESCo is going to vote on this on Thursday to make sure there is enough time to implement whatever decision is made. If you feel strongly that this is the wrong decision, please speak up before the Thursday Meeting [1]_: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections#VotingSystem [2]_: http://en.wikipedia.org/wiki/Range_voting [3]_: http://en.wikipedia.org/wiki/Approval_voting Thank you, -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jpo at di.uminho.pt Sat Jun 30 22:02:18 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sat, 30 Jun 2007 23:02:18 +0100 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <200706301055.46506.jkeating@redhat.com> References: <46853AE1.9010801@di.uminho.pt> <200706301055.46506.jkeating@redhat.com> Message-ID: <4686D2EA.9040703@di.uminho.pt> Jesse Keating wrote: > On Friday 29 June 2007 13:01:21 Jose Pedro Oliveira wrote: >> FYI: more than 700 packages will have to be reviewed due to this change >> which I consider a waste of packagers time, in particular mine. > > Clearly we should just do full installs into buildroots so that nobody has to > bother with tracking what is actually needed to build their packages. Right now we don't have an easy way to pull all the perl core modules into he build system. Not even pulling the perl-devel package, or any other meta-package, can we have the perl runtime environment installed in the building systems. The problem has been caused by the patch https://www.redhat.com/archives/fedora-extras-commits/2007-June/msg00114.html. applied in the begining of the month but only built this week. Discussion about the patch: https://www.redhat.com/archives/fedora-perl-devel-list/2007-June/msg00018.html jpo -- Jos? Pedro Oliveira * mailto:jpo at di.uminho.pt * http://gsd.di.uminho.pt/members/jpo/ * From Axel.Thimm at ATrpms.net Sat Jun 30 22:00:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 00:00:57 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <1183126185.6299.8.camel@dhcp83-186.boston.redhat.com> References: <46847475.6000405@fedoraproject.org> <3170f42f0706290151m7f3133e4ue2e0bc484d6d276c@mail.gmail.com> <1183126161.2845.7.camel@kennedy> <1183126185.6299.8.camel@dhcp83-186.boston.redhat.com> Message-ID: <20070630220057.GD15787@puariko.nirvana> On Fri, Jun 29, 2007 at 10:09:45AM -0400, Matthias Clasen wrote: > On Fri, 2007-06-29 at 10:09 -0400, Brian Pepple wrote: > > On Fri, 2007-06-29 at 14:21 +0530, Debarshi 'Rishi' Ray wrote: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245649 > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245826 > > > > > > I have a couple of review requests which may be affected by the > > > outcome of this discussion. Specifically whether one should append > > > "fedora-" to the names of the *.desktop files or use the "X-Fedora" > > > category in the *.desktop files installed by these packages in > > > /usr/share/applications ? > > > > The packaging guidelines seem pretty clear to me. For new packages, if > > upstream uses , leave it intact, otherwise use fedora as > > . > > > > The part that is unclear is that it is not defined anywhere what a > vendor prefix is, really. Upstream just happens to ship desktop files > that are called gnome-foobar.desktop or kde-powertoy.desktop, and we > have to guess that the part up to the first - is the vendor prefix. > But what about things like tetex-xdvi.desktop or virt-manager.desktop ? Rex made (inho) a good analysis wrt to what the vendor should be and crafted the guideline that is now used. It's quite messy, I agree, but Rex' solution looks fine. > Once again, desktop files prove to be the worst possible implementation > of an application registry... > -- 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 Jun 30 22:02:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 00:02:32 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <1183094681.21296.37.camel@localhost.localdomain> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> Message-ID: <20070630220232.GE15787@puariko.nirvana> On Thu, Jun 28, 2007 at 10:24:41PM -0700, Toshio Kuratomi wrote: > On Fri, 2007-06-29 at 10:30 +0530, Rahul Sundaram wrote: > > In the case of README files there is genuine advantages to have generic > > names. You have less changes to take care off when you branch off to > > RHEL, EPEL or OLPC. Maybe other distributions can be encouraged to use > > README.distribution too. > > That would be unfortunate. README.suse != README.fedora != > README.ubuntu.... Exactly. If the contents are equal then by definition it would not be suited for README.. Isn't EPEL Fedora anymore? Why the need to banish README.Fedora? -- 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 Jun 30 22:14:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 00:14:20 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> Message-ID: <20070630221420.GF15787@puariko.nirvana> On Sat, Jun 30, 2007 at 11:22:02AM +0100, Nigel Metheringham wrote: > > On 6/21/07, Alan Cox wrote: > >On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote: > >>I'm thinking about getting a new box anyway (it's an old > >>not-quite-C3 with some odd Biblean-sounding codename, chugging > >>along at 800MHz). With less than 40 users, it's just not worth > >>it. I'm surprised though, I thought VIA was more popular than > >>that. > > >It is a good deal more popular than that (although the 686 > >compatible but not gcc 686 compatible ones are the older ones > >generally) > > >Unless Dave can publish data sets and a methodology for his count > >(and given even the big marketing companies can't do it I want to > >see this) we should assume he made up a number to justify killing it > >cos he finds it a hassle to maintain. > > Having watched from the sidelines I updated my VIA mini-ITX system > yesterday. Its an original 800 MHz model. > > Fedora installs for an i586 on it - 586 kernel etc. However, at least > post F7 upgrade (meaning I didn't check beforehand) uname -m and arch > report i686. Smolt also sees this as an i686 - in fact the complete > profile is at > However it will not boot a current i686 kernel - resets immediately. > > There are 264 (0.4%) CentaurHauls CPUs in Smolt right now (and obviously > upgraders like me would not appear there unless we make the effort). Its > not much of a proportion, but there are more users than the i586 figures > suggest. I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586. And even though ppc is not expected to be a frontline arch, only 378 boxes? Makes me feel like having a big share of ppc boxes. -- 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 lightsolphoenix at gmail.com Sat Jun 30 22:31:17 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 30 Jun 2007 18:31:17 -0400 Subject: Sunbird in devel In-Reply-To: <3170f42f0706290149m39c9de40r9afb764986ce613f@mail.gmail.com> References: <46840DD8.4020303@andrei.myip.org> <200706281707.57230.lightsolphoenix@gmail.com> <3170f42f0706290149m39c9de40r9afb764986ce613f@mail.gmail.com> Message-ID: <200706301831.18498.lightsolphoenix@gmail.com> On Friday, June 29, 2007 4:49 am Debarshi 'Rishi' Ray wrote: > > Oh, and if there's enough interest, I'll package Sunbird for Fedora. > > What are you waiting for? > > Cheerio, > Debarshi > -- > GPG key ID: 63D4A5A7 > Key server: pgp.mit.edu I've got the spec file written, but I can't get it to compile. I keep getting errors from ld about missing symbols. I'm posting here to see if this is a known problem with the Mozilla builds in general. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From benny+usenet at amorsen.dk Sat Jun 30 22:46:42 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 01 Jul 2007 00:46:42 +0200 Subject: kernel support for VE's (OpenVZ / Linux-vServer) References: <46853233.3010508@verizon.net> <1183134589.30145.38.camel@weaponx.rchland.ibm.com> <468534B9.1030609@verizon.net> <200706291234.59009.jkeating@redhat.com> <1183204449.29568.12.camel@xo-13-A4-25.localdomain> <468651A0.3080202@verizon.net> Message-ID: >>>>> "GR" == Gerry Reno writes: GR> I think the best approach would be to provide a VE framework in GR> the kernel with an API that both OpenVZ and Linux-vServer (and GR> anybody else) could use. Keep particular implementation details GR> outside in loadable modules. That is the approach taken, apart from the last line -- OpenVZ and Linux-vserver will end up just being user space tools using a common kernel interface. Rather like racoon and openswan these days, if you don't apply the openswan KLIPS patch. They should not need separate modules. /Benny From sundaram at fedoraproject.org Sat Jun 30 23:04:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 04:34:18 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <20070630220232.GE15787@puariko.nirvana> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> Message-ID: <4686E172.3000202@fedoraproject.org> Axel Thimm wrote: > On Thu, Jun 28, 2007 at 10:24:41PM -0700, Toshio Kuratomi wrote: >> On Fri, 2007-06-29 at 10:30 +0530, Rahul Sundaram wrote: >>> In the case of README files there is genuine advantages to have generic >>> names. You have less changes to take care off when you branch off to >>> RHEL, EPEL or OLPC. Maybe other distributions can be encouraged to use >>> README.distribution too. >> That would be unfortunate. README.suse != README.fedora != >> README.ubuntu.... > > Exactly. If the contents are equal then by definition it would not be > suited for README.. > > Isn't EPEL Fedora anymore? Why the need to banish README.Fedora? EPEL isn't targeted for Fedora. I did refer to the discussion. Think about this from the end user perspective rather than from the project perspective. Rahul From alan at redhat.com Sat Jun 30 23:05:51 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 30 Jun 2007 19:05:51 -0400 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <4686A644.2040700@redhat.com> References: <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> <20070630174007.GA3405@devserv.devel.redhat.com> <4686A644.2040700@redhat.com> Message-ID: <20070630230551.GA15010@devserv.devel.redhat.com> On Sat, Jun 30, 2007 at 01:51:48PM -0500, Mike McGrath wrote: > I guess I could look at it another way, what info can I grab so its > useful to the developers to make decisions about this stuff :) Depends what DaveJ plans for FC8 For current rpm you want to check that 1. All CPUs report family 6 or higher 2. All CPUs have the cmov flag in their cpuid capability bits From alan at redhat.com Sat Jun 30 23:07:29 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 30 Jun 2007 19:07:29 -0400 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070630221420.GF15787@puariko.nirvana> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> Message-ID: <20070630230729.GB15010@devserv.devel.redhat.com> On Sun, Jul 01, 2007 at 12:14:20AM +0200, Axel Thimm wrote: > I also wonder what the 2.1% i386 are. These can't be true i386, or if > they are they can't be 30x as many as i586. I'd been wondering if those are qemu/vmware/xen or something similar ? > And even though ppc is not expected to be a frontline arch, only 378 > boxes? Makes me feel like having a big share of ppc boxes. Most users won't be reporting anything From Axel.Thimm at ATrpms.net Sat Jun 30 23:10:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 01:10:22 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <4686E172.3000202@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> Message-ID: <20070630231022.GJ15787@puariko.nirvana> On Sun, Jul 01, 2007 at 04:34:18AM +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > >On Thu, Jun 28, 2007 at 10:24:41PM -0700, Toshio Kuratomi wrote: > >>On Fri, 2007-06-29 at 10:30 +0530, Rahul Sundaram wrote: > >>>In the case of README files there is genuine advantages to have generic > >>>names. You have less changes to take care off when you branch off to > >>>RHEL, EPEL or OLPC. Maybe other distributions can be encouraged to use > >>>README.distribution too. > >>That would be unfortunate. README.suse != README.fedora != > >>README.ubuntu.... > > > >Exactly. If the contents are equal then by definition it would not be > >suited for README.. > > > >Isn't EPEL Fedora anymore? Why the need to banish README.Fedora? > > EPEL isn't targeted for Fedora. Not for, but from. > I did refer to the discussion. Think about this from the end user > perspective rather than from the project perspective. Yes, the end user should hopefully not wonder that EPEL is from Fedora. If so, then he'll hopfully get up to speed, and README.Fedora kicking him off to do so will have been a feature and not a bug. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Jun 30 23:10:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 04:40:41 +0530 Subject: Sunbird in devel In-Reply-To: <200706301831.18498.lightsolphoenix@gmail.com> References: <46840DD8.4020303@andrei.myip.org> <200706281707.57230.lightsolphoenix@gmail.com> <3170f42f0706290149m39c9de40r9afb764986ce613f@mail.gmail.com> <200706301831.18498.lightsolphoenix@gmail.com> Message-ID: <4686E2F1.6050503@fedoraproject.org> Kelly wrote: > On Friday, June 29, 2007 4:49 am Debarshi 'Rishi' Ray wrote: >>> Oh, and if there's enough interest, I'll package Sunbird for Fedora. >> What are you waiting for? >> >> Cheerio, >> Debarshi >> -- >> GPG key ID: 63D4A5A7 >> Key server: pgp.mit.edu > > I've got the spec file written, but I can't get it to compile. I keep getting > errors from ld about missing symbols. > > I'm posting here to see if this is a known problem with the Mozilla builds in > general. You got to post the build output then. Rahul From sundaram at fedoraproject.org Sat Jun 30 23:13:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 04:43:43 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <20070630231022.GJ15787@puariko.nirvana> References: <46847475.6000405@fedoraproject.org> <200706282251.30065.jkeating@redhat.com> <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> Message-ID: <4686E3A7.1070106@fedoraproject.org> Axel Thimm wrote: > On Sun, Jul 01, 2007 at 04:34:18AM +0530, Rahul Sundaram wrote: >> Axel Thimm wrote: >>> On Thu, Jun 28, 2007 at 10:24:41PM -0700, Toshio Kuratomi wrote: >>>> On Fri, 2007-06-29 at 10:30 +0530, Rahul Sundaram wrote: >>>>> In the case of README files there is genuine advantages to have generic >>>>> names. You have less changes to take care off when you branch off to >>>>> RHEL, EPEL or OLPC. Maybe other distributions can be encouraged to use >>>>> README.distribution too. >>>> That would be unfortunate. README.suse != README.fedora != >>>> README.ubuntu.... >>> Exactly. If the contents are equal then by definition it would not be >>> suited for README.. >>> >>> Isn't EPEL Fedora anymore? Why the need to banish README.Fedora? >> EPEL isn't targeted for Fedora. > > Not for, but from. > >> I did refer to the discussion. Think about this from the end user >> perspective rather than from the project perspective. > > Yes, the end user should hopefully not wonder that EPEL is from > Fedora. If so, then he'll hopfully get up to speed, and README.Fedora > kicking him off to do so will have been a feature and not a bug. Seems the emphasis is incorrectly about where the repository is from rather than where it is going to be used in. Rahul From Axel.Thimm at ATrpms.net Sat Jun 30 23:15:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 01:15:40 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070630230729.GB15010@devserv.devel.redhat.com> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> Message-ID: <20070630231540.GK15787@puariko.nirvana> On Sat, Jun 30, 2007 at 07:07:29PM -0400, Alan Cox wrote: > > And even though ppc is not expected to be a frontline arch, only 378 > > boxes? Makes me feel like having a big share of ppc boxes. > > Most users won't be reporting anything Yes, that's the issue with these kind of statistics. At least for ppc one can get some comparative statistics by checking the ratio of ppc to i386/x86_64 iso downloads. The correcting factor would show how different the black numbers behind the smolt stats are from i386/x86_64 to ppc and use that as a weighing factor for getting improved estimators for ppc. But for the i586 vs i686 issue we can't find any other stats to compare with smolt. -- 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 Jun 30 23:18:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 01:18:34 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <4686A644.2040700@redhat.com> References: <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> <20070630174007.GA3405@devserv.devel.redhat.com> <4686A644.2040700@redhat.com> Message-ID: <20070630231834.GL15787@puariko.nirvana> On Sat, Jun 30, 2007 at 01:51:48PM -0500, Mike McGrath wrote: > Alan Cox wrote: > >On Sat, Jun 30, 2007 at 11:57:39AM -0500, Mike McGrath wrote: > > > >>>post F7 upgrade (meaning I didn't check beforehand) uname -m and arch > >>>report i686. Smolt also sees this as an i686 - in fact the complete > >>>profile is at > >>> > >>Whats the right way to determine the arch of the box? > >> > > > >uname -m > > > >However for the "gcc 686" as opposed to "Intel/AMD 686" you must also check > >that cmov is available. Basically smolt is right gcc is wrong 8) > > > > I guess I could look at it another way, what info can I grab so its > useful to the developers to make decisions about this stuff :) Isn't all of /proc/cpuinfo transmitted? Maybe a finer grained stats on cpu family/model/flags under the "CPU" tag? -- 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 opensource at till.name Sat Jun 30 23:18:20 2007 From: opensource at till.name (Till Maas) Date: Sun, 01 Jul 2007 01:18:20 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <4686E172.3000202@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> Message-ID: <200707010118.22246.opensource@till.name> On So Juli 1 2007, Rahul Sundaram wrote: > EPEL isn't targeted for Fedora. I did refer to the discussion. Think > about this from the end user perspective rather than from the project > perspective. Where does a user not see Fedora when he looks at EPEL? Bugs go to the "Fedora EPEL" Product on Bugzilla, all documentation is found at http://FEDORAproject.org/wiki/EPEL and repoview at http://redhat.download.FEDORAproject.org/pub/epel/5/i386/repoview/ has the title "Fedora EPEL". So are you sure, that a lot of end users are confused by README.Fedora files? Regards, Till From Axel.Thimm at ATrpms.net Sat Jun 30 23:22:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 01:22:35 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <4686E3A7.1070106@fedoraproject.org> References: <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> Message-ID: <20070630232235.GM15787@puariko.nirvana> On Sun, Jul 01, 2007 at 04:43:43AM +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > >On Sun, Jul 01, 2007 at 04:34:18AM +0530, Rahul Sundaram wrote: > >>Axel Thimm wrote: > >>>On Thu, Jun 28, 2007 at 10:24:41PM -0700, Toshio Kuratomi wrote: > >>>>On Fri, 2007-06-29 at 10:30 +0530, Rahul Sundaram wrote: > >>>>>In the case of README files there is genuine advantages to have > >>>>>generic names. You have less changes to take care off when you branch > >>>>>off to RHEL, EPEL or OLPC. Maybe other distributions can be encouraged > >>>>>to use README.distribution too. > >>>>That would be unfortunate. README.suse != README.fedora != > >>>>README.ubuntu.... > >>>Exactly. If the contents are equal then by definition it would not be > >>>suited for README.. > >>> > >>>Isn't EPEL Fedora anymore? Why the need to banish README.Fedora? > >>EPEL isn't targeted for Fedora. > > > >Not for, but from. > > > >>I did refer to the discussion. Think about this from the end user > >>perspective rather than from the project perspective. > > > >Yes, the end user should hopefully not wonder that EPEL is from > >Fedora. If so, then he'll hopfully get up to speed, and > >README.Fedora kicking him off to do so will have been a feature and > >not a bug. > > Seems the emphasis is incorrectly about where the repository is from > rather than where it is going to be used in. Whether it's "incorrectly" or not is up to the eye of the beholder, and FWIW README.distribution is serving neither side of the grammar. Or is this package really going to be used in a "distribution"? I'm quite sure it will be. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sat Jun 30 23:27:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 04:57:06 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <200707010118.22246.opensource@till.name> References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <200707010118.22246.opensource@till.name> Message-ID: <4686E6CA.5080701@fedoraproject.org> Till Maas wrote: > On So Juli 1 2007, Rahul Sundaram wrote: > >> EPEL isn't targeted for Fedora. I did refer to the discussion. Think >> about this from the end user perspective rather than from the project >> perspective. > > Where does a user not see Fedora when he looks at EPEL? Bugs go to the "Fedora > EPEL" Product on Bugzilla, all documentation is found at > http://FEDORAproject.org/wiki/EPEL and repoview at > http://redhat.download.FEDORAproject.org/pub/epel/5/i386/repoview/ has the > title "Fedora EPEL". So are you sure, that a lot of end users are confused by > README.Fedora files? In places where enterprise distributions are used there is typically a lot of end users running preconfigured locked down systems which might also have EPEL repository enabled. They wouldn't be reporting bugs or installing the repository themselves. I can't really be sure about anyone getting confused at all. I have no interest in discussing this further. It's upto to FESCo to make a decision. Rahul From lightsolphoenix at gmail.com Sat Jun 30 23:27:37 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 30 Jun 2007 19:27:37 -0400 Subject: Sunbird in devel In-Reply-To: <4686E2F1.6050503@fedoraproject.org> References: <46840DD8.4020303@andrei.myip.org> <200706301831.18498.lightsolphoenix@gmail.com> <4686E2F1.6050503@fedoraproject.org> Message-ID: <200706301927.38592.lightsolphoenix@gmail.com> On Saturday, June 30, 2007 7:10 pm Rahul Sundaram wrote: > You got to post the build output then. > > Rahul Yep, which is why I'm running rpmbuild again. The compilation takes a couple of hours, so I've got to wait. I'll post the results when it's done running. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From sundaram at fedoraproject.org Sat Jun 30 23:32:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 05:02:41 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <20070630232235.GM15787@puariko.nirvana> References: <468476FC.9020300@fedoraproject.org> <200706282300.33107.jkeating@redhat.com> <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> Message-ID: <4686E819.8030207@fedoraproject.org> Axel Thimm wrote: > > Whether it's "incorrectly" or not is up to the eye of the beholder, > and FWIW README.distribution is serving neither side of the > grammar. Or is this package really going to be used in a > "distribution"? I'm quite sure it will be. Distribution is just a off hand suggestion. Feel free to come up with a better name like others have suggested. Rahul From Axel.Thimm at ATrpms.net Sat Jun 30 23:39:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 01:39:10 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <4686E819.8030207@fedoraproject.org> References: <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> <4686E819.8030207@fedoraproject.org> Message-ID: <20070630233910.GN15787@puariko.nirvana> On Sun, Jul 01, 2007 at 05:02:41AM +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > > > > >Whether it's "incorrectly" or not is up to the eye of the beholder, > >and FWIW README.distribution is serving neither side of the > >grammar. Or is this package really going to be used in a > >"distribution"? I'm quite sure it will be. > > Distribution is just a off hand suggestion. Feel free to come up with a > better name like others have suggested. How about README.Fedora? -- 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 lightsolphoenix at gmail.com Sat Jun 30 23:41:01 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 30 Jun 2007 19:41:01 -0400 Subject: Sunbird Build Output (was Re: Sunbird in devel) In-Reply-To: <4686E2F1.6050503@fedoraproject.org> References: <46840DD8.4020303@andrei.myip.org> <200706301831.18498.lightsolphoenix@gmail.com> <4686E2F1.6050503@fedoraproject.org> Message-ID: <200706301941.02349.lightsolphoenix@gmail.com> On Saturday, June 30, 2007 7:10 pm Rahul Sundaram wrote: > You got to post the build output then. Okay, the build output is attached here. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: errorlog.log Type: text/x-log Size: 4048 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Jun 30 23:43:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 01:43:56 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <4686E6CA.5080701@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <200707010118.22246.opensource@till.name> <4686E6CA.5080701@fedoraproject.org> Message-ID: <20070630234356.GO15787@puariko.nirvana> On Sun, Jul 01, 2007 at 04:57:06AM +0530, Rahul Sundaram wrote: > Till Maas wrote: > >On So Juli 1 2007, Rahul Sundaram wrote: > > > >>EPEL isn't targeted for Fedora. I did refer to the discussion. Think > >>about this from the end user perspective rather than from the project > >>perspective. > > > >Where does a user not see Fedora when he looks at EPEL? Bugs go to the > >"Fedora EPEL" Product on Bugzilla, all documentation is found at > >http://FEDORAproject.org/wiki/EPEL and repoview at > >http://redhat.download.FEDORAproject.org/pub/epel/5/i386/repoview/ has the > >title "Fedora EPEL". So are you sure, that a lot of end users are confused > >by README.Fedora files? > > In places where enterprise distributions are used there is typically a > lot of end users running preconfigured locked down systems which might > also have EPEL repository enabled. They wouldn't be reporting bugs or > installing the repository themselves. I can't really be sure about > anyone getting confused at all. The above use case has some flwas. Either the system is locked down in which case the user calls his support to touch anything on the system, or the user is in charge and needs to be aware of the origin and support options of his software. The case above really cries out for using the proper Fedora association. The only one uncomfortable with this could be an OEM preconfiguring EPEL or other third party software on top of RHEL and supposedly selling this as having the same support options as RHEL packages. And you do want the customer to become aware of this situation. > I have no interest in discussing this further. It's upto to FESCo to > make a decision. -- 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: