An error while using livecd-creator
Hi,
I am using livecd-creator on a F-11 box. I have 27GB free on my / partition.
The error I am getting is given below:
[r...@rhelabi spin-kickstarts]# livecd-creator
--config=photographers-11.ks --cache=cache/ --fslabel=photographers
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=photographers
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
196608 inodes, 786432 blocks
7864 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=805306368
24 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
tune2fs 1.41.4 (27-Jan-2009)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
filespec_eval: hash table stats: 12 elements, 12/65536 buckets used,
longest chain length 1
Retrieving
http://ftp.linux.ncsu.edu/pub/fedora/linux/releases/11/Everything/i386/os/repodata/repomd.xml
...OK
Retrieving
http://mirror.hmc.edu/fedora/linux/updates/11/i386/repodata/repomd.xml
...OK
No such package *debuginfo to remove
/usr/lib/python2.6/site-packages/imgcreate/errors.py:45:
DeprecationWarning: BaseException.message has been deprecated as of
Python 2.6
return unicode(self.message)
Error creating Live CD : Unable to install: [('installing package
bug-buddy-1:2.26.0-2.fc11.i586 needs 684KB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 700416L)), ('installing
package gvfs-gphoto2-1.2.3-9.fc11.i586 needs 920KB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 942080L)), ('installing
package gvfs-fuse-1.2.3-9.fc11.i586 needs 948KB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 970752L)), ('installing
package gvfs-smb-1.2.3-9.fc11.i586 needs 2MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 1273856L)), ('installing
package gvfs-archive-1.2.3-9.fc11.i586 needs 2MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 1421312L)), ('installing
package vino-2.26.2-1.fc11.i586 needs 4MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 3796992L)), ('installing
package gnome-session-xsession-2.26.2-1.fc11.i586 needs 4MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 3805184L)), ('installing
package postr-0.12.3-2.fc11.noarch needs 5MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 4587520L)), ('installing
package gnome-panel-2.26.3-1.fc11.i586 needs 16MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 16580608L)), ('installing
package gnome-applets-1:2.26.3-1.fc11.i586 needs 40MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 41603072L)), ('installing
package bluez-4.42-1.fc11.i586 needs 41MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 42848256L)), ('installing
package pulseaudio-module-bluetooth-0.9.15-14.fc11.i586 needs 42MB on
the /var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 43061248L)), ('installing
package gnome-bluetooth-2.27.5-1.fc11.i586 needs 43MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 44228608L)), ('installing
package gnome-bluetooth-libs-2.27.5-1.fc11.i586 needs 43MB on the
/var/tmp/imgcreate-rScTyr/install_root filesystem', (9,
'/var/tmp/imgcreate-rScTyr/install_root', 44331008L))]
Any pointer on how to fix this ?
Kushal
--
http://fedoraproject.org
http://kushaldas.in
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Tue, 11 Aug 2009 00:24:01 +0300 Axel Thimm wrote: > Hi, > > On Mon, Aug 10, 2009 at 10:15:42AM -0600, Kevin Fenzi wrote: > > Here's attached another run of my sources/patches url checker. > > can one download this script somewhere to locally apply to one's > packages and understand why the errors (maybe false positives) are > shown? Thanks! Yes, it's in the same dir as the files: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck Note that it's an ugly shell script. :) If someone wants to re-write it in python or something and tie it into the auto-qa efforts, feel free to do so. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Mon, 10 Aug 2009 21:24:54 +0200 Andrea Musuruane wrote: > On Mon, Aug 10, 2009 at 6:15 PM, Kevin Fenzi wrote: > > Here's attached another run of my sources/patches url checker. > > musuruan:BADSOURCE:hatari-1.2.0.tar.bz2:hatari > > Thanks! URL changed. I'll updated it soon. Thanks. > > musuruan:BADSOURCE:libicns-0.7.0.tar.gz:libicns > > This is valid. Temporary SF problem? The URL is fine, but the source doesn't match up. What I downloaded from the URL: e2932389d10ccee20dc922155165c8f8 libicns-0.7.0.tar.gz what sources has in the lookaside cache: d2539bb1bec033395ad908311c49a954 libicns-0.7.0.tar.gz So, either upstream changed sources without changing release, or something else bad happened. ;( > Regards, > > Andrea. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Reminder: fit and finish test day tomorrow
Just a quick reminder: We are meeting tomorrow in #fedora-fit-and-finish on freenode to test how well F12 works with phones, music players, cameras, usb sticks and other things you care to plug into your computer. See http://www.fedoraproject.org/wiki/Test_Day:2009-08-04_Fit_and_Finish:Peripherals Live cds are available on that page now. See you tomorrow, Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Mon, 2009-08-10 at 10:15 -0600, Kevin Fenzi wrote: > jkeating:BADSOURCE:email2trac.tar.gz:email2trac This has been fixed. Silly upstream doesn't version their tarball. -- 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: midi seq interface vs. fc11: #505421
On Tue, 2009-07-21 at 09:48 -0700, Fernando Lopez-Lezcano wrote: > Hi... anyone out there could help with the bugzilla bug 505421?? Filed > on 2009-06-11, no answers of substance yet and no workaround suggested. Now at the 2009-08-10 mark... > Should be easy, a module is not being loaded on demand, it was before. > > I keep getting questions about this on the Planet CCRMA list, it makes > midi unusable for a normal user, anyone installing fc11 for audio _will_ > stumble into this problem. It was working, it is broken, please fix it! Thanks Adam for writing a comment in the bug that agrees this issue should be fixed ASAP... Fully up to date fc11, trying again, problem still has not been fixed. Sigh. I _know_ the following is not going to get anything fixed, but will anyone left using midi in fedora have to wait till fc12? (ie: very basic stuff like this not being fixed means a bad initial experience for whoever tries the distro, usually meaning the trial install immediately following it is not going to be Fedora). -- Fernando -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switch from OpenAL to OpenAL-Soft
Shouldn't it also be possible for openal-soft to replace the crappy old OpenAL package included in previous versions of Fedora? The openal-soft library is supposed to be compatible with applications that normally use the older OpenAL SI library that has been rotting for years. On Mon, Aug 10, 2009 at 6:08 PM, LinuxDonald wrote: > I have add the openal-soft package into fedora 12 that will replace > openal. > At all packager when you have openal as dependency please change it to > openal-soft and recompile your package for f-12 please > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Switch from OpenAL to OpenAL-Soft
I have add the openal-soft package into fedora 12 that will replace openal. At all packager when you have openal as dependency please change it to openal-soft and recompile your package for f-12 please -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/10/2009 11:56 PM, Ben Boeckel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Corsepius wrote: On 08/10/2009 09:01 PM, Bill McGonigle wrote: Are these of the sort where a bug is reported, it's found that autotools made a bad decision, and then patching autotools fixed the problem? Unlike some people around on this list, these tools' upstreams know how to use the autotools (I am active contributor to all of them): Use pregenerated files, do not run the autotools while building. And things like this make the autotools completely unattractive as a developer (to me at least). Well, not all tools suite all needs. If you believe other tools better suite your needs, use them, if you feel like it. But if you use a tool (such as the autotools) you should learn to use them and to use them correctly. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Consistent PolicyKit system policy
On Mon, Aug 10, 2009 at 15:42, Colin Walters wrote: > On Mon, Aug 10, 2009 at 9:08 AM, Tim Waugh wrote: > >> What is the goal of the default Fedora PolicyKit policy system-wide, and >> how can we check that PolicyKit mechanisms' default policies are >> adhering to it? > > Generally where I'd like to move to is where the RPM package defaults > are appropriate for a shared computer lab PC, and the desktop spin > kickstart modifies things as appropriate for the unmanaged home > PC/laptop. I'm confused, does this mean that the desktop spin doesn't (or won't) use the RPM package defaults? If so, what about someone who install a « shared computer lab PC » using the desktop spin? After all, users of this « shared lab PC » need a desktop, so the admin could think the desktop spin is the most appropriate... That seems confusing, and potentially misguiding :-/ Or did I simply not understand what you meant? Best regards, -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: possible to file bug to change 32-bit DVD arch name from i386 to i686?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre Robatino wrote: > On 08/07/2009 08:26 PM, Ben Boeckel wrote: >> yum also uses i386 for $basearch which causes (well, it's >> chicken-and-egg) repos to have i386 directories. These should >> also go with this update I imagine. > > Is it possible to do one without the other? It would be nice if the > names of the ISOs could be changed now to reduce user confusion over > whether it can install on their machine. Having an i386 basearch is > probably less visible to most people. Both changes should be made > eventually but people may be too busy right now to do both. I wrote "should" where I should have written "could". Sorry for the confusion. In any case, both of these changes are probably best done at a major release and the earliest would be F13 at this point. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqAl/oACgkQiPi+MRHG3qR4GQCeJwoJqWFpCl2xTg1FdUIWRdFL dyUAoKa9TMdnhZduMwzP7/419ZzB9gpg =gh9Q -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Corsepius wrote: > On 08/10/2009 09:01 PM, Bill McGonigle wrote: >> Are these of the sort where a bug is reported, it's found that autotools >> made a bad decision, and then patching autotools fixed the problem? > Unlike some people around on this list, these tools' upstreams know how > to use the autotools (I am active contributor to all of them): > Use pregenerated files, do not run the autotools while building. > > Ralf And things like this make the autotools completely unattractive as a developer (to me at least). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqAl5YACgkQiPi+MRHG3qSwgQCgjKugZQpLTmm6ONNWCUbg0ptU YRgAn0LDfIbEMmGkOJNV0yB84xdmzQDa =+4DF -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Consistent PolicyKit system policy
On Mon, 2009-08-10 at 09:42 -0400, Colin Walters wrote: > Generally where I'd like to move to is where the RPM package defaults > are appropriate for a shared computer lab PC, and the desktop spin > kickstart modifies things as appropriate for the unmanaged home > PC/laptop. It would do this by writing to the appropriate files in /var/lib/PolicyKit-public/? > We don't do this at all now though =) For your particular case I > think your current policy is the best we can do for all targets. OK, good to know. Thanks. Tim. */ 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: source file audit - 2009-08-10
Hi, On Mon, Aug 10, 2009 at 10:15:42AM -0600, Kevin Fenzi wrote: > Here's attached another run of my sources/patches url checker. can one download this script somewhere to locally apply to one's packages and understand why the errors (maybe false positives) are shown? Thanks! -- Axel.Thimm at ATrpms.net pgpMfzOs0lqxH.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Slip of Fedora 12 Alpha by one week
Today in the release engineering meeting, it was decided to enact a one week slip of the Fedora 12 Alpha release date. This is due to remaining bugs on the F12Alpha tracker preventing creation of a release candidate and preventing testing of proposed fixes. We expect to be able to test/clear the list early this week, therefor only a week slip is needed at this time. The new Alpha release date August 25th. As soon as we have a successful Alpha compose we will lift the Alpha freeze and allow rawhide to move forward. We also agreed to adjust the final schedule based on Alpha slipping, however we are deferring that discussion to a later date, once we've successfully composed Fedora 12 Alpha. John Poelstra will send mail regarding this later. -- 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-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/10/2009 09:01 PM, Bill McGonigle wrote: On 08/10/2009 11:44 AM, Ralf Corsepius wrote: They are very easy to demonstrate. Commonly known cases are building gcc, binutils, gdb, firefox etc. Are these of the sort where a bug is reported, it's found that autotools made a bad decision, and then patching autotools fixed the problem? Unlike some people around on this list, these tools' upstreams know how to use the autotools (I am active contributor to all of them): Use pregenerated files, do not run the autotools while building. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: possible to file bug to change 32-bit DVD arch name from i386 to i686?
On 08/07/2009 08:26 PM, Ben Boeckel wrote: > Andre Robatino wrote: > >> The names of the 32-bit Live CDs already use i686, consistent > with the >> minimum required arch. But the 32-bit DVD still uses i386, > despite the >> fact that not only has i586 been required for years, but with > the i586 >> package rebuild, there aren't even any i386 packages on the > DVD anymore. >> Now i686 is required and all packages are i686 (or noarch). > I'd like >> to file a bug to get this changed, in order to increase the > chance it >> actually happens by F12 Final. (The 32-bit F12 Alpha TC is > still named >> using i386.) Is this possible, and if so, under what > component should I >> file it? > > yum also uses i386 for $basearch which causes (well, it's > chicken-and-egg) repos to have i386 directories. These should > also go with this update I imagine. Is it possible to do one without the other? It would be nice if the names of the ISOs could be changed now to reduce user confusion over whether it can install on their machine. Having an i386 basearch is probably less visible to most people. Both changes should be made eventually but people may be too busy right now to do both. signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/10/2009 08:48 PM, Kevin Kofler wrote: Ralf Corsepius wrote: I am applying this approach to several of my Fedora packages (some of which I know to suffer from such issues, e.g. Coin2), fixed some packages (owned by others) this way, which had failed during the F11-mass-rebuild, exactly because of such issues. I'd be pretty pissed off if you "fixed" one of my packages that way, instead of addressing the real issue (that rerunning the current autotools fails). Thanks for providing evidence for you not having understood the problems. Also, thank you for you crossposting to a newgroup in replies list postings. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora Release Engineering meeting summary for 2009-08-10
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-10/fedora-meeting.2009-08-10-18.08.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-08-10/fedora-meeting.2009-08-10-18.08.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-10/fedora-meeting.2009-08-10-18.08.log.html Meeting log --- * **roll call** (Oxf13-18:08:41_) * **old business** (Oxf13-18:14:50_) * **orphans (old business)** (Oxf13-18:15:37_) * *ACTION*: Oxf13 will send warning about recursively removing cryptix today (Oxf13-18:16:43_) * **critical path (old business)** (Oxf13-18:17:11_) * *LINK*: http://koji.fedoraproject.org/koji/buildinfo?buildID=126049 (dgilmore-18:19:30_) * *ACTION*: Oxf13 will make sure the latest fedora-packager gets tagged for Alpha so that the tag-request make target can be used. (Oxf13-18:20:01_) * *ACTION*: lmacken still needs to report on critical path bodhi updates (Oxf13-18:20:46_) * **rpm changes (old business)** (Oxf13-18:21:15_) * *ACTION*: dgilmore will draft an SOP (with help) for managing RPM changes in rawhide (Oxf13-18:21:42_) * **no frozen rawhide (old business)** (Oxf13-18:21:56_) * **signing (old business)** (Oxf13-18:23:01_) * **Fedora 12 Alpha** (Oxf13-18:24:22_) * *AGREED*: A newer anaconda will be tagged today, even if it's known broken, to help with verifying other bug fixes. (Oxf13-18:35:09_) * *AGREED*: Slip alpha 1 week. Intend to slip final one week. Discuss schedule consequences at the planned release readiness meeting while using logistics list to gather feedback. (Oxf13-19:10:12_) * **open floor** (Oxf13-19:19:41_) * *ACTION*: Oxf13 will announce Alpha slip (Oxf13-19:20:44_) * *ACTION*: poelcat will announce intention to slip final and start discussion on logistics list to discuss impact of such slip. (Oxf13-19:21:47_) * *AGREED*: no need to vette the slip decision via FESCo (Oxf13-19:23:51_) * *ACTION*: Oxf13 to deliver F12 key ID to notting for mash configs (Oxf13-19:28:29_) -- 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: pygtk2 and its numpy dependency
Hi, > pygtk2 implements a function called gtk.gdk.get_pixels_array(), which > returns the pixel contents of a GDK pixbuf as a numpy array. Fine and > dandy, but this means it links against numpy (7 megs) which is itself > linked against atlas (12 megs). Kind of a lot for a single function, > especially on a live image. > > Especially for a function that's basically unused! gnome-applet-music > uses it to implement a poor-man's Porter-Duff blend, and that's the only > caller currently packaged in Fedora, at least according to package deps. > I have a patch (attached) that fixes that [1], which means we could > compile our pygtk2 without numpy support and not break anything in > Fedora proper. > > However, google codesearch does turn up what look like a few other users > of that function, some of which we may actually want to ship someday. > So we've got options: > > a) remove the explicit Requires: numpy from pygtk2, require apps that > actually want this function to Require it themselves > > b) fake the numpy data type ABI in pygtk2 itself by cult-and-pasting it > from numpy > > c) declare that get_pixels_array() just doesn't work in Fedora > (historically true, back in like FC3) > > d) leave things as they are > > I lean towards a). I think b) is icky but doable, since that ABI is > effectively unbreakable anyway (inherited from the older python-numeric > module). The other two are way lame. > > Thoughts? I know sugar use numpy and pygtk. They had forked pygtk packages with patches so that they could use the functionality in older releases. I'm not sure whether including adding numpy to the requires would work or not as I don't know the codebase. Peter > [1] - Readers are invited to count the wtf's in the code being replaced, > as well as in its callers. Don't treat it as a drinking game though. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review: Fedora 12 Alpha Release Notes
On Mon, 2009-08-10 at 20:38 +0530, Rahul Sundaram wrote: > Hi, > > Wit the Fedora 12 Alpha release coming up shortly, now would be a good > time to review the release notes. Make sure the major features are > covered, import bugs and workarounds noted etc > > http://fedoraproject.org/wiki/Fedora_12_Alpha_release_notes I'd actually prefer to keep bugs and workarounds noted in the Common Bugs page now, if that's OK with you. My plan since re-working the Common Bugs page for F11 has been to have the F12 page start with the Alpha release, and cover pre-release issues right up until the final release, then switch to covering final release issues. I'll try and put a bare-bones page framework up soon. -- 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: source file audit - 2009-08-10
On Mon, Aug 10, 2009 at 11:15 AM, Kevin Fenzi wrote: > maxamillion:BADURL:dc3dd-6.12.3.tar.gz:dc3dd > maxamillion:BADURL:oggvideotools-0.7b.tar.gz:oggvideotools > maxamillion:BADURL:shed-1.15.tar.gz:shed > maxamillion:BADURL:TPG-3.1.2.tar.gz:python-tpg Mine are fixed and rawhide builds are complete. Many thanks for running the report. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: pygtk2 and its numpy dependency
On Mon, 2009-08-10 at 14:40 -0500, Jon Ciesla wrote: > Adam Jackson wrote: > > a) remove the explicit Requires: numpy from pygtk2, require apps that > > actually want this function to Require it themselves > > > > b) fake the numpy data type ABI in pygtk2 itself by cult-and-pasting it > > from numpy > > > > c) declare that get_pixels_array() just doesn't work in Fedora > > (historically true, back in like FC3) > > > > d) leave things as they are > > > Since pygtk2 does actually use numpy, isn't d) the best (albeit most > annoying) option? Internally? Or just to implement that one entrypoint? I believe it to be the latter. - 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: source file audit - 2009-08-10
Hi, > pbrobinson:BADURL:Journal-99.tar.bz2:sugar-journal I'm pretty sure this has been obsoleted and is a dead package but I'm in the process of confirming the status and will update as appropriate once I have confirmation. > pbrobinson:BADURL:mojito-0.19.2.tar.bz2:mojito This is fixed in cvs and will go out with the next release. Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: pygtk2 and its numpy dependency
Adam Jackson wrote: pygtk2 implements a function called gtk.gdk.get_pixels_array(), which returns the pixel contents of a GDK pixbuf as a numpy array. Fine and dandy, but this means it links against numpy (7 megs) which is itself linked against atlas (12 megs). Kind of a lot for a single function, especially on a live image. Especially for a function that's basically unused! gnome-applet-music uses it to implement a poor-man's Porter-Duff blend, and that's the only caller currently packaged in Fedora, at least according to package deps. I have a patch (attached) that fixes that [1], which means we could compile our pygtk2 without numpy support and not break anything in Fedora proper. However, google codesearch does turn up what look like a few other users of that function, some of which we may actually want to ship someday. So we've got options: a) remove the explicit Requires: numpy from pygtk2, require apps that actually want this function to Require it themselves b) fake the numpy data type ABI in pygtk2 itself by cult-and-pasting it from numpy c) declare that get_pixels_array() just doesn't work in Fedora (historically true, back in like FC3) d) leave things as they are I lean towards a). I think b) is icky but doable, since that ABI is effectively unbreakable anyway (inherited from the older python-numeric module). The other two are way lame. Thoughts? [1] - Readers are invited to count the wtf's in the code being replaced, as well as in its callers. Don't treat it as a drinking game though. - ajax Since pygtk2 does actually use numpy, isn't d) the best (albeit most annoying) option? Full disclosure: Numpy maintainer. -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
pygtk2 and its numpy dependency
pygtk2 implements a function called gtk.gdk.get_pixels_array(), which returns the pixel contents of a GDK pixbuf as a numpy array. Fine and dandy, but this means it links against numpy (7 megs) which is itself linked against atlas (12 megs). Kind of a lot for a single function, especially on a live image. Especially for a function that's basically unused! gnome-applet-music uses it to implement a poor-man's Porter-Duff blend, and that's the only caller currently packaged in Fedora, at least according to package deps. I have a patch (attached) that fixes that [1], which means we could compile our pygtk2 without numpy support and not break anything in Fedora proper. However, google codesearch does turn up what look like a few other users of that function, some of which we may actually want to ship someday. So we've got options: a) remove the explicit Requires: numpy from pygtk2, require apps that actually want this function to Require it themselves b) fake the numpy data type ABI in pygtk2 itself by cult-and-pasting it from numpy c) declare that get_pixels_array() just doesn't work in Fedora (historically true, back in like FC3) d) leave things as they are I lean towards a). I think b) is icky but doable, since that ABI is effectively unbreakable anyway (inherited from the older python-numeric module). The other two are way lame. Thoughts? [1] - Readers are invited to count the wtf's in the code being replaced, as well as in its callers. Don't treat it as a drinking game though. - ajax diff -up ./music-applet-2.5.1/src/musicapplet/applet.py.jx ./music-applet-2.5.1/src/musicapplet/applet.py --- ./music-applet-2.5.1/src/musicapplet/applet.py.jx 2009-08-10 15:03:29.0 -0400 +++ ./music-applet-2.5.1/src/musicapplet/applet.py 2009-08-10 15:03:36.0 -0400 @@ -831,22 +831,11 @@ class Rating (gtk.EventBox): def create_colorized_pixbuf (self, stock_pixbuf, color): -pixbuf = stock_pixbuf.copy () -red_scale = color.red / 65535.0 -green_scale = color.green / 65535.0 -blue_scale = color.blue / 65535.0 -for row in pixbuf.get_pixels_array (): -for pixel in row: -# Yay API changes! -if str (type (pixel[0])) == "": -pixel[0][0] *= red_scale -pixel[1][0] *= green_scale -pixel[2][0] *= blue_scale -else: -pixel[0] *= red_scale -pixel[1] *= green_scale -pixel[2] *= blue_scale -return pixbuf + pixbuf = stock_pixbuf.composite_color_simple(stock_pixbuf.get_width(), + stock_pixbuf.get_height(), + gtk.gdk.INTERP_NEAREST, + 255, 1, color, color) + return pixbuf 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: source file audit - 2009-08-10
On Mon, Aug 10, 2009 at 6:15 PM, Kevin Fenzi wrote: > Here's attached another run of my sources/patches url checker. > musuruan:BADSOURCE:hatari-1.2.0.tar.bz2:hatari Thanks! URL changed. I'll updated it soon. > musuruan:BADSOURCE:libicns-0.7.0.tar.gz:libicns This is valid. Temporary SF problem? Regards, Andrea. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Makefile target to download SourceX file
Doug Warner wrote:
> On 08/10/2009 02:14 PM, Todd Zullinger wrote:
>> Would a make target be much simpler than using spectool -g
>> foo.spec? It wouldn't take much to wrap that, if it would be
>> helpful.
>
> No, it wouldn't be. spectool is definitely what I was looking for,
> thanks!
Well, in case anyone thinks it would be helpful, here's a quick patch
for Makefile.common to add a few convenient targets (get-sources and
get-patches, as well as get-source-% and get-patch-%, which can be
used to grab selected source and patch files, respectively):
Index: Makefile.common
===
RCS file: /cvs/extras/common/Makefile.common,v
retrieving revision 1.132
diff -u -p -r1.132 Makefile.common
--- Makefile.common 10 Aug 2009 14:45:16 - 1.132
+++ Makefile.common 10 Aug 2009 19:01:49 -
@@ -326,6 +326,23 @@ upload new-source new-sources:
@echo "FILES variable not set!"
endif
+# Download Source and Patch files via the URL in the spec file
+SPECTOOL ?= $(shell which spectool 2>/dev/null)
+spectool-check:
+ @if [ ! -x "$(SPECTOOL)" ]; then echo "Must have spectool (from the
rpmdevtools package) installed"; exit 1; fi
+
+get-sources: spectool-check $(SPECFILE)
+ $(SPECTOOL) --get --sources $(SPECFILE)
+
+get-source-%: spectool-check $(SPECFILE)
+ $(SPECTOOL) --get --source $* $(SPECFILE)
+
+get-patches: spectool-check $(SPECFILE)
+ $(SPECTOOL) --get --patches $(SPECFILE)
+
+get-patch-%: spectool-check $(SPECFILE)
+ $(SPECTOOL) --get --patch $* $(SPECFILE)
+
# allow overriding buildarch so you can do, say, an i386 build on x86_64
ifndef BUILDARCH
BUILDARCH := $(shell rpm --eval "%{_arch}")
I found that spectool currently has a bug if you try to pass multiple
source or patch numbers. The spectool help says --source x,y is
accepted, but it is not. The option parsing code enforces the value
passed to --source and --patch be an integer. A trivial fix for this
may be:
--- spectool~ 2008-09-23 11:47:54.0 -0400
+++ spectool2009-08-10 15:04:20.0 -0400
@@ -271,8 +271,8 @@
'v|verbose' => sub { $verbose++; },
'n|dryrun|dry-run' => sub { $dryrun = 1; },
'V|version' => sub { $command = 'version'; },
- 's|source=i' => \...@sources,
- 'p|patch=i' => \...@patches,
+ 's|source=s' => \...@sources,
+ 'p|patch=s' => \...@patches,
'S|sources' => sub { push @what, 'sources'; },
'P|patches' => sub { push @what, 'patches'; },
'A|all' => sub { push @what, 'all'; },
--
ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
Nothing is so simple that it cannot be misunderstood.
-- Teague's Paradox
pgpek1VtBcaxE.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: UTF-8 specfiles, better upstream tarball commits coming
On Monday 10 August 2009, Bill Nottingham wrote: > Ville Skyttä (ville.sky...@iki.fi) said: > > I ran a few scripts on the CVS tree and will commit the resulting > > improvements in a few days to devel and rebuild changed packages if ACL's > > allow. Let me know if you for some reason don't want your packages > > touched (affected package lists below). > > If I may ask - is there a reason to do rebuilds? Given that there's > no functional differences, isn't having the changes in CVS for the > next rebuild 'good enough'? I have some past experience in people accidentally/carelessly overwriting changes that have been in CVS only. Actually doing the builds was intended as an additional safeguard against that, as well as one for immediately catching problems I may have caused (there shouldn't be any, but I managed to create (and fix) one so far). But I'll resort to just tagging changes in CVS and doing builds as local or scratch ones for the remaining packages, hopefully that's enough. > > Packages that may have a better upstream tarball available: > > --- > > (not necessarily all of these will be touched) > > ... > > > lzma > > ... > > I'd assume this would not be changed, for bootstrapping reasons. Yep, I considered that, but ended up including it in the list of possibly-to- be-touched packages for two reasons: there are already bootstrapping problems (coreutils, gzip, rpm etc etc and I'm not aware of documentation what are the expected issues/special cases that one should take care of when bootstrapping Fedora), and I think it's quite likely that rpm will start unpacking lzma tarballs with xz soon[0] so this wouldn't actually be a bootstrap problem much longer. But I'll take a 2nd look when I get this far. [0] http://rpm.org/ticket/85 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/10/2009 11:44 AM, Ralf Corsepius wrote: > They are very easy to demonstrate. Commonly known cases are building > gcc, binutils, gdb, firefox etc. Are these of the sort where a bug is reported, it's found that autotools made a bad decision, and then patching autotools fixed the problem? I'd like to read through such a bug report to learn more, if you can think of one easily. > Other cases are pretty easy to find. Actually, probably almost any > non-trivial, complex package has such issues. I don't _seem_ to have trouble rebuilding SRPM's (including some of the above cited) that I see are running autoconf. I'm curious to understand why or what I'm missing. -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Email, IM, VOIP: b...@bfccomputing.com Telephone: +1.603.448.4440 Twitter, etc.: bill_mcgonigle/bill.mcgonigle VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: UTF-8 specfiles, better upstream tarball commits coming
Bill Nottingham wrote: > If I may ask - is there a reason to do rebuilds? Smaller SRPMs for F12. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Consistent PolicyKit system policy
Colin Walters wrote: > An example of something that would be different between the RPM > package and desktop spin is the policy for software installation. In > the RPM package it should be either none allowed or "initiate updates > only", whereas the desktop spin would allow clickthrough for arbitrary > RPM installation. (This is mainly relevant in the future when we > don't have a separate root password in important places in the UI > flow). The current policy is already safe for a shared lab. You cannot install software as a user who hasn't authenticated as root (for the purpose of sofware installation – PolicyKit rights are per task!) at least once. If, as the admin, you're installing software from a user's account, you can uncheck the box to remember authentication. And you cannot do anything which can really break something, e.g. removing packages, without authenticating as root EACH TIME. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
> "SG" == Steve Grubb writes: SG> I was doing the package review and someone else took it from me. You had it assigned to yourself with the fedora-review flag set? Looking at https://bugzilla.redhat.com/show_activity.cgi?id=514602, it seems that it was assigned to you but the flag was not set. I certainly would have asked before taking the review in that case; I can't say why Jochen didn't but you're certainly welcome to ask him. Were I you, I also would have just taken the review back, especially after Jochen failed to reply to the updated package in comment 5. - J< -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: enigmail for F-11's thunderbird ?
On 08/10/2009 11:46 AM, Remi Collet wrote: > 1 in 3.x which solves a build break ppc64 build... Is this appropriate as a Thunderbird SOURCES/ patch? -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Email, IM, VOIP: b...@bfccomputing.com Telephone: +1.603.448.4440 Twitter, etc.: bill_mcgonigle/bill.mcgonigle VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Ralf Corsepius wrote: > I am applying this approach to several of my Fedora packages (some of > which I know to suffer from such issues, e.g. Coin2), fixed some > packages (owned by others) this way, which had failed during the > F11-mass-rebuild, exactly because of such issues. I'd be pretty pissed off if you "fixed" one of my packages that way, instead of addressing the real issue (that rerunning the current autotools fails). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FedoraStudio: the final step
On Mon, 2009-08-10 at 12:15 +0100, Bastien Nocera wrote: > > So please follow the link [2] and check if your multimedia package > > meets the criteria for any of the submenus we will have. If you have > > any questions, do not hesitate to contact me. I will do a final check > > around September 8th, about two weeks before the beta freeze and fix > > the remaining .desktop files. Also let me know if you don't want your > > package to be touched. > > I didn't change this for gnome-volume-control seeing as it shows up in > the (hardware) preferences rather than in the main menu. I'm intending to drop gst-mixer as the improved g-v-c in F12 should cover all areas gst-mixer was introduced to fill. So I won't bother to make this change there either. -- 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: Makefile target to download SourceX file
On 08/10/2009 02:38 PM, Orcan Ogetbil wrote: > I think he means to download from the look-aside cache, not from the > upstream location, which might not exist for snapshot packages. > > I believe this would be useful too. No, actually did mean the upstream source. The look-aside cache can currently be downloaded via either "make" or "make sources". I was thinking this would be a natural complement to that. -Doug signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Makefile target to download SourceX file
On 08/10/2009 02:14 PM, Todd Zullinger wrote: > Would a make target be much simpler than using spectool -g foo.spec? > It wouldn't take much to wrap that, if it would be helpful. No, it wouldn't be. spectool is definitely what I was looking for, thanks! -Doug signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Makefile target to download SourceX file
On Mon, Aug 10, 2009 at 2:14 PM, Todd Zullinger wrote: > Doug Warner wrote: >> Does anyone have a Makefile target for download a SourceX file >> (similar to Kevin Fenzi's recent report)? This would have the added >> benefit of simplifying the update process for new versions (ex: >> "make source NUM=0" instead of manually downloading the file). > > Would a make target be much simpler than using spectool -g foo.spec? > It wouldn't take much to wrap that, if it would be helpful. > I think he means to download from the look-aside cache, not from the upstream location, which might not exist for snapshot packages. I believe this would be useful too. Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Monday 10 August 2009 02:02:47 pm Jason L Tibbitts III wrote: > > "SG" == Steve Grubb writes: > > SG> It would have been in before feature freeze if sc-audit hadn't > SG> gotten stuck in package review. > > A couple of points here, since you seem to be blaming the review > process for the lateness of this package: > > Submitting a new package request and expecting it to be reviewed in > under a week is simply not reasonable. I was doing the package review and someone else took it from me. I knew the deadline and that we were splitting sc-audit into its own package during this release. The person that took the review from me seemed to be interested in it and Mirek created a new package real fast. There just wasn't follow up after the new package was created. I could have taken the package review back, I suppose. But I didn't want to seem rude. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Makefile target to download SourceX file
Doug Warner wrote: > Does anyone have a Makefile target for download a SourceX file > (similar to Kevin Fenzi's recent report)? This would have the added > benefit of simplifying the update process for new versions (ex: > "make source NUM=0" instead of manually downloading the file). Would a make target be much simpler than using spectool -g foo.spec? It wouldn't take much to wrap that, if it would be helpful. -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ The nice thing about egotists is that they don't talk about other people. -- Lucille S. Harper pgpAxZGH9nnsl.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Mon, 2009-08-10 at 13:02 -0500, Jason L Tibbitts III wrote: > > Submitting a new package request and expecting it to be reviewed in > under a week is simply not reasonable. Sorry, it just isn't. If > reviews are going to be blocked on package reviews, get those reviews in > early, not at the last minute. > > If something important, like a new feature or something disruptive like > this is going to be held up by a package review but needs to get done by > feature or alpha freeze time, please make an announcement to that > effect, or at least indicate that in the review itself. The review in > question (https://bugzilla.redhat.com/show_bug.cgi?id=514602) said > nothing about this issue. Otherwise the reviewers have no idea that > they should prioritize this review. Or line up a peer to do your review instead of just waiting for a volunteer to pick up the review. -- 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: Ongoing effort to package JOSM
2009/8/10 Jerry James > On Sun, Aug 9, 2009 at 2:05 AM, Andrea Musuruane > wrote: > > If I do that I get: > > > > [...] > > test: > >[junit] WARNING: multiple versions of ant detected in path for junit > >[junit] > > > jar:file:/usr/share/java/ant-1.7.1.jar!/org/apache/tools/ant/Project.class > >[junit] and > > jar:file:/usr/share/java/ant.jar!/org/apache/tools/ant/Project.class > >[junit] Running com.drew.metadata.test.AllTests > >[junit] Tests run: 79, Failures: 1, Errors: 0, Time elapsed: 0,269 sec > > > > BUILD FAILED > > /home/andrea/devel/prg/metadata-extractor/build.xml:48: Test > > com.drew.metadata.test.AllTests failed > > > > Total time: 1 second > > > > Regards, > > > > Andrea. > > /usr/share/java/ant.jar is a symlink to /usr/share/java/ant-1.7.1.jar, > so it is finding the same jar file twice. I don't know what to tell > you to do now. You'll have to figure out how to make it not look at > one or the other of the two names. That's just a warning, the error is due to bad coding in the test themselves; a workaround can be to let ant pass a "correct" locale to the jvm task, see the bug page for more details > > -- > Jerry James > http://www.jamezone.org/ > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Guido Grazioli Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
> "SG" == Steve Grubb writes: SG> It would have been in before feature freeze if sc-audit hadn't SG> gotten stuck in package review. A couple of points here, since you seem to be blaming the review process for the lateness of this package: Submitting a new package request and expecting it to be reviewed in under a week is simply not reasonable. Sorry, it just isn't. If reviews are going to be blocked on package reviews, get those reviews in early, not at the last minute. If something important, like a new feature or something disruptive like this is going to be held up by a package review but needs to get done by feature or alpha freeze time, please make an announcement to that effect, or at least indicate that in the review itself. The review in question (https://bugzilla.redhat.com/show_bug.cgi?id=514602) said nothing about this issue. Otherwise the reviewers have no idea that they should prioritize this review. People go on vacation occasionally, or run out of free time. As far as I know, nobody is paid to review packages and we all have other work to do. If an important review gets blocked behind someone who is not responding, let someone know about it. I stole and finished the xz review because it turns out the person doing the review went on vacation and the entire mass rebuild was blocked on us getting xz in. Bottom line: We can get things done when we know about them needing to get done. - J< -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Mon, 2009-08-10 at 11:15 -0600, Kevin Fenzi wrote: > --16:54:18-- http://hkit.googlecode.com/files/hkit-v0.5.tgz > Resolving hkit.googlecode.com... 209.85.225.82 > Connecting to hkit.googlecode.com|209.85.225.82|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 16:54:19 ERROR 404: Not Found. > > So, possibly a issue on googlecode having a outage? Argh ! This is not what I'm used to call a "transient failure"... but in this case, it is one :-( Everything is then possible with Google ! Anyway, retrying the failed BADURL cases after a while would probably reduce a bit your statistics... And yes, publishing the detailed failures as above is a great help. Thanks. Patrick -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Makefile target to download SourceX file
Does anyone have a Makefile target for download a SourceX file (similar to Kevin Fenzi's recent report)? This would have the added benefit of simplifying the update process for new versions (ex: "make source NUM=0" instead of manually downloading the file). -Doug signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Monday 10 August 2009 01:04:32 pm Jesse Keating wrote: > > OK, fine. I'll wait until after the Alpha freeze is over. > > > Even after that one has to wonder, why is a change like this going in > after the feature freeze. It would have been in before feature freeze if sc-audit hadn't gotten stuck in package review. > How big of an ABI change is this, will there have to be any porting effort, > what's the risk, what's the gain? Should be little risk. This removes the old API needed for communicating with kernels before the 2.6.16 kernel was released. Somewhere around 2.6.22 libaudit made the old API hard to use. It was still there for anything linking to it. I have not looked in detail at all the packages on the dependency list but the changes only affect the audit rule setting interface and not the logging interface. Auditctl is likely to be the only program affected by the change, but to be safe and make sure nothing falls through the cracks, the number is bumped. Almost all apps are using the logging interface and are not affected. If anything actually is sending audit rules, the porting is trivial. You just use the _data equivalent function and use the audit_rule_data structure to hold your rules. The gain is that we want to clean up/deprecate the old kernel API somewhere around 2.6.36 and need user space to quit using it asap. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Mon, 10 Aug 2009 19:07:46 +0200
Patrick MONNERAT wrote:
> On Mon, 2009-08-10 at 10:15 -0600, Kevin Fenzi wrote:
>
> Many thanks Kevin for your report.
No problem.
> > monnerat:BADURL:hkit-v0.5.tgz:php-hkit
>
> I confirm the URL is OK:
>
> Version:0.5
> Source0:http://hkit.googlecode.com/files/hkit-v%{version}.tgz
>
> --> Effective URL: http://hkit.googlecode.com/files/hkit-v0.5.tgz
>
> Still valid and downloadable.
>
> I thus suppose the server was not accessible at script run time.
Yeah, it seems so somehow.
> Why not updating the script to log the exact failure reason and/or
> retry transient connection failures after some delay? This would help
> everyone finding the real problem, and limit the amount of false
> negatives and overall line count growth you "complain" about :-)
Yes, it does log each download, I just haven't put those files up. ;)
I suppose I could so people could check them...
In this case:
--16:54:18-- http://hkit.googlecode.com/files/hkit-v0.5.tgz
Resolving hkit.googlecode.com... 209.85.225.82
Connecting to hkit.googlecode.com|209.85.225.82|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
16:54:19 ERROR 404: Not Found.
So, possibly a issue on googlecode having a outage?
> Regards,
> Patrick
kevin
signature.asc
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-08-10
On Mon, 2009-08-10 at 10:15 -0600, Kevin Fenzi wrote:
Many thanks Kevin for your report.
> monnerat:BADURL:hkit-v0.5.tgz:php-hkit
I confirm the URL is OK:
Version:0.5
Source0:http://hkit.googlecode.com/files/hkit-v%{version}.tgz
--> Effective URL: http://hkit.googlecode.com/files/hkit-v0.5.tgz
Still valid and downloadable.
I thus suppose the server was not accessible at script run time.
Why not updating the script to log the exact failure reason and/or retry
transient connection failures after some delay? This would help everyone
finding the real problem, and limit the amount of false negatives and
overall line count growth you "complain" about :-)
Regards,
Patrick
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Ongoing effort to package JOSM
On Sun, Aug 9, 2009 at 2:05 AM, Andrea Musuruane wrote: > If I do that I get: > > [...] > test: > [junit] WARNING: multiple versions of ant detected in path for junit > [junit] > jar:file:/usr/share/java/ant-1.7.1.jar!/org/apache/tools/ant/Project.class > [junit] and > jar:file:/usr/share/java/ant.jar!/org/apache/tools/ant/Project.class > [junit] Running com.drew.metadata.test.AllTests > [junit] Tests run: 79, Failures: 1, Errors: 0, Time elapsed: 0,269 sec > > BUILD FAILED > /home/andrea/devel/prg/metadata-extractor/build.xml:48: Test > com.drew.metadata.test.AllTests failed > > Total time: 1 second > > Regards, > > Andrea. /usr/share/java/ant.jar is a symlink to /usr/share/java/ant-1.7.1.jar, so it is finding the same jar file twice. I don't know what to tell you to do now. You'll have to figure out how to make it not look at one or the other of the two names. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Mon, 2009-08-10 at 12:55 -0400, Steve Grubb wrote: > On Monday 10 August 2009 12:41:48 pm Jesse Keating wrote: > > > I wanted to let everyone know that I will be pushing audit-2.0 into > > > rawhide in the next day or two. It will change the version number of > > > libaudit. The following packages are known to have dependencies on > > > audit-libs: > > > > I would strongly prefer that this wait until after the Alpha freeze is > > over. Otherwise we'll have a huge pile of things to track and tag > > should we need an updated build of anything on that list for an Alpha > > blocker. Anaconda being on that list makes this a very real > > possibility. > > OK, fine. I'll wait until after the Alpha freeze is over. > > -Steve > Even after that one has to wonder, why is a change like this going in after the feature freeze. How big of an ABI change is this, will there have to be any porting effort, what's the risk, what's the gain? -- 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: soname number bump for audit-libs
On Monday 10 August 2009 12:41:48 pm Jesse Keating wrote: > > I wanted to let everyone know that I will be pushing audit-2.0 into > > rawhide in the next day or two. It will change the version number of > > libaudit. The following packages are known to have dependencies on > > audit-libs: > > I would strongly prefer that this wait until after the Alpha freeze is > over. Otherwise we'll have a huge pile of things to track and tag > should we need an updated build of anything on that list for an Alpha > blocker. Anaconda being on that list makes this a very real > possibility. OK, fine. I'll wait until after the Alpha freeze is over. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
On 08/07/2009 05:47 PM, Dave Airlie wrote: > On Fri, 2009-08-07 at 16:42 -0400, Casey Dahlin wrote: >> On 08/06/2009 01:26 AM, Dave Airlie wrote: >>> On Mon, 2009-08-03 at 15:08 +0530, Rahul Sundaram wrote: Hi A few days back I ran into http://lists.x.org/archives/xorg-devel/2009-July/001293.html I am wondering, since we are already using KMS in most places in Fedora, how far are we from achieving this by default in a Fedora release? >>> non-root X is a big security hole at the moment, and until we get >>> revoke() support in the kernel, we can probably move X to running as a >>> special user, and maybe once we get revoke to running as the real user. >>> >>> However it doesn't solve the issue how we know we need or don't need >>> root since X only figures out what graphics drivers are needed after >>> starting, so if you needed a non-kms gpu driver we wouldn't know >>> until after we'd started as non-root. >>> >>> Dave. >>> >> Why can't we just start as root or with the setuid bit, and use the standard >> set*uid() calls to drop what we don't need once we know what we're doing? >> > > We have to undo some stuff when X exits. > > Dave. > > I meant start as setuid, then determine if root was necessary at all. If it is, keep running as root for the duration. If not, drop privileges. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Mon, 2009-08-10 at 12:32 -0400, Steve Grubb wrote: > Hello, > > I wanted to let everyone know that I will be pushing audit-2.0 into rawhide > in > the next day or two. It will change the version number of libaudit. The > following packages are known to have dependencies on audit-libs: I would strongly prefer that this wait until after the Alpha freeze is over. Otherwise we'll have a huge pile of things to track and tag should we need an updated build of anything on that list for an Alpha blocker. Anaconda being on that list makes this a very real possibility. -- 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: NetworkManager-novellvpn
On Sat, 2009-08-08 at 11:07 +0200, Matěj Cepl wrote: > Dan Williams writes: > > > On Fri, 2009-08-07 at 11:11 -0300, Murilo Opsfelder Araujo wrote: > > Not that I know of. Despite repeated proddings of the Novell guys, they > > have never bothered to upstream the code. Second, is 'nvpn' even > > open-source? If it's not, it's pretty pointless to including a package > > in Fedora that is useless without a closed-source binary. > > 'nvpn' is a client or server? If server, they I wouldn't know about VPN > which we support in Fedora even though we have no server part. It's a binary that the NetworkManager-novellvpn package executes to start the vpn connection. NM-novellvpn does not seem to include nvpn, so it must be some external program. See src/nm-novellvpn-service.c :: nm_novellvpn_start_novellvpn_binary(). I assume there's a novellvpn package in OpenSUSE somewhere. Obviously adding that package (if it's open-source) to Fedora would be a prerequisite to adding NetworkManager-novellvpn. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
soname number bump for audit-libs
Hello, I wanted to let everyone know that I will be pushing audit-2.0 into rawhide in the next day or two. It will change the version number of libaudit. The following packages are known to have dependencies on audit-libs: repoquery --repoid=rawhide --whatrequires --alldeps 'libaudit.so.0()(64bit)' | grep x86_64 cups-1:1.4-0.rc1.12.fc12.x86_64 xorg-x11-server-Xorg-0:1.6.99-28.20090804.fc12.x86_64 shadow-utils-2:4.1.4.1-6.fc12.x86_64 dbus-1:1.2.16-4.fc12.x86_64 cups-libs-1:1.4-0.rc1.12.fc12.x86_64 cups-lpd-1:1.4-0.rc1.12.fc12.x86_64 xorg-x11-server-Xvfb-0:1.6.99-28.20090804.fc12.x86_64 frysk-gnome-0:0.4-11.fc12.x86_64 readahead-1:1.4.9-3.fc12.x86_64 cronie-0:1.4-3.fc12.x86_64 util-linux-ng-0:2.16-3.fc12.x86_64 nscd-0:2.10.90-12.x86_64 xorg-x11-server-Xnest-0:1.6.99-28.20090804.fc12.x86_64 policycoreutils-newrole-0:2.0.68-1.fc12.x86_64 passwd-0:0.76-3.fc12.x86_64 gdm-1:2.27.4-4.fc12.x86_64 openssh-server-0:5.2p1-17.fc12.x86_64 anaconda-0:12.7-1.fc12.x86_64 sudo-0:1.7.1-5.fc12.x86_64 frysk-devel-0:0.4-11.fc12.x86_64 frysk-0:0.4-11.fc12.x86_64 xorg-x11-server-Xephyr-0:1.6.99-28.20090804.fc12.x86_64 upstart-0:0.3.11-2.fc12.x86_64 cups-php-1:1.4-0.rc1.12.fc12.x86_64 policycoreutils-0:2.0.68-1.fc12.x86_64 libxf86config-0:1.6.99-28.20090804.fc12.x86_64 ipsec-tools-0:0.7.2-3.fc12.x86_64 amtu-0:1.0.8-1.fc12.x86_64 pam-0:1.1.0-3.fc12.x86_64 aide-0:0.13.1-10.fc12.x86_64 rsh-server-0:0.17-55.fc12.x86_64 I can rebuild all these against the new audit package. If you would rather me not touch your package, just let me know. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: UTF-8 specfiles, better upstream tarball commits coming
Ville Skyttä (ville.sky...@iki.fi) said: > I ran a few scripts on the CVS tree and will commit the resulting > improvements > in a few days to devel and rebuild changed packages if ACL's allow. Let me > know if you for some reason don't want your packages touched (affected > package > lists below). If I may ask - is there a reason to do rebuilds? Given that there's no functional differences, isn't having the changes in CVS for the next rebuild 'good enough'? > Packages that may have a better upstream tarball available: > --- > (not necessarily all of these will be touched) > ... > lzma ... I'd assume this would not be changed, for bootstrapping reasons. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
source file audit - 2009-08-10
Here's attached another run of my sources/patches url checker. - There are 1060 lines in this run. Up from 884 last run. 700 sourcecheck-20070826.txt 620 sourcecheck-20070917.txt 561 sourcecheck-20071017.txt 775 sourcecheck-20080206.txt 685 sourcecheck-20080214.txt 674 sourcecheck-20080301.txt 666 sourcecheck-20080401.txt 660 sourcecheck-20080501.txt 642 sourcecheck-20080603.txt 649 sourcecheck-20080705.txt 662 sourcecheck-20080801.txt 912 sourcecheck-20081114.txt 884 sourcecheck-20090215.txt 1060 sourcecheck-20090810.txt You can find the results file at: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20090810.txt And also attached to this mail. Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). - BADSOURCE:$SOURCENAME:$PACKAGENAME This means that the source was downloaded ok from the upstream site, but doesn't match the md5sum given in the sources file. This could be due to needing to strip out content that fedora cannot ship (but in that case you shouldn't have the full URI in the Source line). Or upstream following poor release practices and updating without changing their release. - BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME This means that the file was downloaded from the URI given, and the md5sum did not match the file thats present in CVS (not the lookaside). This might be due to timestamps, or any of the above reasons. kevin -- abbot:BADURL:mitter-0.4.3.tar.gz:mitter abbot:BADURL:protobuf-2.0.2.tar.bz2:protobuf abompard:BADSOURCE:cryptopp560.zip:cryptopp abompard:BADSOURCE:pure-ftpd-1.0.22.tar.bz2:pure-ftpd abompard:BADURL:awstats-6.9.tar.gz:awstats abompard:BADURL:Comet_Catcher_Redux.sd7:spring-maps-default abompard:BADURL:glest_data_3.2.1.zip:glest-data abompard:BADURL:psi-0.13.tar.bz2:psi abompard:BADURL:Sands_of_War_v2.sd7:spring-maps-default abompard:BADURL:SmallDivide.sd7:spring-maps-default adalloz:BADURL:pan-0.133.tar.bz2:pan adrian:BADURL:gmpc-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-alarm-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-avahi-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-coveramazon-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-extraplaylist-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-jamendo-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-last-fm-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-libnotify-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-lirc-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-lyrics-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-lyricwiki-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-magnatune-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-mdcover-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-mserver-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-osd-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-shout-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-tagedit-0.18.0.tar.gz:gmpc adrian:BADURL:gmpc-wikipedia-0.18.0.tar.gz:gmpc adrian:BADURL:libmpd-0.18.0.tar.gz:libmpd agoode:BAD_CVS_SOURCE:fvwm-xdg-menu.py:fvwm ajax:BADURL:vbetool-1.2.1.tar.bz2:vbetool akahl:BADURL:bmpx-0.40.14.tar.bz2:bmpx akahl:BADURL:ZendFramework-1.8.4PL1.tar.gz:php-ZendFramework akurtakov:BADSOURCE:jdepend-2.6-RHCLEAN.zip:jdepend akurtakov:BADURL:birt-source-2.5M7.zip:eclipse-birt allisson:BADURL:amora-server-1.1.tar.gz:amora allisson:BADURL:Variable-Magic-0.34.tar.gz:perl-Variable-Magic amdunn:BADURL:coq-8.2pl1.tar.gz:coq anaconda-maint:BADURL:isomd5sum-1.0.5.tar.bz2:isomd5sum andriy:BAD_CVS_SOURCE:fmio-gq-wrapper.py:fmio anithra:BADSOURCE:com.ibm.systemtapgui.src.tar.gz:eclipse-systemtapgui asheesh:BADURL:liblicense-0.8.1.tar.gz:liblicense ashokdas:BADURL:elfinfo-1.1.tar.gz:elfinfo ashokdas:BADURL:greadelf-1.0.tar.gz:greadelf athimm:BAD_CVS_SOURCE:RiceBSD.doc:arpack athimm:BADURL:apt-0.5.15lorg3.95.git416.tar.bz2:apt athimm:BADURL:chrpath-0.13.tar.gz:chrpath athimm:BADURL:fakeroot_1.12.2.tar.gz:fakeroot athimm:BADURL:greylistd_0.8.7.tar.gz:greylistd athimm:BADURL:vtkdata-5.4.2.tar.gz:vtkdata atkac:BADURL:adns-python-1.2.1.tar.gz:python-adns atkac:BADURL:mtools-4.0.10.tar.bz2:mtools atkac:BADURL:rexec-1.5.tar.gz:rsh atkac:BADURL:swig-1.3.39.tar.gz:swig atkac:BADURL:xdelta-1.1.4.tar.gz:xdelta ausil:BADSOURCE:elftoaout-2.3.tgz:elftoaout ausil:BADSOURCE:silo-1.4.13.tar.bz2:silo ausil:BADURL:mysql-gui-tools-5.0r12.tar.gz:mysql-gui-tools ausil:BADURL:pam_yubico-2.1.tar.gz:pam_yubico ausil:BADURL:snort-2.8.3.2.tar.gz:snort ausil:BADURL:ykclient-2.3.tar.gz:ykclient awjb:BAD_CVS_SOURCE:winepulse-0.29-configure.ac.patch:wine awjb:BAD_CVS_SOURCE:wmweather+-2.9.tar.gz:wmweather+ awjb:BADSOURCE:libpolyxmass-0.9.1.tar.gz:libpolyxmass awjb:BADURL:dosbox-0.73.tar.gz:dosbox awjb:BADURL:freealut-1.1.0.tar.gz:freealut awjb:BADURL:httplib2-0.4.0.tar.gz:python-ht
Re: Firefox SELinux bug from Alpha Blockers meeting.
Mathieu Bridon (bochecha) (boche...@fedoraproject.org) said: > I just wanted to know if I should open a new bug report for Epiphany > as SEAlert got confused or if it is indeed the same bug, in which case > I'll be patient. See bug 516057. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: enigmail for F-11's thunderbird ?
Le 10/08/2009 17:27, Bill McGonigle a écrit : > On 08/10/2009 08:50 AM, Bernie Innocenti wrote: >> Why is thunderbird-enigmail in rpfusion-free rather than fedora proper? > > As currently constructed, enigmail's SRPM requires the entire > Thunderbird source. > > I speculated here last week that perhaps we need a thunderbird-devel > package, but I don't know enough to qualify that. Yes, that's the solution used on debian. But we also need to patch some files in the sources tree 1 in 2.x which solves a build break non-i386 build 1 in 3.x which solves a build break ppc64 build... The really simplest solution will be to build enigmail "with" thunderbird (as a subpackage). But this seems not aceptable. + P.S. but rpmfusion-free is really a "mandatory" repo ;) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/10/2009 05:17 PM, Bill McGonigle wrote: On 08/07/2009 02:54 AM, Rahul Sundaram wrote: Pointing it out on a review and restoring to calling the packages bad quality if people don't follow your controversial recommendation isn't going to scale at all. This is a good perspective, Ralf. Putting the same energy into individual reviews won't have as amplified an impact as convincing the packaging committee of problems. I am member of the FPC, but ... I have failed to convince the FPC so far. I understand the theoretical value of a deterministic package build - I'm not aware of specific examples of where non-determinism has caused problems in Fedora, though I can imagine some. They are very easy to demonstrate. Commonly known cases are building gcc, binutils, gdb, firefox etc. Other cases are pretty easy to find. Actually, probably almost any non-trivial, complex package has such issues. It's only the fact that most packages are trivial autotool-wise and the fact that autotools-changes often are subtile, which lets people who are not intimate with the autotools (erroroniously) believe it's safe to run autotools during builts. Gathering evidence of breakage may cause a change of opinion. Having a practical alternative is probably required as well. The practical alternative is very simple: Run the autotools on the system you are testing on, create diffs from them and to apply them during builds. I am applying this approach to several of my Fedora packages (some of which I know to suffer from such issues, e.g. Coin2), fixed some packages (owned by others) this way, which had failed during the F11-mass-rebuild, exactly because of such issues. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review: Fedora 12 Alpha Release Notes
On 08/10/2009 09:00 PM, Michael Cronenworth wrote: > Rahul Sundaram on 08/10/2009 10:08 AM wrote: >> Please edit the wiki directly for any improvements if you can or reply >> with suggestions. Thanks. > > Why are some internal Fedora wiki links set as external links? No particular reason. Fixed. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review: Fedora 12 Alpha Release Notes
Rahul Sundaram on 08/10/2009 10:08 AM wrote: > Please edit the wiki directly for any improvements if you can or reply > with suggestions. Thanks. Why are some internal Fedora wiki links set as external links? For example: [https://fedoraproject.org/wiki/Dracut Dracut] instead of [[Dracut]] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: enigmail for F-11's thunderbird ?
On 08/10/2009 08:50 AM, Bernie Innocenti wrote: > Why is thunderbird-enigmail in rpfusion-free rather than fedora proper? As currently constructed, enigmail's SRPM requires the entire Thunderbird source. I speculated here last week that perhaps we need a thunderbird-devel package, but I don't know enough to qualify that. -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Email, IM, VOIP: b...@bfccomputing.com Telephone: +1.603.448.4440 Twitter, etc.: bill_mcgonigle/bill.mcgonigle VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/07/2009 02:54 AM, Rahul Sundaram wrote: > Pointing it out on a review and restoring to calling the > packages bad quality if people don't follow your controversial > recommendation isn't going to scale at all. This is a good perspective, Ralf. Putting the same energy into individual reviews won't have as amplified an impact as convincing the packaging committee of problems. I understand the theoretical value of a deterministic package build - I'm not aware of specific examples of where non-determinism has caused problems in Fedora, though I can imagine some. Gathering evidence of breakage may cause a change of opinion. Having a practical alternative is probably required as well. -Bill P.S. I support your position to not review packages you find morally offensive. Fedora itself is a moral stance (on Free software), and as such should not ask its members to behave in a personally unethical manner. -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Email, IM, VOIP: b...@bfccomputing.com Telephone: +1.603.448.4440 Twitter, etc.: bill_mcgonigle/bill.mcgonigle VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Review: Fedora 12 Alpha Release Notes
Hi, Wit the Fedora 12 Alpha release coming up shortly, now would be a good time to review the release notes. Make sure the major features are covered, import bugs and workarounds noted etc http://fedoraproject.org/wiki/Fedora_12_Alpha_release_notes Please edit the wiki directly for any improvements if you can or reply with suggestions. Thanks. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Isue on building blender agains system ftgl library
On Sun, Aug 9, 2009 at 7:14 PM, Jochen Schmitt wrote: > Unfortunately, I have got the following error message: > > /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc > build/linux2/lib/libbf_ftfont.a(FTF_TTFont.o): In function > `FTF_TTFont::GetBoundingBox(char*, float*, float*, float*, float*, > float*, float*, unsigned int)': > /home/s4504kr/cvs/fedora/blender/devel/blender-2.49a/source/blender/ftfont/intern/FTF_TTFont.cpp:381: > undefined reference to `FTFont::BBox(wchar_t const*, float&, float&, > float&, float&, float&, float&)' The build log shows that the object files were all compiled in 64-bit mode. This message (and the others following it in the build log) are complaints about trying to link 32-bit libraries against the 64-bit object files. This is because the link line for build/linux2/bin/blender includes "-L/usr/lib". (It also includes "-L/usr/lib64", twice, which is unnecessary.) -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
On 08/07/2009 05:47 PM, Dave Airlie wrote: > We have to undo some stuff when X exits. I was thinking OpenSSH handles this with privilege separation, maybe X could too? Sure enough, there's a paper on it (from '04 no less): ftp://ftp.laas.fr/pub/ii/matthieu/xf86-sec.pdf -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Email, IM, VOIP: b...@bfccomputing.com Telephone: +1.603.448.4440 Twitter, etc.: bill_mcgonigle/bill.mcgonigle VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Consistent PolicyKit system policy
On Mon, Aug 10, 2009 at 9:08 AM, Tim Waugh wrote: > What is the goal of the default Fedora PolicyKit policy system-wide, and > how can we check that PolicyKit mechanisms' default policies are > adhering to it? Generally where I'd like to move to is where the RPM package defaults are appropriate for a shared computer lab PC, and the desktop spin kickstart modifies things as appropriate for the unmanaged home PC/laptop. You could think of "computer lab PC" as very similar to the our heritage, the "timesharing unix server" case, except that it makes sense for say plugging in a USB key to do something useful. An example of something that would be different between the RPM package and desktop spin is the policy for software installation. In the RPM package it should be either none allowed or "initiate updates only", whereas the desktop spin would allow clickthrough for arbitrary RPM installation. (This is mainly relevant in the future when we don't have a separate root password in important places in the UI flow). We don't do this at all now though =) For your particular case I think your current policy is the best we can do for all targets. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: enigmail for F-11's thunderbird ?
> Actually, why does rpmfusion-free even exist? A cheeky question, > admittedly, but I'm honestly curious. AFAIK, it's because there are some free software that are not acceptable in Fedora. A free implementation of a patented codec comes to mind. -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Consistent PolicyKit system policy
When defining a new policy mechanism for PolicyKit, what are the "rules" for setting the default policy? PolicyKit's flexibility is excellent, but it means that we have to choose sensible and consistent defaults for each application that uses it. I ask because the default policy for cups-pk-helper is to require the root password, and not to remember it even for that session. What is the goal of the default Fedora PolicyKit policy system-wide, and how can we check that PolicyKit mechanisms' default policies are adhering to it? For example, what should the default Fedora policy be for locally connected peripherals? Tim. */ 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: enigmail for F-11's thunderbird ?
El Sat, 08-08-2009 a las 12:03 -0400, Mail Lists escribió: > On 08/08/2009 07:38 AM, Frank Murphy (Frankly3D) wrote: > > On 08/08/09 12:39, Gregory Hosler wrote: > >> Hi all, > >> > > > > Works fine for me. > > Did you get TB from Mozilla? > > > > I believe enigmail is setup fro the Fedora packaged version of TB, > > which is on TB 3 Beta2 > > > > I am using stock F11 tb and enigmail from rpmfusion on x64 - and it > does NOT work. It says 'not compatible'. Why is thunderbird-enigmail in rpfusion-free rather than fedora proper? Actually, why does rpmfusion-free even exist? A cheeky question, admittedly, but I'm honestly curious. > Since the mozilla builds do not provide x64 (which is a shame 64 bit > are basically the baseline now with core 2) and the plugins are not 64 > bit I am not using them - but if you use the 32 bit mozilla tb and > enigmail nightly from mozilla - they do work. And here's another thing I've been wondering for years: why doesn't Mozilla provide Linux x86_64 builds? It should probably be asked on one of their lists, though. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090810 changes
Compose started at Mon Aug 10 06:15:06 UTC 2009 Updated Packages: xorg-x11-drv-nouveau-0.0.15-2.20090805git712064e.fc12 - * Wed Aug 05 2009 Ben Skeggs 0.0.15-2.20090803git712064e - dri2 fixes, no wfb without kms, non-kms fb resize fixes, other misc fixes Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 Broken deps for i386 -- 389-ds-1.1.3-4.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs asterisk-fax-1.6.1-0.24.rc1.fc12.i686 requires libspandsp.so.1 bigboard-0.6.4-12.fc12.i686 requires mugshot >= 0:1.1.90-1 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) cluttermm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 cluttermm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-0.9) dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdap.so.9 dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdapserver.so.6 entertainer-0.4.2-5.fc12.noarch requires pyclutter-cairo octave-forge-20080831-10.fc12.i686 requires octave(api) = 0:api-v32 perl-DBIx-Class-Schema-Loader-0.04006-4.fc12.noarch requires perl(DBIX::Class) php-layers-menu-3.2.0-0.2.rc.fc12.noarch requires php-pear(HTML_Template_PHPLIB) plplot-octave-5.9.4-1.fc12.i586 requires octave(api) = 0:api-v32 ppl-yap-0.10.2-5.fc12.i686 requires libYap.so python-repoze-what-quickstart-1.0-2.fc12.noarch requires python-repoze-who-plugins-sql qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-3.fc12.noarch requires rubygem(fattr) >= 0:1.0.3 sems-1.1.1-2.fc12.i586 requires libspandsp.so.1 sems-g722-1.1.1-2.fc12.i586 requires libspandsp.so.1 sems-gsm-1.1.1-2.fc12.i586 requires libspandsp.so.1 sems-speex-1.1.1-2.fc12.i586 requires libspandsp.so.1 serpentine-0.9-5.fc12.noarch requires gnome-python2-nautilus-cd-burner showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6(CXXABI_1.3)(64bit) sugar-pippy-34-2.fc12.i686 requires libc.so.6()(64bit) sugar-pippy-34-2.fc12.i686 requires libgcc_s.so.1(GCC_3.0)(64bit) sugar-pippy-34-2.fc12.i686 requires libm.so.6()(64bit) sugar-pippy-34-2.fc12.i686 requires libm.so.6(GLIBC_2.2.5)(64bit) sugar-pippy-34-2.fc12.i686 requires libc.so.6(GLIBC_2.2.5)(64bit) sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6()(64bit) sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6(GLIBCXX_3.4)(64bit) sugar-pippy-34-2.fc12.i686 requires libgcc_s.so.1()(64bit) thunderbird-lightning-1.0-0.8.20090513hg.fc12.i686 requires thunderbird < 0:3.0-3.6.b4 trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 Broken deps for x86_64 -- 389-ds-1.1.3-4.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs asterisk-fax-1.6.1-0.24.rc1.fc12.x86_64 requires libspandsp.so.1()(64bit) bigboard-0.6.4-12.fc12.x86_64 requires mugshot >= 0:1.1.90-1 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so
Re: FedoraStudio: the final step
On Sun, 2009-08-09 at 19:26 -0400, Orcan Ogetbil wrote: > Hello everyone, > > (If you don't own a multimedia package you can skip this thread) > > This is a call for help for adjusting the .desktop files of your > multimedia applications according to the new FedoraStudio feature [1]. > For those who missed the news, with F-12 we will have an optional > multimedia-menus package that will subcategorize the Sound&Video menu > in Gnome (Multimedia menu in KDE). This package is currently geared > towards multimedia creation folks, however this target audience may be > expanded in the future to meet the demand. > > To place the applications in the proper category, the .desktop files > need to have proper categories listed. Since I am a (co)maintainer of > most audio creation packages in Fedora, I have finished most of the > required work. However there are a few packages left that need to be > addressed. > > So please follow the link [2] and check if your multimedia package > meets the criteria for any of the submenus we will have. If you have > any questions, do not hesitate to contact me. I will do a final check > around September 8th, about two weeks before the beta freeze and fix > the remaining .desktop files. Also let me know if you don't want your > package to be touched. I didn't change this for gnome-volume-control seeing as it shows up in the (hardware) preferences rather than in the main menu. Cheers > PS: Adjusting your .desktop file with this specification will not > change the experience of anyone who doesn't have the multimedia-menus > package installed. Your application will be still in the > Sound&Video/Multimedia desktop menu as long as you have "AudioVideo" > listed as a category in your .desktop file. > > [1] http://fedoraproject.org/wiki/Features/FedoraStudio > [2] http://fedoraproject.org/wiki/Features/FedoraStudio#Outline > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/gnash/devel gnash.spec,1.57,1.58
On Sun, 9 Aug 2009 18:54:40 + (UTC), Kevin wrote:
> Author: kkofler
>
> Update of /cvs/pkgs/rpms/gnash/devel
> %files devel
> -%{_prefix}/include/gnash/*.h
> +%{_includedir}/gnash/*.h
> %{_libdir}/pkgconfig/gnash.pc
>
> %files widget
> -%{_prefix}/include/gnash/*.h
> +%{_includedir}/gnash/*.h
> %{python_sitearch}/*
As I see that I wonder which package owns the gnash directory?
https://fedoraproject.org/wiki/Packaging:UnownedDirectories
Also, %defattr is missing for the two packages quoted here.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: kernel 2.6.29.6-217.2.3.fc11 compiled from source will not boot
On Sunday 09 August 2009 11:16:12 pm Markus Kesaromous wrote: > There is something seriously wrong with this kernel release. Again -- the list you want is fedora-kernel-list, NOT fedora-devel-list. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
