Re: Sources file audit - 2010-01-05
On Wed, Jan 6, 2010 at 8:24 PM, Dave Jones da...@redhat.com wrote:
On Wed, Jan 06, 2010 at 11:38:20AM -0700, Kevin Fenzi wrote:
- BADURL:base-file-name:$PACKAGENAME
This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc.
Also there are a number of packages with incorrect sourceforge links.
(BTW, there are still some packages with ftp://people.redhat.com/
URLs). This could also be a transitory network failure from my checking
host or the project hosting.
davej:BADURL:midisport-firmware-1.2.tar.gz:midisport-firmware
so %{version} in the Source: line isn't allowed any more ?
It is...
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT considered painful
On Sat, Jan 2, 2010 at 1:25 PM, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Sat, 02 Jan 2010 11:53:28 +0100, Jiri Moskovcak wrote: the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this. Which YUM bug # is it? Could you provide a temporary workaround supplying something like (needs some testing): --disablerepo='*' --enablerepo='fedora*' --enablerepo='updates*' I think --skip-broken could apply also to inaccessible repositories; but that is offtopic here - for ABRT, this is a YUM issue. Well this yum issue is by design .. reporting it does not have much sense because Seth do not want to change/fix it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT considered painful
On Tue, Dec 29, 2009 at 7:56 PM, Michael Schwendt mschwe...@gmail.com wrote: What's wrong with ABRT? Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older. And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-( Also some duplicate detection wouldn't hurt ... (I get new bug reports everyday just to notice that almost all of them are duplicates). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 9:24 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jon Masters j...@redhat.com said: But again, Apples to Oranges. x86_64 (we should formally call it Intel 64, or similar, since I'm not aware of x86_64 having a formal blessing) Intel 64 has no formal blessing either (it is Intel's marketing name for their copy of AMD's instruction set). If you want to call it after a vendor, it should be AMD 64 anyway, since AMD created it. They called it x86-64 (which is where the x86_64 name came from), until marketing got in the way and they changed to AMD 64. Intel 64 is confusing anyway, since Intel has pushed multiple 64 bit architectures. Also there is the x64 marketing bullshit floating around -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 10:28 PM, Paul Jakma p...@dishone.st wrote: - I am incredulous at the people who keep arguing that x86-64 is better because it has PC-relative addressing, or because the ABI is pass-by-register by default. I am extremely sceptical that these respondents would be able to distinguish between a 32bit and a 64bit cp or nautilus or ls or gnome-panel or ... etc. It'd be interesting to see if this applied even to browsers. (E.g. Chrome on 32bit is extremely fast, hard to see that it'd get much faster on 64. Firefox is slow on 64bit too). Well while there was no x86_64 chromium build midori (which uses webkit) was faster in every JS while the whole web was praising google's V8 as the fastest JS engine ... Once the 64bit chromium come out, this was indeed the case. So a software that is supposed to be slower than another one was faster only because it was running an x86_64 version. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 10:54 PM, Paul Jakma p...@dishone.st wrote: On Tue, 15 Dec 2009, Paul Jakma wrote: I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. Ah, and to get the memory benefits, you need a generally-32bit userspace (32bit apps on x86-64 obviously works just fine, but there's no savings benefit when most of userspace is 64bit). Sorry again for the noise. :) There are shops that sells stuff called ram sticks ;) (sorry I will shut up already) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 7:33 PM, Paul Jakma p...@dishone.st wrote: On Wed, 18 Nov 2009, Jeff Garzik wrote: Running a 64-bit kernel with a 32-bit userland is a common practice on non-x86 platforms, and non-Linux OS's. FWIW, it works on Linux too. I ran F10 i386 on a x86_64 kernel for a while. About the only thing that doesn't work right is yum wrt kernel updates. For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit process address space. Both executable code and in-memory data structures tend to be smaller on 32-bit. Indeed. It would be nice if i386-userspace/x64-kernel were officially support.. such a setup does not make much sense, when your hardware supports x86_64 not using it for userspace is a waste -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 8:16 PM, Paul Jakma p...@dishone.st wrote: On Sun, 13 Dec 2009, drago01 wrote: such a setup does not make much sense, when your hardware supports x86_64 not using it for userspace is a waste a) i386 has a lower memory footprint, as has been mentioned in this thread. Yes which is pretty much the only valid complaint but trading memory for performance is a price I am willing to take ... b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 registers would make an appreciable difference is probably not that significant - kernel hotpots The kernel doesn't do any have computing... - graphics hotspots (X server perhaps) I havn't measured this, but nor have the people who say x86_64 is faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. Yes but the stuff adds up, you gain almost nothing by running i686 code but where it matters x86_64 can make a HUGE difference. c) There is a definite cost to a distro in having to maintain 2 x86_64 and i386 as separate arches Not a reason to move forward with hardware development. d) Like or not, i386 is the de-facto standard for binary interfaces: - Netscape plugins This is slowly being fixed. - Windows executables Nobody stops you from running i386 apps on a x86_64 system. - VM images to run in, say, QEMU/KVM - Sandboxing technologies for, say, browser plugins (I think Google have stuff in this area) - Free software windows-only apps (don't know if they exist) All the code here can be open-source/free-software and still be relying on i386 as a widely known and hence convenient /interface/. As such, it likely needs to be supported on x86_64 kernel-based systems anyway, as performantly as possible. (And yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying). Er.. don't quite get your point here, what is stopping me from running i686 VMs on a x86_64 host? I have been doing this for a while and there are there problems (you don't even need multilib for that) So personally I think x86_64-pure is unrealistic and, independently, I think 32-on-64 makes sense, but hey. :) I did not suggest using pure x86_64 but using x86_64 where we can (ie. not just the kernel). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 9:09 PM, drago01 drag...@gmail.com wrote: c) There is a definite cost to a distro in having to maintain 2 x86_64 and i386 as separate arches Not a reason to move forward with hardware development. reason to _not_ move ... Er.. don't quite get your point here, what is stopping me from running i686 VMs on a x86_64 host? I have been doing this for a while and there are there problems (you don't even need multilib for that) should read _zero_ problems. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd robinstar1...@gmail.com wrote: On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler kevin.kof...@chello.at wrote: Bill McGonigle wrote: Are you installing Fedora on the computer you're using now? [YES] [NO] YES - is any sort of check even possible if the user is running 32-bit on 64-bit? Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and using the 32-bit version is suboptimal. Kevin Kofler But wouldn't it be better to use 32 bit when less then 4 GB of ram is present? no, using x86_64 means more registers, sse2 as default floating point instruction set, better calling convention (register passing vs. stack) or in other words in most cases faster code. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
On Sun, Nov 29, 2009 at 3:58 PM, Paulo Cavalcanti pro...@gmail.com wrote: Hi, I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess. This is a feature, not a bug. But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ... This sounds like a bug (works for me though) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Thu, Nov 26, 2009 at 11:12 PM, Dave Airlie airl...@redhat.com wrote: Yes, some graphics boards I am sure work well, although 3D should really be working on all cards in 2009 ... But this is the point, there are a lot of different graphics boards, and so a much wider scope for the testing is required here which requires more users over more time with many different applications using basically the same software. Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point. GPUs have gotten more and more complex every 6 months for about 8 years now. A current radeonhd 4000 series bears little resemblence to the radeon r100 that was out then. The newer GPUs require a full complier to be written for an instruction set more complex than x86 in some places. The newer GPUs get more and more varied modesetting combos that all require supporting. Now I'd would guess (educated slightly) that the amount of code required to write a full driver stack for a modern GPU has probably gone up 40-50x what used to be required, whereas the number of open source community developers has probably doubled since 2001. Also newer GPU designs have forced us to redesign the Linux GPU architecture, this had to happen in parallel with all the other stuff, again with similiar number of developers. So yes it sucks but it should point out why there is no reason why 3D should really be working on all cards. Thats true but a driver that does not work with 3D can hardly be called a working driver. Sure GPUs are more complex nowdays and we have limited manpower but most of this complexity (which people pay for) is for 3D. 3D shouldn't be considered as nice to have but an essential feature that should be working. But yeah talking is easy, actually fixing this problem is harder. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Fri, Nov 27, 2009 at 11:52 AM, Felix Miata mrma...@earthlink.net wrote: On 2009/11/27 10:28 (GMT+0100) drago01 composed: 3D shouldn't be considered as nice to have but an essential feature that should be working. You can't be serious. 3D is an illusion. A computer display screen only provides two dimensions. 3D is bling that I have 0 use for. The fact that you don't need it does not make my statement invalid. And 3D is way more than useless bling. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Fri, Nov 27, 2009 at 11:29 PM, Felix Miata mrma...@earthlink.net wrote: On 2009/11/28 03:01 (GMT+0530) Rahul Sundaram composed: Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch. Good thing all puters don't depend on batteries for power. It does not matter how often people repeat that (and even if KDE has an option to disable composting to save power) just running a composite manager should NOT require any more power. If it does it is just broken. In fact it should use LESS power if done right (less wakeups because you don't have to update the whole screen every time something changes), Let me say this again a cm DOES NOT require more power than a non composited desktop. (notice the NOT) My laptop uses 6.9W-8W when running compiz, and about the same when running metacity (intel GM45). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Sun, Nov 22, 2009 at 10:51 AM, drago01 drag...@gmail.com wrote: On Sun, Nov 22, 2009 at 9:15 AM, Sir Gallantmon ngomp...@gmail.com wrote: On Sun, Nov 22, 2009 at 1:35 AM, Jonathan Dieter jdie...@gmail.com wrote: On Sun, 2009-11-22 at 00:52 -0500, Bill McGonigle wrote: On 11/21/2009 03:52 AM, Jonathan Dieter wrote: FWIW, there is a syslinux module named ifcpu64 that will load different kernels/initrds based on whether the cpu is 64-bit. Cool, do syslinux modules work in isolinux? We could have a tiny 32-bit image on a 64-bit CD that would say, sorry, you got the wrong CD. They should; it's all the same project. I think the the 64-bit kernel already gives a sane error message when you attempt to run it on a 32-bit machine. Jonathan I wonder... Why can't we have 32-bit Linux able to run 64-bit applications? Mac OS X can do it. 1) because it isn't possible 2) no it doesn't mac OS X use a 64bit hypervisor and run the rest inside it. An more importantly ... why should we want that? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
On Sun, Nov 22, 2009 at 7:21 PM, Martin Sourada martin.sour...@gmail.com wrote: So, since I've already received 3 separate bug reports caused by BadIDChoice X Error in subtitleeditor [1][2][3] (haven't had enough time to debug and try to fix it yet though) by abrt, I wonder if there is any room for duplicity detection improvement in these cases, or if we are doomed to zillions of duplicates in rhbz? (btw. otherwise abrt is awesome, IMHO the bugreports from abrt are much more useful than before :-) Yeah duplicate detection needs to improve, my inbox is flooded with bugreports, I didn't have time to debug them yet. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson awill...@redhat.com wrote: On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote: Hi folks, I also got bitten by the FC11 packages 'newer' than FC12 hickup, and while going through the yum remove/add maneuver I pondered: - is there ever a time when, while upgrading from Fedora n to Fedora n+1 I would expect a package .fcn to be kept instead of getting the .fcn+1 instance ? My answer was: no So I wondered if there would be a simple way to make this happen regardless of whether a maintainer blunders and gets things slightly out of sync between the 2 or 3 current Fedora releases. To me, this is the wrong fix. The problem here isn't RPM's version comparison logic, which is perfectly sound. Instead of nerfing up RPM comparisons, which are already full of enough hidden mines, we should just improve Fedora's package versioning conventions so this doesn't happen, or at least happens less often. We should just use release epochs, people might hate them for whatever reasons, but they would easily prevent such issues from happing. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, Nov 21, 2009 at 10:49 AM, Conrad Meyer ceme...@u.washington.edu wrote: On Saturday 21 November 2009 01:38:35 am drago01 wrote: We should just use release epochs, people might hate them for whatever reasons, but they would easily prevent such issues from happing. The problem with this system, which has been pointed out before, is that upgrades using the Fedora N release DVD on an up-to-date Fedora N-1 system will replace newer versions of packages with older ones -- this is bad. Bad .. a yum update after the upgrade will fix it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, Nov 21, 2009 at 12:00 PM, Michael Schwendt mschwe...@gmail.com wrote:
On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
We should just use release epochs, people might hate them for whatever
reasons, but they would easily prevent such issues from happing.
Vendor Epochs have been discussed years ago and have been rejected.
The normal %{epoch} in RPM Version Comparison is hidden and bad enough
already. We don't need another hidden super-Epoch that wins
version comparison even with that other %epoch.
You misunderstood me, I was not suggesting adding another epoch but
simply bump the %{epoch} for every release.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Thu, Nov 19, 2009 at 9:59 AM, Rudolf Kastl che...@gmail.com wrote: btw... you dont need to buy a netbook to get the performance benefits of an ssd. *writing that on f12 64bit on a lenovo x301 with ssd*, and no... ssds are not a step back but a leap ahead in many regards: power consumption, read performance, no seek times, close to no heat generation and no moveable parts (so no head crashes when you run around with the laptop.) - but that wasnt the real topic this thread was initially about. I know I never said that SSDs are netbook only, just because the diskspace is less than traditional HDs does not mean that they are a step back. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Thu, Nov 19, 2009 at 10:22 PM, Casey Dahlin cdah...@redhat.com wrote: On 11/19/2009 04:21 PM, Peter Jones wrote: On 11/19/2009 04:13 PM, Casey Dahlin wrote: On 11/18/2009 09:23 PM, King InuYasha wrote: On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not really affecting us much, most of us will replace our PCs long before then) I believe even 32-bit kernels now keep the time in a 64-bit integer. This shouldn't apply any more. Sure it does -- time_t in userland is 32-bit, and that's what applications are using, and what the system call interface supports. Problematic, but we do have 29 years to fix it :) Hah ... yeah because 32bit machines will be relevant by then... Can I complain that fedora does not work on my 29+ years old system right now (that I don't even have) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Thu, Nov 19, 2009 at 2:56 AM, Kevin Kofler kevin.kof...@chello.at wrote: King InuYasha wrote: In any case, 32-bit shouldn't be considered legacy until every type of computer sold is 64-bit. And the fact is, that isn't true. It already basically was before netbooks came and turned the clock back. :-( Netbooks are entirely 32-bit currently Yeah, they're a huge step backwards (and not just for 64-bit computing, but also for CPU speed, RAM, disk space (especially where SSDs are used instead of the traditional HDDs) If you ever used an SSD you wouldn't call it a step backwards, it is so much better than a traditional HD that I don't want a Laptop without one ever again. HDDs should be the ones of the past, but for that prices need to drop. Anyway offtopic here. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Mon, Nov 2, 2009 at 7:18 PM, Adam Jackson a...@redhat.com wrote: On Mon, 2009-11-02 at 18:16 +0100, Michal Schmidt wrote: Dne 2.11.2009 17:31, Kevin Kofler napsal: Ankur Sinha wrote: wodim is completely unmaintained since May 6th 2007, don't expect to see any fixes anytime soon as long as Redhat continues to distribute wodim instead of the original software. Can someone please clear this up? It's just the usual FUD from Jörg Schilling. Ignore it. The latest commit to cdrkit upstream was 3 weeks ago. Although you are technically right, the commits for the last two years have been boring cleanups, typo fixes and warning silencers. They don't seem to be fixing any actual bugs in CD/DVD burning. The last commit that did something which looks like a technical change was indeed on 2007-05-06 ( http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?rev=767sc=1 ). Look here for the log and read the commit messages: http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?op=logrev=0sc=0isdir=1 So wodim does not look like a well maintained project to me. That may be true, but since cdrecord is not shippable, it's a pretty vacuous truth. The solution is obviously to fix the bug and help revive upstream, or else host a development tree on fh if upstream stays idle. Or switch to libburn and friends. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel using LZMA compression
On Sat, Oct 31, 2009 at 2:24 PM, Ikem Krueger ikem.krue...@googlemail.com wrote: As I know, the kernel is compressed with bzip2 or gzip. How about using LZMA instead? Or is that already the case? There is such an option but it is currently disabled due to missing support in xen. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel using LZMA compression
On Sat, Oct 31, 2009 at 6:03 PM, Ikem Krueger ikem.krue...@googlemail.com wrote: As I know, the kernel is compressed with bzip2 or gzip. How about using LZMA instead? Or is that already the case? There is such an option but it is currently disabled due to missing support in xen. Thanks. But don't understand. What has LZMA todo with Xen? https://bugzilla.redhat.com/show_bug.cgi?id=515831 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Status of touchpad support in F12 for kdm?
On Mon, Oct 19, 2009 at 9:10 PM, mcloaked mike.cloa...@gmail.com wrote: Kevin Kofler kevin.kofler at chello.at writes: No, tapping is disabled by default distrowide, there's nothing KDM can or should do about this. This is an intentional decision by the upstream Synaptics driver developers. Most touchpads have dedicated buttons you can press, which are much harder to click accidentally than it is to trigger an unwanted tapping click. Kevin Kofler Given the recent long thread concerning upstream decisions about defaults in Thunderbird 3.0beta4 it seems to me that just because upstream makes a specific decision does not always mean that is the best decision. What happens when releasing a package in Fedora can be given a possible better decision than upstream at times - I wonder what others feel about the defaults in this case for touchpad behaviour? Well that does not quite work if the fedora maintainer is the upstream maintainer. He would either change both or none. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Status of touchpad support in F12 for kdm?
On Sun, Oct 18, 2009 at 12:20 PM, Kevin Kofler kevin.kof...@chello.at wrote: Mike Cloaked wrote: In F11 every laptop I installed had support for the touchpad under Gnome, but in order to have touchpad tap action at the greeter stage in kdm I need to put in place a suitable hal/fdi file. Is touchpad support in kdm going to be available by default in F12? No, tapping is disabled by default distrowide, there's nothing KDM can or should do about this. This is an intentional decision by the upstream Well it can enable it via input properties (configuration interface for xorg input drivers). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Sun, Oct 4, 2009 at 10:42 PM, Eric Springer erik...@gmail.com wrote: On Mon, Oct 5, 2009 at 5:05 AM, Adam Williamson awill...@redhat.com wrote: Quick follow-up on this issue: I heard that this part at least has been done, and it certainly seems to have done the trick. Delta rebuild speeds have increased approx ten-fold here, and are now faster than my (pretty quick) download speeds. Is it possible to do the rebuilds in parallel? I noticed that only one of my four cores was used. And that on smolt 63% of people have a dual-core or greater, so it could lead to massive speed-ups as well. xz is not threaded yet, I did some benchmark on my core i7 systems: http://193.200.113.196/apache2-default/res pbzip2 and pigz are threaded (compare them with bzip2 and gzip in the output to see what kind of speedup is possible). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dracut, or should booting a LiveCD touch the hard disk?
On Sun, Oct 4, 2009 at 11:44 PM, Warren Togami war...@togami.com wrote: LiveCD boot has liveimg in cmdline. We could automatically skip various parts of the bootup if parameter exists. I suppose there are no drawbacks to this? Well it makes stuff easier if you are booting to fix up your existing system, but this still shouldn't be the default behavior. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] x86_64 kernel running in i386 distribution
2009/9/13 Xose Vazquez Perez xose.vazq...@gmail.com: hi, would it be possible to adapt the i386 distribucion to run also the x86_64 kernel ? Why not just use a x86_64 userspace and kernel i.e x86_64 distro ? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On Fri, Oct 2, 2009 at 8:51 PM, Matej Cepl mc...@redhat.com wrote: - Bruno Wolff III br...@wolff.to wrote: Bugs can include RFEs as well as actual brokeness. I don't think that really buys you anything. And a bad maintainer could just file an RFE for an upgrade and refer to that bug when they provide the upgrade. Yes, of course, but I expect Fedora maintainers to be adults, so they would behave at least reasonably responsibly and not fluke rules we agree upon. Well but doesn't this defeats the purpose of most have a bug attached ? If we trust maintainers to apply common sense a hard policy should not be needed. Also if you are unhappy with a process you should at least try to fix it before drawing consequences like this (orphaning packages). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Mon, Sep 28, 2009 at 9:53 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2009-09-16 at 13:28 -0700, Toshio Kuratomi wrote: On 09/16/2009 08:59 AM, Jochen Schmitt wrote: Am 16.09.2009 17:47, schrieb Toshio Kuratomi: That still leaves open the question of why no one has asked rsync upstream to make their fork publicly available instead of hoarding it as a private, internal copy. I would ask, why the modification will not integrated in the 'official' Fedora zlib package? After this integration the fedora maintainer can forward the pach to the upsream author. And a short followup -- I've gone through the zlib-devel mailing list archives now. I was unable to find any request for the rsync patches to be merged into mainline zlib. The mailing list archives only go back to March 2002, so it could be that the request to merge came before that directly to one of the zlib authors. But if so, there's not a record of what problems, if any, there were with the patch. My follow-up on this: I'm pursuing two tracks. I've mailed zlib maintainers directly - they specifically ask for questions to be sent to a direct email address rather than the zlib-devel list - to ask what their position is on this, so we can get some clarity there. I will pass on what (if anything) I hear back from them. Secondly, where would be the appropriate place to propose accepting zsync with the internal zlib? Is that something I should bring to the packaging committee? fesco ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0pre?
On Sun, Sep 27, 2009 at 5:00 PM, mike cloaked mike.cloa...@gmail.com wrote: Is there any chance there will be a build of Thunderbird 3.0PRE in Koji soon? It would be nice to see a build for F11 and F12 as I believe there are significant fixes compared to 3.0beta 4 in the 3.0pre build. like? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0pre?
On Sun, Sep 27, 2009 at 5:21 PM, Michael Cronenworth m...@cchtml.com wrote: On 09/27/2009 10:15 AM, Mail Lists wrote: I do know that the 64 bit fedora beta 4 (there is no 64 bit mozilla.org as, last I read a while ago, they are not comfortable the code is 64 bit clean) had terrible problems from beta 4 (tho beta 3 was fine). I switched to 32 bit mozilla.org 3.0pre (on x64 install of f11) and the problems went away. The beta 4 (from updates-testing) started the indexing thing - and then it took 100% cpu and memory growth went to 3.5 GiB - after a period memory use fell to 200 MiB, cpu declined .. then it repeated this cycle several times .. i left this for 6 hours - eventually tb locked up and left a dirty screen image - stuck - cpu usage went to 0 for TB. I had to hand kill it. Installing the stock mozilla 386 build has no such problems. I suspect there is some 64 very unclean code underlying the problem. Tho it could be beta 4 versus pre as well Gee. Here I am messaging you on TB 3.0b4 on a x86_64 machine with TB 3.0b4 x86_64 from updates-testing. Your message was in a folder with 1367 other email messages. Indexing worked fine. I don't see any spikes in CPU or memory usage. No other bugs in b4 at the moment. It's the best version yet. You might want to delete your .thunderbird directory and try again. b4 is working fine for me to (x86_64) have not noticed any regressions compared to b3. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Thu, Sep 24, 2009 at 11:46 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Thu, 24 Sep 2009, Adam Williamson wrote: On Thu, 2009-09-24 at 17:21 -0400, Matthias Clasen wrote: On Thu, 2009-09-24 at 16:52 -0400, Josh Boyer wrote: or generally that you find our users to be unintelligent enough to work out how to get a piece of software onto their systems. I find that to be rather wrong, and I don't think you have to be the maintainer of yum to understand how to install something. There is a difference between saying someone is 'unintelligent' and not expecting them to figure out on their own that in order to solve their bandwidth problem they should install something called yum-presto. Right. The issue isn't whether people would be able to install the package, it's whether they'd be aware that they ought to be installing it in the first place. which is why, I thought, we have documentation. OK lets read up docs on how can I let updates not require that much bandwith ... well how many users think that way? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 10:51 AM, Michal Schmidt mschm...@redhat.com wrote: Dne Wed, 23 Sep 2009 07:04:23 +0300 Jonathan Dieter napsal(a): https://bugzilla.redhat.com/show_bug.cgi?id=524720 https://bugzilla.redhat.com/show_bug.cgi?id=524982 ... The second one has to do with the fact that when rebuilding the rpms, we have to recompress the data, and xz compression is over 10x slower than gzip. Do I understand it right that yum-presto compresses the data and then passes them to rpm which decompresses them back again? Why? Is it because it's currently the only way to verify checksums/signatures? We had a IRC discussion about this yesterday ... it is not yum-presto but delta rpm and it does not make sense at all. It should just create uncompressed rpms (assuming rpm can handle them which it should) ...according to Seth yum does not care whether the rpms are compressed or not. So yes the compression is a useless step here. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 4:20 PM, James Antill ja...@fedoraproject.org wrote: On Wed, 2009-09-23 at 15:22 +0300, Jonathan Dieter wrote: On Wed, 2009-09-23 at 10:49 +0200, drago01 wrote: On Wed, Sep 23, 2009 at 10:51 AM, Michal Schmidt mschm...@redhat.com wrote: Dne Wed, 23 Sep 2009 07:04:23 +0300 Jonathan Dieter napsal(a): https://bugzilla.redhat.com/show_bug.cgi?id=524720 https://bugzilla.redhat.com/show_bug.cgi?id=524982 ... The second one has to do with the fact that when rebuilding the rpms, we have to recompress the data, and xz compression is over 10x slower than gzip. Do I understand it right that yum-presto compresses the data and then passes them to rpm which decompresses them back again? Why? Is it because it's currently the only way to verify checksums/signatures? We had a IRC discussion about this yesterday ... it is not yum-presto but delta rpm and it does not make sense at all. It should just create uncompressed rpms (assuming rpm can handle them which it should) ...according to Seth yum does not care whether the rpms are compressed or not. So yes the compression is a useless step here. As I think may have been mentioned elsewhere, the *only* problem is that the rpm signatures must match and the signatures are over the *compressed* rpm. No, we have at least 3 problems I think: 1. Nobody wants to download uncompressed rpms, if they don't have presto. 2. gig signature is over the rpm data (and thus. is over compressed data). 3. createrepo sha256 data is over the entire rpm (and thus. is over compressed data). ...but to me this is all a _problem_in_xz_, not presto/deltarpms. If nobody can fix xz before F12 GA then IMNSO we should revert the compression to something that works ... the minor savings in xz compression isn't worth as much as delta's. Does not matter which compression algorithm we use creating a compressed rpm just to uncompressed it again shortly after that is a waste of cycles/power/time. As for the GPG signature ... can't the drpm itself be signed? So we would only need to check that, rather than the rebuilt rpm if we don't trust the files on the disk we already lost anyway (box is compromised). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 5:11 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 23 Sep 2009, drago01 wrote: Does not matter which compression algorithm we use creating a compressed rpm just to uncompressed it again shortly after that is a waste of cycles/power/time. As for the GPG signature ... can't the drpm itself be signed? We'd need to do that signing which would take, umm, forever. What? You mean at compose time? (Signing on the client side would not make much sense) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 5:14 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 23 Sep 2009, drago01 wrote: On Wed, Sep 23, 2009 at 5:11 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 23 Sep 2009, drago01 wrote: Does not matter which compression algorithm we use creating a compressed rpm just to uncompressed it again shortly after that is a waste of cycles/power/time. As for the GPG signature ... can't the drpm itself be signed? We'd need to do that signing which would take, umm, forever. What? You mean at compose time? (Signing on the client side would not make much sense) I mean on the server/repo side. The steps we'd need to do for a full release would be: 1. compose tree 2. sign pkgs in tree 3. make deltarpms of pkgs vs older tree 4. sign deltarpms 5. generate repository metadata that would take a long time. Yeah but if you take into account the time saved on x clients it would be worth it (assume x is very high). How long would the extra signing process take? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Thu, Sep 3, 2009 at 5:05 PM, Tom spot Callawaytcall...@redhat.com wrote: On 09/03/2009 10:57 AM, Hans de Goede wrote: It really is like having to support gentoo, versus having to support a distro using pre build packages. And I would really like to move to the having to support a pre-build package model for the initrd. The problem is this: The kernel binary RPM contains this pre-built initrd. The kernel source RPM does not contain the sources necessary to make this pre-built initrd. As long as we (fedora) ship the source code this shouldn't be an issue, or am I missing something? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Wed, Sep 2, 2009 at 7:04 PM, Colin Walterswalt...@verbum.org wrote: On Wed, Sep 2, 2009 at 4:38 PM, Matthias Clasenmcla...@redhat.com wrote: After talking to the abrt guys, I've changed the desktop spin ks to replace bug-buddy and kerneloops by abrt. This change should be made in comps (as per my original attached patch), not the kickstart. If we only change the kickstart then people doing automatic kickstarted desktop installs will get a divergent desktop which is not what we want. The obsoltes already handles the change for updates, so it makes sense to have new installs behave like systems upgraded to F12. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Fri, Aug 28, 2009 at 11:31 PM, Colin Walterswalt...@verbum.org wrote: Hi internets, I was looking at the current state of ABRT (I tested on F11). The core capturing seems to work well. In brief, I propose to apply the (attached) patch to comps-f12.xml.in. For upgrades, we'll need to add a Conflicts: bug-buddy, correct? No, you want Obsoletes: bug-buddy, so yum/anaconda will replace bug-buddy with abrt. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Sat, Aug 29, 2009 at 12:19 AM, Colin Walterswalt...@verbum.org wrote: On Fri, Aug 28, 2009 at 5:49 PM, drago01drag...@gmail.com wrote: On Fri, Aug 28, 2009 at 11:31 PM, Colin Walterswalt...@verbum.org wrote: Hi internets, I was looking at the current state of ABRT (I tested on F11). The core capturing seems to work well. In brief, I propose to apply the (attached) patch to comps-f12.xml.in. For upgrades, we'll need to add a Conflicts: bug-buddy, correct? No, you want Obsoletes: bug-buddy, so yum/anaconda will replace bug-buddy with abrt. Ok, thanks. Should then the current %package addon-kerneloops [...] Conflicts: kerneloops Also be changed to Obsoletes? Yes a conflict will just prevent it from getting installed when kerneloops is installed. (which is kinda useless and not what was intended here) Obsoleting a specific version would be even better: Obsoletes: kerneloops = lastestversion -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On Sat, Aug 29, 2009 at 12:26 AM, drago01drag...@gmail.com wrote: On Sat, Aug 29, 2009 at 12:19 AM, Colin Walterswalt...@verbum.org wrote: On Fri, Aug 28, 2009 at 5:49 PM, drago01drag...@gmail.com wrote: On Fri, Aug 28, 2009 at 11:31 PM, Colin Walterswalt...@verbum.org wrote: Hi internets, I was looking at the current state of ABRT (I tested on F11). The core capturing seems to work well. In brief, I propose to apply the (attached) patch to comps-f12.xml.in. For upgrades, we'll need to add a Conflicts: bug-buddy, correct? No, you want Obsoletes: bug-buddy, so yum/anaconda will replace bug-buddy with abrt. Ok, thanks. Should then the current %package addon-kerneloops [...] Conflicts: kerneloops Also be changed to Obsoletes? Yes a conflict will just prevent it from getting installed when kerneloops is installed. (which is kinda useless and not what was intended here) Obsoleting a specific version would be even better: Obsoletes: kerneloops = lastestversion But do we even want to drop kerneloops from the distro? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Sun, Aug 23, 2009 at 9:35 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 08/23/2009 10:50 AM, Rahul Sundaram wrote: Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. For the front-end to be end user suitable it should: * List applications rather than packages * Group them * Provide some kind of rating system to show best rated or most downloaded * Use the application icon if it has one * Make use of the packagekit browser plugin for installation But just letting the user search for random packages should not be the goal imho. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 4:31 PM, Matthias Clasenmcla...@redhat.com wrote: On Mon, 2009-08-24 at 14:36 +0200, drago01 wrote: On Sun, Aug 23, 2009 at 9:35 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 08/23/2009 10:50 AM, Rahul Sundaram wrote: Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. For the front-end to be end user suitable it should: * List applications rather than packages * Group them * Provide some kind of rating system to show best rated or most downloaded * Use the application icon if it has one * Make use of the packagekit browser plugin for installation But just letting the user search for random packages should not be the goal imho. Very good points. I very much agree that a list of applications is what we want here. Fedora Community is not really filling that niche, since is very much focused on the 'project' aspect of Fedora. In fact, I have been toying with the idea to make a 'Cool applications for Fedora' style page, using the PackageKit browser plugin. A very crude test of the idea can be seen here: http://people.redhat.com/mclasen/Screenshot-Applications%20for% 20Fedora.png Yeah looks good but I would rather not show screenshots in this view (or atleast not different sized ones). A short description + icon should be enough. Have a show more link that contains a longer description + screenshots and a Install Now link. Pretty much like it is done in Apples Appstore This obviously needs the helping hand of a web designer. For F12, this would probably be not much more than a static web page. Static? Doesn't scale (unless you would want to do it just for specific apps) Rating and similar ideas described in http://www.fedoraproject.org/wiki/Features/ApplicationInstaller will come later. mockup links are dead. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 7:26 PM, Matthias Clasenmcla...@redhat.com wrote: [..] Static? Doesn't scale (unless you would want to do it just for specific apps) My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... Yeah but where does this top 10 come from? Wouldn't that end up list stuff that is installed by default anyway (+/- Oo.org ) ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Mon, Aug 24, 2009 at 7:36 PM, Adam Williamsonawill...@redhat.com wrote: On Sat, 2009-08-22 at 12:04 -0700, Arjan van de Ven wrote: The Moblin OS uses Connman for everything networking. This is a different architecture than what Fedora does, where Fedora has /etc/sysconfig and other scripts that do part of the work etc. At first this looks like a minor change, but it's kinda fundamental. AIUI this isn't an entirely accurate characterization. When NetworkManager is in use on Fedora it takes over entirely; it ignores the settings in /etc/sysconfig/network-profiles and so forth, it uses its own configuration data only. For F12 it's growing a feature where it will 'assume' connections handled by the old-style scripts that are active when it starts up, and pass them off again when it shuts down, but still, while it's running, it is in charge of everything networking, as you describe for Connman. The difference is just that, on Fedora, you have the option of _not_ running NetworkManager at all, instead using the older system, if you choose. Others correct me if I'm wrong, but I think this is the case :) You are wrong ;) NM does use so called system settings which are pretty much the legacy ifup scripts. It has its own keyfile based backend for this but currently we use the old format trough the redhat/fedora plugin. So when you create a connection by system-config-network nm would use it unless you remove the nm controlled bit. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Plan for tomorrow's (20090821) FESCo meeting
On Fri, Aug 21, 2009 at 3:57 PM, Adam Jacksona...@redhat.com wrote: On Fri, 2009-08-21 at 15:39 +0200, Jochen Schmitt wrote: On Thu, 20 Aug 2009 22:10:59 -0400, you wrote: 238 Can libvdpau go in Fedora? As far I understand this package itself is open source but has a dependency to the properitary nVidia video driver which is provides by rpmfusion.org. For this reason I vote agains the inclusion of this package into Fedora because I introduce a requirement reference to a third-party repository. I think there's precedents for accepting it for Fedora: - libXNVCtrl, another X extension library that happens to only do anything when the user is running the nvidia binary driver, but which is itself MIT-licensed. - gstreamer-plugins-flumpegdemux, which allows you to separate the audio and video streams from MPEG files, even though the decoding itself is off-limits for Fedora It happens that only nvidia implements VDPAU at the moment, but so what? Any other vendor could too. Well S3 does, but there driver isn't open either. But it proves that non nvidia implementations are possible. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Plan for tomorrow's (20090821) FESCo meeting
On Fri, Aug 21, 2009 at 5:54 PM, Adam Williamsonawill...@redhat.com wrote: On Fri, 2009-08-21 at 16:51 +0200, drago01 wrote: Well S3 does, but there driver isn't open either. But it proves that non nvidia implementations are possible. S3's driver implements VAAPI, not VDPAU. I already have a package review for libva submitted (mentioned it yesterday). http://drivers.s3graphics.com/en/download/drivers/chrome5x-Linux/RN_Linux_EN.txt hmm? I have not tested it due to lack of hardware but it says: 06/26/2009: Version 14.02.17 - Bug Fixes - XRandR support - VDPAU support - KMS Support SUPPORTED FEATURES - H/W accelerated 2D (XAA/EXA) - H/W accelerated direct-rendering OpenG3.0 - H/W accelerated H.264/MPEG2/WMV-9/VC-1 video playback. - SAMM / Rotation / Xinerama / Compiz - XRandR support - VDPAU support - KMS Support And there are a lot of VDPAU references in the bug fixed list. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies in Fedora 11 - 2009-08-20
On Fri, Aug 21, 2009 at 8:13 PM, Kevin Koflerkevin.kof...@chello.at wrote: drago01 wrote: Sorry but the fail here is 100% on bodhi's side , why does a single package obsolete a complete group update? That is just broken, and this example clearly showed it. It's broken (we've had some fun with that with the KDE grouped updates too, we learned to be careful about what we push when), but a maintainer should know how to use our tools, which includes being aware of their limitations. Double-checking things both before and after filing an update (e.g. checking https://admin.fedoraproject.org/updates/thepackageyoureabouttopushanupdatefor before filing the new update request) definitely can't hurt (I always do that), and it will help avoiding issues you don't even know about, or at least catching them earlier than 2 months after the fact (as happened here). Sure if you know about a bug/limitation you can try to avoid it, but as Josh said you can't expect that every maintainer knows about all (undocumented) bugs/limitations. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto plugin by default
On Tue, Aug 18, 2009 at 11:47 PM, Jeff Spaletajspal...@gmail.com wrote: On Tue, Aug 18, 2009 at 1:40 PM, Christopher Brownsnecklif...@gmail.com wrote: FWIW, I have also experienced zero problems with it and believe it would be better enabled by default, retaining the option to disable. Updates would get done faster and mirrors would be able to cope with more connections, especially in the first push after release day... :) Only potential side effect is cpu consumption that the delta unpacking process requires. User on single core systems may notice that unless presto renices itself down in priority. Most users are using packagekit so the update process is reniced to 10 and the io prio is set to idle. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Empathy default in F12?
On Sun, Aug 16, 2009 at 9:40 AM, Rahul Sundaramsunda...@fedoraproject.org wrote: On 08/16/2009 01:05 PM, Gregory Maxwell wrote: The F12 feature still indicates the switch to Empathy as a default IM client in Fedora. However, the talk page for the feature (https://fedoraproject.org/wiki/Talk:Features/Empathy) raises material concerns that the switch to Empathy would result in an insufficiently justified loss of functionality. Where does this currently stand? My understanding is that Empathy is still planned to be the default. What specific concerns do you have? File transfer support is missing for almost all protocols. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switch from OpenAL to OpenAL-Soft
On Tue, Aug 11, 2009 at 1:08 AM, LinuxDonaldlinuxdon...@linuxdonald.de wrote: I have add the openal-soft package into fedora 12 that will replace openal. At all packager when you have openal as dependency please change it to openal-soft and recompile your package for f-12 please Any reason why you decided to do this after the freeze? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Sun, Aug 9, 2009 at 9:11 PM, Adam Williamsonawill...@redhat.com wrote: On Sun, 2009-08-09 at 19:51 +0200, Ralf Ertzinger wrote: Hi. On Sun, 09 Aug 2009 00:13:40 -0700, Adam Williamson wrote Indirectly, probably yes. There's a workaround for that known problem posted on rawhidewatch - restart notification-applet (or whatever the exact name is) until you get the icons instead of the boxes (can take over 20 tries, for me at least). That's https://bugzilla.redhat.com/show_bug.cgi?id=510249, right? It currently blocks F12, shouldn't it block the aplha, too? No, we wouldn't consider it blocking the Alpha per the criteria (we consider only bugs that break the critical path - booting into X, getting a network connection and updating the system - as blockers for the Alpha, pretty much). + installing the system -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 9:12 AM, Adam Williamsonawill...@redhat.com wrote: On Wed, 2009-08-05 at 23:50 -0700, Markus Kesaromous wrote: I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) I don't think anything special is done to make it part of our kernel .src.rpm, it's just in there because it's in the upstream kernel tarball :). I don't _think_ any of the Fedora kernel devs will jump to fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based card and it'd be nice not to have to rely on an out-of-tree, not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or one of the main committers directly, though. Actually, now I look at it, it appears the driver is developed as part of the serialmonkey project: http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which has links in the blue bar at the top for 'lists' and 'forum'. Those sound like good places to poke. The rt2860 driver is the Vendor driver provided by Ralink, it is considered crap by linux-wireless developers (for good reasons). Upstream work is being done on rt2800pci / rt2800usb the usb driver is supposed to be in a working state right now, the pci one could need some help (its not there yet). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbiloget.fed...@gmail.com wrote: On Thu, Aug 6, 2009 at 4:23 AM, Peter Robinson wrote: I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) I don't think anything special is done to make it part of our kernel .src.rpm, it's just in there because it's in the upstream kernel tarball :). I don't _think_ any of the Fedora kernel devs will jump to fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based card and it'd be nice not to have to rely on an out-of-tree, not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or one of the main committers directly, though. Actually, now I look at it, it appears the driver is developed as part of the serialmonkey project: http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which has links in the blue bar at the top for 'lists' and 'forum'. Those sound like good places to poke. Good luck with that! This driver has been in the process of being re-written for well over a year, I've long given up hope. Its unfortunate as its in alot of netbooks including all the atom based eeePCs. Fortunately rpmfusion has one that works reasonably well (it even suspends and resumes!) appart from spewing massive amount of debug into /var/log/messages (if left on about half a gig a day). Peter I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 11:14 AM, Orcan Ogetbiloget.fed...@gmail.com wrote: On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote: On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote: I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) From my understanding, the staging tree of the kernel contains drivers that are being prepared to be included in the main kernel tree[1]. Correct me if I'm wrong. I'm not quite sure if I could catch what you meant. Are you being sarcastic, implying that the rt2xxx staging drivers will stay in the staging repo forever? I sure hope not :) Hey! Don't break my hopes! The rt vendor drivers are considered a dead end by the linux-wireless developers (just try to read the code and you would now why), the plan is to get rt2800pci and rt2800usb into shape and get them upstreamed. They get no support from the wireless developers at all, Greg added them to staging because they are better than no drivers. See the linux-wireless list for details. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, Aug 6, 2009 at 11:56 AM, Kevin Koflerkevin.kof...@chello.at wrote: Christopher Aillon wrote: Sure, you can blame Gecko for having it's unstable ABI be, well, unstable. But blame also goes to the apps for not using the stable ABI. Why does Mozilla expect apps to use an ABI: * which didn't exist when the apps were written and * which they aren't even using for their own apps? Everyone complains about M$ using internal W32 APIs in IE, who does that? why does Mozilla do the same with internal xulrunner APIs? If you think everyone should use the stable ABI, why is Firefox not using it? I don't see whats wrong with providing a an ABI that you can/want to support (i.e no ABI breaks for minor updates) and one for your internal use (i.e you know when it breaks and therefore fix your own app). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, Aug 6, 2009 at 1:33 PM, Ralf Corsepiusrc040...@freenet.de wrote: On 08/06/2009 10:55 AM, Rahul Sundaram wrote: On 08/06/2009 02:14 PM, Ralf Corsepius wrote: IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Be specific. This is not enough information to influence the decision at this stage. OK, more verbose: * In their present shape the packages are non-functional. According to the submitter, this is due to lack of upstream vs. Fedora integration. * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. Can you be more verbose on that one? Instead of hand waving its low quality -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, Aug 5, 2009 at 12:23 PM, Thorsten Leemhuisfed...@leemhuis.info wrote: Further: The behavior changes to much IMHO -- one reason why I use Fedora at home and work and suggested it to others were the major new kernel versions that got delivered as regular update. But that doesn't really work anymore since half a year or something: F-10 is still on 2.6.27, 2.6.29 sits in Updates-testing for ages; 2.6.30 is out for weeks, but no sign of a update for F-11 apart for a few commits in CVS. :-( If I got this correctly the main reason are the out of tree drm patches (modestetting) needs to be ported, just rebasing to newer upstream bits does not always work because it would require updated X drivers. So it ended up like the old xen days (delays due to back/forwardporting effort). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, Aug 5, 2009 at 10:18 PM, Tom spot Callawaytcall...@redhat.com wrote: On 08/05/2009 04:11 PM, Adam Williamson wrote: The question is whether Fedora intends to be a distribution suitable for day-to-day general purpose use by people who are not necessarily that interested in Fedora per se - whether it's got an aim to be a general-purpose operating system like other distributions do - or not. That's the only framework in which you can sensibly answer whether we want a stable update set or not, to my mind. What does a stable update set mean? Does it mean updates which don't break ABI/API? Does it mean backporting patches and not permitting new versions as updates? I seriously doubt that anyone is pushing updates simply to push them in the current Fedora model. Maintainers are pushing updates because they feel there is a reason, a bug fixed, a security hole closed, a significant feature enhancement that users want (or that they think users want). Without a finer definition here, it's all just hand-waving. The whole thing is useless, maintainers should decide whether the risk of pushing foo-x.y.z is worth the gain or not. Threads like this are IMHO useless why can't you update bar, foo has been updated to foo+1 ... well each maintainer has a reason why he does a update or not, while asking for the reasons is not wrong demanding a policy (bureaucracy) on when to update what an for which reasons will as Josh already said just piss people off. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
On Sun, Aug 2, 2009 at 9:13 PM, Ville Skyttäville.sky...@iki.fi wrote: On Thursday 30 July 2009, Ville Skyttä wrote: On Thursday 30 July 2009, Jesse Keating wrote: http://jkeating.fedorapeople.org/failed-f12-rebuilds.html scop (1): perltidy BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information DEBUG util.py:256: http://kojipkgs.fedoraproject.org/packages/gcc/4.4.1/3/i686/gcc-4.4.1-3.i68 6.rpm: [Errno 4] Socket Error: timed out DEBUG util.py:256: Trying other mirror. DEBUG util.py:256: Error Downloading Packages: DEBUG util.py:256: gcc-4.4.1-3.i686: failed to retrieve gcc/4.4.1/3/i686/gcc-4.4.1-3.i686.rpm from build DEBUG util.py:256: error was [Errno 4] Socket Error: timed out Resubmitting the job should be ok, but I don't see that button in koji for this job, could you do it? rel-eng: ping? Am I supposed to do something about this? I haven't seen any instructions regarding this and as said, it doesn't seem to be possible for me to just resubmit this build in koji (no resubmit link shown for me). Well you can just do a checkout and make build (done that for you http://koji.fedoraproject.org/koji/taskinfo?taskID=1574035 ) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
On Thu, Jul 30, 2009 at 1:40 AM, Jesse Keatingjkeat...@redhat.com wrote: I've now generated the first of the mass rebuild status pages. http://jkeating.fedorapeople.org/needed-f12-rebuilds.html http://jkeating.fedorapeople.org/failed-f12-rebuilds.html I will try to keep these updated multiple times a day. In the case of the needed rebuilds file we're working on a version that takes secondary arch into account. drago01 (1): dbus-c++ - /usr/bin/install -c -m 644 ../include/dbus-c++/dbus.h ../include/dbus-c++/types.h ../include/dbus-c++/connection.h ../include/dbus-c++/property.h ../include/dbus-c++/debug.h ../include/dbus-c++/error.h ../include/dbus-c++/interface.h ../include/dbus-c++/message.h ../include/dbus-c++/dispatcher.h ../include/dbus-c++/object.h ../include/dbus-c++/pendingcall.h ../include/dbus-c++/server.h ../include/dbus-c++/debug.h ../include/dbus-c++/util.h ../include/dbus-c++/refptr_impl.h ../include/dbus-c++/introspection.h ../include/dbus-c++/api.h ../include/dbus-c++/eventloop.h ../include/dbus-c++/eventloop-integration.h ../include/dbus-c++/glib-integration.h '/builddir/build/BUILDROOT/dbus-c++-0.5.0-0.9.20090203git13281b3.fc12.x86_64/usr/include/dbus-c++-1/dbus-c++/' /usr/bin/install: will not overwrite just-created `/builddir/build/BUILDROOT/dbus-c++-0.5.0-0.9.20090203git13281b3.fc12.x86_64/usr/include/dbus-c++-1/dbus-c++/debug.h' with `../include/dbus-c++/debug.h' make[2]: *** [install-lib_includeHEADERS] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/dbus-c++/src' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/dbus-c++/src' make: *** [install-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.UHUMwZ (%install) --- err.. wtf? The package did not change at all since the last mass rebuild, thanks autotools -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
On Fri, Jul 31, 2009 at 10:35 AM, Caolán McNamaracaol...@redhat.com wrote: On Fri, 2009-07-31 at 10:16 +0200, drago01 wrote: '/builddir/build/BUILDROOT/dbus-c++-0.5.0-0.9.20090203git13281b3.fc12.x86_64/usr/include/dbus-c++-1/dbus-c++/' /usr/bin/install: will not overwrite just-created `/builddir/build/BUILDROOT/dbus-c++-0.5.0-0.9.20090203git13281b3.fc12.x86_64/usr/include/dbus-c++-1/dbus-c++/debug.h' with `../include/dbus-c++/debug.h' The Makefile[.am] there has that header file listed twice, i.e. $(HEADER_DIR)/debug.h \ ... $(HEADER_DIR)/debug.h \ so just remove one of them and you'll be good to go. good catch, thanks. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
[..] 17:45:48 Kevin_Kofler As for killing multilibs, a proposal for next week: restrict multilibs to wine, redhat-lsb and their dependencies. Rationale: way too much stuff which will never be needed multilib is multilib. The people who really need that stuff should just use the i?86 repo and deal with the conflicts. 17:46:08 nirik Kevin_Kofler: write up a proposal. ;) Sure making the life harder for our users just deal with conflicts is the way to go... If there are issues with multilib (there are!) we should work on fixing them instead of making the user experience even worse. (if you want a pure 64 bit system that is what you get by _DEFAULT_ anyway, so no flamewars about that please.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Tue, Jul 28, 2009 at 8:32 PM, Ben Boeckelmaths...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Poettering wrote: Please note that it is our intention not to wrap obsolete mixer controls such as CD, PC Speaker, MIDI and so on. If you file a bug asking for those to be wrapped we will disappoint you and close the bug WONTFIX. Curious: would patches be accepted if someone else did it or is there just no support at all? as this would violate the design choices made I doubt such patches would be accepted. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/26/2009 09:28 PM, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? Well, to some extend, I am blaming it, because a) filling '/' may easily kill a system and may easily cause further damage (processes running in parallel to preupgrade might be malfunctioning due lack of diskspace). b) I expect an installer to be able to check whether sufficient space is available in advance, rsp. not to leave a system in an unusable state in case of something going wrong. In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183 I questioned whether using /var/cache/yum is a good choice for preupgrade's package cache. Though I meanwhile know that this BZ is was a side-effect of the nfs-parser bugs in anaconda, I still think using /root or /tmp would be better choices. No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). /root is not supposed to be used by random apps. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 1:38 PM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/27/2009 11:25 AM, drago01 wrote: On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/26/2009 09:28 PM, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? Well, to some extend, I am blaming it, because a) filling '/' may easily kill a system and may easily cause further damage (processes running in parallel to preupgrade might be malfunctioning due lack of diskspace). b) I expect an installer to be able to check whether sufficient space is available in advance, rsp. not to leave a system in an unusable state in case of something going wrong. In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183 I questioned whether using /var/cache/yum is a good choice for preupgrade's package cache. Though I meanwhile know that this BZ is was a side-effect of the nfs-parser bugs in anaconda, I still think using /root or /tmp would be better choices. No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). Your problem, if you are using a non-reboot persistant /tmp What kind of argument is that? Your problem for not using a big enough /var partition ;) I don't care about the stuff in /tmp across reboots, and this has been no issue for now. Well the best way to solve this is default to /var/cache/yum but make it configureable for people that insists on another location. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 3:14 PM, Ralf Ertzingerfed...@camperquake.de wrote: Hi. On Mon, 27 Jul 2009 13:38:09 +0200, Ralf Corsepius wrote: No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). Your problem, if you are using a non-reboot persistant /tmp I'd think that something that depends on files in /tmp surviving a reboot is definitely broken. There's a reason it's called 'tmp'. Exactly. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Sun, Jul 26, 2009 at 8:34 AM, Ralf Corsepiusrc040...@freenet.de wrote: It may be news to you, but a single negative result invalidates a whole series of positive tests ;) No, that means that they are bugs / problems but not that the feature is broken in general. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
Well I upgraded two systems from F10 to F11 using anaconda (booted the DVD), run a yum update after that and it works just fine. One of this systems have been running Fedora since FC4 and got updated to F/FC N+1 using the same method and still works. (FC4-FC5-FC6-F7-F8-F9-F10-F11) Seems like your problem is that anaconda for some reasons crash on your system, but with the infos you provided we can only speculate what happened. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 12:01 AM, Rahul Sundaramsunda...@fedoraproject.org wrote: On 07/18/2009 03:11 AM, drago01 wrote: On Fri, Jul 17, 2009 at 11:19 PM, Rahul Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? You don't have to push _every_ upstream release as an update. Was I not clear? In my case, I do often have to. They fix important bugs. Sure but lets say upstream releases every week and you rebase every second week, whats wrong with that? Unless they are really critical bugs (dataloss / security). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
On Thu, Jul 16, 2009 at 10:11 PM, John Poelstrapoels...@redhat.com wrote: Hi FESCo, https://fedoraproject.org/wiki/Features/XZRpmPayloads https://fedoraproject.org/wiki/Features/F12X86Support Afaik those are blocking on 1) xz review request 2) rel-eng to coordinate a mass rebuild -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: beagle
On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 07/14/2009 04:16 AM, Michael Schwendt wrote: On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: * Delivery to the following recipient failed permanently: beagle-owner AT fedoraproject DOT org Recipient address rejected: User unknown in local recipient table (state 14). * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a dozen people on watchcommit+commit, but no package owner. It's an orphan. * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a dozen open tickets, but nobody is subscribed to watchbugzilla. * yum list beagle shows beagle-0.3.9-6.fc11 in fedora. There is still no beagle-owner for this package. So, it looks like the desktop team isn't interested in picking up beagle (and they're most of the people in the commit/watchcommit) for the package. If no one else is willing to take ownership, I think we should block the package for rawhide and list it as retired for not having someone interested in working on it. It does not even build on rawhide right now (epiphany related breakage). I dropped it due to lack of time (which is worse rather than better now) but nobody responded to my mail where I was searching for a new maintainer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: beagle
On Tue, Jul 14, 2009 at 6:09 PM, Juan Rodrigueznus...@fedoraproject.org wrote: On Tue, Jul 14, 2009 at 11:07 AM, drago01 drag...@gmail.com wrote: On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 07/14/2009 04:16 AM, Michael Schwendt wrote: On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: * Delivery to the following recipient failed permanently: beagle-owner AT fedoraproject DOT org Recipient address rejected: User unknown in local recipient table (state 14). * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a dozen people on watchcommit+commit, but no package owner. It's an orphan. * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a dozen open tickets, but nobody is subscribed to watchbugzilla. * yum list beagle shows beagle-0.3.9-6.fc11 in fedora. There is still no beagle-owner for this package. So, it looks like the desktop team isn't interested in picking up beagle (and they're most of the people in the commit/watchcommit) for the package. If no one else is willing to take ownership, I think we should block the package for rawhide and list it as retired for not having someone interested in working on it. It does not even build on rawhide right now (epiphany related breakage). I dropped it due to lack of time (which is worse rather than better now) but nobody responded to my mail where I was searching for a new maintainer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list As a beagle user, I'd like to help co-maintain it (Or maintain it if noone else is interested), What would I have to do? Are you already sponsored? If yes just take it in pkgdb (it is already orphaned) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On Sun, Jul 12, 2009 at 4:35 AM, Davidbrusefamel...@gmail.com wrote: On 7/11/2009 9:35 PM, Jesse Keating wrote: On Jul 11, 2009, at 17:03, David brusefamel...@gmail.com wrote: On 7/11/2009 6:17 PM, Kevin Kofler wrote: Frank Murphy wrote: Doesn't seem to work for wine :) That's because WINE is only 32-bit, because most Winblow$ executables are. Kevin Kofler Winblow$? You really should learn some control here. The 'real guys'. The developers, code writers, people-in-the-know, show respect where respect is warranted. Microsoft should recieve that respect IMO. 90% of the desktop computers in the world use some version of Windows. More desktop computers use some form of Mac OS than all combined versions (distributions) of Linux. WINE? Is a nice concept. But it will never, again IMO, as long as the 'Windows programs' that WINE can run are mostly really old DOS programs. Sheesh. -- Perhaps you should do a little research before you spout off. Wine is capable of running very modern day applications that are written for the windows platform. It is anything but old dos programs. Mr. Keating. May I call you Jessie? I know who you are and I respect you a lot. Would you please name some very modern day applications that are written for the windows platform that will run in a Linux current version of WINE? That will run under the currently available WINE in Fedora 11. Names and versions. _Real_ applications. The ones that ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. I am serious here. Really. The names are...? Adobe Photoshop, Microsoft Office, Microsoft Visio, Quicken, Lotus Notes and games like WoW, CoD, Halflife, Counter Strike + many more. Sure they are all old DOS programs that nobody uses -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On Sun, Jul 12, 2009 at 11:17 AM, drago01drag...@gmail.com wrote: On Sun, Jul 12, 2009 at 4:35 AM, Davidbrusefamel...@gmail.com wrote: On 7/11/2009 9:35 PM, Jesse Keating wrote: On Jul 11, 2009, at 17:03, David brusefamel...@gmail.com wrote: On 7/11/2009 6:17 PM, Kevin Kofler wrote: Frank Murphy wrote: Doesn't seem to work for wine :) That's because WINE is only 32-bit, because most Winblow$ executables are. Kevin Kofler Winblow$? You really should learn some control here. The 'real guys'. The developers, code writers, people-in-the-know, show respect where respect is warranted. Microsoft should recieve that respect IMO. 90% of the desktop computers in the world use some version of Windows. More desktop computers use some form of Mac OS than all combined versions (distributions) of Linux. WINE? Is a nice concept. But it will never, again IMO, as long as the 'Windows programs' that WINE can run are mostly really old DOS programs. Sheesh. -- Perhaps you should do a little research before you spout off. Wine is capable of running very modern day applications that are written for the windows platform. It is anything but old dos programs. Mr. Keating. May I call you Jessie? I know who you are and I respect you a lot. Would you please name some very modern day applications that are written for the windows platform that will run in a Linux current version of WINE? That will run under the currently available WINE in Fedora 11. Names and versions. _Real_ applications. The ones that ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. I am serious here. Really. The names are...? Adobe Photoshop, Microsoft Office, Microsoft Visio, Quicken, Lotus Notes and games like WoW, CoD, Halflife, Counter Strike + many more. Sure they are all old DOS programs that nobody uses Forgot to add wine does not even support DOS programs (you can use dosbox for them) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 10:50 AM, Ahmad Al-Yamanahmad221...@yahoo.com wrote:
I was able to find out the messages that are displayed before plymouth
starts, but I still have no idea what's causing them:
[ INFO: possible circular locking dependency detected ]
2.6.29.5-191.eeepc.fc11.i686.PAE #1
---
plymouthd/746 is trying to acquire lock:
(fb_info-lock){--..}, at: [c05288bc] fb_mmap+0x83/0x153
but task is already holding lock:
(mm-mmap_sem){}, at: [c0406a3c] sys_mmap2+0x44/0x7b
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #3 (mm-mmap_sem){}:
[c04463fa] __lock_acquire+0x1068/0x137e
[c044676e] lock_acquire+0x5e/0x7a
[c046ddb4] might_fault+0x68/0x88
[c0510de3] copy_to_user+0x2f/0x106
[c0489920] filldir+0x80/0xbb
[c04b8a3d] sysfs_readdir+0x104/0x138
[c0489a99] vfs_readdir+0x68/0x94
[c0489bd2] sys_getdents+0x60/0xa4
[c0403202] syscall_call+0x7/0xb
[] 0x
- #2 (sysfs_mutex){--..}:
[c04463fa] __lock_acquire+0x1068/0x137e
[c044676e] lock_acquire+0x5e/0x7a
[c07c919f] mutex_lock_nested+0xe0/0x267
[c04b8cf4] sysfs_addrm_start+0x23/0x95
[c04b919d] create_dir+0x3a/0x76
[c04b9206] sysfs_create_dir+0x2d/0x3d
[c050c198] kobject_add_internal+0xaa/0x159
[c050c2ee] kobject_add_varg+0x31/0x3d
[c050c364] kobject_add+0x43/0x49
[c05ad349] device_add+0x79/0x3fb
[c05ad6dd] device_register+0x12/0x15
[c05ad757] device_create_vargs+0x77/0xa0
[c05ad79b] device_create+0x1b/0x1d
[c056f49e] register_con_driver+0xdd/0x137
[c0570637] take_over_console+0x14/0x35
[c0532c59] fbcon_takeover+0x5f/0x92
[c053336f] fbcon_event_notify+0x3b7/0x726
[c043ab5c] notifier_call_chain+0x51/0x78
[c043ad1d] __blocking_notifier_call_chain+0x37/0x4c
[c043ad3e] blocking_notifier_call_chain+0xc/0xe
[c05283fd] fb_notifier_call_chain+0x11/0x13
[c0529198] register_framebuffer+0x1e2/0x1f3
[c05a01b6] intelfb_probe+0x491/0x4fb
[c0586cc5] drm_helper_initial_config+0x148/0x152
[c05902b5] i915_driver_load+0x8b2/0x912
[c057fb7b] drm_get_dev+0x343/0x405
[c07b6741] i915_pci_probe+0xd/0xf
[c051aee2] local_pci_probe+0xe/0x10
[c051b84d] pci_device_probe+0x46/0x69
[c05aedd5] driver_probe_device+0xa2/0x11d
[c05aee9c] __driver_attach+0x4c/0x6b
[c05ae7f1] bus_for_each_dev+0x3b/0x63
[c05aec76] driver_attach+0x14/0x16
[c05ae28c] bus_add_driver+0x98/0x1ab
[c05af033] driver_register+0x6f/0xd3
[c051bb3d] __pci_register_driver+0x46/0xa5
[c057c3f4] drm_init+0x5b/0xb3
[c0a39544] i915_init+0x46/0x48
[c0401132] _stext+0x4a/0x111
[c0a1e386] kernel_init+0x17f/0x1d0
[c0403a37] kernel_thread_helper+0x7/0x10
[] 0x
- #1 ((fb_notifier_list).rwsem){..--}:
[c04463fa] __lock_acquire+0x1068/0x137e
[c044676e] lock_acquire+0x5e/0x7a
[c07c98db] down_read+0x2a/0x3e
[c043ad0a] __blocking_notifier_call_chain+0x24/0x4c
[c043ad3e] blocking_notifier_call_chain+0xc/0xe
[c05283fd] fb_notifier_call_chain+0x11/0x13
[c0529198] register_framebuffer+0x1e2/0x1f3
[c05a01b6] intelfb_probe+0x491/0x4fb
[c0586cc5] drm_helper_initial_config+0x148/0x152
[c05902b5] i915_driver_load+0x8b2/0x912
[c057fb7b] drm_get_dev+0x343/0x405
[c07b6741] i915_pci_probe+0xd/0xf
[c051aee2] local_pci_probe+0xe/0x10
[c051b84d] pci_device_probe+0x46/0x69
[c05aedd5] driver_probe_device+0xa2/0x11d
[c05aee9c] __driver_attach+0x4c/0x6b
[c05ae7f1] bus_for_each_dev+0x3b/0x63
[c05aec76] driver_attach+0x14/0x16
[c05ae28c] bus_add_driver+0x98/0x1ab
[c05af033] driver_register+0x6f/0xd3
[c051bb3d] __pci_register_driver+0x46/0xa5
[c057c3f4] drm_init+0x5b/0xb3
[c0a39544] i915_init+0x46/0x48
[c0401132] _stext+0x4a/0x111
[c0a1e386] kernel_init+0x17f/0x1d0
[c0403a37] kernel_thread_helper+0x7/0x10
[] 0x
- #0 (fb_info-lock){--..}:
[c04460d9] __lock_acquire+0xd47/0x137e
[c044676e] lock_acquire+0x5e/0x7a
[c07c919f] mutex_lock_nested+0xe0/0x267
[c05288bc] fb_mmap+0x83/0x153
[c0473ab7] mmap_region+0x21c/0x3ab
[c0473e96] do_mmap_pgoff+0x250/0x2a2
[c0406a52] sys_mmap2+0x5a/0x7b
[c0403202] syscall_call+0x7/0xb
[] 0x
other info that might help us debug this:
1 lock held by plymouthd/746:
#0: (mm-mmap_sem){}, at: [c0406a3c] sys_mmap2+0x44/0x7b
stack backtrace:
Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1
Call Trace:
[c07c7b14] ? printk+0xf/0x11
[c0445054] print_circular_bug_tail+0xab/0xb6
[c04460d9]
Re: Fw: Kernel Loading Sequence
On Sun, Jul 12, 2009 at 1:32 PM, Ahmad Al-Yamanahmad221...@yahoo.com wrote: Thank you, I adjusted the config file as you recommended and the messages are gone. Where should I report this lockdep? Depends on which kernel / patches do you use. If it is a vanilla tarball then upstream (lkml / bugzilla.kernel.org) if you are using the fedora kernel bugzilla.redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: x86_64 packages depends on i586.
On Sat, Jul 11, 2009 at 6:49 PM, drago01drag...@gmail.com wrote: On Sat, Jul 11, 2009 at 6:18 PM, Frank Murphyfrankl...@gmail.com wrote: On 11/07/09 10:41, Jussi Lehtola wrote: snip The x86_64 repo contains some multilib packages. If you don't specify the wanted architecture when installing, yum might install both 32- and 64-bit versions if available. Try adding the .x86_64 arch specifier, e.g. instead of # yum install foo perform # yum install foo.x86_64 Doesn't seem to work for wine :) yum install foo will install foo.x86_64 by default it will only install foo.i586 if foo.x86_64 when s/if foo.x86_64// ;) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On Sat, Jul 11, 2009 at 6:18 PM, Frank Murphyfrankl...@gmail.com wrote: On 11/07/09 10:41, Jussi Lehtola wrote: snip The x86_64 repo contains some multilib packages. If you don't specify the wanted architecture when installing, yum might install both 32- and 64-bit versions if available. Try adding the .x86_64 arch specifier, e.g. instead of # yum install foo perform # yum install foo.x86_64 Doesn't seem to work for wine :) yum install foo will install foo.x86_64 by default it will only install foo.i586 if foo.x86_64 when 1) you do yum install foo and only foo.i586 is in the repo 2) yo do yum install foo.i586 3) if you set exactarch=0 in /etc/yum.conf (default is 1 which leads to the behavior I explained above) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jul 7, 2009 at 10:56 AM, Rui Miguel Silva Seabrar...@1407.org wrote: On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: On Mon, Jun 29, 2009 at 9:38 AM, Frank Murphyfrankl...@gmail.com wrote: Is there any contingency plans in place, for a worst case scenario if C#, is lost? FesCo? Legal? Is there any searchable parameter, to work out what something is coded in\depending on (code wise) This is not the normal mono post. I hope, I worded it enough, that my concern is: Fedora and *All* our Users (http://fedoraproject.org/wiki/Overview#What_is_Fedora.3F) http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx Oh poo, and what's the difference? None. None whatsoever but more marketing. You can't distribute GPL'ed software unless you have the right to do it. So? The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. [1] = means you can't do it with GPL It explicitly grant this right. [2] = means you can't do it with GPL3 If you want to do it with GPL'ed software, you need to obtain a RAND or RAND-Z patent license. Who ever got it, could s/he please publish it? Microsoft promised to give it to a company that asked for it in Portugal, and they never fulfilled (even after insistence). I know of several other people who have asked for it and never got it. You need to stop believing in Santa. We already had the OIN protection and this is additional safety. But I am not a lawyer so I leave the judgment to them. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jul 7, 2009 at 3:27 PM, Jonathan Underwoodjonathan.underw...@gmail.com wrote: 2009/7/7 Adam Jackson a...@redhat.com: On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx Oh poo, and what's the difference? None. None whatsoever but more marketing. You can't distribute GPL'ed software unless you have the right to do it. The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. I am unable to read the Community Promise in any way that implies either of the above. Please cite exactly which statement in the Community Promise you take issue with. http://www.microsoft.com/interop/cp/default.mspx Not answering Ajax's question specifically, but this looks a bit iffy: If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you. So, say a few years have passed and C# and the CLI is now a very key component of the stack, and Red Hat (for example) filed a patent lawsuit against MS for something *unrelated*, against a Microsoft implementation of any Covered Specification I don't see why Red Hat would ever sue MS because of a C# / CLI patent. Anything unrelated _IS_ unrelated. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabrar...@1407.org wrote: On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. [1] = means you can't do it with GPL It explicitly grant this right. What you're explicitly told s that you won't be sued if you do so without the right. And you have no right! If I told you you can do whatever you want with this and I won't sue you or you have the right to implement this Where exactly is the difference? I can redistribute the implementation as I wish because nobody will sue me if I do so .. which means that I HAVE the right to do so. Further down (in the FAQ, outside the promise) you're told you need to get a RAND or RAND-Z license to have the rights. Source? You don't need a lawyer to distinguish between a) having a right or b) not being sued if you infringe So what? not being sued is the key here... (does not matter how they phrase it, see above) You try to find holes, without backing it up with any citation so sure you need a lawyer to clarification this. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jul 7, 2009 at 4:06 PM, Julian Aloofijulian.fedorali...@googlemail.com wrote: Am Dienstag, den 07.07.2009, 15:36 +0200 schrieb drago01: On Tue, Jul 7, 2009 at 3:27 PM, Jonathan Underwoodjonathan.underw...@gmail.com wrote: 2009/7/7 Adam Jackson a...@redhat.com: On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx Oh poo, and what's the difference? None. None whatsoever but more marketing. You can't distribute GPL'ed software unless you have the right to do it. The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. I am unable to read the Community Promise in any way that implies either of the above. Please cite exactly which statement in the Community Promise you take issue with. http://www.microsoft.com/interop/cp/default.mspx Not answering Ajax's question specifically, but this looks a bit iffy: If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you. So, say a few years have passed and C# and the CLI is now a very key component of the stack, and Red Hat (for example) filed a patent lawsuit against MS for something *unrelated*, against a Microsoft implementation of any Covered Specification I don't see why Red Hat would ever sue MS because of a C# / CLI patent. Anything unrelated _IS_ unrelated. Unfortunately the patent promise covers more things than just C# / CLI patents. And it seems like you're going to lose the whole promise when you just sue them over one specification in there, e.g. the XPS specification. Maybe that's less of a problem for Red Hat because they don't like patents anyway and are not likely holding any XPS related patents, but it could be a problem for the OIN. Yeah got this after reading Ajax's post. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jul 7, 2009 at 10:11 PM, Rui Miguel Silva Seabrar...@1407.org wrote: On Tue, Jul 07, 2009 at 04:06:02PM +0200, drago01 wrote: On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabrar...@1407.org wrote: On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. [1] = means you can't do it with GPL It explicitly grant this right. What you're explicitly told s that you won't be sued if you do so without the right. And you have no right! If I told you you can do whatever you want with this and I won't sue you or you have the right to implement this Where exactly is the difference? In one you can be sued (because it's not only Microsoft who can do that in some jurisdictions) and you're doing something which is illegal. In the other you're lawfully using legally granted rights. Where exactly is the difference? I don't know, what do you think? In which jurisdictions can somebody sue me because I infringe a US Patent of a different company? And no I am not doing something illegal because the company which holds the patents stated in a legally binding document that I can implement this standards as long as I don't sue them over a patent that is covered by the CP. Further down (in the FAQ, outside the promise) you're told you need to get a RAND or RAND-Z license to have the rights. Source? It's in the FAQ, which you would know by now if you read the promise and the FAQ instead of trusting Microsoft's employees. I did read the FAQ and I could not find what you are referring to so I asked. But ok lets quote the FAQ: -- Q: Why does Microsoft obtain patents that apply to specifications to which the Community Promise apply? Is that something that others do too? A: Microsoft invests a significant amount of resources in research and development efforts. Like any other company that commits such resources to creating new technologies, Microsoft seeks to protect its investment by obtaining patents on the resulting innovations. At a minimum, patents have value in defending Microsoft with regard to patent infringement claims made by others. Many patent owners use their patents defensively to protect themselves against third-party law suits when they make their patents available under reasonable and non-discriminatory (RAND or RAND-Z) terms and conditions (including promises like the CP). -- (The only text that mentions RAND or RAND-Z) How do you conclude that you need one to get the rights to do anything. They just try to justifity why the filled patents to begin with. There is no you need a RAND or RAND-Z license to implement the standards that are covered by this promise, no matter how you read it. You don't need a lawyer to distinguish between a) having a right or b) not being sued if you infringe So what? not being sued is the key here... (does not matter how they phrase it, see above) You try to find holes, without backing it up with any citation so sure you need a lawyer to clarification this. I'm backing it up with what is in the text of the promise, instead of what is in the mouth of marketing agents. Trust whatever you want, but I prefer authoritative texts infinity times more than a marketing agent's tongue. No you did not, you are interpreting the text in the way you want. I don't trust MS so it must have holes, while blindly trusting anybody is wrong, I don't see the point in making up points that do not exits in the text. Neither in the promise itself nor in the FAQ. In order to get 100% clearance consult a lawyer I doubt that any lawyer would interprets it the way you do. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Wed, Jul 8, 2009 at 12:11 AM, Matthew Woehlke wrote: (Since I see some people here doing it... *cough*Please do not quote my e-mail address unobfuscated in message bodies.*cough* Thank you.) Simo Sorce wrote: People, why don't you all stop playing lawyer and wait that some lawyer actually comment on the promise? I guess some organization like the SFLC might be willing to comment if there is enough demand (and maybe they are already working on that). Um... really? You mean they haven't, already? GIYF: http://www.google.com/search?sourceid=mozclientie=utf-8oe=utf-8q=sflc+microsoft+patent+promise (Granted, much of that is about OOXML, but it seems to be referring to the same OSP, and even so, given the opinion on how poorly OOXML is covered, I doubt M$ would do anything to make the Mono/C#/CLI situation appreciably better.) No its not the same Open Specification Promise != Community Promise Oh, and drago01: I doubt that any lawyer would interprets it the way [Riu does]. I don't about exact agreement with Riu's specific arguments, but they sure don't seem to share /your/ comfort level. I stated serval times that I am not a laywer and therefore can be wrong, than Riu stated that we don't need laywers because his point is obivious (to him). Besides my personal opinion to this is I don't give a damn about software patents (and they are void here anyway). But unfortunatly the US laws suck, and that won't change anytime soon. Next time, either check that 5 seconds of googling doesn't make you look like you don't know what you are talking about, or else point out why said googling does not invalidate your point :-). When providing links make sure that they cover the same topic ;) Because than _you_ look that you have no idea what you are talking about. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Wed, Jul 8, 2009 at 12:19 AM, Rui Miguel Silva Seabrar...@1407.org wrote: And no I am not doing something illegal because the company which holds the patents stated in a legally binding document that I can implement this standards as long as I don't sue them over a patent that is covered by the CP. Yes, you're possibly doing something illegal, in the US it's called patent infringement. They just promised (and their word is worthless in this regard) not to sue you. So what about the patents owned by redhat? http://www.redhat.com/legal/patent_policy.html It's also just promise. You claim that this is a worthless statement, but others (including MS here) claim that this is a legal binding document. So we need a lawyer or better a court decision to clear this up. (The only text that mentions RAND or RAND-Z) How do you conclude that you need one to get the rights to do anything. Two things: 1) they told so in several TC that analysed MS-OOXML, and even *promised* to bring these terms to the TCs. Guess what? The promise was worthless. Only because it is called promise in the sense we will bring this terms it is not legaly binding. This document is different. they *promised* to get these terms to some companies. Where are the terms? Microsoft doesn't even answer anymore. See above. and 2) Because, as the *promise* quite clearly tells you so: No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise. Yes but we are talking about the things stated here. Since they don't give you a license (just promise not to sue) you haven't got any right. The FAQ subtly reveals there's RAND or RAND-Z terms, and tries to fool you into believing not suing == granting rights In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the promise down the drain. Same applies to Redhat. They just try to justifity why the filled patents to begin with. You think filing software patents is correct? It may be legal in the US and a few other countries, but while filing a few software patents in the US may be viewed as a defense strategy in a software patent infected country, filing them by the thousands, even in countries where they're invalid, but you'll still have to pay possibly hundreds of thousands of Euros to prove that. Yes it is, even though I think that software patents are a stupid idea and should go away, if the law allows you to fill patents it is broken and needs fixing. Not that companies that file patents are evil. (Even RedHat owns and files softeware patents) I'm backing it up with what is in the text of the promise, instead of what is in the mouth of marketing agents. Trust whatever you want, but I prefer authoritative texts infinity times more than a marketing agent's tongue. No you did not, you are interpreting the text in the way you want. I don't trust MS so it must have holes, while blindly trusting anybody is wrong, I don't see the point in making up points that do not exits in the text. And I don't see the point of scorning someone by implying they blindly mistrust Microsoft. It's not blind mistrust, the reality is filled with enough fishy things to give the benefit of doubt. Proof is needed. someone by implying they blindly mistrust Microsoft I never said that but the opposite while blindly trusting anybody is wrong. Which implies do not trust anybody unless you have a reason. But trying to come up with any unproven statements isn't right either. And again whether this is worth anything has to be judged by a lawyer. Neither in the promise itself nor in the FAQ. In order to get 100% clearance consult a lawyer I doubt that any lawyer would interprets it the way you do. Funny enough we tried to get a lawyer team to analyse this problem in Portugal. No you did not it was a _different_ (but similar) case. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090705 changes
On Mon, Jul 6, 2009 at 2:36 AM, Josh Boyerjwbo...@gmail.com wrote: On Sun, Jul 05, 2009 at 06:46:36PM -0400, Dave Jones wrote: On Sun, Jul 05, 2009 at 11:21:58AM +, Rawhide Report wrote: kernel-2.6.31-0.42.rc2.fc12 --- * Sat Jul 04 2009 Chuck Ebbert cebb...@redhat.com - 2.6.31-rc1-git11 * Sat Jul 04 2009 Dave Jones da...@redhat.com 2.6.31-0.42.rc2 - 2.6.31-rc2 * Fri Jul 03 2009 Hans de Goede hdego...@redhat.com - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by v4l2 gspca subdrivers) Why is the changelog out of order in the rawhide report? It's the right way around in CVS. Because the script that generates it doesn't deal with multiple entries on the same day properly. It's becoming a common question. Why does it mess with them at all? Why not just copy them from the specfile and assume that this is correct? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Time for 2.6.30 in F-11?
On Sun, Jul 5, 2009 at 8:50 AM, Gregory Maxwellgmaxw...@gmail.com wrote: On Sat, Jul 4, 2009 at 6:40 AM, Bojan Smojverbo...@rexursive.com wrote: Now that .1 is out, is there anything in particular stopping F-11 from having this kernel? Worth mentioning— .30 makes a non-backwards-compatible BTRFS format change. So if you go .30 on a BTRFS system you can't go back. (though, I suppose that can be seen an argument for getting Fedora to .30 sooner) brtfs support was always if you care about data than don't use it or make backups -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
On Sat, Jul 4, 2009 at 4:10 PM, Kevin Koflerkevin.kof...@chello.at wrote: Patrice Dumas wrote: Certainly not. Many very useful package are not utf8 aware Those packages need to be fixed. It is not acceptable that we ship applications which don't work properly in our default locales. You can't even open your files with those broken applications if they're in a directory containing special characters. at least many that use motif or the athena widget set. Those applications are obsolete by definition. Sure for most people they are .. same as old gtk1 apps. But who is forcing anybody to use them? They are not installed by default, and adding unicode support to legacy frameworks means breaking API/ABI and the apps would have to be ported. In this case we could as well port them to newer frameworks and be done with it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
On Fri, Jul 3, 2009 at 9:29 PM, Ralf Corsepiusrc040...@freenet.de wrote: Miroslav Lichvar wrote: I'd like to update readline to the latest version 6.0. The problem is that the license was changed to GPLv3+ and we have some GPLv2 packages using readline. A possible replacement is the editline library which provides a compatible interface and is licensed under BSD, unfortunately it doesn't handle UTF-8. I thought, we banned all non-utf-8 aware packages? err .. what? no we still have a lot of them... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Reportrawh...@fedoraproject.org wrote: Compose started at Thu Jul 2 06:15:05 UTC 2009 ... New package ldd-pdf Linux Device Drivers, Third Edition Book in PDF format We ship books as packages? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 5:07 PM, Kevin Koflerkevin.kof...@chello.at wrote: Rahul Sundaram wrote: Yes and this is not even the first time. Dive Into Python has been in the repo for ages already. That doesn't mean it's compliant with our guidelines on shipping content. I really don't see what benefit it gives us to have a package dumping some book into /usr/share. Can't it be given as a regular download on a website? Possibly even the Fedora wiki. But packages sound to me like a completely overkill format to distribute PDF books. +1 http://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK. So does a programming book enhance the OS user experience? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 4:22 PM, Rahul Sundaramsunda...@fedoraproject.org wrote: On 07/02/2009 06:58 PM, Adam Miller wrote: +1 on the Books idea Does this look ok? --- comps-f12.xml.in.orig 2009-07-02 15:39:02.0 +0530 +++ comps-f12.xml.in 2009-07-02 19:49:32.108616562 +0530 @@ -520,6 +520,17 @@ /packagelist /group group + idbooks/id + _nameTechnical Books/_name + _description/ + defaultfalse/default + uservisibletrue/uservisible + packagelist + packagereq type=defaultdiveintopython/packagereq + packagereq type=defaultldd-pdf/packagereq + /packagelist + /group + group idbuildsys-build/id _nameBuildsystem building group/_name _description/ If we want to go this route, why limit it to technical books? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 5:19 PM, Adam Millermaxamill...@gmail.com wrote: On Thu, Jul 2, 2009 at 10:14 AM, drago01drag...@gmail.com wrote: If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK. So does a programming book enhance the OS user experience? That's subject to opinion which is exactly why this policy is flawed. I know (there is a reason why I did not provide an answer to this question) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Thu, Jul 2, 2009 at 5:43 PM, Bill Nottinghamnott...@redhat.com wrote: Glen Turner (g...@gdt.id.au) said: That's a really crappy place for that message, though. What's the user supposed to do there... reboot and then go download another 700MB - 4GB? Yes it's a crappy place. I knew that when I suggested it. I just couldn't think of a Javascript hack which would cough up the CPU features even when running under a 32b OS like Windows Xp. Suggestions welcomed. Dual-arch media. (Which is a pain, and will run into space issues sooner or later.) I don't see this as an issue for live media (if it is possible to do here). We have 700MB x 2 = 1400MB out of 4GB which we can ship on a DVD. We can provide an extra link download CD if someone really still has no dvd burner / drive in 2009. This also would allow us to add software like openoffice to the live media (which is ommited for space reasons because we insist on the pointless cd limit). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Tue, Jun 30, 2009 at 8:55 AM, Matej Ceplmc...@redhat.com wrote: Kevin Kofler, Mon, 29 Jun 2009 17:08:11 +0200: I'm not familiar with the JavaScript story, but if he really recommended against using it, there was certainly a valid reason. His point was that thousands of line of hardly obfuscated Javascript (think Google Docs) is hard to recognize from binary-only distribution, which I can see as pretty good argument. And yes I know that this obfuscation is not for malicious reasons (it's compression as well), but still, it would be lovely if source for Google Docs was available somewhere. Well as the code has a non free license anyway its better that it is obfuscated. So a developer cannot read and get infected by it. Write his own code and copy parts of the code which he is not allowed to copy. Sure getting Google to release it under a free license would be a good thing, but I doubt that will do it anytime soon :(. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Mon, Jun 29, 2009 at 3:07 PM, Kevin Koflerkevin.kof...@chello.at wrote: Josh Boyer wrote: It is not obvious to me without seeing comparison data as to why it's such a good thing to have numerous stable updates. It's a good thing because those updates fix bugs, update translations and in some cases add features. and introduce new bugs ;) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
