Re: Orphans on the chopping block for F12
On Tue, Jul 28, 2009 at 03:12:10PM -0700, Jesse Keating wrote: As today is the Feature Freeze, I am preparing to block all the unblocked orphans. This is your last chance to pick one of them up. Those that remain unblocked at the end of my day (around UTC) will be blocked. Unblocked orphan gimp-lqr-plugin Unblocked orphan liblqr-1 I've taken those two. While it's arguably past UTC already the facts that the owner change worked and that the packages are still in cvs make me believe that your day isn't quite over yet. -- sven === jabber/xmpp: s...@lankes.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Tue, 2009-07-28 at 01:51 +0200, Ralf Corsepius wrote: On 07/28/2009 01:19 AM, Paul W. Frields wrote: On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: That means that you can take revisor, pungi or livecd-tools in your existing Fedora system None of these are what I am looking for. I'm terribly sorry - what color exactly did you want us to paint your fricking pony, Ralf? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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-07-28
On Tue, 2009-07-28 at 01:29 +, Michael Schwendt wrote: synce-kde-0.9.1-4.fc11.ppc requires synce-serial vdccm-0.10.1-5.fc11.ppc requires synce-serial I thought I'd seen these addressed on the list before, but just in case: synce-serial is entirely deprecated now, it is not needed for anything. These packages should not depend on it, and synce-hal should obsolete it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Tue, 2009-07-28 at 01:41 +0200, Jeroen van Meeuwen wrote: On 07/27/2009 10:21 PM, Jeremy Katz wrote: Regenerating the images is expensive -- it requires effort on the part of the developers doing fixes, release engineering doing builds with the fixes, QA testing the fixes, infrastructure (mirrors) carrying a significant amount more bits[1], ... Hey, that's funny. That's what I do. With a little help from my friends. Well, that doesn't really contradict Jeremy: Jeremy's point is that we require more resources to do something like this, and here you are, being an extra resource :). You and your 'friends'. that said, though, I think what you do is super awesome and I'm entirely in favour of everyone pulling fingers out of unmentionable areas and helping you to do it 'officially'. From a QA perspective, I'm willing to stick my neck out and say if all the other pieces can happen - you get maintainer privileges to anaconda and some kind of system to officially publish respun installer images - I'll try and get the QA piece of the puzzle into place, either by finding people within the current QA group to help test the images, or by integrating your 'friends' into our QA team. I'd love to see that happen. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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, 2009-07-28 at 23:55 -0700, Adam Williamson wrote: When you mean 'not wrap them', do you mean they're no longer selectable as a record source, if the hardware exports them? Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. If you want to control them you can always install alsamixer or gst-mixer or whatever. But really, this controls are obsolete. so really lennart means 'no' :) they're not selectable via PA's mixer interface. they will still be selectable via ALSA's mixer interface, and hence via any alsamixer (alsamixer, kmix, xfce's mixer, gst-mixer as long as it's around, etc). (sorry for the self-reply) - and of course, this isn't a regression in PA, as PA's mixer interface has never exposed these choices. so nothing's got more restricted than it was before. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-07-29 at 04:48 +0200, Ralf Corsepius wrote: On 07/29/2009 12:37 AM, Adam Williamson wrote: On Mon, 2009-07-27 at 13:43 +0200, Ralf Corsepius wrote: With all due respect to fedoraunity and you. To me it is a serious Fedora management and rel-eng mistake causing major harm to fedora's and RH's reputation to not provide updated media, thus to expose users to known bugs. I can't think of any major distro that actually does this. And? Isn't Fedora about innovation? Sure, but we do have a process for innovation ;). As I've mentioned in other mails, I'm not actually against this happening, but it has to be a significant project, handled properly, which involves bringing in extra people, or else it wouldn't run very well. It's a very big effort that would take much manpower away from working on the installer and releng tasks for the next release. The discussion about whether that compromise would be justified has not been done yet. It's not as simple as you suggest. My impression is you only say so because you're too close to Ole' Red Hat's habits and don't want to leave them. That's funny, since I've never been a part of Ole' Red Hat. I joined RH in February. I've never actually run RHEL, only Fedora. I don't even have an RHCE. People inside RH are forever complaining that I insist on doing everything outside the company. :P The key to implement what I said is a minimial installer image - Actually RH distros once had an installer which was very close to this. Unfortuately, this doesn't apply anymore. Well, I believe the reason it's so big is because it contains stage2, and the reason for that is so it doesn't have to be loaded into RAM, which would make the installer rather more RAM-intensive (things already get dicey with 512MB in certain circumstances). that does sound like an area that could be re-examined, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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-07-28
On Tue, 2009-07-28 at 23:05 -0700, Adam Williamson wrote: On Tue, 2009-07-28 at 01:29 +, Michael Schwendt wrote: synce-kde-0.9.1-4.fc11.ppc requires synce-serial vdccm-0.10.1-5.fc11.ppc requires synce-serial I thought I'd seen these addressed on the list before, but just in case: synce-serial is entirely deprecated now, it is not needed for anything. These packages should not depend on it, and synce-hal should obsolete it. Erm - actually, vdccm is obsoleted by synce-hal too. Sorry. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Mon, Jul 27, 2009 at 1:01 PM, Michael Schroeder m...@suse.de wrote: Hi folks, I'm the author of the libsatsolver library, a library solves package dependencies with a SAT algorithm. This library is currently used in SUSE by YaST/zypp. I'm currently trying to make it less SUSE specific like adding support for package coloring and different repo handling, but I'm pretty sure I didn't catch all things where Fedora is different from SUSE. To test things I've written a small application called solv that works like a very tiny package manager. It's available via: http://software.opensuse.org/search?baseproject=Fedora:11q=libsatsolver-demo (To get the src rpm search for libsatsolver) The package contains just a single file, /usr/bin/solv. It can be run as normal user, but then the transaction can't be commited. Also, the repository metadata caching mechanism needs write access to /var/cache/solv. If it can't write there, it still works but downloads the metadata again every time it is called. So, if you have some spare time, could you give it a try and tell me where it works well/ does stupid things/ doesn't work at all? Thanks, Michael. BTW, if you want a wider audience for your project, outside the narrow circle of people involved in rpm development :=) for example, so that it can be considered for inclusion in different distributions from OpenSUSE, you should, as usual, publish it as a separate and autonomous project. This is what do yum and smart for example, both in Fedora repository. Regards (aside) in a (perhaps old but not i cannot check now the latest release) RHEL5 release glibc don't have qsort_r ( http://sourceware.org/bugzilla/show_bug.cgi?id=173) so the code don't compile. http://sourceware.org/ml/glibc-cvs/2007-q4/msg00436.html -- 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 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: 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. When you mean 'not wrap them', do you mean they're no longer selectable as a record source, if the hardware exports them? Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. Karel -- Karel Zak k...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphans on the chopping block for F12
2009/7/29 Jesse Keating jkeat...@redhat.com: As today is the Feature Freeze, I am preparing to block all the unblocked orphans. This is your last chance to pick one of them up. Those that remain unblocked at the end of my day (around UTC) will be blocked. Unblocked orphan surfraw Unblocked orphan viewmtn Took those. -- Thomas Moschny thomas.mosc...@gmail.com -- 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, 2009-07-28 at 15:59 +0200, Lennart Poettering wrote: In the F11 cycle there has been some criticism on how g-v-c was presenting a new minimal volume control interface. Most issues raised back then should now be fixed, except for a few which we consider strictly out of focus for us. I'd like to ask everyone to test this new volume logic. If you don't raise your voice now that some output port is not properly detected or audio is too faint then later on you won't have any right to complain. You should particularly pay attention to the new Hardware tab in g-v-c, where you can now choose the hardware profile (i.e. stereo vs. 5.1, and so on) which you want to use. And then on the Input/Output tab you may or may not find an additional dropdown menu for selecting the port you want to use (only shown if you have more than one). gst-mixer is not longer listed as default in comps now. as the other interested party, this is perfectly fine by me as long as we get any bugs out of the new code, which I'm sure we'll manage. I may even drop the package entirely, since we do have other alternatives. thanks a lot for the work on the new stuff. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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
Let me take the chance to thank you, Lennart. Even though PulseAudio has always been a controversial topic and there are many negative feelings about it I still think I am not the only one who really enjoys the new audio and volume control features Fedoa offers. It has really made my life easier and is a big step forward towards a user-friendly desktop environment. I think many people who don't actually know how to use a mailing list and just use PulseAudio et al. think the same. Lennart, I think you are moving things in the right direction and I would like to thank you for all the hard work you have put into PulseAudio. I think you have the kind of thick skin that is required to make fundamental changes in this environment ;-) Felix -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
question about clipboard behavior
Hi all, I have a question about the standard clipboard. Highlighting some text in an app, may it be firefox, thunderbird, tomboy, whatever and then pasting it to an existing xterm with middle mouse button works. However if you open a new xterm _after_ you highlighted some text the previously highlighted text is not being pasted to the new xterm. There might be some some security concerns I might not be thinking of but it's not the behavior I would expect from a user perspective. What's actually going on there? Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Tue, Jul 28, 2009 at 11:00:17PM -0700, Adam Williamson wrote:
Of course, that depends on whether what we have in yum is as slow as
whatever SUSE had before this. :)
I doubt that. It's not an easy task to create software as slow
as the 10.x update stack ;-)
ISTR that SUSE was rather infamous for
very slow package manager performance before zypper came along.
To clarify: this has nothing to do with zypper. Both zypper and
YaST use libzypp, which was pretty much unusable in the 10.x
SUSE releases. That's what prompted me to create the libsatsolver
library, now used by libzypp. Thus, both zypper and YaST are fast.
(PackageKit also uses libzypp, btw.)
Using the same library has the big advantage that you get the same
results (and bugs) using all interfaces.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On Tue, Jul 28, 2009 at 01:54:20PM -0700, Toshio Kuratomi wrote: It was in my post to the last thread:: Is someone in a position to verify whether setting security flags on a bug prevents someone who would be put in the CC list by the default cc attribute would or would not let people see those bugs? Is someone in a position to tell me if watching a person in bugzilla would also let you violate this? I think people are generally amenable to autoapproving CC to watchbugzilla as long as security bugs do not send updates out to random people who have signed up to be CC'd. Knowing just how security bugs work allows us to evaluate what the risks are. How about just test this? Is the following what to think may cause trouble? 1) Security bug 12345 against package foo is created 2) Alice requests watchbugzilla for package foo 3) Alice can now watch bug 12345 We can test this with this bug I marked as security sensitive: https://bugzilla.redhat.com/show_bug.cgi?id=472110 You can now apply for watchbugzilla here: https://admin.fedoraproject.org/pkgdb/packages/name/pam_mount According to the Bugzilla docs, only people that are already on the CC list can access restricted bugs, and this can also be disabled: http://www.bugzilla.org/docs/tip/en/html/groups.html | By default, bugs can also be seen by the Assignee, the Reporter, and by | everyone on the CC List, regardless of whether or not the bug would | typically be viewable by them. Visibility to the Reporter and CC List | can be overridden (on a per-bug basis) by bringing up the bug, finding | the section that starts with Users in the roles selected below... and | un-checking the box next to either 'Reporter' or 'CC List' (or both). Regards Till -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphans on the chopping block for F12
On Wed, Jul 29, 2009 at 02:04:28AM +0200, Haïkel Guémar wrote: gnochm, it has two co-maintainers: pertusus and wolfy, maybe one of them would take ownership. Not me (I am not in fedora anymore, but still watch over my former packages, be it only for EPEL). Manuel (wolfy) owns already many packages, so I think it would be right if you could take ownership of gnochm. -- Pat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On 07/28/2009 03:04 PM, Michael Schroeder wrote: Ok, solv now supports mirrorlists. Updated packages should be available in an hour or two (depending on the build service load). Tested. Works with mirror lists atleast partially but still too slow. I have compared it with yum http://fpaste.org/paste/20255 Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Wed, 29 Jul 2009 09:27:00 +0200 yersinia yersinia.spi...@gmail.com wrote: BTW, if you want a wider audience for your project, outside the narrow circle of people involved in rpm development :=) for example, so that it can be considered for inclusion in different distributions from OpenSUSE, [cut] I completely agree, some time ago I asked in zypp-devel if it was possible to get proper source tarballs without a) having to 'extract' them from the SRPMs on the OBS b) having to do some trickery with the OBS REST api curl Anyway, as far as I know, they are moving the source code repositories on gitorious (great!), I bet we won't wait longer to see the ZYpp stack released on its own (with proper release tarballs? :-) ). --- Lorenzo Villani -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphans on the chopping block for F12
Le 29/07/2009 11:01, Patrice Dumas a écrit : On Wed, Jul 29, 2009 at 02:04:28AM +0200, Haïkel Guémar wrote: gnochm, it has two co-maintainers: pertusus and wolfy, maybe one of them would take ownership. Not me (I am not in fedora anymore, but still watch over my former packages, be it only for EPEL). Manuel (wolfy) owns already many packages, so I think it would be right if you could take ownership of gnochm. -- Pat Thanks for your quick answer (and your wonderful job), I took ownership for F-11 and devel. It would have been crap to lose it, though upstream seems to have vanished, it still working and useful (at least for myself). -- 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
This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm l PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. First, I like pulseaudio, especially the ability of moving streams from one sink to another is awesome for laptops with external sound card :o) But imo hw mixer (or other hw parts) are not that bad... we still have hw accelerated graphic, math,... why not sound? Also this remains me that pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1 which (I suppose) some hw mixer could do while letting cpu free for other tasks. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Wed, Jul 29, 2009 at 02:44:02PM +0530, Rahul Sundaram wrote:
On 07/28/2009 03:04 PM, Michael Schroeder wrote:
Ok, solv now supports mirrorlists. Updated packages should be
available in an hour or two (depending on the build service load).
Tested. Works with mirror lists atleast partially but still too slow. I
have compared it with yum
some points:
- seems like it still accesses some remote hosts
because it checks if the metadata is up-to-date. It shouldn't
do this the second time you call it, seems like it doesn't
have write access to /var/cache/solv. Please chown the directory
to your uid.
- FL access is slowing it down a bit (FL is the complete filelist).
Even worse is that it had to download the file list for the
chromium repository every time because of the missing write
access.
- Also, I've rewritten the file provides algorithm, so it should
be quite a bit faster now (packages available in an hour). It
now rewrites the cache file after the file provides have been
added.
$ echo n | ( time ./solv up )
rpm database: cached
repo 'fedora': cached
repo 'rpmfusion-free': cached
repo 'rpmfusion-free-updates': cached
repo 'updates': cached
Transaction summary:
73 upgraded packages:
[...]
install size change: -8008 K
OK to continue (y/n)? Abort.
0.248u 0.052s 0:00.32 90.6% 0+0k 0+0io 0pf+0w
As you can see, if the solv can take full advantage of the
cache (no FL loads), it's pretty fast.
But this really isn't about execution speed, but correctness
of the solver results.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heads up: nautilus-cd-burner is gone
In devel. Replaced by brasero in GNOME 2.26. Applications that were using libnautilus-burn should have been ported already at this stage, or deprecated. Cheers -- 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 Wed, Jul 29, 2009 at 5:33 AM, Michal Hlavinka mhlav...@redhat.comwrote: This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm l PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. First, I like pulseaudio, especially the ability of moving streams from one sink to another is awesome for laptops with external sound card :o) But imo hw mixer (or other hw parts) are not that bad... we still have hw accelerated graphic, math,... why not sound? Also this remains me that pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1 which (I suppose) some hw mixer could do while letting cpu free for other tasks. Absolutely... IMO Pulseaudio needs some serious justification for its direction. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On 07/29/2009 08:03 AM, Adam Williamson wrote: On Tue, 2009-07-28 at 01:51 +0200, Ralf Corsepius wrote: On 07/28/2009 01:19 AM, Paul W. Frields wrote: On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: That means that you can take revisor, pungi or livecd-tools in your existing Fedora system None of these are what I am looking for. I'm terribly sorry - what color exactly did you want us to paint your fricking pony, Ralf? Plonk. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Tue, 2009-07-28 at 20:13 -0500, Serge E. Hallyn wrote: Quoting Bill McGonigle (b...@bfccomputing.com): On 07/28/2009 04:11 PM, Chris Adams wrote: Still, is such a change less severe than changing what root means? Is Fedora that committed to SELinux? What's it going to take to make most people who shut off SELinux stop doing that? Moving to heavier exploitation of capabilities doesn't mean stop using SELinux. Any more than finding and fixing buffer overflows should only be done if we want to turn off selinux. Well, it isn't quite the same thing. Assignment of capabilities to specific processes running specific binaries is something that SELinux can already do via Type Enforcement. And preventing a uid 0 process from writing to system files is likewise something that SELinux can already do via Type Enforcement. So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Tue, 2009-07-28 at 17:53 -0400, Bill McGonigle wrote: On 07/28/2009 04:11 PM, Chris Adams wrote: AFAIK SELinux introduces additional controls and does not replace or override existing controls. I'm pretty sure non-root still can't directly listen on a low-numbered port. For some reason I thought it was possible with MAC, but I can't find anything to support that. I might have been thinking of Solaris privileges. There was a patch floated on selinux list circa June 2007 that would have allowed SELinux to directly grant capabilities. But it met a certain amount of resistance from people concerned about the implications of changing the historical position that SELinux only further restricts access and about how to handle states like permissive mode, selinux-disabled, etc seamlessly. http://marc.info/?l=selinuxm=118159187318524w=2 http://marc.info/?l=selinuxm=118192327422630w=2 http://marc.info/?l=selinuxm=118191791828777w=2 -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wed, 29 Jul 2009, Stephen Smalley wrote: So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. Once we have access control on policy itself, we may be able to provide an API where an application can toggle a boolean on itself, e.g. to perform one action with broader permissions, then switch to a tighter set of permissions. This might be implementable in a way which also prevents applications from ever gaining more permissions (via typebounds). - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wed, 2009-07-29 at 23:01 +1000, James Morris wrote: On Wed, 29 Jul 2009, Stephen Smalley wrote: So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. Once we have access control on policy itself, we may be able to provide an API where an application can toggle a boolean on itself, e.g. to perform one action with broader permissions, then switch to a tighter set of permissions. This might be implementable in a way which also prevents applications from ever gaining more permissions (via typebounds). We can actually already apply fine-grained access control on temporary changes to booleans - just specify a distinct label for the boolean in policy (via genfscon selinuxfs entries) and then control who can write to that file type. However, note that such changes affect all processes running in a given domain, so it isn't precisely the same thing as process privilege bracketing. -- Stephen Smalley National Security Agency -- 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 Wed, 29.07.09 12:33, Michal Hlavinka (mhlav...@redhat.com) wrote: This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm l PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. First, I like pulseaudio, especially the ability of moving streams from one sink to another is awesome for laptops with external sound card :o) But imo hw mixer (or other hw parts) are not that bad... we still have hw accelerated graphic, math,... why not sound? Also this remains me that pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1 which (I suppose) some hw mixer could do while letting cpu free for other tasks. If PA eats a lot of CPU this can have many reasons, most of them have to do with the latency settings requested by the applications or that have been configured due to frequent underruns. However the actual mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. But then again, I am happy to take patches. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC
The link https://admin.fedoraproject.org/community doesn't seem to work with konqueror. Just says 'loading' and nothing happens. Works in firefox. -- 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 Wed, 29.07.09 09:46, Karel Zak (k...@redhat.com) wrote: On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: 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. When you mean 'not wrap them', do you mean they're no longer selectable as a record source, if the hardware exports them? Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It's my opinion. Which is based on not being blind to what's happening around me. It seems that HW companies still produce the obsolete technology. Modern sound card designs don't do hw mixing anymore, it's like fm synthesis or wavetable audio. It's simply not done in hw anymore. The only exceptions are cards for gamers, i.e. Creative cards. And uh, quite frankly those cards probably only have it because they need at least something that distuingishes them from normal HDA cards. In my little array of sound cards I have here not a single one still does hw mixing. So even if I wanted to add hw mixing support to PA I couldn't because I have nothing to test with. Also given that these days you find that feature only in Creative cards and Creative is mostly anti-Free-Software I really see no point in spending a minute on adding support for this to PA even if it would make technical sense, which it doesn't. Also, let's not forget smething: DirectSound in Vista does not support hw acceleration for audio at all anymore: http://connect.creativelabs.com/openal/OpenAL%20Wiki/OpenAL%C2%AE%20and%20Windows%20Vista%E2%84%A2.aspx And CoreAudio never did either. Creative is now pushing OpenAL since they apparently believe that hw mixing just for hw mixing's sake is something that makes sense to gamers -- even though it makes no sense at all to me. But than again, if hw mixing is that important to you, I am happy to merge patches if they are clean. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- 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 Wed, 29.07.09 06:48, Jeff Garzik (jgar...@pobox.com) wrote: Karel Zak wrote: On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. Quite agreed [says a former kernel audio driver maintainer], and I will go even farther: Maybe since the times you worked on audio drivers the design of the sound cards changed a little and stuff like SSE became largely available? It is completely stupid to waste host CPU on a task that can be offloaded in parallel to dedicated audio hardware. If the user intentionally purchased expensive audio hardware with nice hardware mixing, do not subvert the user's intentions by ignoring such nice hardware. Any developer who claims always use software mixing or always use hardware mixing is a young, inexperienced fool. There are valid situations for both choices. Hear hear, Mr. Garzik is the the old experienced wise man of audio, who knows so much more about audio than any of the audio guys at Microsoft or Apple. Happy to take patches. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- 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 Wednesday 29 July 2009 15:16:20 Lennart Poettering wrote: On Wed, 29.07.09 12:33, Michal Hlavinka (mhlav...@redhat.com) wrote: This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519 .htm l PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. First, I like pulseaudio, especially the ability of moving streams from one sink to another is awesome for laptops with external sound card :o) But imo hw mixer (or other hw parts) are not that bad... we still have hw accelerated graphic, math,... why not sound? Also this remains me that pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1 which (I suppose) some hw mixer could do while letting cpu free for other tasks. If PA eats a lot of CPU this can have many reasons, most of them have to do with the latency settings requested by the applications or that have been configured due to frequent underruns. However the actual mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Well... I'm pretty sure I have no idea how it works :D I've just noticed that when playing stereo and sound card (Aureon MK II) is configured for stereo, it eats about 4 % and (when speakers are set as 5.1) only front speakers work (as expected), when I configure that card for 5.1 output and play stereo stream it goes to all 5.1 speakers and eats about 24 % of cpu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wed, 2009-07-29 at 09:10 -0400, Stephen Smalley wrote: On Wed, 2009-07-29 at 23:01 +1000, James Morris wrote: On Wed, 29 Jul 2009, Stephen Smalley wrote: So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. Once we have access control on policy itself, we may be able to provide an API where an application can toggle a boolean on itself, e.g. to perform one action with broader permissions, then switch to a tighter set of permissions. This might be implementable in a way which also prevents applications from ever gaining more permissions (via typebounds). We can actually already apply fine-grained access control on temporary changes to booleans - just specify a distinct label for the boolean in policy (via genfscon selinuxfs entries) and then control who can write to that file type. However, note that such changes affect all processes running in a given domain, so it isn't precisely the same thing as process privilege bracketing. If you want something more akin to privilege bracketing within a program, then a closer analog in SELinux would be setcon(3) to switch to a more restricted domain. But in general our goal is to enforce security goals at the system level and not depend on the correctness of the application to shed privilege. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On 07/29/2009 01:59 AM, Till Maas wrote: On Tue, Jul 28, 2009 at 01:54:20PM -0700, Toshio Kuratomi wrote: It was in my post to the last thread:: Is someone in a position to verify whether setting security flags on a bug prevents someone who would be put in the CC list by the default cc attribute would or would not let people see those bugs? Is someone in a position to tell me if watching a person in bugzilla would also let you violate this? I think people are generally amenable to autoapproving CC to watchbugzilla as long as security bugs do not send updates out to random people who have signed up to be CC'd. Knowing just how security bugs work allows us to evaluate what the risks are. How about just test this? Is the following what to think may cause trouble? 1) Security bug 12345 against package foo is created 2) Alice requests watchbugzilla for package foo 3) Alice can now watch bug 12345 Reverse steps 1 and 2. We can test this with this bug I marked as security sensitive: https://bugzilla.redhat.com/show_bug.cgi?id=472110 You can now apply for watchbugzilla here: https://admin.fedoraproject.org/pkgdb/packages/name/pam_mount According to the Bugzilla docs, only people that are already on the CC list can access restricted bugs, and this can also be disabled: http://www.bugzilla.org/docs/tip/en/html/groups.html | By default, bugs can also be seen by the Assignee, the Reporter, and by | everyone on the CC List, regardless of whether or not the bug would | typically be viewable by them. Visibility to the Reporter and CC List | can be overridden (on a per-bug basis) by bringing up the bug, finding | the section that starts with Users in the roles selected below... and | un-checking the box next to either 'Reporter' or 'CC List' (or both). This implies that autoapproving watchbugzilla would allow people to see security bugs. Is the same thing true of watching a person? till, I'm now watching till-opensource.name, if you want to open a new security bug and see if I get CC'd. -Toshi signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
The death of rhpl
We're hoping to be able to not ship rhpl for Fedora 12 -- this isn't something which is really a feature, but it might be something that a heads up is useful for. Anyone who has a package with a dependency on rhpl should have a bug filed, 98% of them with patches, to switch to using something else. If you are using rhpl and *don't* have a Requires: rhpl in your spec file (or are using it for something not in Fedora), here's the replacements for the things which were commonly used * rhpl.translate - Use python's gettext module. It's a lot more functional these days. rhpl.translate was a good idea 7 years ago, but not anymore :) * rhpl.ethtool - python-ethtool provides a module with similar/the same API * rhpl.exception - Chris Lumens has split out a new package python-meh which includes the exception handling capabilities from rhpl with the added support for filing to bugzilla like anaconda does * rhpl.keyboard* - these now live in system-config-keyboard Jeremy -- 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 Wednesday, 29 July 2009 at 15:24, Lennart Poettering wrote: On Wed, 29.07.09 06:48, Jeff Garzik (jgar...@pobox.com) wrote: Karel Zak wrote: On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. Quite agreed [says a former kernel audio driver maintainer], and I will go even farther: Maybe since the times you worked on audio drivers the design of the sound cards changed a little and stuff like SSE became largely available? It is completely stupid to waste host CPU on a task that can be offloaded in parallel to dedicated audio hardware. If the user intentionally purchased expensive audio hardware with nice hardware mixing, do not subvert the user's intentions by ignoring such nice hardware. Any developer who claims always use software mixing or always use hardware mixing is a young, inexperienced fool. There are valid situations for both choices. Hear hear, Mr. Garzik is the the old experienced wise man of audio, who knows so much more about audio than any of the audio guys at Microsoft or Apple. It's quite hypocritical of you to use an anti-open-source company (Creative) as an argument for not supporting hw mixing on one side and then touting other anti-open-source companies as examples to follow on the other. But whatever. Just please stop imposing pulseaudio on those who don't want to use it. For the record, I'm still considering leaving Fedora because - as a GNOME desktop - it's becoming unusable without pulseaudio. Making it a hard dependency for GNOME bluetooth stack in F11 went a bit too far in my opinion. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Stephen Smalley (s...@tycho.nsa.gov): On Tue, 2009-07-28 at 17:53 -0400, Bill McGonigle wrote: On 07/28/2009 04:11 PM, Chris Adams wrote: AFAIK SELinux introduces additional controls and does not replace or override existing controls. I'm pretty sure non-root still can't directly listen on a low-numbered port. For some reason I thought it was possible with MAC, but I can't find anything to support that. I might have been thinking of Solaris privileges. There was a patch floated on selinux list circa June 2007 that would have allowed SELinux to directly grant capabilities. But it met a certain amount of resistance from people concerned about the implications of changing the historical position that SELinux only further restricts access and about how to handle states like permissive mode, selinux-disabled, etc seamlessly. http://marc.info/?l=selinuxm=118159187318524w=2 http://marc.info/?l=selinuxm=118192327422630w=2 http://marc.info/?l=selinuxm=118191791828777w=2 I suppose the main problem with relying on this for granting privilege to system processes would be that if the selinux policy wasn't loaded for some reason, such processes (sshd, login, ...) would fail. The same thing can happen at the moment with capabilities for an NFS rootfs, so perhaps the same solution (falling back to classic setuid if there is no selinux policy loaded) could apply? -serge -- 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 Wed, Jul 29, 2009 at 8:39 AM, Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: On Wednesday, 29 July 2009 at 15:24, Lennart Poettering wrote: On Wed, 29.07.09 06:48, Jeff Garzik (jgar...@pobox.com) wrote: Karel Zak wrote: On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. Quite agreed [says a former kernel audio driver maintainer], and I will go even farther: Maybe since the times you worked on audio drivers the design of the sound cards changed a little and stuff like SSE became largely available? It is completely stupid to waste host CPU on a task that can be offloaded in parallel to dedicated audio hardware. If the user intentionally purchased expensive audio hardware with nice hardware mixing, do not subvert the user's intentions by ignoring such nice hardware. Any developer who claims always use software mixing or always use hardware mixing is a young, inexperienced fool. There are valid situations for both choices. Hear hear, Mr. Garzik is the the old experienced wise man of audio, who knows so much more about audio than any of the audio guys at Microsoft or Apple. It's quite hypocritical of you to use an anti-open-source company (Creative) as an argument for not supporting hw mixing on one side and then touting other anti-open-source companies as examples to follow on the other. But whatever. Just please stop imposing pulseaudio on those who don't want to use it. For the record, I'm still considering leaving Fedora because - as a GNOME desktop - it's becoming unusable without pulseaudio. Making it a hard dependency for GNOME bluetooth stack in F11 went a bit too far in my opinion. Regards, R. This is supported by the zillions of forum messages asking how to fix or remove pulseaudio. Not to mention the billion post thread here on devel. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On Wed, Jul 29, 2009 at 06:30:27AM -0700, Toshio Kuratomi wrote: Is the same thing true of watching a person? till, I'm now watching till-opensource.name, if you want to open a new security bug and see if I get CC'd. I created https://bugzilla.redhat.com/show_bug.cgi?id=514518 According to bugzilla, you did not receive any mails, but only security-response-team@ rh.. Regards Till pgpkucXsdtMK9.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wednesday 29 July 2009 09:49:29 am Serge E. Hallyn wrote: There was a patch floated on selinux list circa June 2007 that would have allowed SELinux to directly grant capabilities. But it met a certain amount of resistance from people concerned about the implications of changing the historical position that SELinux only further restricts access and about how to handle states like permissive mode, selinux-disabled, etc seamlessly. http://marc.info/?l=selinuxm=118159187318524w=2 http://marc.info/?l=selinuxm=118192327422630w=2 http://marc.info/?l=selinuxm=118191791828777w=2 I suppose the main problem with relying on this for granting privilege to system processes would be that if the selinux policy wasn't loaded for some reason, such processes (sshd, login, ...) would fail. There is also the argument that what we've been teaching people for years is that SE Linux strips away privileges and doesn't grant them. Changing the model would be somewhat confusing. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Jul 29, 2009, at 8:49 AM, Serge E. Hallyn wrote: The same thing can happen at the moment with capabilities for an NFS rootfs, prelink killed file caps on fedora last time I checked. Makes them useless for general purpose app protection. https://bugzilla.redhat.com/show_bug.cgi?id=456105 joe so perhaps the same solution (falling back to classic setuid if there is no selinux policy loaded) could apply? -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- 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 Wednesday, 29 July 2009 at 15:47, Bastien Nocera wrote: On Wed, 2009-07-29 at 15:39 +0200, Dominik 'Rathann' Mierzejewski wrote: snip It's quite hypocritical of you to use an anti-open-source company (Creative) as an argument for not supporting hw mixing on one side and then touting other anti-open-source companies as examples to follow on the other. Since when does using technology as an example mean that you condone the way companies do business? Ask Lennart. I only took his argument to its logical conclusion. Maybe we should start removing other parts of Fedora because they were inspired by, or share similar technical features to things Microsoft or Apple did before us. Ah, so dropping support for hw mixing is a great innovation. I hope you see how flawed your argument is. It was more of a ridicule than anything else. But whatever. Just please stop imposing pulseaudio on those who don't want to use it. For the record, I'm still considering leaving Fedora because - as a GNOME desktop - it's becoming unusable without pulseaudio. Making it a hard dependency for GNOME bluetooth stack in F11 went a bit too far in my opinion. I did that, and the reasons for it were discussed on this list. Nobody has made any headway into explaining how to fix the problem[1] without the hard dependency. [1]: That'd be out-of-the-box Bluetooth headset and speakers support While having support for stuff like that is great, I still would like to be able to remove pulseaudio (even it it means losing support for bluetooth headsets and speakers) without losing the rest of gnome-bluetooth. What was the problem with that? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- 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
Dne Wed, 29 Jul 2009 16:21:00 +0200 Dominik 'Rathann' Mierzejewski napsal: But whatever. Just please stop imposing pulseaudio on those who don't want to use it. For the record, I'm still considering leaving Fedora because - as a GNOME desktop - it's becoming unusable without pulseaudio. Making it a hard dependency for GNOME bluetooth stack in F11 went a bit too far in my opinion. I did that, and the reasons for it were discussed on this list. Nobody has made any headway into explaining how to fix the problem[1] without the hard dependency. [1]: That'd be out-of-the-box Bluetooth headset and speakers support While having support for stuff like that is great, I still would like to be able to remove pulseaudio (even it it means losing support for bluetooth headsets and speakers) without losing the rest of gnome-bluetooth. Dominik, if you don't want to use PA, remove only alsa-plugins-pulseaudio, then the default ALSA output won't be redirected to PA. You can leave pulseaudio package installed to satisfy the dependencies. Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora mini revisted
Hi All, I'd like some thoughts, and some help so yes, I'm opening a can of worms :-) A while a go jkatz put out a call about support for netbooks, and I begun to step up and the idea behind Fedora Mini [1] was born before being sidetracked by shiny things in the corner. snipped Is this not where LXDE\Moblin are heading? No idea about LXDE but Moblin is a component within Fedora Mini. The idea being that there's a lot of overlap between requirements of small devices so alot of effort can be saved by grouping all the interfaces together under one SIG. See the third paragraph of the original email :-) Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090729 changes
On Wed, 2009-07-29 at 11:13 +, Rawhide Report wrote: xorg-x11-server-1.6.99-21.20090724.fc12 --- * Tue Jul 28 2009 Adam Jackson a...@redhat.com 1.6.99-19.20090724 - xserver-1.6.99-randr-error-debugging.patch: Dump RANDR protocol errors to the log. - Un-package xf8_16bpp, no one cares. * Tue Jul 28 2009 Adam Jackson a...@redhat.com 1.6.99-20.20090724 - xserver-1.6.99-use-pci-access-boot.patch: Some chips (thanks Intel) will change their PCI class at runtime if you disable their VGA decode, so consider both 0x0300 and 0x0380 classes when looking for the boot VGA. * Tue Jul 28 2009 Adam Jackson a...@redhat.com 1.6.99-21.20090724 - xserver-1.6.99-right-of.patch: Default to right-of initial placement for RANDR 1.2 drivers with enough virtual space. I just want to highlight this, as it's a behaviour change that might surprise people. With this change you'll get a spanning desktop by default if possible, which matches the behaviour of every other major window system and is what you usually configured in the session anyway. The cloning heuristic was pretty losing to begin with, since the available mode lists for each output don't have a lot of commonality. There are still some rough edges here. X will center the mouse over the root window, and not over a particular screen, which is usually wrong. gdm extends the error by displaying the greeter on the screen that contains the cursor; so if for example your external display is larger than your laptop display, the cursor will be centered on the external, and gdm will show up there instead of on the LVDS like you probably expected. Known bug, we're working on it. Also, Intel gen3 hardware (915 and 945 variants) hit a corner case here, where the maximum 3d pitch is 2048 but the maximum scanout pitch is 4096. So if you're using compiz or another GL compositor in your session, you'll see garbage rendering off to the right. This isn't a _new_ problem, but you might hit it now when you didn't before. However, with KMS, we'll resize the render buffers on RANDR events, so if you switch back to cloning in your session GL compositors should look right. - ajax signature.asc Description: This is a digitally signed message part -- 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
Hi. On Wed, 29 Jul 2009 15:39:14 +0200, Dominik 'Rathann' Mierzejewski wrote: But whatever. Just please stop imposing pulseaudio on those who don't want to use it. For the record, I'm still considering leaving Fedora because - as a GNOME desktop - it's becoming unusable without pulseaudio. Making it a hard dependency for GNOME bluetooth stack in F11 went a bit too far in my opinion. I'm obviously missing something. Are you opposed to the general fact that PA packages use up your disk space, or just to the fact that PA tries to handle your audio? If the latter, I've removed alsa-plugins-pulseaudio and pointed my audip apps to alsa for sound output. As far as I can tell that removes PA from the picture. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora mini revisted
On Mon, 2009-07-27 at 21:33 +0100, Peter Robinson wrote: snip So what do people want out of a Fedora Mini SIG? Is Fedora Mini really Fedora Netbook? If so, then I'd concentrate on: - Moblin as a spin - Hardware support is pushed into the distribution The problem space is really the same as the desktop one (and both are built on the same technology), but with a UI better suited to the device. For netbooks that aren't able to run this code because of graphics drivers deficiencies, there's always the desktop SIG and spin. Making sure existing applications can run on smaller resolutions, or less powerful hardware is a task for the whole distribution, not just the Fedora Mini SIG. If the goal is to cater for OLPC's running GNOME, then the efforts are better done through the desktop SIG. If one of the goals is to help Sugar, it would better be handled through a Sugar specific list and SIG. Personally, I'd be interested in a fedora-moblin list, but not so much in a general purpose Fedora Mini list (which would probably overlap with other SIGs, say a SIG wanting to create a MythTV spin a-la Mythdora). Cheers -- 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
Lennart Poettering wrote: On Wed, 29.07.09 09:47, Jeff Garzik (jgar...@pobox.com) wrote: mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Please don't forget that hardware mixing... is more than just mixing. Modern audio hardware can offload sample rate conversion, attenuation, 3D processing, and other goodies. Interesting in which parallel universe you must be living. Modern audio hardware is usually locked to a specific sample rate, got rid of all mixer controls by going to 24bit and letting the CPU attenuate using the 8bit extra headroom. And 3d processing, and other goodies aren't avilable in newer hw designs anymore either. In fact haven't been available since quite some time in any design anymore. (With the excption of those creative cards) bzzt, sorry, thanks for playing. The world has more to offer than 2005-era motherboard audio locked at 48K. If you keeping bringing up Microsoft as a shining example, it might behoove you examine how DirectSound has evolved for modern audio. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On Wed, Jul 29, 2009 at 07:12:00AM -0700, Toshio Kuratomi wrote: On 07/29/2009 07:05 AM, Till Maas wrote: On Wed, Jul 29, 2009 at 06:30:27AM -0700, Toshio Kuratomi wrote: Is the same thing true of watching a person? till, I'm now watching till-opensource.name, if you want to open a new security bug and see if I get CC'd. I created https://bugzilla.redhat.com/show_bug.cgi?id=514518 According to bugzilla, you did not receive any mails, but only security-response-team@ rh.. Confirmed. So autoapproving watchbugzilla would open up security bugs in a way that watching a person does not. According to Tomas Hoger, who replied to the bug, creating a security sensitive bug also skips initialccs, therefore there seems to be no security issue at all with autoapproving watchbugzilla in reality afaics. I also oberserved that I was not added to the CC list of the bug, which would be the default beheaviour. Regards Till pgpbri2UiUP4Y.pgp Description: PGP signature -- 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 Wed, 2009-07-29 at 15:13 +0200, Lennart Poettering wrote: Modern sound card designs don't do hw mixing anymore, it's like fm synthesis or wavetable audio. It's simply not done in hw anymore. The only exceptions are cards for gamers, i.e. Creative cards. And uh, quite frankly those cards probably only have it because they need at least something that distuingishes them from normal HDA cards. Just out of curiosity - do modern pro cards (M-Audio etc) do hw mixing? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-07-29 at 15:26 +0200, Michal Hlavinka wrote: If PA eats a lot of CPU this can have many reasons, most of them have to do with the latency settings requested by the applications or that have been configured due to frequent underruns. However the actual mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Well... I'm pretty sure I have no idea how it works :D I've just noticed that when playing stereo and sound card (Aureon MK II) is configured for stereo, it eats about 4 % and (when speakers are set as 5.1) only front speakers work (as expected), when I configure that card for 5.1 output and play stereo stream it goes to all 5.1 speakers and eats about 24 % of cpu That's not mixing, it's multiplexing. I don't think any card has ever had hardware acceleration for that operation (though hey, I'm probably wrong ;). Mixing is what happens when you play sound from two or more applications at once. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-07-29 at 16:46 +0200, Michal Schmidt wrote: Dominik, if you don't want to use PA, remove only alsa-plugins-pulseaudio, then the default ALSA output won't be redirected to PA. You can leave pulseaudio package installed to satisfy the dependencies. That does mean a PA daemon will still be run by default and anything that, for instance, checks if PA is running and then outputs direct to PA, still will. I think this is what gstreamer's default 'auto detect' setting does. But you can re-configure that to go to ALSA directly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On 07/29/2009 08:20 AM, Till Maas wrote: On Wed, Jul 29, 2009 at 07:12:00AM -0700, Toshio Kuratomi wrote: On 07/29/2009 07:05 AM, Till Maas wrote: On Wed, Jul 29, 2009 at 06:30:27AM -0700, Toshio Kuratomi wrote: Is the same thing true of watching a person? till, I'm now watching till-opensource.name, if you want to open a new security bug and see if I get CC'd. I created https://bugzilla.redhat.com/show_bug.cgi?id=514518 According to bugzilla, you did not receive any mails, but only security-response-team@ rh.. Confirmed. So autoapproving watchbugzilla would open up security bugs in a way that watching a person does not. According to Tomas Hoger, who replied to the bug, creating a security sensitive bug also skips initialccs, therefore there seems to be no security issue at all with autoapproving watchbugzilla in reality afaics. I also oberserved that I was not added to the CC list of the bug, which would be the default beheaviour. Okay, please test this with a package that has people on the initial CC list so we've tested precisely the behaviour people are concerned about. If the initialcclist is not set when a security bug comes in I don't think there's a reason we shouldn't auto-approve watchbugzilla in pkgdb. -Toshio signature.asc Description: OpenPGP digital signature -- 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 Wed, 2009-07-29 at 15:56 +0200, Lennart Poettering wrote: On Wed, 29.07.09 09:47, Jeff Garzik (jgar...@pobox.com) wrote: mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Please don't forget that hardware mixing... is more than just mixing. Modern audio hardware can offload sample rate conversion, attenuation, 3D processing, and other goodies. Interesting in which parallel universe you must be living. Modern audio hardware is usually locked to a specific sample rate, got rid of all mixer controls by going to 24bit and letting the CPU attenuate using the 8bit extra headroom. And 3d processing, and other goodies aren't avilable in newer hw designs anymore either. In fact haven't been available since quite some time in any design anymore. (With the excption of those creative cards) Just get over it, the new designs are really dumbed down but high-quality 24bit dacs. That's all. It may be easier to resolve this if both of you would say exactly what hardware you're talking about... for the sake of argument, my local PC store sells a range of cheap cards that are just what Lennart says. For expensive consumer cards it has several Asus cards (appear to be based on CMI chips), some AuzenTechs (also CMI), and some HT Omegas (CMI again, I think I'm seeing a pattern here :). The Asus cards claim specifically that they support DirectSound in hardware. Aside from that, all the expensive cards make loud claims about Dolby and/or DTS systems for multiplexing and headphone processing, but don't make clear whether they're done in hardware or software. I didn't see anything about hardware SRC, though they probably wouldn't advertise that, it's hard to tell until you own one. My card, a Chaintech AV-710, does do SRC in hardware (you can set it to any output sampling rate you like, via the mixer), but you can't buy it any more, it was discontinued. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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, 28 Jul 2009, Lennart Poettering wrote: I'd like to ask everyone to test this new volume logic. If you don't raise your voice now that some output port is not properly detected or audio is too faint then later on you won't have any right to complain. Is there a way to test this if one does not have the luxury of re-installing one's desktop to F12 (from F11)? ObPA: I wish client volume state was kept PA side - not enjoying the frequent resets of volume in clients in F11. Bring back system-side state for volume please.. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Your mode of life will be changed to ASCII. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Trouble with koji
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, I'm trying to make a scratch build for kaya on rawhide to fix a FTBFS. Unfortunately, I have got the lollowing error message: DEBUG util.py:256: No Package Found for ghc-editline But from my view of point this package should exist. It may be nice, if anyone can help me. You may find the build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1563211 Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwyIQACgkQT2AHK6txfgxGBgCfQuiZYYlOYB9btu4oqsBe9Eqj PQ8An1k9qzfl1FqLc7fCry8s3iaFehWt =zRAL -END PGP SIGNATURE- -- 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 Wed, Jul 29, 2009 at 10:50 AM, Adam Williamson awill...@redhat.comwrote: On Wed, 2009-07-29 at 15:56 +0200, Lennart Poettering wrote: On Wed, 29.07.09 09:47, Jeff Garzik (jgar...@pobox.com) wrote: mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Please don't forget that hardware mixing... is more than just mixing. Modern audio hardware can offload sample rate conversion, attenuation, 3D processing, and other goodies. Interesting in which parallel universe you must be living. Modern audio hardware is usually locked to a specific sample rate, got rid of all mixer controls by going to 24bit and letting the CPU attenuate using the 8bit extra headroom. And 3d processing, and other goodies aren't avilable in newer hw designs anymore either. In fact haven't been available since quite some time in any design anymore. (With the excption of those creative cards) Just get over it, the new designs are really dumbed down but high-quality 24bit dacs. That's all. It may be easier to resolve this if both of you would say exactly what hardware you're talking about... for the sake of argument, my local PC store sells a range of cheap cards that are just what Lennart says. For expensive consumer cards it has several Asus cards (appear to be based on CMI chips), some AuzenTechs (also CMI), and some HT Omegas (CMI again, I think I'm seeing a pattern here :). The Asus cards claim specifically that they support DirectSound in hardware. Aside from that, all the expensive cards make loud claims about Dolby and/or DTS systems for multiplexing and headphone processing, but don't make clear whether they're done in hardware or software. I didn't see anything about hardware SRC, though they probably wouldn't advertise that, it's hard to tell until you own one. My card, a Chaintech AV-710, does do SRC in hardware (you can set it to any output sampling rate you like, via the mixer), but you can't buy it any more, it was discontinued. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list If these controls and hardware accelerated audio isn't going to work anymore, then why does Fedora still include the older OpenAL sample implementation instead of the new OpenAL Soft implementation that comes with a PulseAudio backend? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Trouble with koji
On 07/29/2009 06:09 PM, Jochen Schmitt wrote: Hallo, I'm trying to make a scratch build for kaya on rawhide to fix a FTBFS. Unfortunately, I have got the lollowing error message: DEBUG util.py:256: No Package Found for ghc-editline But from my view of point this package should exist. It may be nice, if anyone can help me. You may find the build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1563211 The build of ghc-editline creates 3 subpackages ghc-editline-devel ghc-editline-doc ghc-editline-prof but no ghc-editline base package. http://koji.fedoraproject.org/koji/buildinfo?buildID=121279 So there is no package providing ghc-editline. I don't know enough about Haskell packaging to know whether this is expected or not. -- 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 Wed, 2009-07-29 at 08:51 -0500, Dr. Diesel wrote: This is supported by the zillions of forum messages asking how to fix or remove pulseaudio. Not to mention the billion post thread here on devel. In my experience, this is a more common pattern: $POOR_NEWBIE: I have a problem with audio. $RANDOM_'HELPFUL'_PERSON: Oh, you need to remove PulseAudio! Removing PA is far too often jumped on as the 'obvious' fix for resolving any kind of audio problem whatsoever. Even if it had nothing to do with PA in the first place. In any case, there's a fairly easy, working way to disable PA that has been posted to this thread, that works in all Fedora releases. So there's no problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On Wed, 2009-07-29 at 07:12 -0700, Toshio Kuratomi wrote: On 07/29/2009 07:05 AM, Till Maas wrote: On Wed, Jul 29, 2009 at 06:30:27AM -0700, Toshio Kuratomi wrote: Is the same thing true of watching a person? till, I'm now watching till-opensource.name, if you want to open a new security bug and see if I get CC'd. I created https://bugzilla.redhat.com/show_bug.cgi?id=514518 According to bugzilla, you did not receive any mails, but only security-response-team@ rh.. Confirmed. So autoapproving watchbugzilla would open up security bugs in a way that watching a person does not. Why are we not just treating this as a bug? If the privacy model is that non-privileged people should not be notified about security bugs, then non-privileged people not be notified about security bugs, no matter whether they're using watchbugzilla or watchcommits or anything else. Relying on manual filtering by not auto-approving watch requests does not smell like the right 'fix' to me - humans are fallible, after all. Shouldn't we just treat this as a bug in Bugzilla, report it, and get it fixed? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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
Adam Williamson wrote: On Wed, 2009-07-29 at 08:51 -0500, Dr. Diesel wrote: This is supported by the zillions of forum messages asking how to fix or remove pulseaudio. Not to mention the billion post thread here on devel. In my experience, this is a more common pattern: $POOR_NEWBIE: I have a problem with audio. $RANDOM_'HELPFUL'_PERSON: Oh, you need to remove PulseAudio! Removing PA is far too often jumped on as the 'obvious' fix for resolving any kind of audio problem whatsoever. Even if it had nothing to do with PA in the first place. And? Random helpful person quickly becomes ignored person, if the advice fails to work. Problem is... removing or disabling PA often -does- solve a problem. Jeff -- 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 Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote: Adam Williamson wrote: On Wed, 2009-07-29 at 08:51 -0500, Dr. Diesel wrote: This is supported by the zillions of forum messages asking how to fix or remove pulseaudio. Not to mention the billion post thread here on devel. In my experience, this is a more common pattern: $POOR_NEWBIE: I have a problem with audio. $RANDOM_'HELPFUL'_PERSON: Oh, you need to remove PulseAudio! Removing PA is far too often jumped on as the 'obvious' fix for resolving any kind of audio problem whatsoever. Even if it had nothing to do with PA in the first place. And? Random helpful person quickly becomes ignored person, if the advice fails to work. Problem is... removing or disabling PA often -does- solve a problem. Rather, it works around it. The problems in the kernel drivers are usually still there... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Wed, 2009-07-29 at 12:39 +0200, Ralf Corsepius wrote: On 07/29/2009 08:03 AM, Adam Williamson wrote: On Tue, 2009-07-28 at 01:51 +0200, Ralf Corsepius wrote: On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: That means that you can take revisor, pungi or livecd-tools in your existing Fedora system None of these are what I am looking for. I'm terribly sorry - what color exactly did you want us to paint your fricking pony, Ralf? Plonk. That's sorta purplish pinkish black, right? - ajax signature.asc Description: This is a digitally signed message part -- 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 Wed, Jul 29, 2009 at 11:53 AM, Adam Williamson awill...@redhat.comwrote: On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote: Removing PA is far too often jumped on as the 'obvious' fix for resolving any kind of audio problem whatsoever. Even if it had nothing to do with PA in the first place. And? Random helpful person quickly becomes ignored person, if the advice fails to work. Problem is... removing or disabling PA often -does- solve a problem. There's two problems. One, it's often not the _right_ fix - there are cases where PA's interaction with ALSA reveals bugs in ALSA that otherwise stay hidden. So disabling PA 'fixes the bug', but in reality is just sweeping it under the carpet. Two, even when the bug is in PA, if everyone just goes around disabling PA, how are they going to get fixed? Telepathy? How long do we expect people to tolerate these bugs before they move on? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC
On 07/29/2009 11:12 AM, Thomas Janssen wrote: 2009/7/29 Neal Becker ndbeck...@gmail.com: The link https://admin.fedoraproject.org/community doesn't seem to work with konqueror. Just says 'loading' and nothing happens. Works in firefox. Confirmed with Konqueror 4.2.98 Hmm. How to put this nicely... Konqueror is a terrible web browser. Use something else. If you want a more detailed answer, it is that konqueror doesn't properly support javascript, specifically, jquery. See: http://dev.jquery.com/ticket/4362 http://dev.jquery.com/ticket/4725 http://docs.jquery.com/Browser_Compatibility ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Trouble with koji
On 07/29/2009 07:37 PM, Jochen Schmitt wrote: Am 29.07.2009 12:21, schrieb Mike Bonnet: The build of ghc-editline creates 3 subpackages ghc-editline-devel ghc-editline-doc ghc-editline-prof Thank you for your hint. Now it's works for Rawhide, but not for F-11. On F-11 I got DEBUG util.py:256: No Package Found for ghc-editline-devel The build you may find at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1563427 It looks like ghc-editline was only added to Fedora after F11 GA. It has been built for F11 but never pushed through bodhi, so it never made it into the Koji buildroots for F11 updates. You'll need to create and update via bodhi, or request a buildroot override by emailing rel-...@fedoraproject.org explaining why it's required (for example, so dependent packages can be built and the entire set pushed out as one update). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On 07/29/2009 10:06 AM, Steve Grubb wrote: There is also the argument that what we've been teaching people for years is that SE Linux strips away privileges and doesn't grant them. Changing the model would be somewhat confusing. Just to play the devil's hair-splitting advocate, if the kernel were enforcing less and SELinux were enforcing more, the SElinux model wouldn't have changed, 'just' the kernel's. Certainly there's a good forty years of expectation about what the kernel will enforce, though I'm not sure that's important if SELinux is preventing unwanted access. Thanks for the mailing list links from '07, those made for good reading. I think the vision of SELinux in Fedora has alot to say about what the right options are. Will Fedora ever get to the point where advice to turn off SELinux is as verboten as suggesting to chmod -R 777 to solve a problem? That is, if we can guarantee that SELinux is enforcing, a whole different set of options is open that don't exist if SELinux is an optional bolt-on. Tangentially, has anybody attempted a statistical analysis tool to gather data from systems running in permissive mode to look for policy holes, ala smolt? -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- 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 Wed, 2009-07-29 at 12:25 -0500, Dr. Diesel wrote: How long do we expect people to tolerate these bugs before they move on? I don't. However, for those doing support, there's better approaches than 'disable PA and carry on using the system'. There's some configuration tweaks you can make to PA. You can check the kernel and PA logs for clues as to what the problem may be. You can get the alsa-info.sh output and check for known issues with the hardware in question (search on subv / subd for HDA hardware). Finally, if disabling PA 'solves' the problem, you can file a bug on PA explaining the issue and the symptoms, and including the kernel and PA logs. (To get PA log output, kill the system pulseaudio instance, and run it from a console as 'pulseaudio -v', then reproduce the problem). The key point is to try and get some useful information about the problem and file a bug, so that Lennart and the kernel sound guys _know_ about it. If no bugs are filed, it's very unlikely the problem is going to be fixed. I should probably write up a Debugging page for sound / PulseAudio, actually... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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-07-28
On Wed, 2009-07-29 at 20:50 +0200, Michael Schwendt wrote: On Wed, 29 Jul 2009 00:09:30 -0700, Adam wrote: On Tue, 2009-07-28 at 23:05 -0700, Adam Williamson wrote: On Tue, 2009-07-28 at 01:29 +, Michael Schwendt wrote: synce-kde-0.9.1-4.fc11.ppc requires synce-serial vdccm-0.10.1-5.fc11.ppc requires synce-serial I thought I'd seen these addressed on the list before, but just in case: synce-serial is entirely deprecated now, it is not needed for anything. These packages should not depend on it, and synce-hal should obsolete it. Erm - actually, vdccm is obsoleted by synce-hal too. Sorry. May be true, but such a synce-hal is not in the repos yet. (Extras repoclosure does evaluate Obsoletes tags) Yes, I meant that synce-hal obsoletes vdccm in a code sense, so the package ought to have the Obsoletes set if it isn't already. Sorry to not be clear. https://admin.fedoraproject.org/updates/libopensync-plugin-synce-0.22.1-1.fc11,synce-sync-engine-0.14-1.fc11,synce-hal-0.14-1.fc11,synce-kpm-0.14-1.fc11,librra-0.14-1.fc11,librapi-0.14-1.fc11,unshield-0.6-1.fc11,libsynce-0.14-1.fc11 Submitted on 2009-07-21, still pending. Not pushed anywhere? Bodhi problem? vdccm = synce-serial is obsolete https://bugzilla.redhat.com/498409 synce-kde = synce-serial is obsolete https://bugzilla.redhat.com/498410 I'm not sure. May be just that it doesn't have the karma yet. I'll try and find time to test on my little F11 box and confirm/deny...this system runs F12. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora mini revisted
ke, 2009-07-29 kello 15:18 +0100, Bastien Nocera kirjoitti:
Is there any actual way to package Firefox extensions for Fedora? That
would probably make my installs of Firebug more up-to-date...
Yes. I maintain an extension which is C++ [1]. It's built against
xulrunner and installed under %{_libdir}/mozilla/extensions. I'm not
sure how extensions written in Javascript/XUL would be installed.
[1]
http://cvs.fedoraproject.org/viewvc/rpms/mozvoikko/devel/mozvoikko.spec?view=markup
--
Ville-Pekka Vainio
--
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 Wed, 29.07.09 20:20, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit : On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote: Problem is... removing or disabling PA often -does- solve a problem. Rather, it works around it. The problems in the kernel drivers are usually still there... Before PA a sound problem didn't freeze the GUI (effectively bricking the system for normal users). Now it can. In my case, a few months ago, it was doing so because a new PA version could not parse a manual config change advertised in Fedora's own Glitch-free audio feature page a release before. Lennart stated that all this (PA being able to pull the GUI down, PA not being able to parse what was a correct config file a version before, PA rpm performing an unsafe upgrade) was NOTABUG. Twisting my words Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Scripted mass rebuild has completed
On Wed, 2009-07-29 at 11:28 -0700, Jesse Keating wrote: The scripted part of the mass rebuild has completed, including the tag requests to move things into dist-f12. They will be in buildroots very soon. It has been pointed out that my tag script may have tagged some rebuilds that were older than normal builds done during the rebuild window. I'm looking into this now to see if I can fix it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom spot Callaway wrote: On 07/29/2009 11:12 AM, Thomas Janssen wrote: 2009/7/29 Neal Becker ndbeck...@gmail.com: The link https://admin.fedoraproject.org/community doesn't seem to work with konqueror. Just says 'loading' and nothing happens. Works in firefox. Confirmed with Konqueror 4.2.98 Hmm. How to put this nicely... Konqueror is a terrible web browser. Use something else. I find it much nicer than Firefox (integration with Firefox is...umm...nonexistent here), but it's choice anyways. /flame- war (before one starts). If you want a more detailed answer, it is that konqueror doesn't properly support javascript, specifically, jquery. See: http://dev.jquery.com/ticket/4362 http://dev.jquery.com/ticket/4725 http://docs.jquery.com/Browser_Compatibility ~spot If the Community devteam could file bugs against Konqueror and then notify the KDE-SIG about them, we can track bugs and such. Is there a test page somewhere (similar to ACID)? FWIW, 4.2.98 seems to be improved, but still not there. Arora is apparently better to (from Rex, I don't use it). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpwoxMACgkQiPi+MRHG3qRJmwCfbXHP9kJWLWFLhbUP7l4P6tLD RTAAnRifvheD/eI3A4qE0dftBBCGVu6J =KfX4 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom spot Callaway wrote: On 07/29/2009 11:12 AM, Thomas Janssen wrote: 2009/7/29 Neal Becker ndbeck...@gmail.com: The link https://admin.fedoraproject.org/community doesn't seem to work with konqueror. Just says 'loading' and nothing happens. Works in firefox. Confirmed with Konqueror 4.2.98 Hmm. How to put this nicely... Konqueror is a terrible web browser. Use something else. If you want a more detailed answer, it is that konqueror doesn't properly support javascript, specifically, jquery. See: http://dev.jquery.com/ticket/4362 http://dev.jquery.com/ticket/4725 http://docs.jquery.com/Browser_Compatibility ~spot Actually, the only things that the jQuery test page[1] says that Konqueror (4.2.4) is failing at are: 31. core module: append(String|Element|ArrayElement|jQuery) 7. Check for appending text with spaces 137. ajax module: jQuery.post(String, Hash, Function) - simple with xml 3. Expected 4 assertions, but 2 were run 197. fx module: Chain hide show 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible 198. fx module: Chain show hide 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible 199. fx module: Chain toggle in 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible 200. fx module: Chain toggle out 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible 201. fx module: Chain slideUp slideDown 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible 202. fx module: Chain slideDown slideUp 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible 203. fx module: Chain slideToggle in 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible 204. fx module: Chain slideToggle out 5. Make sure that overflow is reset (Old: visible Cur: hidden) expected: hidden actual: visible The first two seem like bugs (137 looks fixed as of 4.2.98), the last bunch like not-implemented-yet. I assume the Chain stuff is used to load/show the panels and such in the work area (pardon the ignorance of any official jargon). So once the Chain stuff is implemented, I imagine Konq should work (unless there are things that the test page doesn't test for). - --Ben [1] http://jquery.com/test -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpwqXAACgkQiPi+MRHG3qTeZgCdG21WwTwJyKgK2k/hDyLGMYVC 07wAnROMMFp2Nom4fH3i0fdrASuaAjtf =r52Y -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC
On 07/29/2009 01:28 PM, Tom spot Callaway wrote: of the two with no patches landed: http://dev.jquery.com/ticket/4362 this one lacks a konqueror bug report, or at least link. at: http://code.jquery.com/jquery-nightly.js select box val() handling seems to be done at, search for: // We need to handle select boxes special Somebody who uses either of jquery or konqueror ought to file. Fedora projects should support the browsers we ship when it's reasonable to do so. I noticed Konqueror is supposed to emit JavaScript debugging on the console, but none of the jquery test cases cause any such output. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC
2009/7/29 Tom spot Callaway tcall...@redhat.com: On 07/29/2009 11:12 AM, Thomas Janssen wrote: 2009/7/29 Neal Becker ndbeck...@gmail.com: The link https://admin.fedoraproject.org/community doesn't seem to work with konqueror. Just says 'loading' and nothing happens. Works in firefox. Confirmed with Konqueror 4.2.98 Hmm. How to put this nicely... Konqueror is a terrible web browser. Use something else. I do, i use chromium ;P Thanks by the way for your repo, much appreciated. I just confirmed it for the OP so he knows it really doesn't work and is no missconfiguration on his side. -- LG Thomas Dubium sapientiae initium -- 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 Wed, Jul 29, 2009 at 9:24 AM, Lennart Poettering mzerq...@0pointer.dewrote: On Wed, 29.07.09 06:48, Jeff Garzik (jgar...@pobox.com) wrote: Karel Zak wrote: On Tue, Jul 28, 2009 at 10:07:32PM +0200, Lennart Poettering wrote: On Tue, 28.07.09 15:48, Bill Nottingham (nott...@redhat.com) wrote: Yes. You cannot select them as record source, you cannot mute or unmute them, you cannot change their volume. CD, PC Speaker, MIDI and so on are just obsolete. This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.html PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. Quite agreed [says a former kernel audio driver maintainer], and I will go even farther: Maybe since the times you worked on audio drivers the design of the sound cards changed a little and stuff like SSE became largely available? It is completely stupid to waste host CPU on a task that can be offloaded in parallel to dedicated audio hardware. If the user intentionally purchased expensive audio hardware with nice hardware mixing, do not subvert the user's intentions by ignoring such nice hardware. Any developer who claims always use software mixing or always use hardware mixing is a young, inexperienced fool. There are valid situations for both choices. Hear hear, Mr. Garzik is the the old experienced wise man of audio, who knows so much more about audio than any of the audio guys at Microsoft or Apple. Happy to take patches. Lennart Here is a patch, 2 weeks old. https://bugzilla.redhat.com/show_bug.cgi?id=461546 -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -- 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 Wed, Jul 29, 2009 at 12:53 PM, Adam Williamson wrote: On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote: Removing PA is far too often jumped on as the 'obvious' fix for resolving any kind of audio problem whatsoever. Even if it had nothing to do with PA in the first place. And? Random helpful person quickly becomes ignored person, if the advice fails to work. Problem is... removing or disabling PA often -does- solve a problem. There's two problems. One, it's often not the _right_ fix - there are cases where PA's interaction with ALSA reveals bugs in ALSA that otherwise stay hidden. So disabling PA 'fixes the bug', but in reality is just sweeping it under the carpet. Two, even when the bug is in PA, if everyone just goes around disabling PA, how are they going to get fixed? Telepathy? Well, the fix is easy. Do I need repeat it once more? It's been a while :) Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Trouble with koji
edOn Wed, 2009-07-29 at 19:37 -0400, Jochen Schmitt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.07.2009 12:21, schrieb Mike Bonnet: The build of ghc-editline creates 3 subpackages ghc-editline-devel ghc-editline-doc ghc-editline-prof Thank you for your hint. Now it's works for Rawhide, but not for F-11. On F-11 I got DEBUG util.py:256: No Package Found for ghc-editline-devel The build you may find at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1563427 A quick query on koji http://koji.fedoraproject.org/koji/packageinfo?packageID=8851 reveals that there is a succesful Fedora 11 build (a few even). A cross-check in the updates database https://admin.fedoraproject.org/updates/search/ghc-editline reveals no updates have been submitted. So the package has to be tagged to the buildroot or be available in the updates repository, first. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090729 changes
The report shows there is a new version of rpm, version rpm-4.7.1-2.fc11.i586. The previous version, announced in the rawhide report 20090722 was rpm-4.7.1.1.fc12.i686. This update appears to be going the wrong way, and it seems strange for an f12 version to be replaced by an f11 version. I noticed this because a yum update updated my rpm from 4.7.1.1.fc12.i686 to 4.7.1.2.fc11.i586. Are there other packages that are getting onto the Rawhide updates that are from earlier versions of Fedora, and inadvertently superseding the (later) Rawhide versions? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090729 changes
On Wed, 2009-07-29 at 23:30 +0100, Quentin Armitage wrote: The report shows there is a new version of rpm, version rpm-4.7.1-2.fc11.i586. The previous version, announced in the rawhide report 20090722 was rpm-4.7.1.1.fc12.i686. This update appears to be ^ going the wrong way, and it seems strange for an f12 version to be replaced by an f11 version. I noticed this because a yum update updated my rpm from 4.7.1.1.fc12.i686 to 4.7.1.2.fc11.i586. ^^ should be dashes. Are there other packages that are getting onto the Rawhide updates that are from earlier versions of Fedora, and inadvertently superseding the (later) Rawhide versions? AFAIK when the rawhide refresh is done the newest EVR is picked up in rawhide. A look at koji http://koji.fedoraproject.org/koji/packageinfo?packageID=319 reveals that there was a 19 hour window in between the F11 and F12 build (F11 being first), so the rawhide compose has been during that window. The next refresh should pick up the correct F12 version. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090729 changes
On Wednesday 29 July 2009 05:30:57 pm Quentin Armitage wrote: The report shows there is a new version of rpm, version rpm-4.7.1-2.fc11.i586. The previous version, announced in the rawhide report 20090722 was rpm-4.7.1.1.fc12.i686. This update appears to be going the wrong way, and it seems strange for an f12 version to be replaced by an f11 version. I noticed this because a yum update updated my rpm from 4.7.1.1.fc12.i686 to 4.7.1.2.fc11.i586. Are there other packages that are getting onto the Rawhide updates that are from earlier versions of Fedora, and inadvertently superseding the (later) Rawhide versions? it was done on purpose this is because the newer rpm version build in rawhide has a dependency on the new glibc. which needs the newer rpm with xz compression. we wanted to make sure that people would be able to update there systems so we tagged in the newer one from F-11 that provides xz support but doesnt need the newer glibc. Dennis signature.asc Description: This is a digitally signed message part. -- 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 Wed, Jul 29, 2009 at 4:40 PM, Jesse Keatingjkeat...@redhat.com wrote: http://jkeating.fedorapeople.org/failed-f12-rebuilds.html xulchris (1): spambayes From build log: + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/spambayes-1.0.4 find: `debug': No such file or directory At first glance this appears to be a problem with the debuginfo script. Is this a known issue? Regards, Chris -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
From build log: + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/spambayes-1.0.4 find: `debug': No such file or directory At first glance this appears to be a problem with the debuginfo script. Is this a known issue? It should not even be run on a noarch build, I don't think. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning glade2
I'm going to orphan glade2. glade3 is the only actively maintained version of glade, and I don't see a reason to keep glade2 around any longer. Matthias -- 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 Wed, 2009-07-29 at 20:29 -0400, Todd Zullinger wrote: It has not seen a release since November of 2006. I think we should let it slip into retirement. I'm fine with seeing it go. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
Jesse Keating wrote: On Wed, 2009-07-29 at 20:29 -0400, Todd Zullinger wrote: It has not seen a release since November of 2006. I think we should let it slip into retirement. I'm fine with seeing it go. I should make it clear that I'm not the owner of cogito (Chris is), nor am I a user of it (and I don't play one on TV either). I'm just some guy on a mailing list saying that package should be retired. :) -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Nothing strengthens authority so much as silence. -- Charles De Gaulle pgp2XwbuwEUe7.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 20090729
Sorry for the delay in getting this out, I was distracted right at the end of the meeting by a coworker hovering over my desk :). Summary: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-29/fedora-meeting.2009-07-29-17.01.html Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-29/fedora-meeting.2009-07-29-17.01.log.html Note that the vote on VirtTCK was not unanimous, somehow that didn't make it into the summary but was something that we wanted to call out. 17:01:20 jds2001 #startmeeting FESCo special meeting - 2009-07-29 17:01:24 jds2001 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:01:28 * onekopaka will be here. 17:01:41 * skvidal is here 17:01:44 * cwickert is also here as Christoph Wickert 17:01:44 * notting is here 17:01:47 * nirik is here. 17:01:49 Kevin_Kofler Present. 17:01:54 * sharkcz is here 17:01:56 Kevin_Kofler onekopaka: Yeah, but you can't vote. ^^ 17:01:58 * jds2001 brings up the list 17:02:02 onekopaka Jeff_S: I know! 17:02:07 onekopaka err 17:02:10 onekopaka Kevin_Kofler: I know! 17:02:10 Gerd Gerd is also here as Gerd Pokorra 17:02:22 * Jeff_S can't vote either 17:02:24 * onekopaka will be here for the fun of it. 17:02:31 * dgilmore is here 17:02:39 dgilmore but im in another meeting also 17:02:42 onekopaka because it's fun to watch these meetings. 17:02:45 onekopaka FUN. 17:02:50 jds2001 anyhow 17:02:51 jds2001 ;et 17:02:54 jds2001 let 17:02:59 jds2001 's get started 17:03:05 jds2001 i cant type today 17:03:13 jds2001 #topic Raduko perl 6 17:03:16 * skvidal gives jds2001 a new 300 baud acoustic coupler to use 17:03:18 jds2001 .fesco 218 17:03:29 cwickert can I say something about this? 17:03:31 onekopaka perl 6? 17:03:35 jds2001 sure 17:03:43 cwickert first of all I feel like people who voted were not really informed 17:03:50 dgilmore -1 17:03:53 cwickert somebody claimed we were still waiting for something. 17:03:57 Kevin_Kofler +1, seems they can get it in, and if not it can always be punted later. 17:03:58 cwickert this is not correct. the 'something was released three days before. 17:04:06 cwickert we have a building package now 17:04:07 dgilmore this feature is 33% done and feature freeze is past 17:04:10 jds2001 right, we didnt think you had a working interpreter at all. 17:04:17 jds2001 but now you do :) 17:04:23 skvidal cwickert: fortunately we don't have to be informed to vote - it's just like the american electorate :) 17:04:26 Kevin_Kofler I think we should approve this. 17:04:31 cwickert skvidal: ;) 17:04:32 Kevin_Kofler It's a new package, it can't break anything. 17:04:52 cwickert dgilmore: the feature does not need to be at 100% for feature freeze 17:04:56 Kevin_Kofler So even if it gets completed a few days late due to upstream scheduling, that won't affect Fedora in any negative way. 17:05:12 cwickert we did it in a couple of days, so please let us try 17:05:22 Kevin_Kofler And if it really fails, we can always postpone it to F13 later. 17:05:44 cwickert Kevin_Kofler: we are in contact with upstream, at least Gerd works with them closely 17:05:45 * jds2001 says to let them try 17:05:58 * onekopaka would say +1. 17:05:59 nirik is someone planning on reviewing that package? it's still in new. ;) 17:06:03 dgilmore cwickert: it should be very close 17:06:12 skvidal so I'm confused 17:06:19 Kevin_Kofler dgilmore: It's a new package, it can't break anything. 17:06:20 cwickert nirik: I will and I think lubomir will too 17:06:21 Kevin_Kofler It can go in late. 17:06:37 skvidal cwickert: if we don't approve this as a feature - how does it stop you from working on it? 17:06:38 dgilmore Kevin_Kofler: doesnt matter 17:06:41 Kevin_Kofler I'm sure rel-eng can let it in. 17:06:56 cwickert skvidal: nothing, but Fedora won't benefit then 17:06:56 dgilmore skvidal: it doesnt 17:06:58 nirik skvidal: it doesn't, it just doesn't get advertised. 17:07:05 nirik (or as much) 17:07:07 Kevin_Kofler dgilmore: Freeze exemptions have been granted for new packages in several cases. 17:07:10 skvidal cwickert: fedora benefits from it how? 17:07:15 Kevin_Kofler The rationale is: it can't hurt. 17:07:32 Kevin_Kofler skvidal: It supports a new language which is going to be the next big thing in the Perl community. 17:07:38 cwickert if we have a working perl6 binary, fedora can be used by teachers to show their students the future of perl 17:07:46 Kevin_Kofler Maybe KDE 5 or even some later 4.x will even require it. 17:07:48 cwickert we could hae it in the devel spin as well 17:08:04 Kevin_Kofler (Current KDE requires Perl 5 for some things, e.g. kconf_update and some build-time scripts.) 17:08:08 cwickert Fedora will be a better platform for developers 17:08:13 * nirik looks at the feature freeze page. 17:08:14 skvidal cwickert: again 17:08:18 skvidal nothing says it can't get it 17:08:21 skvidal just that it is not a feature 17:08:26 skvidal see what I mean? 17:08:30 Kevin_Kofler skvidal: Why is it not a feature? 17:08:37 skvidal if we
Re: Orphaning glade2
On Wed, Jul 29, 2009 at 08:41:49PM -0400, Matthias Clasen wrote: I'm going to orphan glade2. glade3 is the only actively maintained version of glade, and I don't see a reason to keep glade2 around any longer. You should probably retire glade2 if nobody rejects. For more information look at this page: https://fedoraproject.org/wiki/Retired_packages Regards Till pgpiyad8clALY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/kmess/F-11 kmess.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On Wed, Jul 29, 2009 at 06:36:42PM -0500, Jason L Tibbitts III wrote: SMP == Steven M Parrish tuxbr...@fedoraproject.org writes: SMP Summary: A MSN Messenger Clone Please don't build a package with this summary. Please explain why. Regards Till pgpkbPjcHnHO3.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/kmess/F-11 kmess.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
TM == Till Maas opensou...@till.name writes: TM Please explain why. The details are in the review ticket; I neglected to check where my message was going before I sent it. But basically, it's not permissible to say your package is a clone of X where X is a trademark. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 20090729
On Thu, 30 Jul 2009 03:52:04 +0200 Till Maas opensou...@till.name wrote: On Wed, Jul 29, 2009 at 09:39:50PM -0400, Jon Stanley wrote: 17:03:13 jds2001 #topic Raduko perl 6 17:03:16 * skvidal gives jds2001 a new 300 baud acoustic coupler to use 17:03:18 jds2001 .fesco 218 17:03:29 cwickert can I say something about this? 17:03:31 onekopaka perl 6? 17:03:35 jds2001 sure Again the log seems to be incomplete. If I type .fesco 218 in #feedora-meeting, I get this line from zodbot: | zodbot tyll: #218 (Rakudo Perl 6 - | https://fedoraproject.org/wiki/Features/Rakudo_Perl_6) - FESCo - Trac - | https://fedorahosted.org/fesco/ticket/218 But the log does not contain such a line near the .fesco 218 from jds2001. I have brought this issue up to the upstream meetbot author. I suspect it's the _s in there that are confusing it. Will get it tracked down and fixed up. Regards Till kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
Jesse Keating wrote: http://jkeating.fedorapeople.org/failed-f12-rebuilds.html chunkd should be fixed as soon as wait-repo permits :) Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
2009/7/29 Toshio Kuratomi a.bad...@gmail.com: Okay, please test this with a package that has people on the initial CC list so we've tested precisely the behaviour people are concerned about. If the initialcclist is not set when a security bug comes in I don't think there's a reason we shouldn't auto-approve watchbugzilla in pkgdb. I think, that we should treat this as an issue - user should be added to watchlist for sensitive bugs, only if he is in commits group (which means, that he can fix security bugs). If he just in watchbugzilla, then he shouldn't see such tickets. Anyway, we should autoapprove watchcommits, at least. -- With best regards, Peter Lemenkov. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On 07/29/2009 08:41 PM, Peter Lemenkov wrote: 2009/7/29 Toshio Kuratomi a.bad...@gmail.com: Okay, please test this with a package that has people on the initial CC list so we've tested precisely the behaviour people are concerned about. If the initialcclist is not set when a security bug comes in I don't think there's a reason we shouldn't auto-approve watchbugzilla in pkgdb. I think, that we should treat this as an issue - user should be added to watchlist for sensitive bugs, only if he is in commits group (which means, that he can fix security bugs). If he just in watchbugzilla, then he shouldn't see such tickets. AFAIK, this can't be done because there is only one initialcclist field in bugzilla. So at the bugzilla level, you can either apply the cclist or not apply the cclist. Can't have both. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090729 changes
clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) Since there is no separate clutter-cairo, shouldn't clutter-cairomm be discontinued? Cheerio, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- 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 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.i686.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? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Ok. Looks like this one _may_ fulfill our calendering needs. Testing required.
Hi, I am quite frightened to take up this topic again and again lest you all be bored. But interestingly, this one http://publictest15.fedoraproject.org/calender/ can fulfill all our requisites. But, I don't use a calender on my phone, so I never used remote export/import etc. And no surprise that I shall not be able to test it fully. So, if someone who is familiar with these help me out, it will be nice. Thanks. [1] https://fedorahosted.org/fedora-infrastructure/ticket/1197 -- Regards, Susmit. = ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit = ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required.
Also to note - WebCalendar is rather inaccessible to users without JavaScript, whether WCAG are to be followed / are a requirement I don't know - just thought I'd point it out. I also don't like their usage of JavaScript - it's very messy! Cheers, David JM Emmett ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
