Review swaps

2012-07-15 Thread Brendan Jones
Once again I've a number of small audio packages up for review that I'm willing to swap. They are: rtirq - realtime IRQ threading https://bugzilla.redhat.com/show_bug.cgi?id=839527 Add64 - an additive synthesizer for JACK https://bugzilla.redhat.com/show_bug.cgi?id=830664 samplv1 -A polypho

Re: [Fontconfig] Heads up: Droid fonts update in Rawhide

2012-07-15 Thread Nicolas Mailhot
> >> On 07/15/2012 06:01 PM, Nicolas Mailhot wrote: > C. I tried to dispatch the Arabic variants in the Latin family they > were > >> designed to complement, but I may have misunderstood the design > info > >> available online. > > Please clarify 'dispatch' :-) >>> Ku

[Test-Announce] CANCELLED: 2012-07-16 Fedora QA Meeting

2012-07-15 Thread Adam Williamson
Looks like another week where we can skip the meeting - there's no significant ongoing business besides the anaconda new UI testing, and we've already discussed that. No-one proposed any topics. If anyone's feeling terribly sad about missing meetings, do let me know... -- Adam Williamson Fedora QA

Re: [Fontconfig] Heads up: Droid fonts update in Rawhide

2012-07-15 Thread Nicolas Mailhot
> On 07/15/2012 06:01 PM, Nicolas Mailhot wrote: C. I tried to dispatch the Arabic variants in the Latin family they were >> designed to complement, but I may have misunderstood the design info >> available online. >>> > >>> > Please clarify 'dispatch' :-) >> Kufi with San

Re: prelink should not mess with running executables

2012-07-15 Thread Miloslav Trmač
On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik wrote: > Chris Adams writes: > >> Once upon a time, Sam Varshavchik said: >> > Chris Adams writes: >> > >Is there anything that actually does that and depends on the result? >> >> You skipped this part. Can you name something that tries this? I b

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Chris Adams writes: Once upon a time, Sam Varshavchik said: > Chris Adams writes: > >Is there anything that actually does that and depends on the result? You skipped this part. Can you name something that tries this? I bet somebody can break it if so. When the code is ready, I'll name it,

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Chris Adams writes: Once upon a time, Sam Varshavchik said: > Can you explain how two completely different executables could possibly end > up having the same absolute pathname? chroot for one. That would require root's environment, in order to set one up. A non- privileged process cannot s

Re: prelink should not mess with running executables

2012-07-15 Thread Chris Adams
Once upon a time, Sam Varshavchik said: > Chris Adams writes: > >Is there anything that actually does that and depends on the result? You skipped this part. Can you name something that tries this? I bet somebody can break it if so. -- Chris Adams Systems and Network Administrator - HiWAAY In

Re: prelink should not mess with running executables

2012-07-15 Thread Chris Adams
Once upon a time, Sam Varshavchik said: > Can you explain how two completely different executables could possibly end > up having the same absolute pathname? chroot for one. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Chris Adams writes: Once upon a time, Sam Varshavchik said: > I would expect that /proc/self/exe symlink gives the name of the running > executable. I don't think it's an unreasonable expectation. There are lots of ways that can fail already; prelink is just one. Running "yum update" can break

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Chris Adams writes: Once upon a time, Sam Varshavchik said: > A means for authenticating a filesystem domain socket's peer. Receive the > peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're > same, the daemon is talking to another instance of itself. Is there anything t

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Garrett Holmstrom writes: On 2012-07-15 15:00, Sam Varshavchik wrote: Benny Amorsen writes: Perhaps it's just me, but why would the daemon stat /proc/self/exe? I presume prelink writes a new file and renames into place as a proper Unix program should, which still leaves the original program in

Re: prelink should not mess with running executables

2012-07-15 Thread Chris Adams
Once upon a time, Sam Varshavchik said: > I would expect that /proc/self/exe symlink gives the name of the running > executable. I don't think it's an unreasonable expectation. There are lots of ways that can fail already; prelink is just one. Running "yum update" can break it as well (not ever

Retired python-certifi

2012-07-15 Thread Arun SAG
Hi, python-certifi has certificate bundle generated from mozilla. This package was needed previously by python-requests. Now python-requests no longer needs this package, it uses system wide cert bundle. I am retiring python-certifi for good. -- Arun S A G http://zer0c00l.in/ -- devel mailing l

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Jef Spaleta writes: On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik wrote: > A means for authenticating a filesystem domain socket's peer. Receive the > peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're > same, the daemon is talking to another instance of itself. T

Re: prelink should not mess with running executables

2012-07-15 Thread Chris Adams
Once upon a time, Sam Varshavchik said: > A means for authenticating a filesystem domain socket's peer. Receive the > peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're > same, the daemon is talking to another instance of itself. Is there anything that actually does th

Re: prelink should not mess with running executables

2012-07-15 Thread Garrett Holmstrom
On 2012-07-15 15:00, Sam Varshavchik wrote: Benny Amorsen writes: Perhaps it's just me, but why would the daemon stat /proc/self/exe? I presume prelink writes a new file and renames into place as a proper Unix program should, which still leaves the original program intact on disk until the last

Re: prelink should not mess with running executables

2012-07-15 Thread Robert Nichols
On 07/15/2012 01:10 PM, Jef Spaleta wrote: Generally speaking do we have a cron-like service that knows how to taste for onbattery in a high level way? Or do we have to encode that check into each script that fires from a cron-like service? In /etc/cron.hourly/0anacron there is a test using /u

Re: prelink should not mess with running executables

2012-07-15 Thread Jef Spaleta
On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik wrote: > A means for authenticating a filesystem domain socket's peer. Receive the > peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're > same, the daemon is talking to another instance of itself. The "same" in what sense?

Re: Heads up: Droid fonts update in Rawhide

2012-07-15 Thread Nicolas Mailhot
Hi Dave, Thanks for the quick answer! > On 15 July 2012 21:42, Nicolas Mailhot > wrote: >> A. I used a few hundred MiBs of Android git checkout as source. > > That's the canonical source for Droid, yes. > > (The Roboto fonts in that repo has another canonical source, > http://developer.android.c

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Benny Amorsen writes: Sam Varshavchik writes: > It took me a while to figure out why my daemon kept breaking all the > time, when it couldn't stat its /proc/self/exe any more. Perhaps it's just me, but why would the daemon stat /proc/self/exe? I presume prelink writes a new file and renames i

Re: prelink should not mess with running executables

2012-07-15 Thread Benny Amorsen
Sam Varshavchik writes: > It took me a while to figure out why my daemon kept breaking all the > time, when it couldn't stat its /proc/self/exe any more. Perhaps it's just me, but why would the daemon stat /proc/self/exe? I presume prelink writes a new file and renames into place as a proper Uni

Re: Heads up: Droid fonts update in Rawhide

2012-07-15 Thread Simone Caronni
--Simone Sent from my phone! On Jul 15, 2012 10:42 PM, "Nicolas Mailhot" wrote: > Hi, > > I've just pushed new Droid font packages to Fedora Rawhide. > http://koji.fedoraproject.org/koji/buildinfo?buildID=330644 > > Droid are complex font families with a difficult upstream and the > following ca

Heads up: Droid fonts update in Rawhide

2012-07-15 Thread Nicolas Mailhot
Hi, I've just pushed new Droid font packages to Fedora Rawhide. http://koji.fedoraproject.org/koji/buildinfo?buildID=330644 Droid are complex font families with a difficult upstream and the following caveats apply: A. I used a few hundred MiBs of Android git checkout as source. The fonts are als

Re: prelink should not mess with running executables

2012-07-15 Thread Sam Varshavchik
Jan Kratochvil writes: On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote: > It took me a while to figure out why my daemon kept breaking all the > time, when it couldn't stat its /proc/self/exe any more. This is a bug of the daemon. While it is already suspicious it needs to mess with

Re: prelink should not mess with running executables

2012-07-15 Thread Jef Spaleta
On Sun, Jul 15, 2012 at 9:58 AM, Jan Kratochvil wrote: > That prelink is being run on battery I repeat is a bug of cron. > > I had a script to disable such jobs automatically, I do it by hand nowadays. Generally speaking do we have a cron-like service that knows how to taste for onbattery in a hi

Re: prelink should not mess with running executables

2012-07-15 Thread Jan Kratochvil
On Sun, 15 Jul 2012 19:37:26 +0200, Reindl Harald wrote: > you must start openoffice damned often that the benfit beats out > the overhead of the /etc/cron.daily/prelink When you prelink it nightly on AC and run it at least once on battery, the saving has been done. > to beat the battery drain o

Re: prelink should not mess with running executables

2012-07-15 Thread Reindl Harald
Am 15.07.2012 19:31, schrieb Jan Kratochvil: > On Sun, 15 Jul 2012 15:50:39 +0200, Reindl Harald wrote: >> only prelink is good with zero benefit? > > Yes, without that "zero benefit". prelink has provable startup performance > improvement and runtime memory savings. not practically >> i did

Re: prelink should not mess with running executables

2012-07-15 Thread Jan Kratochvil
On Sun, 15 Jul 2012 15:50:39 +0200, Reindl Harald wrote: > only prelink is good with zero benefit? Yes, without that "zero benefit". prelink has provable startup performance improvement and runtime memory savings. > i did not notice ever any benfit of prelink even by > starting large applicatio

Re: prelink should not mess with running executables

2012-07-15 Thread Reindl Harald
Am 15.07.2012 15:45, schrieb Jan Kratochvil: > On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote: >> It took me a while to figure out why my daemon kept breaking all the >> time, when it couldn't stat its /proc/self/exe any more. > > This is a bug of the daemon > On Sat, 14 Jul 2012 16:4

Re: prelink should not mess with running executables

2012-07-15 Thread Jan Kratochvil
On Sat, 14 Jul 2012 16:19:23 +0200, Sam Varshavchik wrote: > It took me a while to figure out why my daemon kept breaking all the > time, when it couldn't stat its /proc/self/exe any more. This is a bug of the daemon. While it is already suspicious it needs to mess with "/proc/self/exe" stat work

Re: intel ipw2100/ipw2200 firmware must be removed

2012-07-15 Thread Al Dunsmuir
On Saturday, July 14, 2012, 7:25:15 PM, Eric Smith wrote: > Kevin Fenzi wrote: >> See: >> http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Binary_Firmware > Ralf Ertzinger wrote: >> Question about that: The first requirement is that the file is >> non-executable. Does that mean that Fe

blitz license change

2012-07-15 Thread Sergio Pascual
Hello, blitz-0.10 has updated its license terms. It has changed from either LGPLv3+ or BSD to either LGPLv3+ or BSD or Artistic 2.0 It was Artistic 1.0 febore, but as this is not allowed in Fedora, it wasn't mentioned. This new version will arrive at rawhide soon. Regards, Sergio -- devel mail