Re: [Fedora-cs-list] Preklad Release Notes
On Sun, 26 Jul 2009, Josef Hruška wrote: Ahoj, pokusil jsem se o preklad Release Notes Fedory 11 do cestiny: https://translate.fedoraproject.org/projects/docs-release-notes/f11-tx/view/po/cs.po. Teto prace i iniciativy si velice vazim! Vzhedem k tomu, ze pro jednoho cloveka je preklad temer tisice polozek docela dost, a ze nekterym tematum (softwaru, nastrojum) ani prilis nerozumim, chtel bych take timto poprosit o pomoc s dotazenim prekladu do finalnejsi podoby - da se povazovat bez jakekoliv kontroly kvality. Pomoci muze prakticky kdokoliv, napr. ze zkontroluje preklepy, gramaticke chyby, :( apod. V soucastne verzi PO je to trochu necitelne. Pokud se neozve nikdo, ze vi jak preklad dostat misto toho ceskeho prekladu na web, pokusim se zjistit co a jak, protoze toto je rozhodne lepsi nez co tam je, a bude se to i lepe cist. Jsou vsak vitani take ti, kdo maji patricne technicke znalosti softwaru/nastroju zminovanych v RN. Priznavam, ze nemam IT vzdelani, takze u nekterych veci (a ze jich nebylo zrovna malo) jsem netusil ani ktera bije. Presto doufam, ze jsem preci jen pomohl, nez ublizil. No, nekamenujte me, priste to snad bude lepsi. Zatim nemam nijak predstavu jak postupovat, pokud nas bude pracovat na prekladu vic... takze navrhy vitany. Jak jsem naznacil - pokusim se dostat preklad na docs.fedoraproject.org Pepa Hruška -- Fedora-cs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-cs-list http://fedoraproject.org/ Jeste jednou diky. Adam Pribyl-- Fedora-cs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-cs-list http://fedoraproject.org/
Re: fedora 11 worst then ever release
On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are FIXED RAWHIDE, only. * anaconda's depsolving failed when upgrading an FC10 + FC10-updates system due to NEVR issues. If you have any details of the failure, it would help. Unfortunately no. I had not been involved into upgrading the system this had happened to from the beginning. I was called to troubleshoot this upgrade. The situation I found was a partially upgraded system, stuck on upgrading yum due to a rpm conflict on yum itself. No idea how the person trying to upgrade managed to get into this situation. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: openssh-blacklist - careless waste of space.
On Fri, Jul 24, 2009 at 05:30:27PM +0300, Yanko Kaneti wrote: openssh-blacklist-0.7-1.fc11.src.rpm - size 1072930614 http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372950 openssh-blacklist-0.7-1.fc10.src.rpm - size 1072930519 http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372948 openssh-blacklist-0.7-1.fc12.src.rpm - size 1072930637 http://koji.fedoraproject.org/koji/rpminfo?rpmID=1372843 ~3GB to produce 3 ~15MB rpms of copied ~20MB fingerprints. and it is the biggest source RPM on my mirror in the development branch 646584862 2009-05-27 15:37 nexuiz-data-2.5.1-1.fc12.src.rpm 1072930637 2009-07-22 12:43 openssh-blacklist-0.7-1.fc12.src.rpm (nexuiz-data being the second with probably more useful data) Adrian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
On Sun, 26 Jul 2009 22:17:32 +0200 Simon Wesp cassmod...@fedoraproject.org wrote: nopaste is back... http://agriffis.n01se.net/nopaste/nopaste-2.1 you should include this instead of pearl-App-Nopaste.. the big benefit would be that the package would be alive in epel 4 and 5 again.. sounds good to me. perl-App-Nopaste isn't a good replacement for nopaste as Jason Farell mentoined in Bug #504108 Comment 10 before -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Fedora 12 Schedule (take 2)
On Sun, 2009-07-26 at 20:59 -0700, John Poelstra wrote: Mark McLoughlin said the following on 07/24/2009 05:55 AM Pacific Time: On Mon, 2009-07-13 at 21:09 -0700, John Poelstra wrote: http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng.ics In the F-11 schedule, we had 85 days between Feature Freeze and GA. And then GA slipped by two weeks. In the F-12 schedule, we now have 99 days between Feature Freeze and GA. For Fedora 12 An extra week was added to accommodate Linux plumbers conference, etc...https://fedorahosted.org/rel-eng/ticket/1271 In addition there are four weeks in the Fedora 12 schedule for Alpha (previously known as Beta) versus the three weeks in Fedora 11--this was an oversight in the setting of the Fedora 11 schedule which did not allow for three weekly snapshots. Okay, the extra two weeks are to allow for (rel-eng?) people being missing during plumbers and to allow for a third snapshot between alpha and beta. That makes sense on the face of it, but the end result for developers is a release cycle split into a 49 day development period followed by a 99 day stablization period. That's quite conservative for a bleeding edge distro. Constructive suggestion for the next cycle - we should go back to a shorter gap between Feature Freeze and GA. Cheers, Mark. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
On Sun, 26 Jul 2009 22:17:32 +0200 Simon Wesp cassmod...@fedoraproject.org wrote: nopaste is back... http://agriffis.n01se.net/nopaste/nopaste-2.1 you should include this instead of pearl-App-Nopaste.. - Zitierten Text ausblenden - the big benefit would be that the package would be alive in epel 4 and 5 again.. sounds good to me. perl-App-Nopaste isn't a good replacement for nopaste as Jason Farell mentoined in Bug #504108 Comment 10 before -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On 25/07/09 07:14, Simo Sorce wrote: What's the value of labeling packets based on source/destination ports ? Doesn't seem to add any new information. Indeed. Security marking can add an additional IP header, so that a multilevel operating system on one machine can pass those multiple levels of data across an intervening network. -- Glen Turner -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Lack of perl(Glib::MakeHelper) module?
Now it is time to rebuild the packages for Fedora 12. I try to rebuild my maintained package. When I rebuild my perl-Gnome2-Wnck and perl-Goo-Canvas, it fails and shows that it needs Glib::MakeHelper but it can not find. But in the past when I submitted and build these two package, it is OK. I do not know whether another perl module packages will meet this problem or not. As I see it, it is possible that perl-Glib has a bug. But I can not make sure. These are perl-Gnome2-Wnck and perl-Goo-Canvas build logs. perl-Gnome2-Wnck: http://koji.fedoraproject.org/koji/getfile?taskID=1523997name=build.log perl-Goo-Canvas: http://koji.fedoraproject.org/koji/getfile?taskID=1523891name=build.log Is Glib::MakeHelper moved into perl-Glib-devel? But I think rpmbuild is able to detect and add it into spec file automatically. If it is really a bug, I will write a bug report on bugzilla. At last, perl-Glib has announced 1.222 version. Please maintainer upgrade it. -- urlhttp://liangsuilong.co.cc/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/26/2009 09:28 PM, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? Well, to some extend, I am blaming it, because a) filling '/' may easily kill a system and may easily cause further damage (processes running in parallel to preupgrade might be malfunctioning due lack of diskspace). b) I expect an installer to be able to check whether sufficient space is available in advance, rsp. not to leave a system in an unusable state in case of something going wrong. In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183 I questioned whether using /var/cache/yum is a good choice for preupgrade's package cache. Though I meanwhile know that this BZ is was a side-effect of the nfs-parser bugs in anaconda, I still think using /root or /tmp would be better choices. No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). /root is not supposed to be used by random apps. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. - 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: fedora 11 worst then ever release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are FIXED RAWHIDE, only. That's true. anaconda is unique in that the only way a new one can be released to fix installation issues for users is to generate new media. If the problem is confined to the second stage of the installer, we can put the fix in to an updates.img. We do this for common bugs when a release comes out, but we cannot spend all of our time constantly releasing updates.img files: https://fedoraproject.org/wiki/Common_F11_bugs We continue to fix problems reported against Fedora 11's anaconda in rawhide, but for users needing the fix in the latest stable release, consider Fedora Unity. Fedora Unity generates new spins of the latest stable release including backports of anaconda fixes: http://www.fedoraunity.org/ No guarantees of what Fedora Unity contains, but I know they follow the rawhide anaconda and pick out fixes that work for the latest stable release and generate new installation media. You also get the benefit of having all current stable updates for F-11 rolled up in to the installation media. - -- David Cantrell dcantr...@redhat.com Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkptcuEACgkQ5hsjjIy1VklUDwCg3VaxUZcccm4X2io9BffrPWBP NagAnRS0EuOe/RFaynGENwrN/8RD9kI4 =6ACn -END PGP SIGNATURE--- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
2009/7/26 Simon Wesp cassmod...@fedoraproject.org nopaste is back... http://agriffis.n01se.net/nopaste/nopaste-2.1 you should include this instead of pearl-App-Nopaste.. the big benefit would be that the package would be alive in epel 4 and 5 again.. sounds good to me. perl-App-Nopaste isn't a good replacement for nopaste as Jason Farell mentoined in Bug #504108 Comment 10 before -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
2009/7/26 Simon Wesp cassmod...@fedoraproject.org nopaste is back... http://agriffis.n01se.net/nopaste/nopaste-2.1 you should include this instead of pearl-App-Nopaste.. the big benefit would be that the package would be alive in epel 4 and 5 again.. sounds good to me. perl-App-Nopaste isn't a good replacement for nopaste as Jason Farell mentoined in Bug #504108 Comment 10 before -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lack of perl(Glib::MakeHelper) module?
2009/7/27 梁穗隆 liangsuil...@gmail.com: Now it is time to rebuild the packages for Fedora 12. I try to rebuild my maintained package. When I rebuild my perl-Gnome2-Wnck and perl-Goo-Canvas, it fails and shows that it needs Glib::MakeHelper but it can not find. But in the past when I submitted and build these two package, it is OK. I do not know whether another perl module packages will meet this problem or not. As I see it, it is possible that perl-Glib has a bug. But I can not make sure. These are perl-Gnome2-Wnck and perl-Goo-Canvas build logs. perl-Gnome2-Wnck: http://koji.fedoraproject.org/koji/getfile?taskID=1523997name=build.log perl-Goo-Canvas: http://koji.fedoraproject.org/koji/getfile?taskID=1523891name=build.log Is Glib::MakeHelper moved into perl-Glib-devel? But I think rpmbuild is able to detect and add it into spec file automatically. You have to tweak your build Requires: from BuildRequires: perl(Glib) = 1.180 to BuildRequires: perl(Glib::MakeHelper) = 1.180 As reported from this bug: https://bugzilla.redhat.com/show_bug.cgi?id=509419 Nicolas (kwizart) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Testing libsatsolver on Fedora
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.
--
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: fedora 11 worst then ever release
On 07/27/2009 11:26 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are FIXED RAWHIDE, only. That's true. anaconda is unique in that the only way a new one can be released to fix installation issues for users is to generate new media. Exactly = this bug is _not fixed_. We continue to fix problems reported against Fedora 11's anaconda in rawhide, but for users needing the fix in the latest stable release, consider Fedora Unity. Fedora Unity generates new spins of the latest stable release including backports of anaconda fixes: http://www.fedoraunity.org/ 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. Openly said, I think this management mistake is one of the culprits for the poor shape of Fedora. Another one is not having banned FIXED RAWHIDE/UPSTREAM. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What to do with release number on new EL-5 branch
Hi,
There is nothing wrong with starting at 9-5.
Using the disttag can make it clearer that a package comes from epel as
opposed to someone installing the Fedora package onto an EL-5 system and
expecting it to work.
https://fedoraproject.org/wiki/Packaging/DistTag
-Toshio
Er, I am not saying don't use dist, just that starting at 5%{?dist} instead
of 1%{?dist} is completely fine.
Thanks for the advice; I'll leave it as 9-5%{?dist}.
(Sorry for any confusion - I wasn't going to remove %{?dist}.)
Rich
--
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 07/27/2009 11:25 AM, drago01 wrote: On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/26/2009 09:28 PM, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? Well, to some extend, I am blaming it, because a) filling '/' may easily kill a system and may easily cause further damage (processes running in parallel to preupgrade might be malfunctioning due lack of diskspace). b) I expect an installer to be able to check whether sufficient space is available in advance, rsp. not to leave a system in an unusable state in case of something going wrong. In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183 I questioned whether using /var/cache/yum is a good choice for preupgrade's package cache. Though I meanwhile know that this BZ is was a side-effect of the nfs-parser bugs in anaconda, I still think using /root or /tmp would be better choices. No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). Your problem, if you are using a non-reboot persistant /tmp On my machines, various subdirs of /var are nfs mounted and spread across a network. /root is not supposed to be used by random apps. This is not a random app permanently using a filesystem. It is the user root running an application to set up a personal temporary filesystem to be used exclusively by him. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090727 changes
Compose started at Mon Jul 27 06:15:04 UTC 2009 New package audtty A ncurses based terminal client for the Audacious New package clutter-imcontext IMContext Framework Library for Clutter New package comoonics-cluster-py Comoonics cluster configuration utilities written in Python New package osr-dracut-module Dracut modules for open sharedroot New package sap A small CLI audio player New package verilator A fast simulator for synthesizable Verilog New package virtuoso-opensource A high-performance object-relational SQL database Updated Packages: amtu-1.0.8-1.fc12 - * Sun Jul 26 2009 Steve Grubb sgr...@redhat.com 1.0.8-1 - new upstream version - Add init script for bootup system check * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.7-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild apr-1.3.7-2.fc12 * Sun Jul 26 2009 Bojan Smojver bo...@rexursive.com - 1.3.7-1 - bump up to 1.3.7 * Sun Jul 26 2009 Bojan Smojver bo...@rexursive.com - 1.3.7-2 - include apr_cv_sock_cloexec too * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.3.6-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild aria2-1.5.1-2.fc12 -- blitz-0.9-12.fc12 - * Sun Jul 26 2009 Sergio Pascual sergiopr at fedoraproject.org - 0.9-12 - Noarch doc subpackage * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.9-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild blogtk-1.1-13.fc12 -- * Sun Jul 26 2009 Paul W. Frields sticks...@gmail.com - 1.1-13 - Fix config file naming (#501183) * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.1-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild brasero-2.27.4-3.fc12 - * Sun Jul 26 2009 Matthias Clasne mcla...@redhat.com - 2.27.4-3 - Move ChangeLog to -devel to save some space * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.27.4-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild clutter-gst-0.9.0-1.fc12 * Sat Jul 25 2009 Bastien Nocera bnoc...@redhat.com 0.9.0-1 - Update to 0.9.0 * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.8.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild colossus-0-0.5.20090726svn4462.fc12 --- * Sun Jul 26 2009 Bruno Wolff III br...@wolff.to - 0-0.5.20090726svn4462 - Just when I thought it would be safe to rebase, a new public test build was released - Details at http://colossus.sourceforge.net/public-testing/docs/RecentChangesDetails.html - Rebase to 4462 * Sat Jul 25 2009 Bruno Wolff III br...@wolff.to - 0-0.4.20090725svn4454 - Fix for off by one roll, movement roll in master board header - Rebase to 4454 * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0-0.3.20090710svn4432 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild dracut-0.7-2.fc12 - * Sun Jul 26 2009 Harald Hoyer har...@redhat.com 0.7-1 - build without /sbin/switch_root emacs-common-ebib-1.8.0-1.fc12 -- * Sun Jul 26 2009 Jonathan G. Underwood jonathan.underw...@gmail.com - 1.8.0-1 - Update to version 1.8.0 - Correct typo in spec file changelog * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild geoclue-0.11.1.1-0.8.20090310git3a31d26.fc12 * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.11.1.1-0.8.20090310git3a31d26 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild gkrellm-volume-2.1.13-10.fc12 - * Sat Jul 25 2009 Ville Skyttä ville.skytta at iki.fi - 2.1.13-10 - Make dependency on gkrellm ISA qualified. - Use %global instead of %define. * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.1.13-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild gnome-disk-utility-0.4-3.fc12 - * Mon Jul 27 2009 Matthias Clasen mcla...@redhat.com - 0.4-3.fc12 - Drop PolicyKit from .pc files, too * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.4-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild hosts3d-1.00-3.fc12 --- * Sun Jul 26 2009 Rex Dieter rdie...@fedoraproject.org - 1.00-3 - FTBFS hosts3d-0.98-1.fc11 (#511623) * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.00-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Tue Jul 07 2009 Simon Wesp cassmod...@fedoraproject.org -
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 1:38 PM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/27/2009 11:25 AM, drago01 wrote: On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/26/2009 09:28 PM, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? Well, to some extend, I am blaming it, because a) filling '/' may easily kill a system and may easily cause further damage (processes running in parallel to preupgrade might be malfunctioning due lack of diskspace). b) I expect an installer to be able to check whether sufficient space is available in advance, rsp. not to leave a system in an unusable state in case of something going wrong. In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183 I questioned whether using /var/cache/yum is a good choice for preupgrade's package cache. Though I meanwhile know that this BZ is was a side-effect of the nfs-parser bugs in anaconda, I still think using /root or /tmp would be better choices. No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). Your problem, if you are using a non-reboot persistant /tmp What kind of argument is that? Your problem for not using a big enough /var partition ;) I don't care about the stuff in /tmp across reboots, and this has been no issue for now. Well the best way to solve this is default to /var/cache/yum but make it configureable for people that insists on another location. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Fedora 12 Schedule (take 2)
On Mon, Jul 27, 2009 at 08:40:04 +0100, Mark McLoughlin mar...@redhat.com wrote: Constructive suggestion for the next cycle - we should go back to a shorter gap between Feature Freeze and GA. Isn't development for the N+2 release supposed to start at the branch point and not GA of N+1? I think that is likely to happen at alpha (formerly known as beta) this time around. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Sun, 26 Jul 2009, Bill McGonigle wrote: On 07/26/2009 09:06 AM, Seth Vidal wrote: can you tell me even one such distro+release when this happened? it's never happened with any of the redhat, fedora, rhel releases. fc1-fc2 fc6-fc7 rhel4-rhel5 It's not new. Is this where we branch to debate a release-number super-epoch? I can see some virtue to this - but it'll just make for more game playing. I think we're probably better off pursuing the auto-qa mechanisms we've been planning. Those will enable us to check to make sure that things aren't sideways before we release the bits. -sv -- 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, 27 Jul 2009, Michael Schroeder 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? is libsatsolver supporting file deps as well? Thanks! -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Steve Grubb (sgr...@redhat.com): On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. I should elaborate more. The issue is that sometimes there are secrets that root admins have access to that should not be available to semi-trusted daemons. For example, any private keys in /root or /etc. You do not want any daemon that could be compromised to have access to these. So, its safest just to set the permissions to 0005 so that they have no access to /root. But 0555 will also prevent root without CAP_DAC_OVERRIDE from writing, no? Using 0005 will mean root also needs CAP_DAC_OVERRIDE to read/execute, which seems a bit much. Suddenly it needs extra privilege if i just want it to be able to execute /bin/date. That actually seems less secure in any real system. I expect a few corner cases, but other than /etc/resolve.conf I don't know of any problems. -Steve -- 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: fedora 11 worst then ever release
Hi. On Mon, 27 Jul 2009 13:38:09 +0200, Ralf Corsepius wrote: No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). Your problem, if you are using a non-reboot persistant /tmp I'd think that something that depends on files in /tmp surviving a reboot is definitely broken. There's a reason it's called 'tmp'. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote: Quoting Steve Grubb (sgr...@redhat.com): On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. I should elaborate more. The issue is that sometimes there are secrets that root admins have access to that should not be available to semi-trusted daemons. For example, any private keys in /root or /etc. You do not want any daemon that could be compromised to have access to these. So, its safest just to set the permissions to 0005 so that they have no access to /root. But 0555 will also prevent root without CAP_DAC_OVERRIDE from writing, no? True. After some thought, I guess most secrets that a partially trusted root daemon may attempt to access would be in /root, /etc, /var, and /home. Perhaps those are the ones that need the extra tight permissions? Using 0005 will mean root also needs CAP_DAC_OVERRIDE to read/execute, which seems a bit much. Suddenly it needs extra privilege if i just want it to be able to execute /bin/date. That actually seems less secure in any real system. # ls -l /bin/date -rwxr-xr-x 1 root root 69296 2009-03-02 08:57 /bin/date The file is 0755 and therefore is executable by anyone. DAC_OVERRIDE is not needed for anything but writing to the file as in yum update. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On 07/24/2009 04:55 PM, Steve Grubb wrote: I don't think I explained it well. I was thinking what if you had this rule: -A INPUT -Z cups_t -j ACCEPT and then cups was compromised and started listening on port 80. Since the above rule has no port restrictions and cups is allowed to accept connections, would cups now be able to start serving web pages? -Steve That would be a bad rule. The Apache example I posted only makes sense because Apache can be listening on pretty much any port anyway (every http deployment I see is stranger than the last). For cups it is a lot rarer for an admin to configure a strange port, so we'd want to combine -Z with further rules like port and host restrictions. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 3:14 PM, Ralf Ertzingerfed...@camperquake.de wrote: Hi. On Mon, 27 Jul 2009 13:38:09 +0200, Ralf Corsepius wrote: No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). Your problem, if you are using a non-reboot persistant /tmp I'd think that something that depends on files in /tmp surviving a reboot is definitely broken. There's a reason it's called 'tmp'. Exactly. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Clipboard manager by default in Fedora 12
On 07/26/2009 07:32 AM, Julian Aloofi wrote: Oops, I meant Fedora 12 when I wrote this: I don't think that would count as a feature, and it isn't one. It's basically a program every system should have (in my opinion). The Gnome clipboard isn't working great. I often get complaints from new users I introduce to Fedora that their clipboard content was lost when they closed Firefox, or something similar. And it's true, I don't trust the default Gnome CopyPaste to keep anything in it when I'm not running a clipboard manager and don't close any apps just in case. It would be really nice to have a clipboard manager by default on the Live CD (GNOME and XFCE, KDE already has klipper). When I look in the repos for available clipboard managers, I see glipper, parcellite and the XFCE plugin (xfce4-clipman-plugin). glipper is 111 k, and parcellite is 114, so it shouldn't be a difference of size. I personally would recommend parcellite, because it's pretty lightweight and works good (and I use it myself :D). What do you think about that? I think this would improve the user experience and add functionality to the desktop. I get the feeling you haven't pushed the GNOME clipboard in awhile. Its perfectly fine. The Firefox issue was always Firefox's fault. Its designed to keep information from leaking out of the browser. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Clipboard manager by default in Fedora 11
On 26/07/09 05:06, Julian Aloofi wrote: I don't think that would count as a feature, and it isn't one. It's basically a program every system should have (in my opinion). The Gnome clipboard isn't working great. I often get complaints from new users I introduce to Fedora that their clipboard content was lost when they closed Firefox, or something similar. I'd like to see some consistency between how apps handle clipboard content, when 1. The user highlights content and pastes using the middle mouse button 2. The user uses the copy paste menu options or hot keys. -- Ian Chapman. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Applications install should be idiot proof
On Sun, 26 Jul 2009, Ben Boeckel wrote: Would these be a comps-like system? Could they replace comps with tags like -required and -recommended tag suffixes (my knowledge of the inner working of comps is limited)? Or would they be marked in pkgdb or the spec file? Links to information would be nice; I'd like such a system :) . no - this is not a comps replacement. This is a simple tag system. The info is in the pkgdb but made available for the repodata so that yum (et. al) can get to it. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Clipboard manager by default in Fedora 12
On 27.07.2009 15:49, Casey Dahlin wrote: On 07/26/2009 07:32 AM, Julian Aloofi wrote: Oops, I meant Fedora 12 when I wrote this: I don't think that would count as a feature, and it isn't one. It's basically a program every system should have (in my opinion). The Gnome clipboard isn't working great. I often get complaints from new users I introduce to Fedora that their clipboard content was lost when they closed Firefox, or something similar. And it's true, I don't trust the default Gnome CopyPaste to keep anything in it when I'm not running a clipboard manager and don't close any apps just in case. It would be really nice to have a clipboard manager by default on the Live CD (GNOME and XFCE, KDE already has klipper). When I look in the repos for available clipboard managers, I see glipper, parcellite and the XFCE plugin (xfce4-clipman-plugin). glipper is 111 k, and parcellite is 114, so it shouldn't be a difference of size. I personally would recommend parcellite, because it's pretty lightweight and works good (and I use it myself :D). What do you think about that? I think this would improve the user experience and add functionality to the desktop. I get the feeling you haven't pushed the GNOME clipboard in awhile. Its perfectly fine. The Firefox issue was always Firefox's fault. Its designed to keep information from leaking out of the browser. --CJD Hi all, that's interesting, 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 Mon, Jul 27, 2009 at 09:04:13AM -0400, Seth Vidal wrote:
is libsatsolver supporting file deps as well?
Yes, it downloads filelists.xml.gz if a file dep is not matching the
standard filter regexps.
Btw, there are surprisingly many of such deps in fedora, like:
/lib/lsb/init-functions
/usr/include/infiniband/verbs.h
/usr/lib/libz.so
/usr/lib64/util-vserver/sigexec
/usr/libexec/poker3d/underware
/usr/share/X11/rgb.txt
/usr/share/aclocal
/usr/share/desktop-menu-patches/redhat-audio-player.desktop
/usr/share/emacs/site-lisp
/usr/share/fonts/dejavu/DejaVuSans-Bold.ttf
/usr/share/java/ecj.jar
/var/lib/PolicyKit-public
...
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: Clipboard manager by default in Fedora 12
On 07/27/2009 07:49 AM, Casey Dahlin wrote: The Firefox issue was always Firefox's fault. Its designed to keep information from leaking out of the browser. Seriously? Do you have any reference source for this information? AFAIK, the real truth is that this behaviour is a a result of how X protocol is designed: http://www.pixelbeat.org/docs/xclipboard.html Note it's the X application itself that maintains the storage for what it puts on the buffers, which makes a lot of sense when you think about it, especially considering X's network transparency. But that means when you close the application the content of the clipboard and selection buffer are lost. You can get around this behaviour by using an external application to manage the storage for the clipboard, the standard one being xclipboard. Note this is the reason why it's awkward to get a command line program to paste to the clipboard. It has to fork and run until no longer required (someone else pastes to the clipboard). See xsel http://www.vergenet.net/%7Econrad/software/xsel/ for an example of this. -- thufor -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Mon, 27 Jul 2009, Daniel J Walsh wrote: This is all fascinating conversation. But the question still arises, why can't anyone use SECMARK/IPTABLES rules on a Targeted policy system. My opinion is that it is still too difficult. Well, it's taken years to get all the basic technology into place (including CIPSO and Labeled IPSec), and no work at all has gone into usability as yet. I envisage providing high-level abstractions in one of two ways: a) Building network labeling into a project as a standard configurable aspect of that (e.g. virtualized secure networking for VM to VM communication), which is integrated into and managed by the existing management tool, like we have with sVirt. No policy knowledge is required, just how to use e.g. virt-manager to configure sharing via the network. b) Network design tools which let you visually design and manage protected communications paths between processes on different machines, e.g. for managing your DMZ. This would generate policy and distribute it to systems on the network really be something for advanced users, but domain-specific i.e. thinking in terms of network security vs. SELinux policy. Note that there was never any intention for people to have to know the low-level SELinux policy (as far as I recall). The high-level abstractions we're building with kiosk mode, svirt, sandbox etc. are some glimpses into where things are headed now that we have most of the base technology in place. - 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: fedora 11 worst then ever release
On 07/27/2009 03:39 PM, Emmanuel Seyman wrote: * Ralf Corsepius [27/07/2009 13:49] : Your problem, if you are using a non-reboot persistant /tmp Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Filesystem Hierarchy Standard v2.3 Well, I yes I mixed up /tmp with /var/tmp. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote: On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. I agree with this, with some caveats. Capabilities are hard to reason about, and not just because they're coarse-grained. Practically speaking they don't get used, so kernel developers are careless about picking the right capable() check for a given action, since it ends up being a fancy way of checking current-euid. To pick a favorite example: CAP_SYS_RAWIO is documented to mean iopl, ioperm, and /dev/kcore. It actually means significantly more than that. It's effectively equivalent to root, though, because write access to /dev/kcore means you can change your uid. You might like it to mean can do raw I/O to peripherals like the name suggests, but the one most useful thing that could mean - r/w maps of PCI BARs - is covered under CAP_SYS_ADMIN instead. Which is not merely equivalent to root, but so coarse that it's basically useless. So it's hard for me to justify trying to make X use capabilities, since I'm not meaningfully limiting X's privileges in doing so. Caps are also wrong in that they're effectively a partitioning of root's privileges above those of a user. You would like the ability to do more than that. For example, you'd like to be able to remove your ability to clone() or exec(). SELinux can do this, kinda. And, of course, at an implementation level caps are just a dword bitmask, which is not nearly enough granularity. However, the inheritance model is _not_ hard to reason about. I find it slightly easier to understand than selinux transitions, in fact. And capabilities have the notable advantage of being something I can drop for myself when I don't need them, a safety model I'm used to from setuid. I would like to use SELinux as a defensive development practice, but I'm not aware of any good way to do so. All I have is the hope that the user is running with the policy enabled. - 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: rpms/rubygem-rails/devel .cvsignore, 1.8, 1.9 import.log, 1.1, 1.2 rubygem-rails.spec, 1.13, 1.14 sources, 1.8, 1.9
Mamoru Tasaka wrote:
Hello:
Jeroen van Meeuwen wrote, at 07/26/2009 07:42 PM +9:00:
Author: kanarip
Update of /cvs/pkgs/rpms/rubygem-rails/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28785/devel
Modified Files:
.cvsignore import.log rubygem-rails.spec sources Log Message:
2.3.3-1
snip
+# Delete zero-length files
+find %{buildroot}/%{geminstdir} -type f -size 0c -exec rm -rvf {} \;
+
snip
%changelog
-* Wed Jul 24 2009 Scott Seago sse...@redhat.com - 2.3.2-3
-- Remove the 'delete zero length files' bit, as some of these are
needed.
-
-* Wed May 6 2009 David Lutterkort lut...@redhat.com - 2.3.2-2
-- Fix replacement of shebang lines; broke scripts/generate (bz 496480)
+* Sun Jul 26 2009 Jeroen van Meeuwen j.van.meeu...@ogd.nl - 2.3.3-1
+- New upstream version
* Mon Mar 16 2009 Jeroen van Meeuwen j.van.meeu...@ogd.nl - 2.3.2-1
- New upstream version
Please check out CVS module before committing your change.
You have reverted the changes by Scott Seago to fix bug 496480.
Especially please be very careful when using cvs-import.sh as using
cvs-import.sh will easily lead to this type of reverting.
Regards,
Mamoru
This change also clobbers lutter's fix in build 2.3.2-2. Please
re-generate the 2.3.3 spec file based on all of the fixes made to the
2.3.2 spec updates.
In addition, what are there fixes in 2.3.3 that are really needed for
F11? Unless there are 2.3.3 fixes bugs in 2.3.2 here that are currently
breaking people in F11, it might be better to leave F11 at 2.3.2.
Scott
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Fedora 12 Schedule (take 2)
On Mon, 2009-07-27 at 08:40 +0100, Mark McLoughlin wrote: Constructive suggestion for the next cycle - we should go back to a shorter gap between Feature Freeze and GA. With No Frozen Rawhide approved, the scheduling will look a tad bit different. Please review https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal and consider how that effects time between development start, feature freeze, and GA. -- 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
Wednesday special session FESCo meeting
I've heard back from a few of the FESCo members, and it looks like we're going to do a special session on Wednesday at 17:00UTC in #fedora-meeting in order to knock out a few last features for Fedora 12. I just wanted to drop a note saying that it was happening, the agenda is still dynamic right now, so anything that I sent out would surely be stale by the time of the meeting. I'll probably send out a full agenda tomorrow after work (US/Eastern). You can follow the current agenda real time at https://fedorahosted.org/fesco/report/9 as always. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora Packaging Committee Seat Filled
Thanks to everyone who applied for this open seat. We got a lot of very qualified individuals who were interested in filling the open seat on the Fedora Packaging Committee. After much discussion and thought, I've asked Jon Ciesla to fill the open seat and he has accepted. I'm sure that we will have additional openings on the FPC in the future, as people move on to other tasks, or get committed to various mental institutions. ;) Please feel free to throw your name in the ring for future openings! A few points that I felt might be worth making: * If you're not an active package maintainer in Fedora, it definitely hurts your chances of being on the FPC, as we're always looking for people who are intimately involved with Fedora packaging. * If you haven't done many Fedora Package Reviews, it's a great way to increase your visibility in the Fedora Packaging Community space, and also is a good way to show us that you have a solid understanding of the existing Fedora Packaging Guidelines. Plus, it helps us get new packages into Fedora! Thanks again to all who applied, ~spot ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Release Engineering meeting summary for 2009-07-27
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-27/fedora-meeting.2009-07-27-18.03.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-27/fedora-meeting.2009-07-27-18.03.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-27/fedora-meeting.2009-07-27-18.03.log.html Meeting log --- * **roll call** (f13-18:03:33_) * **old business** (f13-18:07:57_) * **orphans (old business)** (f13-18:08:31_) * **FAD (old business)** (f13-18:09:22_) * **gpg purging in koji (old business)** (f13-18:10:08_) * *ACTION*: f13 will file a ticket about koji-gc signature script needing work to be current. (f13-18:11:09_) * **Critical Path (old business)** (f13-18:11:41_) * *ACTION*: lmacken to report next week on bodhi changes for Critical Path Packages (f13-18:12:45_) * *ACTION*: f13 will get offtrack packaged and make tag-request functional. (f13-18:13:50_) * *ACTION*: skvidal will file a bodhi ticket to define the changes we want to see for critical path packages (f13-18:19:07_) * **mass rebuild** (f13-18:24:04_) * *ACTION*: once rebuilds finish, lists will be generated of failed/needed rebuilds (f13-18:27:24_) * *ACTION*: f13 once rebuilds finish, lists will be generated of failed/needed rebuilds (f13-18:27:31_) * *ACTION*: dgilmore will draft (with help) an SOP for managing rpm changes in rawhide. (f13-18:33:58_) * **No Frozen Rawhide** (f13-18:45:05_) * *LINK*: https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal for the logs (f13-18:45:24_) * *ACTION*: f13 to file a ticket with bodhi to get changes in to support no frozen rawhide (f13-18:46:18_) * *LINK*: https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal (wwoods-18:51:05_) * **Rawhide fixup for rpm deps** (f13-18:51:46_) * *AGREED*: We will build a bumped .f11 package and tag it directly into rawhide (but not push it as an update in F11) (f13-18:57:05_) * *ACTION*: notting will build, tag, and inform the rpm team about the rpm changes. (f13-18:57:18_) * **Fedora 12 Alpha** (f13-18:57:50_) * *ACTION*: f13 will investigate why we aren't getting installer images in rawhide (f13-18:58:27_) * **Package Signing** (f13-18:58:58_) * **open floor** (f13-19:03:40_) -- 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: fedora 11 worst then ever release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 11:26 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are FIXED RAWHIDE, only. That's true. anaconda is unique in that the only way a new one can be released to fix installation issues for users is to generate new media. Exactly = this bug is _not fixed_. We continue to fix problems reported against Fedora 11's anaconda in rawhide, but for users needing the fix in the latest stable release, consider Fedora Unity. Fedora Unity generates new spins of the latest stable release including backports of anaconda fixes: http://www.fedoraunity.org/ 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. Openly said, I think this management mistake is one of the culprits for the poor shape of Fedora. Another one is not having banned FIXED RAWHIDE/UPSTREAM. The problem here is when do you stop generating new media to fix bugs in F-11's installer and start working on F-12? Never? A week after F-11 GA? What determines if an installer bug gets a fix in F-11 vs. not? It's a gigantic waste of time for the installer team to release updates to F-11's installer. We can address those bugs in rawhide and have them fixed in the next stable release. Generating new media for an existing release is not a great solution. The mirrors are already synced up with the GA release. Here's what we do and I think it works best for now given the incredibly short (and damn near impossible to work with) planning and development windows for Fedora releases: 1) Major installation problems are documented on the Common Bugs wiki page for the Fedora release in question. Either a workaround or updates.img file is provided to fix the issue. 2) New bugs come in and we address them in rawhide. Where we run in to issues here is asking people to test the next build of rawhide. Not everyone wants to do that (or can, has time, etc). But spending our time producing new media and/or updates.img files for F-11 takes away from our time to work on F-12. This is where I think Fedora Unity can bridge the gap. They can pick up fixes for F-11 installation problems and roll new media for users. That provides a non-rawhide solution for the reporter, lets the bug at least get some testing, and frees us [installer team] from having to produce media or updates.img files for F-11. A larger problem we have is that we don't get the wide testing on the Alpha, Beta, or Release Candidate releases of the upcoming Fedora release. The same group of people generally test things out and the QA team performs their tests, but we never get the same testing exposure that a GA release does. Most users are sitting around waiting for the GA release and when they find a bug, it's too late for us to do anything about it in that release. Maybe if we lengthened the development cycle for a Fedora release and renamed Alpha, Beta, and RC to .0, .1, and .2, users would think differently of each release. - -- David Cantrell dcantr...@redhat.com
Updated Anaconda packages
On 07/28/2009 01:11 AM, David Cantrell wrote: The problem here is when do you stop generating new media to fix bugs in F-11's installer and start working on F-12? Never? A week after F-11 GA? What determines if an installer bug gets a fix in F-11 vs. not? It's a gigantic waste of time for the installer team to release updates to F-11's installer. We can address those bugs in rawhide and have them fixed in the next stable release. Can you push the fixes as updates for Anaconda in Fedora 11? Fedora Unity isn't the only one doing updated images. It is increasingly becoming useful to have updated Anaconda packages available within the official repository as updates. If the Anaconda team doesn't want to do it, hand over that work to Jeroen van Meeuwen. He has already volunteered to take care of it and since he is doing it anyway for the unity images, his work could benefit more people. The only thing you got to do is give him commit access. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning some packages
I am orphaning this packages because i don't have time to maintain them. clutterhttps://admin.fedoraproject.org/pkgdb/packages/name/clutter?_csrf_token=7d5cb9303441cf36d1b4fcb4a5432efeed555f38-- Open Source software library for creating rich graphical user interfaces clutter-cairohttps://admin.fedoraproject.org/pkgdb/packages/name/clutter-cairo?_csrf_token=7d5cb9303441cf36d1b4fcb4a5432efeed555f38-- A basic Cairo clutter widget clutter-gsthttps://admin.fedoraproject.org/pkgdb/packages/name/clutter-gst?_csrf_token=7d5cb9303441cf36d1b4fcb4a5432efeed555f38-- ClutterMedia interface to GStreamer clutter-gtkhttps://admin.fedoraproject.org/pkgdb/packages/name/clutter-gtk?_csrf_token=7d5cb9303441cf36d1b4fcb4a5432efeed555f38-- A basic GTK clutter widget pyclutterhttps://admin.fedoraproject.org/pkgdb/packages/name/pyclutter?_csrf_token=7d5cb9303441cf36d1b4fcb4a5432efeed555f38-- Python modules that allow you to use the Clutter toolkit Regards. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
Rahul Sundaram wrote: On 07/28/2009 01:11 AM, David Cantrell wrote: The problem here is when do you stop generating new media to fix bugs in F-11's installer and start working on F-12? Never? A week after F-11 GA? What determines if an installer bug gets a fix in F-11 vs. not? It's a gigantic waste of time for the installer team to release updates to F-11's installer. We can address those bugs in rawhide and have them fixed in the next stable release. Can you push the fixes as updates for Anaconda in Fedora 11? Fedora Unity isn't the only one doing updated images. It is increasingly becoming useful to have updated Anaconda packages available within the official repository as updates. If the Anaconda team doesn't want to do it, hand over that work to Jeroen van Meeuwen. He has already volunteered to take care of it and since he is doing it anyway for the unity images, his work could benefit more people. The only thing you got to do is give him commit access. Honestly, I always thought Fedora install images should be regenerated far more frequently. I think back to my days as a Solaris sysadmin in the late 90's, where ordering the latest media kit (CD-ROM) from Sun meant I got a fresh installer, fresh kernel, and all recommended patches. Even in the face of known Linux kernel bugs, people always seemed reluctant to regenerate the Fedora install images. I think Fedora would better serve its users by being much more willing to update install images after initial release. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages
I have grabbed everything, please let me know if I can help with anything else. co-maintaners are always welcome. On Mon, Jul 27, 2009 at 4:59 PM, Allisson Azevedoallis...@gmail.com wrote: I am orphaning this packages because i don't have time to maintain them. clutter -- Open Source software library for creating rich graphical user interfaces clutter-cairo -- A basic Cairo clutter widget clutter-gst -- ClutterMedia interface to GStreamer clutter-gtk -- A basic GTK clutter widget pyclutter -- Python modules that allow you to use the Clutter toolkit Regards. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages
On Mon, 2009-07-27 at 16:59 -0300, Allisson Azevedo wrote: I am orphaning this packages because i don't have time to maintain them. clutter -- Open Source software library for creating rich graphical user interfaces clutter-cairo -- A basic Cairo clutter widget clutter-gst -- ClutterMedia interface to GStreamer clutter-gtk -- A basic GTK clutter widget pyclutter -- Python modules that allow you to use the Clutter toolkit I can certainly pick up clutter (in fact, I may have already been a co-owner of it...) I don't really mind doing the rest, but I'd prefer to have a co-owner since I'm likely to miss upstream releases and otherwise be not be that attentive at times... I don't actually use them at all. - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages
On 07/28/2009 01:38 AM, Itamar Reis Peixoto wrote: I have grabbed everything, please let me know if I can help with anything else. co-maintaners are always welcome. That was fast. I applied to be a co-maintainer for all of them. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Monday, July 27 2009, Jeff Garzik said: Honestly, I always thought Fedora install images should be regenerated far more frequently. I think back to my days as a Solaris sysadmin in the late 90's, where ordering the latest media kit (CD-ROM) from Sun meant I got a fresh installer, fresh kernel, and all recommended patches. And Sun was doing those media kits roughly every six to twelve months from what I remember. And our (major) release frequency is every six months, so ... Even in the face of known Linux kernel bugs, people always seemed reluctant to regenerate the Fedora install images. I think Fedora would better serve its users by being much more willing to update install images after initial release. 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], ... When our releases are at most six months apart, how much effort are we willing to divert from the next release to make this happen? It's not going to happen for free. Jeremy [1] What gets respun? All the images (DVD, live, etc)? Some of them? If some, which ones? How do we differentiate between them? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
Once upon a time, Jeff Garzik jgar...@pobox.com said: I think back to my days as a Solaris sysadmin in the late 90's, where ordering the latest media kit (CD-ROM) from Sun meant I got a fresh installer, fresh kernel, and all recommended patches. IIRC Sun only spun that a couple of times per year though (at most maybe once per quarter, but I don't remember it being that often). That was also because installing Sun recommended patch clusters was another kind of cluster. :-) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- 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 07/26/2009 03:06 PM, Seth Vidal wrote: On Sun, 26 Jul 2009, Farkas Levente wrote: who think about that his system will not working after doing everything as it has to be. can you tell me any other distro (including windows!) where the system installer not working after upgrade? It happens all the time on lots of systems. I've had it happen on debian upgrades, slackware upgrades (granted that was long ago) and many fedora and rhel upgrades. can you tell me even one such distro+release when this happened? it's never happened with any of the redhat, fedora, rhel releases. fc1-fc2 fc6-fc7 rhel4-rhel5 It's not new. just to be correct neither fc6-fc7 nor rhel4-rhel5 break any system tools! and i don't remember to fc1-fc2. -- Levente Si vis pacem para bellum! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, 27 Jul 2009, Farkas Levente wrote: fc1-fc2 fc6-fc7 rhel4-rhel5 It's not new. just to be correct neither fc6-fc7 nor rhel4-rhel5 break any system tools! and i don't remember to fc1-fc2. fc6-fc7 had a couple of fun metadata breaks rhel4-rhel5 upgrades are neither supported (iirc) nor likely to work consistently in my experience b/c of how much things changed between them. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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. So I'd like to get things moving forward again, no matter how slowly, for Fedora 12. At FudCon I started that moving [2] with the hope of getting some form of support for Intel's Moblin [3] in F-12 and there's a few package reviews [4] that I'd like some help with if people have time to review them :-) Moving forward I'd like to have some discussion about what people would like out of Fedora Mini. What is the expectation of Fedora on a NetBook/NetTop/MID style device? Is it worth having separate mailing list, or keeping the discussion on fedora-devel. My thoughts on that last point are mixed. Moving it onto another list allows it to be focused and while keeping the discussion clear of what ever the current heated discussion is also keeps it clear of general mainstream discussions where Fedora Mini can contribute or benefit. My personal thoughts are it could be alot, whether it be a NetBook or NetTop device like a eeePC, a mobile device based on the GNOME Mobile stack, a set top box running elisa or a thin terminal running a web broweser, voip client and some form of remote desktop technology. I have 2 main Fedora Mini devices 1) OLPC XO and a eeePC so I can't support it all so I'd like some help. I started to document some of the NetBook hardware [5] and it would be great to get some form of Hardware matrix together to see what's supported out of the box in Fedora, what's supported through 3rd party repositories and what's, well, not supported. Are people able to step up or help out here? My wiki skills aren't the best and Fedora as a group probably has alot of the Fedora Mini devices out there to document the hardware into as nice I want a small device to do blah and I want it to run Fedora what's my best option so we could probably do with one of the wiki elite to do a basic working layout and to keep it sane and having people with the various devices fill in the blanks. So what do people want out of a Fedora Mini SIG? Cheers, Peter BTW we have an irc channel at #fedora-mini. I'm on there most of the time now and try to keep an eye on it as best I can while doing the rest of my life so feel free to drop in and ask questions, I'll get to them as I can :-) [1] https://fedoraproject.org/wiki/SIGs/FedoraMini [2] https://fedoraproject.org/wiki/FUDCon_Berlin_and_LinuxTag_2009_talks [3] https://fedoraproject.org/wiki/Features/FedoraMoblin [4] https://bugzilla.redhat.com/show_bug.cgi?id=506446 [5] https://fedoraproject.org/wiki/SIGs/FedoraMini/Hardware -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, Jul 27, 2009 at 04:30:55PM -0400, Seth Vidal wrote: On Mon, 27 Jul 2009, Farkas Levente wrote: fc1-fc2 fc6-fc7 rhel4-rhel5 It's not new. just to be correct neither fc6-fc7 nor rhel4-rhel5 break any system tools! and i don't remember to fc1-fc2. fc6-fc7 had a couple of fun metadata breaks rhel4-rhel5 upgrades are neither supported (iirc) nor likely to work consistently in my experience b/c of how much things changed between them. A live in place RHEL upgrade via something like 'yum' may not be supported, but I believe that an Anaconda based upgrade is fully supported. Though 'supported' might include you having to redo customizations to config files the like. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages
clutter-cairo -- A basic Cairo clutter widget This one is deprecated upsteam and merged into clutter, I've already done most of the rawhide dead package stuff in bug [1] it just needs the obsoletes added to clutter. Cheers, Peter [1] https://bugzilla.redhat.com/show_bug.cgi?id=507389 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Mon, 27 Jul 2009, Daniel P. Berrange wrote: On Mon, Jul 27, 2009 at 04:30:55PM -0400, Seth Vidal wrote: On Mon, 27 Jul 2009, Farkas Levente wrote: fc1-fc2 fc6-fc7 rhel4-rhel5 It's not new. just to be correct neither fc6-fc7 nor rhel4-rhel5 break any system tools! and i don't remember to fc1-fc2. fc6-fc7 had a couple of fun metadata breaks rhel4-rhel5 upgrades are neither supported (iirc) nor likely to work consistently in my experience b/c of how much things changed between them. A live in place RHEL upgrade via something like 'yum' may not be supported, but I believe that an Anaconda based upgrade is fully supported. Though 'supported' might include you having to redo customizations to config files the like. agreed and most importantly - all discussions of what is or is not possible for rhel is offsubject. My bad for even mentioning it. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages
On Mon, Jul 27, 2009 at 9:12 PM, Owen Taylorotay...@redhat.com wrote: On Mon, 2009-07-27 at 16:59 -0300, Allisson Azevedo wrote: I am orphaning this packages because i don't have time to maintain them. clutter -- Open Source software library for creating rich graphical user interfaces clutter-cairo -- A basic Cairo clutter widget clutter-gst -- ClutterMedia interface to GStreamer clutter-gtk -- A basic GTK clutter widget pyclutter -- Python modules that allow you to use the Clutter toolkit I can certainly pick up clutter (in fact, I may have already been a co-owner of it...) I don't really mind doing the rest, but I'd prefer to have a co-owner since I'm likely to miss upstream releases and otherwise be not be that attentive at times... I don't actually use them at all. Bastien Nocera has been helpfully doing all the clutter* 0.9.x updates during the current rawhide series. Cheers, Peter -- 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/27/2009 04:45 PM, Rahul Sundaram wrote: What's the eventual goal? Not to speak for Michael or his ambitions, but I was curious and found this on the openSUSE site: http://en.opensuse.org/Package_Management/Sat_Solver -especially- http://en.opensuse.org/Package_Management/Sat_Solver/Basics in part: Conclusion Using SAT solver algorithms solve many of the problems the old solver had * speed: magnitudes faster * reliable results * extendibility[sic]: implementation of complex dependencies is easy * sensible error reports Improving Fedora dependency solving speed by just one order of magnitude would be lovely, the plural is deliriously attractive. -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: Updated Anaconda packages
On 07/28/2009 03:14 AM, David Cantrell wrote: I've been doing that for Jeroen. He's submitting patchsets for review and I've built at least a few anaconda updates for him. He is currently testing updates for F-11 and when that's ready, he'll submit the patches for review for anaconda and we can do an update. That's good news. Thanks for doing it. Are these test packages available publicly? Rahul -- 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/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], ... Not quite true. Instead of building all images, you could build a minimalist network install image, which installs from Everything+updates. I don't know how you build images, but it's hard to image building such an image frequently (e.g. whenever any package it contains has changed) is such kind of expensive. An alternative would be, to ship a script to let people build such an image themselves. It would not help everybody in all situations, but it at least help people who have some (other) version of Fedora running somewhere. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
Once upon a time, Jeff Garzik jgar...@pobox.com said: Chris Adams wrote: IIRC Sun only spun that a couple of times per year though (at most maybe once per quarter, but I don't remember it being that often). Incorrect, for our shop at least. They regenerated every month, and were dated thusly. I saw releases dated monthly, but I never saw releases that had actually been updated every month (but that may have just been me). They might have moved to quarterly in the 2000's, after the Internet bubble; I dunno. I was doing Linux by then :) Oh, I was off of Slowaris in mid-1998. Sun also charged bucket-loads of money at the time for Solaris support, so I expect they could afford the QA. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Tuesday, July 28 2009, Ralf Corsepius said: 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], ... Not quite true. Instead of building all images, you could build a minimalist network install image, which installs from Everything+updates. Except that the majority of our users don't do an install in that fashion, so you're going to be helping the 1% case that least needs help. I don't know how you build images, but it's hard to image building such an image frequently (e.g. whenever any package it contains has changed) is such kind of expensive. The build time, test time[1], mirror time/space is all still there... those are the expensive parts. An alternative would be, to ship a script to let people build such an image themselves. It would not help everybody in all situations, but it at least help people who have some (other) version of Fedora running somewhere. As it turns out, we ship all the tools to build the distribution the exact way we do! And as David said, he's been working with Jeroen for occasional updated anaconda packages. Jeremy [1] And associated find bug/fix bug/respin cycle times -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090727 changes
Hi, kernel-2.6.31-0.94.rc4.fc12 --- * Fri Jul 24 2009 Chuck Ebbert cebb...@redhat.com - Enable CONFIG_DEBUG_KOBJECT in debug kernels. (#513606) * Fri Jul 24 2009 Kristian Høgsberg k...@redhat.com - Add drm-page-flip.patch to support vsynced page flipping on intel chipsets. - Really add patch. - Fix patch to not break nouveau. Sorry, nouveau is still broken due the kernel. Works fine under 2.6.31-0.81.rc3.git4.fc12.i686.PAE, but nothing since. I've a GF7600 on this box. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! 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: Lower Process Capabilities
On Mon, Jul 27, 2009 at 5:29 PM, Adam Jacksona...@redhat.com wrote: On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote: On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. I agree with this, with some caveats. Capabilities are hard to reason about, and not just because they're coarse-grained. Practically speaking they don't get used, so kernel developers are careless about picking the right capable() check for a given action, since it ends up being a fancy way of checking current-euid. To pick a favorite example: CAP_SYS_RAWIO is documented to mean iopl, ioperm, and /dev/kcore. It actually means significantly more than that. It's effectively equivalent to root, though, because write access to /dev/kcore means you can change your uid. You might like it to mean can do raw I/O to peripherals like the name suggests, but the one most useful thing that could mean - r/w maps of PCI BARs - is covered under CAP_SYS_ADMIN instead. Which is not merely equivalent to root, but so coarse that it's basically useless. So it's hard for me to justify trying to make X use capabilities, since I'm not meaningfully limiting X's privileges in doing so. Caps are also wrong in that they're effectively a partitioning of root's privileges above those of a user. You would like the ability to do more than that. For example, you'd like to be able to remove your ability to clone() or exec(). SELinux can do this, kinda. Put an example, thanks. And, of course, at an implementation level caps are just a dword bitmask, which is not nearly enough granularity. However, the inheritance model is _not_ hard to reason about. I find it slightly easier to understand than selinux transitions, in fact. And capabilities have the notable advantage of being something I can drop for myself when I don't need them, a safety model I'm used to from setuid. I would like to use SELinux as a defensive development practice, but I'm not aware of any good way to do so. All I have is the hope that the user is running with the policy enabled. - ajax -- 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: Updated Anaconda packages
OK, in which package can I find your mkimage script. revisor ? livecd-tools ? pungi ? Just pick the one you prefer :) -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: On Tuesday, July 28 2009, Ralf Corsepius said: An alternative would be, to ship a script to let people build such an image themselves. It would not help everybody in all situations, but it at least help people who have some (other) version of Fedora running somewhere. As it turns out, we ship all the tools to build the distribution the exact way we do! And as David said, he's been working with Jeroen for occasional updated anaconda packages. Jeroen also kindly publishes those packages here: http://www.kanarip.com/anaconda/ That means that you can take revisor, pungi or livecd-tools in your existing Fedora system (or in a VM, or mock, I believe), and build an ISO that includes the updated anaconda, and all updates up until present time. These tools have been available for many releases now. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On Mon, Jul 27, 2009 at 12:14:08PM -1000, David Cantrell wrote: On Tue, 28 Jul 2009, Rahul Sundaram wrote: On 07/28/2009 03:14 AM, David Cantrell wrote: I've been doing that for Jeroen. He's submitting patchsets for review and I've built at least a few anaconda updates for him. He is currently testing updates for F-11 and when that's ready, he'll submit the patches for review for anaconda and we can do an update. That's good news. Thanks for doing it. Are these test packages available publicly? You'll have to ask Jeroen how he handles testing. Once he has a patchset suitable for an F-11 update, he submits it for review and then we go from there. The idea being that once we roll the update for F-11, he'll be ready to pick it up and make images. http://www.kanarip.com/anaconda/ ...is what you want, I think. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- 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/28/2009 12:14 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 28 Jul 2009, Rahul Sundaram wrote: On 07/28/2009 03:14 AM, David Cantrell wrote: I've been doing that for Jeroen. He's submitting patchsets for review and I've built at least a few anaconda updates for him. He is currently testing updates for F-11 and when that's ready, he'll submit the patches for review for anaconda and we can do an update. That's good news. Thanks for doing it. Are these test packages available publicly? You'll have to ask Jeroen how he handles testing. Once he has a patchset suitable for an F-11 update, he submits it for review and then we go from there. The idea being that once we roll the update for F-11, he'll be ready to pick it up and make images. There a source repository online at: - git://git.kanarip.com/anaconda, or - http://git.kanarip.com/?p=anaconda There's two YUM repositories online, and public; - http://www.kanarip.com/anaconda/ - stable - http://www.kanarip.com/anaconda-devel/ - unstable The testing is handled by our very adequate friends in the test team of Fedora Unity. Furthermore, by the time the updates are available in the official upstream repository, the product has already hit the streets. It's the rest of the world that needs the update to be available in the official repositories; I can do what I want wrt. the Fedora Unity Re-Spins. However, I'm also upstream for that one other utility people use to Remix, Re-Spin, whathaveyou. To have them ask me again and again and again why things don't work, or why things can't be fixed, made me ship the stable anaconda fixes repository in every default Revisor configuration. Now, I've requested anaconda commit access for stable branches since like forever, since the anaconda team does not want to touch these anymore, I've offered to be on the receiving end of bugs for these branches, so it wouldn't hit the upstream developers, I've requested GIT commit access years ago in order to be able to work with the upstream developers, but so far only David Cantrell and Hans de Goede are willing to help me. David pushes out an update to anaconda every now and then, and Hans reviews lists of commits I'm thinking about cherry-picking from rawhide to the stable fX-branch -because frankly that's all I do until I'm allowed to sink my teeth in it. -- Jeroen -- 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/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. -- Jeroen -- 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/28/2009 04:49 AM, Paul W. Frields wrote: http://www.kanarip.com/anaconda/ ...is what you want, I think. Yes but I want in the official repository as an update. Fedora 11 Anaconda has been troublesome for many people due to the storage layer rewrite. It would have been nice to avoid that issues in the first place but since we are never going to be perfect, the next best thing would be to push Anaconda updates into the repository so that people do images with the updates rolled in can get it without going through Yet Another Place. Usually whenever I do a remix, one of the first questions I get is from people who are using my kickstart file to do something slightly different (change the package set, configuration et all). There is a large number of people who would benefit from this. Either Anaconda team has to do this by itself or if the workload is high (which I assume it is), give other people commit access to push it into the official repository as updates. Given that someone has volunteered to do the work, our job would be to enable that to happen instead of being a roadblock. The need now is more than ever thanks to the growing success of the push from the Fedora Project for spins and remixes. Rahul -- 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/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. Ralf -- 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/28/2009 01:43 AM, Jeroen van Meeuwen wrote: On 07/28/2009 12:54 AM, Ralf Corsepius wrote: On 07/28/2009 12:27 AM, Jeremy Katz wrote: As it turns out, we ship all the tools to build the distribution the exact way we do! And as David said, he's been working with Jeroen for occasional updated anaconda packages. OK, in which package can I find your mkimage script. You mean /usr/lib/anaconda-runtime/mk-images (from the anaconda package)? Well, this seems close. Any documentation? Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Broken dependencies in Fedora 11 - 2009-07-28
== The results in this summary consider Test Updates! == Summary of broken packages (by src.rpm name): beagle CodeAnalyst-gui gauche-gl gauche-gtk mono-tools openmpi pcmanx-gtk2 ppl python-repoze-what python-tgext-crud R-RScaLAPACK rubygem-actionpack rubygem-activeldap rubygem-main rubygem-rails synce-kde tomboy vdccm vtk == Broken packages in fedora-11-i386: R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs gauche-gl-0.4.4-4.fc11.i586 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.i586 requires gauche = 0:0.8.13 openmpi-vt-1.3.1-1.fc11.i586 requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.i586 requires xulrunner = 0:1.9.1 rubygem-actionpack-2.3.2-1.fc11.noarch requires rubygem(activesupport) = 0:2.3.2 synce-kde-0.9.1-4.fc11.i586 requires synce-serial vdccm-0.10.1-5.fc11.i586 requires synce-serial == Broken packages in fedora-11-ppc: R-RScaLAPACK-0.5.1-19.fc11.ppc requires openmpi-libs gauche-gl-0.4.4-4.fc11.ppc requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.ppc requires gauche = 0:0.8.13 openmpi-vt-1.3.1-1.fc11.ppc requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc requires xulrunner = 0:1.9.1 rubygem-actionpack-2.3.2-1.fc11.noarch requires rubygem(activesupport) = 0:2.3.2 synce-kde-0.9.1-4.fc11.ppc requires synce-serial vdccm-0.10.1-5.fc11.ppc requires synce-serial == Broken packages in fedora-11-ppc64: R-RScaLAPACK-0.5.1-19.fc11.ppc64 requires openmpi-libs openmpi-vt-1.3.1-1.fc11.ppc64 requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.ppc64 requires xulrunner = 0:1.9.1 rubygem-actionpack-2.3.2-1.fc11.noarch requires rubygem(activesupport) = 0:2.3.2 synce-kde-0.9.1-4.fc11.ppc64 requires synce-serial vdccm-0.10.1-5.fc11.ppc64 requires synce-serial == Broken packages in fedora-11-x86_64: R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs gauche-gl-0.4.4-4.fc11.x86_64 requires gauche = 0:0.8.13 gauche-gtk-0.4.1-18.fc11.x86_64 requires gauche = 0:0.8.13 openmpi-vt-1.3.1-1.fc11.x86_64 requires openmpi-libs = 0:1.3.1-1.fc11 pcmanx-gtk2-xulrunner-plugin-0.3.8-5.fc11.x86_64 requires xulrunner = 0:1.9.1 rubygem-actionpack-2.3.2-1.fc11.noarch requires rubygem(activesupport) = 0:2.3.2 synce-kde-0.9.1-4.fc11.x86_64 requires synce-serial vdccm-0.10.1-5.fc11.x86_64 requires synce-serial == Broken packages in fedora-updates-11-i386: CodeAnalyst-gui-2.8.38-12.fc11.i586 requires libbfd-2.19.51.0.2-17.fc11.so ppl-swiprolog-0.10.2-3.fc11.i586 requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.i586 requires libYap.so == Broken packages in fedora-updates-11-ppc: ppl-swiprolog-0.10.2-3.fc11.ppc requires libpl.so.5.7.6 ppl-yap-0.10.2-3.fc11.ppc requires libYap.so == Broken packages in fedora-updates-11-ppc64: beagle-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(gsf-sharp) = 0:0.0.0.7 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-0.3.9-9.fc11.ppc64 requires mono(taglib-sharp) = 0:2.0.3.2 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 beagle-evolution-0.3.9-9.fc11.ppc64 requires mono(evolution-sharp) = 0:5.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 beagle-gnome-0.3.9-9.fc11.ppc64 requires mono(NDesk.DBus) = 0:1.0.0.0 beagle-thunderbird-0.3.9-9.fc11.ppc64 requires mono(gmime-sharp) = 0:2.4.0.0 ppl-swiprolog-0.10.2-3.fc11.ppc64 requires libpl.so.5.7.6()(64bit) ppl-yap-0.10.2-3.fc11.ppc64 requires libYap.so()(64bit) tomboy-0.14.3-1.fc11.ppc64 requires mono(NDesk.DBus.GLib) = 0:1.0.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Setup) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(gnome-panel-sharp) = 0:2.24.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires mono(Mono.Addins.Gui) = 0:0.4.0.0 tomboy-0.14.3-1.fc11.ppc64 requires
Re: Package: postgis-1.4.0rc1-2.fc12 Tag: dist-f12-rebuild Status: failed Built by: jkeating
I will take care of this. 1.4.0 also was not built -- I will contact upstream. On Tue, 2009-07-28 at 04:33 +, Koji Build System wrote: Package: postgis-1.4.0rc1-2.fc12 Tag: dist-f12-rebuild Status: failed Built by: jkeating ID: 122120 Started: Tue, 28 Jul 2009 04:25:04 UTC Finished: Tue, 28 Jul 2009 04:28:14 UTC postgis-1.4.0rc1-2.fc12 (122120) failed on x86-2.fedora.phx.redhat.com (x86_64), xenbuilder4.fedora.phx.redhat.com (noarch): BuildError: error building package (arch x86_64), mock exited with status 1; see build.log for more information SRPMS: postgis-1.4.0rc1-2.fc12.src.rpm Failed tasks: - Task 1545857 on x86-2.fedora.phx.redhat.com Task Type: buildArch (postgis-1.4.0rc1-2.fc12.src.rpm, x86_64) logs: http://koji.fedoraproject.org/koji/getfile?taskID=1545857name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1545857name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=1545857name=state.log Task 1525447 on xenbuilder4.fedora.phx.redhat.com Task Type: build (dist-f12-rebuild, /cvs/pkgs:rpms/postgis/devel:postgis-1_4_0rc1-2_fc12) Canceled tasks: --- Task 1545859 Task Type: buildArch (postgis-1.4.0rc1-2.fc12.src.rpm, ppc64) Task 1545860 on x86-7.fedora.phx.redhat.com Task Type: buildArch (postgis-1.4.0rc1-2.fc12.src.rpm, i686) logs: http://koji.fedoraproject.org/koji/getfile?taskID=1545860name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1545860name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=1545860name=state.log Task 1545855 Task Type: buildArch (postgis-1.4.0rc1-2.fc12.src.rpm, ppc) Closed tasks: - Task 1545829 on x86-6.fedora.phx.redhat.com Task Type: buildSRPMFromSCM (/cvs/pkgs:rpms/postgis/devel:postgis-1_4_0rc1-2_fc12) logs: http://koji.fedoraproject.org/koji/getfile?taskID=1545829name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1545829name=checkout.log http://koji.fedoraproject.org/koji/getfile?taskID=1545829name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=1545829name=state.log Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1525447 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=122120 -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org 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
rpms/un-core-fonts/devel un-core-fonts.spec,1.5,1.6
Author: jkeating
Update of /cvs/pkgs/rpms/un-core-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14904
Modified Files:
un-core-fonts.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: un-core-fonts.spec
===
RCS file: /cvs/pkgs/rpms/un-core-fonts/devel/un-core-fonts.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- un-core-fonts.spec 26 Jun 2009 06:45:39 - 1.5
+++ un-core-fonts.spec 27 Jul 2009 06:30:26 - 1.6
@@ -32,7 +32,7 @@ Core 모음: \
Name: %{fontname}-fonts
Version:1.0.2
-Release:0.9.%{alphatag}%{?dist}
+Release:0.10.%{alphatag}%{?dist}
Summary:Un Core family of Korean TrueType fonts
Summary(ko):한글 은글꼴 Core 모음
@@ -224,6 +224,9 @@ rm -rf %{buildroot}
%changelog
+* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.0.2-0.10.080608
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Fri Jun 26 2009 Jens Petersen peter...@redhat.com - 1.0.2-0.9.080608
- update to new fonts packaging and naming (#477474)
- moved bold (and light) weights into main subpackages (#468618)
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/urw-fonts/devel urw-fonts.spec,1.33,1.34
Author: jkeating
Update of /cvs/pkgs/rpms/urw-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20224
Modified Files:
urw-fonts.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: urw-fonts.spec
===
RCS file: /cvs/pkgs/rpms/urw-fonts/devel/urw-fonts.spec,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -p -r1.33 -r1.34
--- urw-fonts.spec 25 Feb 2009 23:25:04 - 1.33
+++ urw-fonts.spec 27 Jul 2009 06:38:46 - 1.34
@@ -5,7 +5,7 @@
Summary: Free versions of the 35 standard PostScript fonts.
Name: urw-fonts
Version: 2.4
-Release: 7%{?dist}
+Release: 8%{?dist}
Source:
ftp://ftp.gnome.ru/fonts/urw/release/urw-fonts-%{filippov_version}.tar.bz2
URL: ftp://ftp.gnome.ru/fonts/urw/release/
# URW holds copyright
@@ -73,6 +73,9 @@ rm -rf $RPM_BUILD_ROOT
%{fontdir}/*.pfb
%changelog
+* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.4-8
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Wed Feb 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.4-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/vlgothic-fonts/devel vlgothic-fonts.spec,1.5,1.6
Author: jkeating
Update of /cvs/pkgs/rpms/vlgothic-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv32016
Modified Files:
vlgothic-fonts.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: vlgothic-fonts.spec
===
RCS file: /cvs/pkgs/rpms/vlgothic-fonts/devel/vlgothic-fonts.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- vlgothic-fonts.spec 15 Jun 2009 11:21:08 - 1.5
+++ vlgothic-fonts.spec 27 Jul 2009 06:56:34 - 1.6
@@ -9,7 +9,7 @@ but some have also been improved by the
Name: %{fontname}-fonts
Version: 20090612
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Japanese TrueType font
License: mplus and BSD
@@ -93,6 +93,9 @@ rm -rf ${RPM_BUILD_ROOT}
%changelog
+* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 20090612-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Mon Jun 15 2009 Akira TAGOH ta...@redhat.com - 20090612-1
- New upstream release.
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/vollkorn-fonts/devel vollkorn-fonts.spec,1.3,1.4
Author: jkeating
Update of /cvs/pkgs/rpms/vollkorn-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv529
Modified Files:
vollkorn-fonts.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: vollkorn-fonts.spec
===
RCS file: /cvs/pkgs/rpms/vollkorn-fonts/devel/vollkorn-fonts.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- vollkorn-fonts.spec 26 Feb 2009 00:47:29 - 1.3
+++ vollkorn-fonts.spec 27 Jul 2009 06:57:58 - 1.4
@@ -5,7 +5,7 @@
Name: %{fontname}-fonts
Version:1.008
-Release:3%{?dist}
+Release:4%{?dist}
Summary:A serif latin font with good readability
Group: User Interface/X
@@ -61,6 +61,9 @@ rm -fr %{buildroot}
%changelog
+* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.008-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Wed Feb 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.008-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 477044] [Tracker] Deploy new font packaging guidelines for Fedora 11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=477044 Bug 477044 depends on bug 477421, which changed state. Bug 477421 Summary: [madan-fonts] Please convert to new font packaging guidelines https://bugzilla.redhat.com/show_bug.cgi?id=477421 What|Old Value |New Value Resolution||ERRATA Status|MODIFIED|CLOSED Bug 477044 depends on bug 477371, which changed state. Bug 477371 Summary: [cave9] Please convert to new font packaging guidelines https://bugzilla.redhat.com/show_bug.cgi?id=477371 What|Old Value |New Value Status|ON_QA |CLOSED Resolution||ERRATA Bug 477044 depends on bug 477419, which changed state. Bug 477419 Summary: [lklug-fonts] Please convert to new font packaging guidelines https://bugzilla.redhat.com/show_bug.cgi?id=477419 What|Old Value |New Value Resolution||CURRENTRELEASE Status|MODIFIED|CLOSED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 477419] [lklug-fonts] Please convert to new font packaging guidelines
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=477419 Pravin Satpute psatp...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution||CURRENTRELEASE --- Comment #8 from Pravin Satpute psatp...@redhat.com 2009-07-27 03:06:24 EDT --- closing for now please reopen if any problem -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/wqy-bitmap-fonts/devel wqy-bitmap-fonts.spec,1.23,1.24
Author: jkeating
Update of /cvs/pkgs/rpms/wqy-bitmap-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17634
Modified Files:
wqy-bitmap-fonts.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: wqy-bitmap-fonts.spec
===
RCS file: /cvs/pkgs/rpms/wqy-bitmap-fonts/devel/wqy-bitmap-fonts.spec,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -p -r1.23 -r1.24
--- wqy-bitmap-fonts.spec 23 Apr 2009 18:31:54 - 1.23
+++ wqy-bitmap-fonts.spec 27 Jul 2009 07:27:36 - 1.24
@@ -4,7 +4,7 @@
Name: %{fontname}-fonts
Version:0.9.9
-Release:10%{?dist}
+Release:11%{?dist}
Summary:WenQuanYi Bitmap Chinese Fonts
Group: User Interface/X
@@ -69,6 +69,9 @@ rm -fr %{buildroot}
%changelog
+* Mon Jul 27 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.9.9-11
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
*Thu Apr 23 2009 Qianqian Fang fan...@gmail.com 0.9.9-10
- correct outdated uming font names for F11 (#492510)
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/wqy-unibit-fonts/devel wqy-unibit-fonts.spec,1.3,1.4
Author: jkeating
Update of /cvs/pkgs/rpms/wqy-unibit-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17784
Modified Files:
wqy-unibit-fonts.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: wqy-unibit-fonts.spec
===
RCS file: /cvs/pkgs/rpms/wqy-unibit-fonts/devel/wqy-unibit-fonts.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- wqy-unibit-fonts.spec 26 Feb 2009 07:14:12 - 1.3
+++ wqy-unibit-fonts.spec 27 Jul 2009 07:27:51 - 1.4
@@ -2,7 +2,7 @@
Name: %{fontname}-fonts
Version:1.1.0
-Release:6%{?dist}
+Release:7%{?dist}
Summary:WenQuanYi Unibit Bitmap Font
Group: User Interface/X
@@ -61,6 +61,9 @@ rm -fr %{buildroot}
%changelog
+* Mon Jul 27 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.1.0-7
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Wed Feb 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.1.0-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/xorg-x11-font-utils/devel xorg-x11-font-utils.spec,1.32,1.33
Author: jkeating
Update of /cvs/pkgs/rpms/xorg-x11-font-utils/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29840
Modified Files:
xorg-x11-font-utils.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: xorg-x11-font-utils.spec
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/devel/xorg-x11-font-utils.spec,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -p -r1.32 -r1.33
--- xorg-x11-font-utils.spec23 Jul 2009 13:58:15 - 1.32
+++ xorg-x11-font-utils.spec27 Jul 2009 08:36:22 - 1.33
@@ -5,7 +5,7 @@ Name: xorg-x11-%{pkgname}
# IMPORTANT: If package ever gets renamed to something else, remove the Epoch
line!
Epoch: 1
Version: 7.2
-Release: 8%{?dist}
+Release: 9%{?dist}
License: MIT
Group: User Interface/X
URL: http://www.x.org
@@ -116,6 +116,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Jul 27 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1:7.2-9
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Thu Jul 23 2009 Adam Jackson a...@redhat.com 7.2-8
- Un-require xorg-x11-filesystem
- Other general spec cleanup.
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/yanone-kaffeesatz-fonts/devel yanone-kaffeesatz-fonts.spec, 1.7, 1.8
Author: jkeating
Update of /cvs/pkgs/rpms/yanone-kaffeesatz-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9645
Modified Files:
yanone-kaffeesatz-fonts.spec
Log Message:
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: yanone-kaffeesatz-fonts.spec
===
RCS file:
/cvs/pkgs/rpms/yanone-kaffeesatz-fonts/devel/yanone-kaffeesatz-fonts.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- yanone-kaffeesatz-fonts.spec25 Feb 2009 18:05:18 - 1.7
+++ yanone-kaffeesatz-fonts.spec27 Jul 2009 08:52:08 - 1.8
@@ -5,7 +5,7 @@
Name:%{fontname}-fonts
Version: 20080723
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary: Yanone Kaffeesatz decorative fonts
Group: User Interface/X
@@ -58,6 +58,9 @@ rm -fr %{buildroot}
%changelog
+* Mon Jul 27 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 20080723-6
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Wed Feb 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 20080723-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 491968] [mathml-fonts] Please rebuild for Fedora 11 to pick up font autodeps
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=491968 Rex Dieter rdie...@math.unl.edu changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG --- Comment #3 from Rex Dieter rdie...@math.unl.edu 2009-07-27 12:11:11 EDT --- Bogus detection on %ghost'd items (ie, not in fedora by default). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 452357] The mathml-fonts package needs some cleaning up
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=452357 --- Comment #4 from Rex Dieter rdie...@math.unl.edu 2009-07-27 12:13:34 EDT --- The more I look at it, the more 2 seems to be the only sane option here. Will commence working on split items. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 452357] The mathml-fonts package needs some cleaning up
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=452357 --- Comment #6 from Rex Dieter rdie...@math.unl.edu 2009-07-27 13:31:10 EDT --- mailed owners of packages with deps on mathml-fonts, including koffice, lyx, abiword, for details on what specifically is required by each of them. In the near future, I'll EOL mathml-fonts, and potentially resurrect anything still needed. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 22942] fc-query does not detect Japanese in Droid Sans Japanese
http://bugs.freedesktop.org/show_bug.cgi?id=22942 --- Comment #3 from Behdad Esfahbod freedesk...@behdad.org 2009-07-27 11:46:26 PST --- Humm, I/we should add a new tool to report which chars are missing in a font to be marked with a lang. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 407605] Exposing more useful font metadata in gnome-font-viewer
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=407605 gnome-control-center | fonts:/// | Ver: unspecified --- Comment #30 from Nicolas Spalinger 2009-07-27 22:31 UTC --- Created an attachment (id=139333) -- (http://bugzilla.gnome.org/attachment.cgi?id=139333action=view) screenshot of Dejavu -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=407605. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 407605] Exposing more useful font metadata in gnome-font-viewer
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=407605 gnome-control-center | fonts:/// | Ver: unspecified --- Comment #31 from Nicolas Spalinger 2009-07-27 22:34 UTC --- Created an attachment (id=139334) -- (http://bugzilla.gnome.org/attachment.cgi?id=139334action=view) screenshot of Inconsolata notice how the mime type that is picked up is the wrong one ODF template instead of OpenType font because unfortunately the OOo project has ignored that .otf pre-existed their new template extension and has created a conflict. -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=407605. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 407605] Exposing more useful font metadata in gnome-font-viewer
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=407605 gnome-control-center | fonts:/// | Ver: unspecified --- Comment #32 from Nicolas Spalinger 2009-07-27 22:35 UTC --- Created an attachment (id=139335) -- (http://bugzilla.gnome.org/attachment.cgi?id=139335action=view) screenshot of Ubuntu-title -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=407605. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 407605] Exposing more useful font metadata in gnome-font-viewer
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=407605 gnome-control-center | fonts:/// | Ver: unspecified --- Comment #33 from Nicolas Spalinger 2009-07-27 22:35 UTC --- Created an attachment (id=139336) -- (http://bugzilla.gnome.org/attachment.cgi?id=139336action=view) screenshot of Cantarell -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=407605. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Fwd: Re: Is F-community using its FAS account?
Original Message Subject: Re: Is F-community using its FAS account? Date: Mon, 27 Jul 2009 14:35:50 -0400 (EDT) From: John Palmieri jo...@redhat.com To: Toshio Kuratomi a.bad...@gmail.com It is used for getting a user's info when you are not logged in similar to the functionality of the bots in #fedora-devel. Going to this link (https://admin.fedoraproject.org/community/?username=jkeating#people) works so the password change worked. - Toshio Kuratomi a.bad...@gmail.com wrote: Hey, lmacken and I realized that we probably hadn't changed Fedora Community's password since moving it from the publictest machines to production so I did that today. But when I went to test it we couldn't figure out where it would actually be used:: [10:00:02] lmacken abadger1999: hmm, I'm actually not sure if that account is getting used at all. It looks like it is only used when the user is not logged in, but in that case they can't view users or anything FAS related as far as I can tell. J5 would know for sure So, is the account being used? If so how can I test that the password update worked okay? If not, can we disable the account? -Toshio -- -- John (J5) Palmieri Software Engineer Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: blogs.fedoraproject.org Update
Hi, I developed one site for Vibrant GNU Linux user group (vglug.info) and implemented spam protection for jobs. it is built in drupal. can we use drupal for this project? Regards, Niraj Bhatt 2009/7/23 Ricky Zhou ri...@fedoraproject.org On 2009-07-24 01:27:34 AM, susmit shannigrahi wrote: It is not working for me. I can't login with my FAS credentials. Hi, this is not live yet, please do not enter your real FAS credentials there (it's currently going against a test FAS). When we do make this live, it will be over SSL to avoid passwords being transmitted in plaintext. Thanks, Ricky ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Niraj Bhatt Give me space to stand, i will move the earth ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: blogs.fedoraproject.org Update
Considering we've now deployed to production, the answer is no. We've found a spam solution as well, we have chosen BadBehavior. Thanks, Darren L. VanBuren = http://oks.verymad.net/ On Mon, Jul 27, 2009 at 12:35, Bhatt Nirajnjbhat...@gmail.com wrote: Hi, I developed one site for Vibrant GNU Linux user group (vglug.info) and implemented spam protection for jobs. it is built in drupal. can we use drupal for this project? Regards, Niraj Bhatt 2009/7/23 Ricky Zhou ri...@fedoraproject.org On 2009-07-24 01:27:34 AM, susmit shannigrahi wrote: It is not working for me. I can't login with my FAS credentials. Hi, this is not live yet, please do not enter your real FAS credentials there (it's currently going against a test FAS). When we do make this live, it will be over SSL to avoid passwords being transmitted in plaintext. Thanks, Ricky ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Niraj Bhatt Give me space to stand, i will move the earth ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: AGPL Licensing: Another configuration file example
On 2009-07-27 10:46:02 AM, Toshio Kuratomi wrote: This wsgi script also helps illustrate some of smooge's concerns about what happens when configuration information is mixed into a script. It has two areas that differ between upstream's distribution and our own: The first is bad application design but I've seen this done frequently in PHP apps (and it sounds like Java frameworks like JBoss promote this as well). The fact that our apps are doing it shows it can occur in any language although we should be able to change our apps to work around it fairly easily: The scripts that start up our web applications under mod_wsgi all seem to have a bit of config tweaking. Historically, this is because we deployed with a start-app.py script that used the config file exclusively and started as a standalone daemon. The app.wsgi script would load the standalone daemon config file and then make some config changes in the wsgi script before starting the application server. This can be seen in the attached wsgi script in lines like this:: Another example of something that could be considered mixing code and configuration in .wsgi files is the usage of WSGI middleware (in TG1 at least, Toshio mentioned that things might be more cleanly separated in TG2 now). Right now, to add middleware to a TG1 application, we'd edit the .wsgi to add code to wrap the application in middleware - it isn't 100% clear to us where this kind of change would fall from the license's standpoint though. Thanks, Ricky pgp4NwyDAumqD.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
bash_history on x86-5
I just deleted my bas_history on x86-5 i typed my password on accident Dennis signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Fedora-legal-list] aria2 license
RS == Rahul Sundaram sunda...@fedoraproject.org writes: RS Hi, http://aria2.sf.net was marked as GPLv2 so far. I recently RS took over the package and noticed that the license is actually RS GPLv2+ with an exception for OpenSSL. That doesn't seem to be RS specifically covered under the licensing page. Adding exceptions to GPLv2+ gets you GPLv2+ with exceptions. It doesn't really matter what the exceptions are, as long as they aren't actually incompatible with the GPL. - J ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
[Fedora-legal-list] A new GCC runtime library license snag?
Hi, Just a heads up in case, Legal isn't aware of this problem http://lwn.net/Articles/343608/ Rahul ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
