Re: ActionNotAllowed: admin permission required
Tom Stage wrote:
Hi all
Well I have to admit that I am in the same boat as the last thread with the
same Subject, this config is also with SSL configured and it seems to be ok
and running good, I can log in to the web interface.
I have Koji installed on a Fedora 10 x86_64 system, and I have followed the
HowTo at http://fedoraproject.org/wiki/Koji/ServerHowTo and I to cant seem
to execute the following commands as an example:
System info:
Uname -a
Linux koji 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23 23:08:10 EDT
2009 x86_64 x86_64 x86_64 GNU/Linux
Rpm -qa
koji-builder-1.3.1-1.fc10.noarch
koji-utils-1.3.1-1.fc10.noarch
koji-1.3.1-1.fc10.noarch
koji-web-1.3.1-1.fc10.noarch
koji-hub-1.3.1-1.fc10.noarch
SSL certificates created after the instructions in the howto, with one
exception, since this is a single host installation I have only created 3
types of certificates. The 1st one is the signing certificate. The 2nd one
is the certificates for the host, and used by all the koji services. The 3rd
one is the user certificates.
[r...@koji ~]koji call getLoggedInUser
{'id': 1, 'krb_principal': None, 'name': 'admin', 'status': 0, 'usertype':
0}
[r...@koji ~]koji add-user kojira
ActionNotAllowed: admin permission required
[r...@koji ~]koji add-host koji.dvos.dk x86_64
ActionNotAllowed: admin permission required
My users in the users table in postgres looks like this:
Id namepasswordstatus usertypekrb_principal
1 admin 0 0
2 koji.dvos.dk0 1
My permissions table looks like this:
Id name
1 admin
2 build
3 repo
I am confused and don't understand what I am doing wrong, and I am willing
to post my configuration files as well.
Any help is appreciated.
To grant a permission to a user you need to insert into the user_perms
table. The user_id column references the id of the users table, and the
perm_id references the id of the permissions table. In your case,
granting the admin user the admin permission would be accomplished
by running:
insert into user_perms (user_id, perm_id) values (1, 1);
After that, you can grant other permissions by using the koji
grant-permission command.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
RE: ActionNotAllowed: admin permission required
Hi Mike, Jay and the rest of you
I have solved the problem with you kind help.
The basic problem was the user_perms table not being updated, so it was a
combo of not reading the how to right.
Thanks for your help on this.
Cheers Tom
-Original Message-
From: Mike Bonnet [mailto:mi...@redhat.com]
Sent: 26. maj 2009 16:18
To: Tom Stage; Discussion of Fedora build system
Subject: Re: ActionNotAllowed: admin permission required
Tom Stage wrote:
Hi all
Well I have to admit that I am in the same boat as the last thread with
the
same Subject, this config is also with SSL configured and it seems to be
ok
and running good, I can log in to the web interface.
I have Koji installed on a Fedora 10 x86_64 system, and I have followed
the
HowTo at http://fedoraproject.org/wiki/Koji/ServerHowTo and I to cant seem
to execute the following commands as an example:
System info:
Uname -a
Linux koji 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23 23:08:10 EDT
2009 x86_64 x86_64 x86_64 GNU/Linux
Rpm -qa
koji-builder-1.3.1-1.fc10.noarch
koji-utils-1.3.1-1.fc10.noarch
koji-1.3.1-1.fc10.noarch
koji-web-1.3.1-1.fc10.noarch
koji-hub-1.3.1-1.fc10.noarch
SSL certificates created after the instructions in the howto, with one
exception, since this is a single host installation I have only created 3
types of certificates. The 1st one is the signing certificate. The 2nd one
is the certificates for the host, and used by all the koji services. The
3rd
one is the user certificates.
[r...@koji ~]koji call getLoggedInUser
{'id': 1, 'krb_principal': None, 'name': 'admin', 'status': 0, 'usertype':
0}
[r...@koji ~]koji add-user kojira
ActionNotAllowed: admin permission required
[r...@koji ~]koji add-host koji.dvos.dk x86_64
ActionNotAllowed: admin permission required
My users in the users table in postgres looks like this:
Idnamepasswordstatus usertypekrb_principal
1 admin 0 0
2 koji.dvos.dk0 1
My permissions table looks like this:
Idname
1 admin
2 build
3 repo
I am confused and don't understand what I am doing wrong, and I am willing
to post my configuration files as well.
Any help is appreciated.
To grant a permission to a user you need to insert into the user_perms
table. The user_id column references the id of the users table, and the
perm_id references the id of the permissions table. In your case,
granting the admin user the admin permission would be accomplished
by running:
insert into user_perms (user_id, perm_id) values (1, 1);
After that, you can grant other permissions by using the koji
grant-permission command.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 How about phasing out Group tag as well? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 How about phasing out Group tag as well? It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). I vote for also removing the %clean section. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody interested in vpnc
On Tue, 2009-05-26 at 09:06 +0100, Richard W.M. Jones wrote: On Mon, May 25, 2009 at 05:29:32PM -0400, Warren Togami wrote: On 05/25/2009 05:07 PM, Richard W.M. Jones wrote: On Mon, May 25, 2009 at 03:52:37PM +0200, Tomas Mraz wrote: is anybody interested in maintaining vpnc in Fedora and EPEL? I'd like to orphan it. I might stay as a comaintainer if you want. It looks like Warren Togami has jumped in there to be co-maintainer. If you need someone else I can help. Rich. wait what? Why are you volunteering me for something I know nothing about? A simple misunderstanding - I looked at the ACLs and noticed that you were there already, so I assumed you'd already taken co-maint for the package. Tomas: If you still want me to co-maintain this package, let me know. I'll orphan it and you can be the primary maintainer. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 26 May 2009 09:10:15 +0100, Richard wrote:
I vote for also removing the %clean section.
Complete removal or only making rm -rf %{buildroot} the default?
In case of the former, let's also add an implicit rm -rf %{buildroot} at
start of %install. There are still packagers who don't empty the buildroot
and who don't know rpmbuild's -bi --short-circuit options.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
dependency errors while upgrading vom F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I checked the ability to upgrade from F10 to F11 (Rawhide) directly using yum. A couple of weeks ago, there were dependency errors with python. These errors are not fixed until now. In my point of view, this issue should be fixed until GA of Leonidas. Thanks, Uwe == What I have done: [r...@alberta ~]# yum --disablerepo=* --enablerepo=rawhide update I got: - -- Finished Dependency Resolution sos-1.8-11.fc10.noarch from installed has depsolving problems -- Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems -- Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems -- Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) kdeedu-marble-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-libs-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) 6:kdelibs-4.2.3-2.fc10.i386 from installed has depsolving problems -- Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-2.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) Error: Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libssl.so.7 is needed by package 6:kdelibs-4.2.3-2.fc10.i386 (installed) Error: Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) Error: Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) Error: Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) [r...@alberta ~]# So, I tried to use updates-testing to fix, but more errors appeared: - -- Finished Dependency Resolution sos-1.8-11.fc10.noarch from installed has depsolving problems -- Missing Dependency: python(abi) = 2.5 is needed by package sos-1.8-11.fc10.noarch (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libdjvulibre.so.15 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems -- Missing Dependency: libpython2.5.so.1.0 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) PyQt4-4.4.4-6.fc10.i386 from installed has depsolving problems -- Missing Dependency: python(abi) = 2.5 is needed by package PyQt4-4.4.4-6.fc10.i386 (installed) createrepo-0.9.7-7.fc10.noarch from updates-testing has depsolving problems -- Missing Dependency: python(abi) = 2.5 is needed by package createrepo-0.9.7-7.fc10.noarch (updates-testing) kdeedu-marble-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libgps.so.17 is needed by package kdeedu-marble-4.2.3-1.fc10.i386 (installed) ntp-4.2.4p7-1.fc10.i386 from updates-testing has depsolving problems -- Missing Dependency: libcrypto.so.7 is needed by package ntp-4.2.4p7-1.fc10.i386 (updates-testing) 1:qt-4.5.1-10.fc10.i386 from updates-testing has depsolving problems -- Missing Dependency: libssl.so.7 is needed by package 1:qt-4.5.1-10.fc10.i386 (updates-testing) 1:qt-x11-4.5.1-10.fc10.i386 from updates-testing has depsolving problems -- Missing Dependency: libcrypto.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) 7:kdegraphics-libs-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libexiv2.so.4 is needed by package 7:kdegraphics-libs-4.2.3-1.fc10.i386 (installed) 7:kdegraphics-4.2.3-1.fc10.i386 from installed has depsolving problems -- Missing Dependency: libpoppler.so.3 is needed by package 7:kdegraphics-4.2.3-1.fc10.i386 (installed) 1:qt-x11-4.5.1-10.fc10.i386 from updates-testing has depsolving problems -- Missing Dependency: libssl.so.7 is needed by package 1:qt-x11-4.5.1-10.fc10.i386 (updates-testing) 6:kdelibs-4.2.3-3.fc10.i386 from
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 01:40 PM, Richard W.M. Jones wrote: On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 How about phasing out Group tag as well? It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). Yes but there should be packaging guidelines adding a note that you can just drop it similar to built root. Does apt, smart and synaptic support comps though? do we care? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unowned files and directories
On Sat, 23 May 2009 19:46:42 +0200, Thorsten wrote: But I'm a bit unsure what to do with the results. Filing bugs likely would be huge amount of work as well as and never-ending task for a small gain. http://mschwendt.fedorapeople.org/dircheck-remote.py Example usage: ./dircheck-remote.py -r rawhide -n ^vtk ./dircheck-remote.py -r rawhide Options? Just ignore? Or will the automatic test scripts QA iirc plans to set up check for things like that in the future? Different strategy. Also to raise awareness of the problem. Focus on those unowned directories - which bear a risk of breaking tarball compilation (e.g. old unowned empty versioned API directories which confuse tarball configure scripts, not limited to %_includedir), - which look like files might be misplaced (e.g. unowned directories in suspicious paths), - which look like missing subpackage dependencies (e.g. yum install foo-something doesn't lead to working software since foo is not installed automatically) - which pile up usability crap, such as empty versioned %docdirs. [1] [1] The latter is annoying. It breaks tab completion in /usr/share/doc (but also makes it harder to browse documentation with graphical file managers). Additionally, some packagers tend to use %doc in almost every subpackage, and I'm not sure they are aware of the consequences. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody interested in vpnc
On Tue, May 26, 2009 at 10:19:45AM +0200, Tomas Mraz wrote: I'll orphan it and you can be the primary maintainer. Done. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 10:39:27 +0200, Uwe wrote: I checked the ability to upgrade from F10 to F11 (Rawhide) directly using yum. A couple of weeks ago, there were dependency errors with python. These errors are not fixed until now. Nobody has posted the results of one of the upgradepathcheck scripts for a long time. :( In my point of view, this issue should be fixed until GA of Leonidas. What set of repositories did you use when enabling updates-testing? In your quote I see lots of references to F10 updates-testing, but did you also enable F11 updates and F11 updates-testing? [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. Not only because of packaging bugs (F10 packages having a higher EVR than F11 packages), but also because there is a growing number of updates and test-updates for F11 already.] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
Le Mar 26 mai 2009 10:43, Rahul Sundaram a écrit : It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). Yes but there should be packaging guidelines adding a note that you can just drop it similar to built root. Does apt, smart and synaptic support comps though? do we care? I'd drop it from the font packaging spec templates at once if FPC FESCO oked it. Each spurious line is pollution that frightens new packagers. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: | From: Rex Dieter rdie...@math.unl.edu | Seems frustrations are mounting: | On policykit and standards | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html [I'm an outsider. This thread is my introduction to the whole area. I'm not even a KDE user.] This certainly does not look like a healthy approach to standardization and cooperation. - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE appears clearly biased towards GNOME, even though its URL and title suggest universality: the first substantial line talks about polkit-gobject-1 (I *think* that gobject means GNOME object) - in a well-constituted standards process (not a de facto standard), stakeholders are consulted before changes are made. It looks as if KDE folks have been stakeholders and have not been allowed to even sign-off on the design, let alone participate in it. - for good reason, the normal output of a standardization process is a document, not code. There appears to be no complete documentation. - all stakeholders ought to be treated respectfully and equitably. That means, for example, KDE ought not the be second to GNOME. More particularly, the architectures should be open-ended, allowing for more than KDE and GNOME. See, for example, http://c2.com/cgi/wiki?ZeroOneInfinityRule I admit that my reactions may be ill-founded. Perhaps this is meant You are attempting to create problems here which don't exist. David has already pointed out in another mail that if apps don't want to use the glib based library, they can talk to DBus directly. There are native QT bindings for DBus, and pretty much any other language can talk to DBus too with no deps on glib / gobject. 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: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 11:17:29 +0200, Uwe wrote: What set of repositories did you use when enabling updates-testing? In your quote I see lots of references to F10 updates-testing, but did you also enable F11 updates and F11 updates-testing? I think, yum only enables updates-testing for F10 if I type [r...@alberta ~]# yum --disablerepo=* - --enablerepo=rawhide,updates-testing update How to enable the other update channels? With a Yum-based distribution upgrade, you typically perform an upgrade in two steps. First you update to the right fedora-release package, so variables like $releasever used in your *.repo files expand to '11' instead of '10'. Then you run a plain yum update, which automatically chooses the Fedora 11 repos. Alternatively, you hardcode the baseurls of the repos you want to upgrade to. [And as long as there is no F11 GA repo yet, you need to enable rawhide manually.] [Upgrading from an up-to-date F10 to F11 Rawhide is bound to fail. Not only because of packaging bugs (F10 packages having a higher EVR than F11 packages), but also because there is a growing number of updates and test-updates for F11 already.] Does it meen an upgrade fron an Up-to-date F10 to F11 GA will also fail? With Yum? Yes. The more packages in F11 Updates, the more likely you need them in order to replace your F10 Updates, which may be seen as newer than F11 GA. Same applies to Test Updates. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 11:43:54 +0200, Uwe wrote: With a Yum-based distribution upgrade, you typically perform an upgrade in two steps. First you update to the right fedora-release package, so variables like $releasever used in your *.repo files expand to '11' instead of '10'. Then you run a plain yum update, which automatically chooses the Fedora 11 repos. I know this procedure. Then use it. ;) Do we have the F11 repos yet? I don't think so, because F11 is not GA. F11 updates and F11 updates-testing _are_ available F11 release Everything, however, is still in development (Rawhide). The more packages in F11 Updates, the more likely you need them in order to replace your F10 Updates, which may be seen as newer than F11 GA. Same applies to Test Updates. That will be a brake a possible option from the past. :-( No. With Yum it has always been like that and the primary reason for creating the old upgradecheck.py script from the Fedora Extras era. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 26 May 2009, Rahul Sundaram wrote: On 05/26/2009 01:40 PM, Richard W.M. Jones wrote: On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 How about phasing out Group tag as well? It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). Yes but there should be packaging guidelines adding a note that you can just drop it similar to built root. Does apt, smart and synaptic support comps though? do we care? Smart in GUI-mode and Synaptic currently use the Group tag to, well, group the packages for viewing: http://laiskiainen.org/tmp/smartpm-groups.png. Apt (and smartpm in cli-mode) dont care. Without spec specified Group they all get lumped under Unspecified but as the group tags are already wildly inconsistent, full of typos etc... dunno if it's such a big loss. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On 05/26/2009 03:38 PM, Panu Matilainen wrote: Smart in GUI-mode and Synaptic currently use the Group tag to, well, group the packages for viewing: http://laiskiainen.org/tmp/smartpm-groups.png. That's great. Apt (and smartpm in cli-mode) dont care. Without spec specified Group they all get lumped under Unspecified but as the group tags are already wildly inconsistent, full of typos etc... dunno if it's such a big loss. Yes, the packaging/review guidelines only care about comps grouping and not the Group tag. So for many packages, it is pretty arbitrary. I guess, we can just lose both build root and group tag to reduce noise. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt schrieb: On Tue, 26 May 2009 11:43:54 +0200, Uwe wrote: With a Yum-based distribution upgrade, you typically perform an upgrade in two steps. First you update to the right fedora-release package, so variables like $releasever used in your *.repo files expand to '11' instead of '10'. Then you run a plain yum update, which automatically chooses the Fedora 11 repos. I know this procedure. Then use it. ;) That was not the right way: rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-notes-11.0.0-2.fc11.noarch.rpm rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm [r...@alberta ~]# yum clean all Loaded plugins: fastestmirror, refresh-packagekit Cleaning up Everything Cleaning up list of fastest mirrors [r...@alberta ~]# yum update Loaded plugins: fastestmirror, refresh-packagekit Determining fastest mirrors YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. /metalink/ removing mirrorlist with no valid mirrors: //var/cache/yum/fedora/mirrorlist.txt Error: Cannot find a valid baseurl for repo: fedora [r...@alberta ~]# another try: [r...@alberta ~]# yum --enablerepo=rawhide --disablerepo=fedora update Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. /metalink/ removing mirrorlist with no valid mirrors: //var/cache/yum/updates/mirrorlist.txt Cannot find a valid baseurl for repo: updates [r...@alberta ~]# last try: yum --disablerepo=* --enablerepo=rawhide update and back to the errors of my very 1st posting... :-( -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShvBbUJXG7BUuynnAQJMiQ//VR/88spZ1C4oDiZx+XrZ0bT/SdeMrTmp VNYwCHLKA8nttxucdMRU3EBvehs7goMHGw8Rbfv0f0ioSMiXrUSOMmf/qiZfqb8+ IGB12T3kYEZmxiYhk4zIFIDZKiUT715bChZ0F5eW2uWiVDD3pCeadWjWHSH+6JE8 smIySAH4GnbULOBkH/XW6+ge7JU5HKZkx//gcKS6qOja7T4/+BQ88VyP/qoiJOHG o2Zw3UKBN+KLJiHN+4EgiyPOr0Azg2ZD6GBIk3gKpFlTZW8zBscKyFU4EVfLan4r 8pjqVQxhO1o6Q7X08liu7/YNWj3ZAuImMTrHS7/NJPCdHfCO+LyiRIxJu65ozxjK jtQnAKLMCnPZjxLshWtDeeunEhV9ZrSQR1djYMUhnTW2tksJ/W6s7HhBk5h7sa++ N4G75yLOGycNWX7shrETuppAKuauhP34pG8RAZb0CXi539fZpPytdM5dRqwc1hde WhDw/ZZQj6kzUCjzR+4FVkV9hnMQxsCVkvFP9NLLUiFlSgdbhSeLsbcsNSg73SNn Owh6LfMgfoOmQPHzBCNuTxgRHwrguVt1zzUG47Zos8w6WfDgoA9XF8hQkYpelTox 2Ofu0pUNEUceUtMO+LYLPHXqxtXsC/fLQe7w7FmrimgDF50obHLqHlvzBsWKIVgh EG7EnsXf7ic= =i5oW -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm And to add some trouble-shooting myself, this new fedora-release package points to a mirrorlist URL that returns an XML file instead of the old plain-text list of baseurls. Perhaps upgrade tools like Yum are needed to handle it. But that doesn't prove that hardcoding the F11 repository baseurls would not work. Especially if above you choose a local mirror already anyway. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Schwendt schrieb: On Tue, 26 May 2009 12:16:13 +0200, Uwe wrote: rpm -Uvh ftp://ftp.solnet.ch/mirror/fedora/linux/development/i386/os/Packages/fedora-release-11-1.noarch.rpm And to add some trouble-shooting myself, this new fedora-release package points to a mirrorlist URL that returns an XML file instead of the old plain-text list of baseurls. Perhaps upgrade tools like Yum are needed to handle it. But that doesn't prove that hardcoding the F11 repository baseurls would not work. Especially if above you choose a local mirror already anyway. I think, thats the point, why it would no be possible to go the way described in http://fedoraproject.org/wiki/YumUpgradeFaq (yet) I will try it again after Leonidas is GA - expecting it won't work. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBShvMdEJXG7BUuynnAQJ4pxAAjHKgNDOfDyh/8S0vUu9Gs75sZusJh+jW Y9Otp1EM7Kcwlo5HXLdqouBaL92mCumtmApU14a7emZ6e7IrnvhstDNHv4wAmXey 1JHnBCYh/8WygMkZRgoW6oWjsgNXBBbQNwJi64lfFxWfBKk+JUmcT1tiBcXLw57P OOaMN/IcERglmvvaJt5w2eaTd7rRIqf8ikn02bKvX4TTOWzCueE0Mp2y45rkgcRh OKINsulviRx8S8abzh7n2Ntg4GiIG60D5hOfT4OyCnBfQUP3uSm6ksPz72RBDyy6 FyAH0iMSwfzNTywEUmYcBvqjC9jLQNiRdZzQ7uAHKKliwGT9S+n/sSoHZCqyCn1f jWUvFmwQ3J3fTOUCavvVAo1PTakieNjwepriwIsvWdvGP4sRJD8pU5/RxCkqNkx2 DyMe5CFTdaaxdmkXKHQClRH+4pOPAQ7HvF4/RjHwM2UxB7D5TiA8tRA29Ok6WEJp EEhm0UrUZqD7JV1xPFuW8St6tM8olBcss0JZOu/NctDp/dzUQ5zq/Qu+P4lBs5PY Q9YMbc/1nkFZ+BRQ1B87D5BU7s/OYeH8viFbBYdlwD/IpnTJVy/0wxoxrRK9DGZH ghzx51t03iYPmGC9QHAV3eWTHK6xGYKKoIR2qoWtZKXgUEojxLwEIYgVRnp6IDcP bYHuAunh7B0= =z7ae -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Conflicts not being resolved
On 05/23/2009 06:37 AM, Michael Schwendt wrote: https://fedoraproject.org/wiki/Packaging/Conflicts https://fedoraproject.org/wiki/Packaging/Conflicts#Other_Uses_of_Conflicts: | As a general rule, Fedora packages must NOT contain any usage of the | Conflicts: field. | Keep in mind that implicit conflicts are NEVER acceptable. | If your package conflicts with another package, then you must either | resolve the conflict, or mark it with Conflicts:. What happens so far is that packagers simply ignore it. Again I see bz tickets from Nov 2008 which have not been responded to. The page doesn't point out that missing Conflicts tags are bad. Implicit conflicts are not detected prior to an RPM transaction check. Typically, implicit conflicts cause tools like Yum to fail, leaving it to the user to do the head-scratching and to remove packages manually. This seems like a great place for someone who is looking for a way to help out Fedora to work on, closing out these bugs. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Breaking deps deliberately
On 05/23/2009 11:03 AM, Braden McDaniel wrote: I didn't know about this until this subthread... and I asked a rather senior packaging person about it some months ago and didn't get this information. So I think this is poorly publicized; and perhaps poorly positioned in the packaging guidelines. Always possible. I'm the first to admit that the packaging guidelines need a thorough reorganization. The information is documented here: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches Suggestions on improvements are always welcomed (as long as they are constructive). ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Package Maintainers Flags policy
On 05/22/2009 03:04 PM, Frank Murphy wrote: 1: Has the flags policy, anything to do with RH becoming more prominent on the site? No problem with them becoming more prominent, they do sponsor a lot. If yes, say so, likewise no No. The fact that I authored the original flag policy had more to do with my awareness of the prior unwritten no flags policy, and nothing at all to do with Red Hat. Red Hat Legal did offer advice as to some of the wording, but they did not mandate it, nor did Red Hat instigate the creation of the flag policy. 2: Would our main Sponsor, suffer financially. As a result of inclusion of certain flags? No. As Adam said, having a no flags policy would make things slightly simpler for Red Hat to compose RHEL, but not enough to suffer any significant financial consequence. 3: Would the fedora project survive, if there was no main sponsor? Thankfully, this is a problem we do not have to be concerned about for the time being. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Package Maintainers Flags policy
On 05/23/2009 03:45 PM, Christopher Stone wrote: What are the T-6 restrictions? A google search only came up with this thread. There are 6 countries that Fedora cannot be legally exported to (as a result of US export restrictions): Cuba, Iran, Iraq, North Korea, Sudan and Syria These are known as the T-6 countries. No individual associated with the Fedora project (or mirror site) should provide Fedora software to anyone in those countries, even if they are not in the US. Here's the full legal paragraph: Because Fedora software contains encryption technology, Fedora software and technical information is subject to the U.S. Export Administration Regulations and other U.S. and foreign law, and may not be exported or re-exported to certain countries (currently Cuba, Iran, Iraq, North Korea, Sudan and Syria) or to persons or entities prohibited from receiving U.S. exports (including those (a) on the Bureau of Industry and Security Denied Parties List or Entity List, (b) on the Office of Foreign Assets Control list of Specially Designated Nationals and Blocked Persons, and (c) involved with missile technology or nuclear, chemical or biological weapons). You may not download Fedora software or technical information if you are located in one of these countries, or otherwise affected by these restrictions. You may not provide Fedora software or technical information to individuals or entities located in one of these countries or otherwise affected by these restrictions. You are also responsible for compliance with foreign law requirements applicable to the import and use of Fedora software and technical information. Tom spot Callaway, Fedora Legal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Martes 26 Mayo 2009 11:16:14 Daniel P. Berrange escribió: On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: | From: Rex Dieter rdie...@math.unl.edu | | Seems frustrations are mounting: | On policykit and standards | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html [I'm an outsider. This thread is my introduction to the whole area. I'm not even a KDE user.] This certainly does not look like a healthy approach to standardization and cooperation. - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE appears clearly biased towards GNOME, even though its URL and title suggest universality: the first substantial line talks about polkit-gobject-1 (I *think* that gobject means GNOME object) - in a well-constituted standards process (not a de facto standard), stakeholders are consulted before changes are made. It looks as if KDE folks have been stakeholders and have not been allowed to even sign-off on the design, let alone participate in it. - for good reason, the normal output of a standardization process is a document, not code. There appears to be no complete documentation. - all stakeholders ought to be treated respectfully and equitably. That means, for example, KDE ought not the be second to GNOME. More particularly, the architectures should be open-ended, allowing for more than KDE and GNOME. See, for example, http://c2.com/cgi/wiki?ZeroOneInfinityRule I admit that my reactions may be ill-founded. Perhaps this is meant You are attempting to create problems here which don't exist. David has already pointed out in another mail that if apps don't want to use the glib based library, they can talk to DBus directly. There are native QT bindings for DBus, and pretty much any other language can talk to DBus too with no deps on glib / gobject. Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized... PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion. Jaroslav 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 :| -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Conflicts not being resolved
On Tue, 26 May 2009, Tom \spot\ Callaway wrote: This seems like a great place for someone who is looking for a way to help out Fedora to work on, closing out these bugs. I wrote a script to dump out potential file conflicts. This needs to be dumped into the auto-qa work so we can look for file conflicts w/o explicit pkg conflicts automatically. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote: Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized... Calling g_type_init() should be enough; there is no direct GTK+ dependency in polkit-gobject. Even g_type_init() may be too much for KDE apps to swallow though, so going directly to the bus is still a good idea. PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion. You mean like http://cgit.freedesktop.org/PolicyKit http://git.gnome.org/cgit/PolicyKit-gnome ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
How to create header.info file
Hello I've made my repository for CentOS (3/4/5) with createrepo version 0.4.9. It makes these files repodata/filelists.xml.gz repodata/other.xml.gz repodata/primary.xml.gz repodata/repomd.xml Yum is working fine but on RHEL 4 I've got this error from up2date An HTTP error occurred: URL: http://ftp-hk.tmapy.cz/tmapy-twist/centos/4/os/i386/headers/header.info Status Code: 404 Error Message: Not Found How can I create this file and other files in headers directory? There is nothing in createrepo docs about these files. Can anybody help me? Pavel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090526 changes
Compose started at Tue May 26 06:15:03 UTC 2009 Removed package CastPodder Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 0 Broken deps for ppc64 -- cabal2spec-0.12-1.fc11.noarch requires ghc 0:6.10.1-7 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How to create header.info file
On Tue, 26 May 2009, Pavel Lisy wrote: Hello I've made my repository for CentOS (3/4/5) with createrepo version 0.4.9. It makes these files repodata/filelists.xml.gz repodata/other.xml.gz repodata/primary.xml.gz repodata/repomd.xml Yum is working fine but on RHEL 4 I've got this error from up2date An HTTP error occurred: URL: http://ftp-hk.tmapy.cz/tmapy-twist/centos/4/os/i386/headers/header.info Status Code: 404 Error Message: Not Found How can I create this file and other files in headers directory? There is nothing in createrepo docs about these files. 1. this is not a fedora-devel question. 2. You can ask on the centos lists about this but a short answer though is - look up about yum-arch I will not respond to any other questions about the above on this list. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
export policy, was Re: Package Maintainers Flags policy
On Tue, 26 May 2009, Tom spot Callaway wrote: Though I am also not a lawyer, I did look into things, being upstream for openswan and an author of a book containing crypto, a rather crypto heavy application and book... There are 6 countries that Fedora cannot be legally exported to (as a result of US export restrictions): Cuba, Iran, Iraq, North Korea, Sudan and Syria I think technically, this restriction only applies on the export of the software out of the US. For those outside the US, US law/doctrine does not apply (even though the US claims it does). Rather, for most Western countries, implementation of the Wassenaar Agreement in local law applies, where some countries have extended the export restrictios as set forth in the Wassenaar Agreement. In Europe, there is also the European Union Dual-Use Export laws. These are known as the T-6 countries. No individual associated with the Fedora project (or mirror site) should provide Fedora software to anyone in those countries, even if they are not in the US. This is again US doctrine. It becomes even stranger as in my case, Fedora imports openswan from The Netherlands, and then tells me I could not obtain my own GPL licensed code to do what is legal within my country? Though in this case, there is a large overlap of implementation of the Wassenaar Agreement. Because Fedora software contains encryption technology, Fedora software and technical information is subject to the U.S. Export Administration Regulations and other U.S. and foreign law, and may not be exported or re-exported to certain countries (currently Cuba, Iran, Iraq, North Korea, Sudan and Syria) See above. Note that the Wassenaar Agreement excludes software that is in the public domain, eg free/open source software. or to persons or entities prohibited from receiving U.S. exports (including those (a) on the Bureau of Industry and Security Denied Parties List or Entity List, (b) on the Office of Foreign Assets Control list of Specially Designated Nationals and Blocked Persons, and (c) involved with missile technology or nuclear, chemical or biological weapons). This is technically a violation of GPL, and could mean that anyone distributing Fedora with those restrictions has lost their rights to use and/or distribute the GPL software contained within Fedora. You may not download Fedora software or technical information if you are located in one of these countries, or otherwise affected by these restrictions. You may not provide Fedora software or technical information to individuals or entities located in one of these countries or otherwise affected by these restrictions. You are also responsible for compliance with foreign law requirements applicable to the import and use of Fedora software and technical information. This is just boilerplate for more US law applies to non-US citizens because we say so doctrine. Though it does not apply to non-US citizens, there is a risk. I formulated it like this in the Openswan book: Unrecognised international claims Certain countries claim jurisdiction even outside their national borders. Most notably, France claims the right to “regulate information on foreign servers”, Italy assumes jurisdiction over sites directed to an Italian audience and the US reserve the right to prosecute offenses against American interests according to US law, irrespective of where they take place. You may want to consider the possibility that you can be sued or prosecuted in another country. Additionally, if you are physically in a country other than the Netherlands when you download our software, you are probably subject to that country's jurisdiction anyway. And if your download happens to pass a router under US control (say in Guam), the US might make additional claims to rights for restriction of your packets or even your person. Note that this text was written a few years ago. For an updated situation, one should probably consult their local lawyer, please the updates from http://www.wassenaar.org/ Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
thinkpad and acpi events
Hi all, I encounter a little weirdness with the recent (aka 2.6.29.3-155.fc11.i586) kernel on my R61 Thinkpad: Neither Suspend on lid-shut nor reaction on power button work. It seems to me that there a no events registered by the driver. Does anyone else see that? Is there a way to log that events? regards christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unowned files and directories
On Sat, May 23, 2009 at 1:46 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: (¹) the list also leads to question like why are there /.dbus and /.pulse? My guess is some code in the installation process running as root with $HOME set to / is trying to connect to the DBus session bus. For compatibility with some unfortunate scenarios libdbus will attempt to auto-launch a bus using dbus-launch which will then create ~/.dbus. I assume pulse is similar (ideally pulse uses dbus, then we only have this bug once, but that's another discussion). Something trying to talk to the session bus sound familiar to anyone working on the installer? If we can set $HOME to /root that would sidestep most of the issues, alternatively in libdbus we could avoid autolaunching for root, since it should never be needed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
compat c++
Hi, I was just wondering, if there is a compat c++ compiler package (or mode) available in fedora. The issue I encountered was that I got a lot of compiler errors because of strdup() malloc() etc. usages in c++ files without proper #include legacy stuff. I am not a C++ expert, but I guess that there was a default behavior change between g++ 3 and 4. What I did was patching that package to get those #includes but as it contains a c++ code generator I also had to patch that. Although it seems to compile now, I still get zillions of DO NOT CAST char* TO string YOU FOOL warnings (wasn't there an option to get rid of them too?). Any kind of compat mode would make things alot easier (besides bringing the developers to write propert C++). regards christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 2009-05-26 at 13:15 +0200, Hans de Goede wrote: Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). Defining groups in the package is broken because different consumers of of the packages may wish to group those packages in different ways. When you define it in the package, you have to rebuild the package just to change how they're grouped. That's one of the big reasons why grouping should be done outside of the packages. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) 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: Agenda for the 2009-05-26 Packaging Committee meeting
Jesse Keating wrote: On Tue, 2009-05-26 at 13:15 +0200, Hans de Goede wrote: Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). ACK. Instead of abandoning rpm-Groups, it should be strengthened and comps be made strictly optional. Defining groups in the package is broken because different consumers of of the packages may wish to group those packages in different ways. When you define it in the package, you have to rebuild the package just to change how they're grouped. That's one of the big reasons why grouping should be done outside of the packages. Comps and Groups are addressing completely different issues. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 07:39 PM, Paul Wouters wrote: This is technically a violation of GPL, and could mean that anyone distributing Fedora with those restrictions has lost their rights to use and/or distribute the GPL software contained within Fedora.here they take place. FSF doesn't seem to think so http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thinkpad and acpi events
2009/5/26 Christoph Höger choe...@cs.tu-berlin.de: Hi all, I encounter a little weirdness with the recent (aka 2.6.29.3-155.fc11.i586) kernel on my R61 Thinkpad: Neither Suspend on lid-shut nor reaction on power button work. It seems to me that there a no events registered by the driver. Does anyone else see that? Is there a way to log that events? regards christoph I noticed something similar on a T41, I think that the thinkpad_acpi(or whatever it's name was) module wasn't loaded. Didn't have the time to look in to it. Can you check the loaded modules? -- NV -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 12:13 PM, Mathieu Bridon (bochecha) wrote: The penalties for export violation are steep and serious, which is why all Fedora contributors are required to abide by the export policies. Maybe this should be mentioned in the CLA ? We (Fedora contributors) have to sign it. Specifying it there would make it more widely known, and could provide a way to make contributors respect it (as they agreed and signed the CLA). Unless I miss it, it is not mentioned: https://fedoraproject.org/wiki/Legal/Licenses/CLA Nope. We'll definitely take that into consideration as we rework the CLA. Historically, we've only highlighted the export details onto people who are likely to redistribute Fedora as part of their normal activities (FreeMedia, Mirrors), but there is no reason we can't make it clear to everyone who signs the CLA. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090523 changes
Kevin Kofler (kevin.kof...@chello.at) said: Yet another insecure temporary file vulnerability. Why do we still not polyinstantiate /tmp by default? We're wasting lots of time on security measures which keep breaking apps such as SELinux, but simple things like polyinstantiation are still not used, why? This code would be perfectly safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? ... send patches? It's techncially feasible, but no one's done the legwork to integrate it fully yet. (xguest goes a bit beyond what we'd want by default.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: List of packages including country flags
Johan Cwiklinski (maili...@x-tnd.be) said: Considering this, I'm not sure simply removing flags for gcompris is the thing to do. Any thoughts ? It's the right thing from a UI standpoint. That dialog is horrible. Here's an example, when started in es_MX.UTF-8: http://notting.fedorapeople.org/gcompris.png 1) I started it in the locale of the largest Spanish-speaking population on the globe. So I get a (broken) flag image for an entirely different country? 2) Say I'm a child who can't read the language but is supposed to pick the language via flag. Not only is it not using a flag that I'd recognize in my locale, how am I even supposed to know that it's a language configuration area? There's no other information other than a name of the language (or 'your system default', which also isn't going to make a lot of sense to most kids) 3) There's also entries there to change the timing of the game, the skin, whether to have music or sound effects, etc. None of these have iconographic representations to make them usable by the pre-literate set. So yes, long term, the flags should be removed. Ideally, upstream would be convinced to do it. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Peter Lemenkov (lemen...@gmail.com) said: Subj. As Debian folks did years ago. Such branching will be done very easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
2009/5/26 Bill Nottingham nott...@redhat.com: Subj. As Debian folks did years ago. Such branching will be done very easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Not a serious reason. Why not to relocate then in Europe? -- With best regards! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090523 changes
On Di Mai 26 2009, Bill Nottingham wrote: Kevin Kofler (kevin.kof...@chello.at) said: Yet another insecure temporary file vulnerability. Why do we still not polyinstantiate /tmp by default? We're wasting lots of time on security measures which keep breaking apps such as SELinux, but simple things like polyinstantiation are still not used, why? This code would be perfectly safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? ... send patches? It's techncially feasible, but no one's done the legwork to integrate it fully yet. It is already done on the Fedorapeople server: https://fedoraproject.org/wiki/Infrastructure/FedoraPeopleConfig#polyinstantiated_tempdirs Regards Till 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: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, 2009-05-26 at 21:10 +0400, Peter Lemenkov wrote: 2009/5/26 Bill Nottingham nott...@redhat.com: Subj. As Debian folks did years ago. Such branching will be done very easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Not a serious reason. Why not to relocate then in Europe? -- With best regards! Find us a Company in Europe that is not based in the US that is willing to fund with people and money as much as Red Hat is doing now. Oh, Europe won't help much, there are just as many silly laws there as there are in the US. -- 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: Why not to create Fedora-us and Fedora-non-us branches?
Peter Lemenkov (lemen...@gmail.com) said: Subj. As Debian folks did years ago. Such branching will be done very easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Not a serious reason. Why not to relocate then in Europe? ... what exactly are you trying to accomplish? Make it legal to ship MP3 code? Sorry, those are patented in Europe as well. Make it so we can ship to various T-6 countries? I'm sure many European countries have their own lists as well. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On 05/26/2009 01:25 PM, Jesse Keating wrote: On Tue, 2009-05-26 at 21:10 +0400, Peter Lemenkov wrote: 2009/5/26 Bill Nottingham nott...@redhat.com: Subj. As Debian folks did years ago. Such branching will be done very easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Not a serious reason. Why not to relocate then in Europe? -- With best regards! Find us a Company in Europe that is not based in the US that is willing to fund with people and money as much as Red Hat is doing now. Oh, Europe won't help much, there are just as many silly laws there as there are in the US. Is there a reason that an interested party (in a locale where such export is legal) couldn't just create a custom spin on their own (and using their own build system) to create a Fedora-T6 spin (or for trademark reasons, rebrand it)? I can see this being a perfectly good premise for setting up a SIG... -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
J == Jason L Tibbitts ti...@math.uh.edu writes: J The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC J in the #fedora-meeting channel on chat.freenode.net. Due to lack of quorum, this meeting is postponed to Tuesday, 2009-06-02. I will send an updated agenda as the meeting approaches. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Chris Weyl wrote: A US corporation is subject to US law no matter where it operates. Sounds serious to me :) I think the idea is to found a Fedora foundation outside of the US to own Fedora instead of RH. The reason given for not creating a foundation was that US tax laws are problematic, creating it outside of the US would mean favorable tax laws could be chosen as well. That said, RH may still get into trouble for contributory infringement, and with a non-US foundation, RH may even get accused of tax evasion, so I'm not that surprised they aren't thrilled by the idea. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090523 changes
On Tue, 2009-05-26 at 19:12 +0200, Till Maas wrote: On Di Mai 26 2009, Bill Nottingham wrote: Kevin Kofler (kevin.kof...@chello.at) said: Yet another insecure temporary file vulnerability. Why do we still not polyinstantiate /tmp by default? We're wasting lots of time on security measures which keep breaking apps such as SELinux, but simple things like polyinstantiation are still not used, why? This code would be perfectly safe if polyinstantiation was mandatory. Why are we stuck in the 1970s? ... send patches? It's techncially feasible, but no one's done the legwork to integrate it fully yet. It is already done on the Fedorapeople server: https://fedoraproject.org/wiki/Infrastructure/FedoraPeopleConfig#polyinstantiated_tempdirs Hey, nice. That should really be an F12 feature. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 2009-05-26 at 10:39 +0200, Uwe Kiewel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I checked the ability to upgrade from F10 to F11 (Rawhide) directly using yum. A couple of weeks ago, there were dependency errors with python. These errors are not fixed until now. In my point of view, this issue should be fixed until GA of Leonidas. Others have explained what you should do to test this properly, but to address your final point: QA's stance on this is that the only supported upgrade methods are via the install images or preupgrade. Upgrade via yum has the status not explicitly supported but may well work. We don't consider issues which would cause upgrading from release to release via yum to be blockers, but issues which would cause upgrading via preupgrade to fail usually would be. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009 19:32:31 +0200, Kevin wrote: Michael Schwendt wrote: [And as long as there is no F11 GA repo yet, you need to enable rawhide manually.] Actually no, as the mirrorlists redirect you automatically. Well, great, but whatever very went wrong for Uwe (the OP), his Yum couldn't read the new XML mirrorlist and therefore couldn't construct a valid baseurl for fedora and other repos. YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. /metalink/ removing mirrorlist with no valid mirrors: //var/cache/yum/fedora/mirrorlist.txt Error: Cannot find a valid baseurl for repo: fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
Once upon a time, Tom spot Callaway tcall...@redhat.com said: Historically, we've only highlighted the export details onto people who are likely to redistribute Fedora as part of their normal activities (FreeMedia, Mirrors), but there is no reason we can't make it clear to everyone who signs the CLA. IIRC mirrors are not required to sign the CLA (I did, but that was because I was working towards being a packager as well). -- 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: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, 2009-05-26 at 13:29 -0400, Bill Nottingham wrote: Peter Lemenkov (lemen...@gmail.com) said: Subj. As Debian folks did years ago. Such branching will be done very easy technically. Because all the builds and composition is done in the US, and the trademarks are held by a US entity. Not a serious reason. Why not to relocate then in Europe? ... what exactly are you trying to accomplish? ...that isn't achieved, in practical terms, just as well by the existence of RPMFusion? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dependency errors while upgrading from F10 to Rawhide (F11)
On Tue, 26 May 2009, Michael Schwendt wrote: On Tue, 26 May 2009 19:32:31 +0200, Kevin wrote: Michael Schwendt wrote: [And as long as there is no F11 GA repo yet, you need to enable rawhide manually.] Actually no, as the mirrorlists redirect you automatically. Well, great, but whatever very went wrong for Uwe (the OP), his Yum couldn't read the new XML mirrorlist and therefore couldn't construct a valid baseurl for fedora and other repos. From f10's yum? Can I get a yum version number for what he's running? I think F10 GA had 3.2.20 in it.. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
On Tue, 26 May 2009, Stephen Gallagher wrote: Find us a Company in Europe that is not based in the US that is willing to fund with people and money as much as Red Hat is doing now. Oh, Europe won't help much, there are just as many silly laws there as there are in the US. 1) Your packets will still flow through the US anyway. 2) The US claim jurisdiction even outside their national borders and reserve the right to prosecute offenses against American interests according to US law, irrespective of where they take place. In other words, you could be extradited even if the offense would not actually be an offense in your country. For example, Dutch people have been extradited for selling drugs to US citizens in The Netherlands, even though marihuana is legal. (well, its complicated) Also, you could never set foot in the US again without getting arrested, and most of us don't think those T-6 countries are worh that. Is there a reason that an interested party (in a locale where such export is legal) couldn't just create a custom spin on their own (and using their own build system) to create a Fedora-T6 spin (or for trademark reasons, rebrand it)? I can see this being a perfectly good premise for setting up a SIG... respin what? remove the crypto? Try removing nss, openssl, gnutls and kerberos and see what's left of your system. Not much :P And who would want it? Surely not the T6 countries :P Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 02:39 PM, Chris Adams wrote: Once upon a time, Tom spot Callaway tcall...@redhat.com said: Historically, we've only highlighted the export details onto people who are likely to redistribute Fedora as part of their normal activities (FreeMedia, Mirrors), but there is no reason we can't make it clear to everyone who signs the CLA. IIRC mirrors are not required to sign the CLA (I did, but that was because I was working towards being a packager as well). Yes, but they are presented with the export restrictions. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting)
On 05/26/2009 04:10 AM, Richard W.M. Jones wrote:
I vote for also removing the %clean section.
So, looking at this objectively, here are the technical problems:
* We're defining a BuildRoot in the spec, but that definition is no
longer used (Fedora 10 or higher), because rpm now automagically sets it
for us.
* We're typing rm -rf %{buildroot} multiple times in every single Fedora
specfile. We want to invoke it twice:
- As the very first operation of the %install scriptlet
- As the very first operation of the %clean scriptlet
The concerns around removing the BuildRoot from the spec is that if that
spec is taken to an older system, the spec would either
* Not work
* Set the BuildRoot to / and cause massive system destruction
The good news is that for all the Fedora targets that we care about, if
BuildRoot is unset, it is just unset. It never gets set to / on anything
we care about (including RHEL 4 and 5, I checked).
And I really don't think we need to care about anything older than RHEL
4 (roughly equivalent to Fedora 6). A comment in the packaging
guidelines should be sufficient, so simply dropping the unnecessary
BuildRoot definition as soon as Fedora 9 is EOL seems like a sane course
of action.
The %install scriptlet case is reasonably simple to solve with
redhat-rpm-config's customized macros file, simply add:
%__spec_install_pre %{___build_pre}\
[ $RPM_BUILD_ROOT != / ] rm -rf ${RPM_BUILD_ROOT}\
mkdir -p `dirname $RPM_BUILD_ROOT`\
mkdir $RPM_BUILD_ROOT\
%{nil}
This ensures that every time %install is invoked in a spec file, it
checks that buildroot isn't / (which, it should never ever be, but given
the past history, doesn't hurt to check), then deletes it. Next, it
makes the basedir of $RPM_BUILD_ROOT, in case that doesn't exist, then
makes the buildroot for us, saving additional pain in some Fedora spec
files where the make install process is either too dumb to do this for
us (or non-existant).
The %clean scriptlet case is harder. Lets get the easy case out of the
way, removing the obligatory rm -rf %{buildroot} invocation:
%__spec_clean_pre %{___build_pre}\
[ $RPM_BUILD_ROOT != / ] rm -rf ${RPM_BUILD_ROOT}\
%{nil}
With that, every time %clean is invoked in a spec file, it checks that
buildroot isn't /, and then deletes it if it is not.
However, that doesn't really resolve the deeper desire, which is as
Richard points out, is to remove the need to explicitly state the %clean
section at all. If we need to overload it beyond its defaults, we should
be able to invoke it manually and append to it, but if it is not set, it
should be invoked automagically.
RPM doesn't act this way. For all scriptlets, their absence does not
result in automatic invocation (there is no idea of always executed
default scriptlets in a spec), but instead is how they are omitted. I
can certainly see valid use cases where a package would not want %clean
to be invoked. It might be possible to change RPM's behavior to
introduce a disabler mechanism for default always executed scriptlets:
pseudocode
%disable %check
/pseudocode
This would be a significant behavior change for RPM, and not something
we could do with distribution specific macro tweaks. It would also break
backwards compatibility with older RPM spec files, which has
traditionally been avoided.
*
So, given those facts, and assuming that RPM isn't changing its
behaviors anytime soon, we can make macro changes in redhat-rpm-config
and change from this:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
...
%install
rm -rf %{buildroot}
make DESTDIR=%{buildroot} install
...
%clean
rm -rf %{buildroot}
...
TO:
...
%install
make DESTDIR=%{buildroot} install
...
%clean
...
Is anyone opposed to that?
~spot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting)
On Tue, May 26, 2009 at 03:02:47PM -0400, Tom spot Callaway wrote: Is anyone opposed to that? Sounds like a very reasonable proposal. I'll note that coughDebian/cough packages include a minimum compatible standards (version) number. The RPM equivalent would I suppose be something like: Min-RPM: 4.4 RPM would check this and refuse to run if its version number was less than this, and of course older versions of RPM would fail completely when they see this header[1]. 'Course we'd have to educate people not to just remove the header or diddle around with the version number at random 'until it works'. Which maybe makes the proposal not completely idiot proof. Rich. [1] Or do they ..? I checked and they give this error: error: line 7: Unknown tag: Min-RPM:1.1 -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Bill Nottingham wrote: Peter Lemenkov (lemen...@gmail.com) said: ... what exactly are you trying to accomplish? Make it legal to ship MP3 code? Sorry, those are patented in Europe as well. Patents are *currently* illegal in Europe, (though they may be granted). The patents offices being self-funding and all that. http://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention Article 52 Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
TC == Tom \spot\ Callaway tcall...@redhat.com writes: TC Is anyone opposed to that? It's hard to oppose anything that frees us from carrying around all of this useless crap in every specfile. If we ever want our packaging to be considered sane, we have to make progress towards getting rid of stuff we don't really need and dumping the inexplicable random stuff that just gets included verbatim in every specfile without most folks understanding why it's there. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
Tom spot Callaway wrote: mkdir -p `dirname $RPM_BUILD_ROOT`\ mkdir $RPM_BUILD_ROOT\ Is that somehow better than just «mkdir -p $RPM_BUILD_ROOT»? Just curious. Björn Persson 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: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 2009-05-26 at 21:17 +0200, Uwe Kiewel wrote: We don't consider issues which would cause upgrading from release to release via yum to be blockers, but issues which would cause upgrading via preupgrade to fail usually would be. So, I have to google about preupgrade. It's the first time I hear about. I did the upgrade via yum since F5 successfuly... Sure. As I said, practically speaking, it's likely to work in many cases. It's just that if you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Dead package notice: freetype1
freetype1 is gone from F12. Nobody's currently using it, and more importantly nobody ought to be, anywhere, ever. - 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: dependency errors while upgrading vom F10 to Rawhide (F11)
On Tue, 26 May 2009, Adam Williamson wrote: On Tue, 2009-05-26 at 21:17 +0200, Uwe Kiewel wrote: We don't consider issues which would cause upgrading from release to release via yum to be blockers, but issues which would cause upgrading via preupgrade to fail usually would be. So, I have to google about preupgrade. It's the first time I hear about. I did the upgrade via yum since F5 successfuly... Sure. As I said, practically speaking, it's likely to work in many cases. It's just that if you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that (Will has done most of the implementing in the last MANY releases of preupgrade) doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline. The biggest problem you are likely to run into with a yum-based upgrade is situations where updating something takes out the foundation on which yum is running. The fontconfig bug comes to mind. If you want to run yum quasi-safely run it from a terminal, in screen. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
Till Maas (opensou...@till.name) said: On Di Mai 26 2009, Tom spot Callaway wrote: On 05/26/2009 04:10 AM, Richard W.M. Jones wrote: * Set the BuildRoot to / and cause massive system destruction What about setting BuildRoot to /home or /etc, this would case similiar massive system destruction? Well, also only if you're building as root. Which you shouldn't do anyways. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thinkpad and acpi events
[choe...@choeger6 ~]$ lsmod | grep think thinkpad_acpi 53944 0 hwmon 2148 1 thinkpad_acpi Seems like it's there. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
On Di Mai 26 2009, Björn Persson wrote: Tom spot Callaway wrote: mkdir -p `dirname $RPM_BUILD_ROOT`\ mkdir $RPM_BUILD_ROOT\ Is that somehow better than just «mkdir -p $RPM_BUILD_ROOT»? Just curious. It prevents a race condition in case that $(dirname $RPM_BUILD_ROOT) already exists or if all directories in the path to this directory are only writable by trustworthy users. In the default configuration, this was the /var/tmp directory, where every user could create a directory, make it writable for others and sneak content into the final rpm. Here is an explation, why 'mkdir -p $RPM_BUILD_ROOT' is vulnerable: http://lists.opensuse.org/opensuse-packaging/2007-02/msg5.html Regards Till 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: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, May 26, 2009 at 09:29:31PM +, Matej Cepl wrote: Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). Hear, hear!!! And add Suggests:/Recommends: (which is the other part of comps). +1000 +1001 ... I've just been involved with submitting a package for febootstrap to Debian [yay, build Fedora images on Debian!], and I'm reminded yet again what a good idea 'Suggests/Recommends' are. I can Suggest packages like 'filelight' for measuring the effects of image minimization, without making it a proper dependency and consequently pulling in the whole of KDE. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 2009-05-26 at 22:34 +0100, Richard W.M. Jones wrote: On Tue, May 26, 2009 at 09:29:31PM +, Matej Cepl wrote: Hans de Goede, Tue, 26 May 2009 13:15:23 +0200: Can we please not remove the Group tag, it is actually quite usefull. What we need to remove / loose is comps. Having all this info in a centralized database is stupid. The spec files should tell which group(s) the package belongs in. So that when one adds a new package, this gets done right more or less automatically (and is part of the review). Hear, hear!!! And add Suggests:/Recommends: (which is the other part of comps). +1000 +1001 ... I've just been involved with submitting a package for febootstrap to Debian [yay, build Fedora images on Debian!], and I'm reminded yet again what a good idea 'Suggests/Recommends' are. I can Suggest packages like 'filelight' for measuring the effects of image minimization, without making it a proper dependency and consequently pulling in the whole of KDE. Indeed - Mandriva's had Suggests for a year or two now, and I found it extremely convenient in several packages I maintain(ed). Isn't it going into upstream RPM soon, or in there already? I had this idea that it was. We'd likely still need comps in some form, though. MDV has Suggests and enforces Group tags, and still uses something similar to comps for fine-tuning ISO builds. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Matej Cepl mc...@redhat.com writes: Jesse Keating, Tue, 26 May 2009 10:25:36 -0700: Oh, Europe won't help much, there are just as many silly laws there as there are in the US. Better is some special place in Europe thinking ... what about Isle of Man, it has some exceptions from many laws ... err, we wouldn't be first Linux distro headquatered there :) Unless everyone working on Fedora *moves* to the Isle of Man (and obtains citizenship there), I don't think this sort of maneuver keeps us out of trouble anyway. Realistically we all have to worry about the laws of wherever we live. So as long as a significant fraction of Fedora contributors are in $country, $country laws will matter for Fedora. (Repeat above statement for a rather long list of $country.) regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: export policy, was Re: Package Maintainers Flags policy
| From: Tom spot Callaway tcall...@redhat.com | On 05/26/2009 10:09 AM, Paul Wouters wrote: | See above. Note that the Wassenaar Agreement excludes software that is | in the public domain, eg free/open source software. | | This is not correct. Public Domain has a very specific legal meaning, | and 99% of FOSS does _not_ meet it. Public Domain is when the copyright | holder has explicitly abandoned his/her/its copyright on the work and | placed it into the Public Domain. (Note: In some countries, such as | Germany, this is impossible) Tom is right about the meaning of public domain in US law. This is not the meaning in the Wassenaar Agreement. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Wed, May 27, 2009 at 7:10 AM, Tim Lauridsen tim.laurid...@googlemail.com wrote: soft-deps (Suggests/Recommends) is really hard to handle at the depsolver level. A depsolver need to now the hard ones, not stuff like 'it would look very nice to have pink bracelet to my little pony'. It is hard to make good decisions based on that, a asking the user every time is not a good solution IMO. You will need to take a popquiz every time you what to install a package. I can see that the information can be useful at a high level gui or in some kind of appstore. People there have bought 'foo' have also bought 'bar'. But at the lowlevel like rpm/yum is not very useful, because we don't have the needed infomation to make a good decision. I wouldn't think it's that hard to implement. When installing a new package, simply treat Suggests as Requires; when removing a package just ignore Suggests completely. Only upgrading adds a little complexity - if new version Suggests something that the old version doesn't, treat it as Requires (so that I get new optional pony accessories automatically), otherwise ignore it (so that I can throw away that optional pink bracelet and not have it come back every time I update). -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 477436] [padauk-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=477436 --- Comment #13 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-05-26 02:29:56 EDT --- APPROVED. You can do the administrative bits in http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#Source_package_naming_changes now -- 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 458430] Review Request: lcdf-typetools - Tools for manipulating OpenType and PostScript fonts
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=458430 --- Comment #12 from Parag pnem...@redhat.com 2009-05-26 02:56:32 EDT --- If no response received in next 15 days, I will close this review. -- 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 502565] New: CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide] https://bugzilla.redhat.com/show_bug.cgi?id=502565 Summary: CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide] Product: Fedora Version: rawhide Platform: All URL: http://fedoraproject.org/wiki/Security/TrackingBugs OS/Version: Linux Status: NEW Keywords: Security Severity: medium Priority: medium Component: freetype1 AssignedTo: a...@redhat.com ReportedBy: tho...@redhat.com QAContact: extras...@fedoraproject.org CC: a...@redhat.com, fedora-fonts-bugs-list@redhat.com Classification: Fedora Target Release: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in all affected branches. You should *not* refer to this bug publicly, as it is a private Fedora Project Contributors bug. For comments that are specific to the vulnerability please use bugs filed against Security Response product referenced in Blocks field. bug #484437: CVE-2006-1861 freetype: multiple integer overflow vulnerabilities bug #240200: CVE-2007-2754 freetype integer overflow Please close this bug with RAWHIDE (referencing appropriate N-V-R in Fixed In field if possible) once is it fixed in devel branch. Do *not* include the bug id of this bug in the RPM changelog and the commit message. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs -- 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 502565] CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
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=502565 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Blocks||484437(CVE-2006-1861), ||240200(CVE-2007-2754) --- Comment #1 from Tomas Hoger tho...@redhat.com 2009-05-26 04:09:30 EDT --- These old issues were previously fixed in FT2, but parts apply to FT1 as well. The fixes were included in RHEL freetype packages update (which contain both FT1 and FT2 on RHEL-2.1 - RHEL-4): http://rhn.redhat.com/errata/RHSA-2009-0329.html All current Fedora branches should contain same FT1 version with identical patches, so this should apply to all. -- 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 502565] CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
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=502565 --- Comment #3 from Tomas Hoger tho...@redhat.com 2009-05-26 04:16:20 EDT --- Created an attachment (id=345397) -- (https://bugzilla.redhat.com/attachment.cgi?id=345397) FT1 CVE-2007-2754 patch as used in RHSA -- 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 502565] CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
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=502565 --- Comment #2 from Tomas Hoger tho...@redhat.com 2009-05-26 04:15:45 EDT --- Created an attachment (id=345396) -- (https://bugzilla.redhat.com/attachment.cgi?id=345396) FT1 CVE-2006-1861 patch as used in RHSA -- 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 502577] CVE-2009-0946 freetype: multiple integer overflows
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=502577 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Blocks||491384(CVE-2009-0946) --- Comment #1 from Tomas Hoger tho...@redhat.com 2009-05-26 05:06:24 EDT --- As mentioned in the parent bug, not yet fixed in any upstream release. Should affect all current Fedora versions F9 - F12. -- 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 502577] New: CVE-2009-0946 freetype: multiple integer overflows
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: CVE-2009-0946 freetype: multiple integer overflows https://bugzilla.redhat.com/show_bug.cgi?id=502577 Summary: CVE-2009-0946 freetype: multiple integer overflows Product: Fedora Version: rawhide Platform: All URL: http://fedoraproject.org/wiki/Security/TrackingBugs OS/Version: Linux Status: NEW Keywords: Security Severity: medium Priority: medium Component: freetype AssignedTo: besfa...@redhat.com ReportedBy: tho...@redhat.com QAContact: extras...@fedoraproject.org CC: besfa...@redhat.com, ke...@tigcc.ticalc.org, fedora-fonts-bugs-list@redhat.com Classification: Fedora Target Release: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in all affected branches. For comments that are specific to the vulnerability please use bugs filed against Security Response product referenced in Blocks field. bug #491384: CVE-2009-0946 freetype: multiple integer overflows When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the Security Response product. Please mention CVE ids in the RPM changelog when available and only close this bug once all affected Fedora versions are fixed. -- 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 502582] New: CVE-2009-1194 pango: pango_glyph_string_set_size integer overflow
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: CVE-2009-1194 pango: pango_glyph_string_set_size integer overflow https://bugzilla.redhat.com/show_bug.cgi?id=502582 Summary: CVE-2009-1194 pango: pango_glyph_string_set_size integer overflow Product: Fedora Version: rawhide Platform: All URL: http://fedoraproject.org/wiki/Security/TrackingBugs OS/Version: Linux Status: NEW Keywords: Security Severity: high Priority: high Component: pango AssignedTo: besfa...@redhat.com ReportedBy: tho...@redhat.com QAContact: extras...@fedoraproject.org CC: besfa...@redhat.com, fedora-fonts-bugs-list@redhat.com Classification: Fedora Target Release: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in all affected branches. For comments that are specific to the vulnerability please use bugs filed against Security Response product referenced in Blocks field. bug #496887: CVE-2009-1194 pango: pango_glyph_string_set_size integer overflow When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the Security Response product. Please mention CVE ids in the RPM changelog when available and only close this bug once all affected Fedora versions are fixed. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=496887 -- 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 502582] CVE-2009-1194 pango: pango_glyph_string_set_size integer overflow
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=502582 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Blocks||496887(CVE-2009-1194) --- Comment #1 from Tomas Hoger tho...@redhat.com 2009-05-26 05:29:34 EDT --- F11 / F12 are already updated to fixed upstream version (1.24+), F9 and F10 are affected. -- 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 493479] Review Request: woodardworks-laconic-fonts - An artistic and minimal sans-serif font family
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=493479 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Flag|needinfo?(tcall...@redhat.c | |om) | --- Comment #2 from Tom spot Callaway tcall...@redhat.com 2009-05-26 10:51:42 EDT --- New Spec URL: http://www.auroralinux.org/people/spot/review/new/woodardworks-laconic-fonts.spec New SRPM URL: http://www.auroralinux.org/people/spot/review/new/woodardworks-laconic-fonts-001.001-2.fc11.src.rpm -- 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 473551] Fix dejavu-* dependencies
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=473551 Jarod Wilson jwil...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE --- Comment #8 from Jarod Wilson jwil...@redhat.com 2009-05-26 12:02:32 EDT --- Fixed yet again for the font package name dependency of the week. rrdtool-1.3.8-2 should get spit out of the build system shortly. -- 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 493479] Review Request: woodardworks-laconic-fonts - An artistic and minimal sans-serif font family
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=493479 --- Comment #3 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-05-26 14:46:37 EDT --- Created an attachment (id=345498) -- (https://bugzilla.redhat.com/attachment.cgi?id=345498) laconic shadow fontconfig rules -- 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/freetype1/devel dead.package, NONE, 1.1 freetype-1.3.1-1.4pre.patch, 1.1, NONE freetype-1.4-disable-ft1-bci.patch, 1.1, NONE freetype-1.4pre-CVE-2008-1808.patch, 1.1, NONE freetype1.spec, 1.6, NO
Author: ajax Update of /cvs/pkgs/rpms/freetype1/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25451 Added Files: dead.package Removed Files: freetype-1.3.1-1.4pre.patch freetype-1.4-disable-ft1-bci.patch freetype-1.4pre-CVE-2008-1808.patch freetype1.spec sources Log Message: Unused in Fedora, and unmaintained upstream. --- NEW FILE dead.package --- Unused in Fedora, and unmaintained upstream. --- freetype-1.3.1-1.4pre.patch DELETED --- --- freetype-1.4-disable-ft1-bci.patch DELETED --- --- freetype-1.4pre-CVE-2008-1808.patch DELETED --- --- freetype1.spec DELETED --- --- sources DELETED --- ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/freetype1/F-11 freetype1.spec,1.6,1.7
Author: ajax
Update of /cvs/pkgs/rpms/freetype1/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29325
Modified Files:
freetype1.spec
Log Message:
* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
Index: freetype1.spec
===
RCS file: /cvs/pkgs/rpms/freetype1/F-11/freetype1.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- freetype1.spec 24 Feb 2009 18:30:12 - 1.6
+++ freetype1.spec 26 May 2009 20:28:24 - 1.7
@@ -4,7 +4,7 @@
Name: freetype1
Version:1.4
-Release:0.7.pre%{?dist}
+Release:0.8.pre%{?dist}
Summary:Free TrueType font rendering engine, compatibility version
Group: System Environment/Libraries
License:FTL
@@ -15,6 +15,9 @@ Source: http://downloads.sourcef
Patch0: freetype-1.3.1-1.4pre.patch
Patch1: freetype-1.4-disable-ft1-bci.patch
Patch2: freetype-1.4pre-CVE-2008-1808.patch
+Patch3:cve-2006-1861.patch
+Patch4:cve-2007-2754.patch
+
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: zlib-devel libXt-devel gettext
@@ -61,6 +64,8 @@ developing applications that use %{name}
%endif
%patch2 -p1
+%patch3 -p1
+%patch4 -p1
iconv -f ISO-8859-1 -t UTF-8 docs/i18n.txt docs/i18n.txt.tmp
touch -r docs/i18n.txt docs/i18n.txt.tmp
@@ -125,6 +130,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
+- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
+
* Tue Feb 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4-0.7.pre
- 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/freetype1/F-11 cve-2006-1861.patch, NONE, 1.1 cve-2007-2754.patch, NONE, 1.1
Author: ajax
Update of /cvs/pkgs/rpms/freetype1/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29730
Added Files:
cve-2006-1861.patch cve-2007-2754.patch
Log Message:
* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
cve-2006-1861.patch:
--- NEW FILE cve-2006-1861.patch ---
diff -up
freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
2009-05-12 19:40:52.0 -0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:41:03.0 -0400
@@ -270,6 +270,10 @@
j= 0;
flag = exec-pts.touch;
+/* CVE-2006-1861 */
+if ( flag == NULL )
+ return TT_Err_Invalid_Composite; /* for lack of a better err code */
+
while ( j n_points )
{
Byte c, cnt;
cve-2007-2754.patch:
--- NEW FILE cve-2007-2754.patch ---
diff -up freetype-pre1.4/lib/ttgload.c.ttf-overflow
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.ttf-overflow 2009-05-12 19:25:25.0
-0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:28:15.0 -0400
@@ -236,7 +236,7 @@
FORGET_Frame();
-if ( n_points left_points )
+if ( n_points 0 || n_points left_points )
{
PTRACE0(( ERROR: Too many points in glyph %ld\n, subg-index ));
return TT_Err_Too_Many_Points;
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/freetype1/F-10 cve-2006-1861.patch, NONE, 1.1 cve-2007-2754.patch, NONE, 1.1 freetype1.spec, 1.5, 1.6
Author: ajax
Update of /cvs/pkgs/rpms/freetype1/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30111
Modified Files:
freetype1.spec
Added Files:
cve-2006-1861.patch cve-2007-2754.patch
Log Message:
* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
cve-2006-1861.patch:
--- NEW FILE cve-2006-1861.patch ---
diff -up
freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
2009-05-12 19:40:52.0 -0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:41:03.0 -0400
@@ -270,6 +270,10 @@
j= 0;
flag = exec-pts.touch;
+/* CVE-2006-1861 */
+if ( flag == NULL )
+ return TT_Err_Invalid_Composite; /* for lack of a better err code */
+
while ( j n_points )
{
Byte c, cnt;
cve-2007-2754.patch:
--- NEW FILE cve-2007-2754.patch ---
diff -up freetype-pre1.4/lib/ttgload.c.ttf-overflow
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.ttf-overflow 2009-05-12 19:25:25.0
-0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:28:15.0 -0400
@@ -236,7 +236,7 @@
FORGET_Frame();
-if ( n_points left_points )
+if ( n_points 0 || n_points left_points )
{
PTRACE0(( ERROR: Too many points in glyph %ld\n, subg-index ));
return TT_Err_Too_Many_Points;
Index: freetype1.spec
===
RCS file: /cvs/pkgs/rpms/freetype1/F-10/freetype1.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- freetype1.spec 14 Jun 2008 08:41:03 - 1.5
+++ freetype1.spec 26 May 2009 20:31:01 - 1.6
@@ -4,7 +4,7 @@
Name: freetype1
Version:1.4
-Release:0.6.pre%{?dist}
+Release:0.8.pre%{?dist}
Summary:Free TrueType font rendering engine, compatibility version
Group: System Environment/Libraries
License:FTL
@@ -15,6 +15,9 @@ Source: http://downloads.sourcef
Patch0: freetype-1.3.1-1.4pre.patch
Patch1: freetype-1.4-disable-ft1-bci.patch
Patch2: freetype-1.4pre-CVE-2008-1808.patch
+Patch3:cve-2006-1861.patch
+Patch4:cve-2007-2754.patch
+
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: zlib-devel libXt-devel gettext
@@ -61,6 +64,8 @@ developing applications that use %{name}
%endif
%patch2 -p1
+%patch3 -p1
+%patch4 -p1
iconv -f ISO-8859-1 -t UTF-8 docs/i18n.txt docs/i18n.txt.tmp
touch -r docs/i18n.txt docs/i18n.txt.tmp
@@ -125,6 +130,12 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
+- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
+
+* Tue Feb 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4-0.7.pre
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
* Sat Jun 14 2008 Hans de Goede j.w.r.dego...@hhs.nl 1.4-0.6.pre
- Backport fixes for CVE-2008-1806, CVE-2008-1807 and CVE-2008-1808 to
freetype 1 (where applicable, bz 450773, 450774)
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 502565] CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
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=502565 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2009-05-26 16:55:07 EDT --- freetype1-1.4-0.8.pre.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/freetype1-1.4-0.8.pre.fc10 -- 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 502565] CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
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=502565 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2009-05-26 16:55:53 EDT --- freetype1-1.4-0.8.pre.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/freetype1-1.4-0.8.pre.fc11 -- 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 502565] CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
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=502565 Alexei Podtelezhnikov apodt...@ucsd.edu changed: What|Removed |Added CC||apodt...@ucsd.edu --- Comment #6 from Alexei Podtelezhnikov apodt...@ucsd.edu 2009-05-26 17:26:18 EDT --- Would you please fix a typo (obsolote) in the package description and make it more obvious that it is an old-old library by moving the second paragraph upfront? I am curious which package still uses it and why we cannot drop this old library. Nobody should use it any longer. -- 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 502307] Review Request:sil-charis-compact-fonts - A version of Charis SIL with tighter line spacing
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=502307 Jason Tibbitts ti...@math.uh.edu changed: What|Removed |Added Flag|fedora-cvs? |fedora-cvs+ --- Comment #3 from Jason Tibbitts ti...@math.uh.edu 2009-05-26 18:30:20 EDT --- CVS done. -- 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
mobile phone + password = 2 factor auth?
I was changing some settings with my mobile phone company and in order to change my password they made me use what looks a lot like 2 factor auth: something I know: my current password something I have: my phone I logged in with my current password - then they txt'd me a temporary password which I had to type in to verify I was me. Which got me to wondering - if most people have a mobile phone and/or have access to one - why couldn't we use that as the second factor for our auth? I can think of multiple ways to do it: 1. login to a web page 2. click on 'auth me' button 3. it sends you a txt msg 4. you input the password it sent you 5. you get a cert back that you use for auths for a set period of time (24 hours?) or 1. login to a webpage 2. download a key 3. it sends you a txt msg which contains a password for that key 4. the key + txt'd password allows you to login for a set period of time (24 hours?) Now, my question is - what is dangerous/silly about this? -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Make bacula backup to /bacula/, include db1's db3 dumps.
Sorry, the commit message wasn't as clear as it could have been. backup1 has been running out of space on catalog backup jobs, as it makes a temporary dump of the bacula database in /var/spool/bacula/bacula.sql. This commit moves this temporary dump to /bacula, which has more space. The other thing in this commit is that it adds /var/lib/mysql/backups into the include list, which makes bacula backup db1's backup of db3. Currently, we're excluding these files, but we're still backing up dumps of db3 in several other places. I'd like to commit these to puppet and run puppet on backup1. Can I get two +1s? Thanks, Ricky pgpuoUtffEMZI.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: mobile phone + password = 2 factor auth?
On Tue, 2009-05-26 at 11:01 -0400, Seth Vidal wrote: 2. cost structure of sending/receiving a lot of txt msgs. Don't most carriers offer an email gateway to sms? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: mobile phone + password = 2 factor auth?
On Tue, 2009-05-26 at 17:44 +0200, Till Maas wrote: A problem with phones is, that they are typically not as secure as hardware tokens. Users can install custom software on them. Also the phone may be compromised via bluetooth. It might be even possible to directly access text messages via bluetooth or maybe also wifi nowadays. Wouldn't that be why you have to combine what comes up on your phone with the password you know, so that just the phone alone can't get you in? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: mobile phone + password = 2 factor auth?
On Tue, 26 May 2009, Bryan Kearney wrote: Seth Vidal wrote: On Tue, 26 May 2009, Bryan Kearney wrote: Seth Vidal wrote: Now, my question is - what is dangerous/silly about this? Luddites like me who have disabled text messages on their phones. Well your options would eventually be: - enable txt msgs - carry a yubikey with you everywhere As long as I get a non-text msg version I am fine. To your original question... things to consider: 1) Cost of sending SMS. 2) How to prove that bkear...@foo.com == 555-1212 1. acknowledged - but we know there is a cost to the hardware keys, too. 2. you prove that they are related the same way that I prove that when we issue a hw key to skvi...@fedoraproject.org that it goes to ME. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: mobile phone + password = 2 factor auth?
On Tue, 26 May 2009, Seth Vidal wrote: I was changing some settings with my mobile phone company and in order to change my password they made me use what looks a lot like 2 factor auth: something I know: my current password something I have: my phone I logged in with my current password - then they txt'd me a temporary password which I had to type in to verify I was me. Which got me to wondering - if most people have a mobile phone and/or have access to one - why couldn't we use that as the second factor for our auth? Now, my question is - what is dangerous/silly about this? Jeremy mentioned some potential problems on jabber: 1. no guaranteed message delivery time 2. cost structure of sending/receiving a lot of txt msgs. In both cases I'd be curious how that ends up in practice. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
