FYI: ZNC IRC->Email/SMS/Twitter
Folks, If anyone here is running ZNC as an IRC bouncer for #f-d, you might be interested in something I hacked together over the weekend: http://www.jonmasters.org/pub/util/awayping/awayping.txt (I'll clean it up some more when I have time). Basically, it lets you have pings and messages matching certain patterns automatically texted, emailed, and tweeted at you while you are detached. I like it because I don't always want to be attached to IRC but I do always like to have a proxy running that can log messages for me. On public IRC, I just have it configured to email me every 5 minutes if my nick is mentioned during that time with a transcript, and then send me a direct tweet about it. If you don't use ZNC, see the SF project page. I'm interested in packaging it, but admit that I would love it if someone else were interested in sharing that. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
OT: why aren't we campaigning against Apple/Nokia's fight against the use of OGG? (was Re: the end of life for flash player (HTML5))
On Mon, 2009-06-08 at 17:30 -0400, Gregory Maxwell wrote: > 2009/6/8 Kelly Miller : > > Thanks to Apple, that isn't going to be happening. Apple's pushing for the > > required default video codec to be the aforementioned nonfree MPEG4/H.264 > > codec, and they don't seem to care whether it can be shipped by anybody > > else. > > Perhaps pedantry but for the sake of accuracy: > > Some of the patent holders in the MPEG-LA patent pool (Apple and > Nokia) pushed hard for there to be no royalty-free baseline > recommended in the standard. I'm not aware of anyone, Apple included, > pushing for H.264 in the standard since the adoption of an encumbered > format as formal formal default is simply a complete non-starter. I'm sick of Apple and Nokia's bullcrap about OGG being encumbered and constantly fighting against it. I think it's a clear sign that OGG is better and the they (Apple particularly) don't want people knowing that they don't have to be locked into Apple's mini-monopoly. So, after having given so much to Apple and Nokia (you can mount a very sound argument that without OSS, Apple would be a backwater stuck with OS9) why aren't we making noise about it being time that Apple and Nokia give a little back. I for one am sick of knowing we enabled them, but in a way that they seem to feel it's fine to lock us out. R. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Reminder: no new Fedora 9 CVS branches
Hi All, As Fedora 11 is released on Tuesday June 9th there will be no new CVS branches allowed for F-9 http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL lists the policy in effect. This means that F-9 is now in a maintenance only cycle, with EOL fast approaching, the exact EOL date will be set at the FESCo meeting this week. Dennis 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: More mock problems
On 06/08/2009 03:15 PM, Rich Megginson wrote: > Ah, so it is. Thanks! So now my only hurdle is the missing popt-devel > - any ideas? > That one looks like a genuine packaging bug. We don't use rpm-devel on the builders so no one saw it. The header files for popt are in the main popt package in RHEL5/CentOS5 so that's what actually needs to be required in this instance, not popt-devel. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
On Mon, 2009-06-08 at 14:50 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2009-06-08 at 11:48 -0700, Fernando Lopez-Lezcano wrote:
> > On Mon, 2009-06-08 at 11:55 -0600, Rich Megginson wrote:
> > > Kevin Kofler wrote:
> > > > Fernando Lopez-Lezcano wrote:
> > > >
> > > >
> > > >> On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote:
> > > >>
> > > >>> Neal Becker wrote:
> > > >>>
> > > rpmdb: Program version 4.7 doesn't match environment version 4.5
> > >
> > > >>> You need at least RPM 4.6 on the host systems to build Rawhide
> > > >>> packages,
> > > >>> that's at least F10 + updates. All the Fedora builders are running a
> > > >>> custom build of RPM 4.6 on the EL5 hosts.
> > > >>>
> > > >> Is this available anywhere? My build host is EL5 and I'm finding it
> > > >> impossible to build F11 packages there
> > > >>
> > > >
> > > > You need these: http://infrastructure.fedoraproject.org/builder-rpms/
> > > > and
> > > > python-hashlib from EPEL.
> > > >
> > > I'm not able to install the packages at builder-rpms
> > > I'm running RHEL5 x86_64
> > > 1) upgrade to latest RHEL5 - reboot
> > > 2) added /etc/yum.repos.d/builder-rpms.repo:
> > > [builder-rpms]
> > > name=builder-rpms
> > > description=New rpm and yum in order to use mock on el5 to build f11 and
> > > later packages
> > > baseurl=http://infrastructure.fedoraproject.org/builder-rpms/x86_64/
> > >
> > > 3) yum upgrade - the only package I was able to successfully upgrade was
> > > yum - yum upgrade yum - everything else fails like this:
> > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems
> > > --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package
> > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed)
> > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems
> > > --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package
> > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed)
> > > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 from builder-rpms has depsolving
> > > problems
> > > --> Missing Dependency: popt-devel is needed by package
> > > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms)
> > > Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package
> > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed)
> > > Error: Missing Dependency: popt-devel is needed by package
> > > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms)
> > > Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package
> > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed)
> > >
> > > I cannot find popt-devel anywhere in the rhel or epel repos. Do I need
> > > to install these rpms manually with rpm rather than with yum?
> >
> > Yup, same here, looks like there's more than just what is in the
> > infrastructure site... I'm currently trying to rebuild locally.
>
> I had to:
>
> - change requires in rpm.spec from popt-devel to just popt
> - build rpm package (for x86_64 and i386)
> - put it in local repository (net-snmp should not need it, I think
> that is the point, but just in case)
> - build net-snmp (merged in spec with latest patch from 5.3) with
> the new rpm in the build environment, x86_64
> - but rpm-libs and rpm-devel require libmagic.so.1 in i386, and
> that seems to not be available in the 5.3 x86_64 standard
> repository, so install the i386 file from 5.3.i386 in the x86_64
> infrastructure repository
> - rebuild yum
> - the result installs in a fully updated 5.3 and a f11 root can be
> created...
Nope, sorry, no luck yet. I can use _mach_ to build a f11 chroot but
mock is not happy ("cannot open Packages index using db3 - No such file
or directory"). Removing all caches seems to help but I only can build a
chroot once. I have tried many times and I'm getting confused. It is an
old version of mock, maybe that's the reason. Sigh.
-- Fernando
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Mon, Jun 8, 2009 at 5:47 PM, Ben Boeckel wrote: > Nokia argued against it for patent worries. Probably worried > that if it did get done, some patent troll would come out of > the woodwork with some obscure patent and sue all OGG the > distributors. If you're going to play the numbers the MPEG codecs have a far worse track record of attracting litigation from trolls. The argument was actually more nuanced than that. It's more along the lines of "We're already committed to shipping H.264 and taking whatever surprise litigation risk there exists from that; even if the risk of negative surprises with Ogg/Theora is lower it would still be an addition to the risk we're already assuming, even evaluating the risks of alternatives has a cost to us, so the adoption of anything as a baseline other than what we're already using is not in our interests" Which isn't an insane argument, but it does have a simple solution: Sufficient market adoption will justify those costs. It's also positive that the only companies who have taken a clear public position against adopting Ogg/Theora as a baseline are companies whom receive payments for the use of MPEG-LA licensed technology. Those who merely pay to play are still shipping Theora. > Apple's biggest complaint was that hardware decoders for Theora > were far and few between (despite there being specs for it). > Their excuse was that H.264 has hardware implementations in > current hardware and handhelds don't have the power to do the > decoding in software. This isn't a correct knock in any case: Typical mobile devices (er, like the iphone) implement H.264 using the regular SIMD instruction sets of pretty boring general purpose CPUs or fairly common off the shelf DSPs (I.e. the c64x on TI OMAP). The existing handhelds very much do have the power to decode Theora in software, at least if someone would bother adding neon versions of the assembly optimized parts. (Although even my anaemic openmoko can *decode* Theora in real time with a totally unoptimized implementation; though display has bandwidth problems; most modern handhelds have far more horsepower.) Direct "hardware" support for non-trivial parts of the decode is something that seems to have been largely abandoned in the late 90s after everyone realized that this stuff changes too fast for economic silicon implementation. When people say hardware support these days usually mean "carefully optimized versions for my embedded processor" or possibly "use of hardware overlay and colorspace conversion" which works equally well for Theora. That said, there is a synthesizable VHDL implementation the back half of the the Theora decoder available: http://svn.xiph.org/trunk/theora-fpga/ (most of the rest of the decode process is more easily and effectively done on a general purpose CPU). So it's not even "there exists a spec" it's "there exists a hardware design needing only integration and manufacture". But as I said, generally true hardware implementation isn't done for decoders anymore. Even the $0.10 vorbis player on a chip is just software on a tiny DSP. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On Mon, Jun 8, 2009 at 6:24 PM, Thorsten Leemhuis wrote: > Not to forget > Jesse (as rel-eng lead in a quite important position) and his "quest > to reduce the number of updates" (which he gave up -- see earlier this > thread), FTR, he actually said "I've all *but* given up on my quest to reduce the number of updates", emphasis is mine. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
Toshio Kuratomi wrote: On 06/08/2009 02:28 PM, Rich Megginson wrote: Ok, that got me further, but I'm still failing. I had to do rpm --force -Uvh net-snmp*.fedorabuilder.x86_64.rpm But I'm stuck on rpm - both yum and rpm install are failing: liblua-5.1.so()(64bit) is needed by rpm-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-build-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 popt-devel is needed by rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-libs-4.6.0-4.0.mitr.1.el5.x86_64 Hmm... The lua package should be available in epel. lftp download.fedora.redhat.com:/pub/epel/5/x86_64> ls lua-5* -rw-rw-r--2 ftp ftp230809 Jun 16 2007 lua-5.1.2-1.el5.i386.rpm -rw-rw-r--1 ftp ftp230063 Jun 16 2007 lua-5.1.2-1.el5.x86_64.rpm -Toshio Ah, so it is. Thanks! So now my only hurdle is the missing popt-devel - any ideas? smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
On 06/08/2009 02:28 PM, Rich Megginson wrote: > Ok, that got me further, but I'm still failing. I had to do rpm --force > -Uvh net-snmp*.fedorabuilder.x86_64.rpm > > But I'm stuck on rpm - both yum and rpm install are failing: >liblua-5.1.so()(64bit) is needed by rpm-4.6.0-4.0.mitr.1.el5.x86_64 >liblua-5.1.so()(64bit) is needed by > rpm-build-4.6.0-4.0.mitr.1.el5.x86_64 >liblua-5.1.so()(64bit) is needed by > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 >popt-devel is needed by rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 >liblua-5.1.so()(64bit) is needed by > rpm-libs-4.6.0-4.0.mitr.1.el5.x86_64 > Hmm... The lua package should be available in epel. lftp download.fedora.redhat.com:/pub/epel/5/x86_64> ls lua-5* -rw-rw-r--2 ftp ftp230809 Jun 16 2007 lua-5.1.2-1.el5.i386.rpm -rw-rw-r--1 ftp ftp230063 Jun 16 2007 lua-5.1.2-1.el5.x86_64.rpm -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
Ben Boeckel wrote: > userbase with extra codec messes. I'm sure IE will just play by > itself in the corner and Safari will play Apple's game no > matter what happens. /s/by/with/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
On Mon, 2009-06-08 at 11:48 -0700, Fernando Lopez-Lezcano wrote: > On Mon, 2009-06-08 at 11:55 -0600, Rich Megginson wrote: > > Kevin Kofler wrote: > > > Fernando Lopez-Lezcano wrote: > > > > > > > > >> On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote: > > >> > > >>> Neal Becker wrote: > > >>> > > rpmdb: Program version 4.7 doesn't match environment version 4.5 > > > > >>> You need at least RPM 4.6 on the host systems to build Rawhide packages, > > >>> that's at least F10 + updates. All the Fedora builders are running a > > >>> custom build of RPM 4.6 on the EL5 hosts. > > >>> > > >> Is this available anywhere? My build host is EL5 and I'm finding it > > >> impossible to build F11 packages there > > >> > > > > > > You need these: http://infrastructure.fedoraproject.org/builder-rpms/ and > > > python-hashlib from EPEL. > > > > > I'm not able to install the packages at builder-rpms > > I'm running RHEL5 x86_64 > > 1) upgrade to latest RHEL5 - reboot > > 2) added /etc/yum.repos.d/builder-rpms.repo: > > [builder-rpms] > > name=builder-rpms > > description=New rpm and yum in order to use mock on el5 to build f11 and > > later packages > > baseurl=http://infrastructure.fedoraproject.org/builder-rpms/x86_64/ > > > > 3) yum upgrade - the only package I was able to successfully upgrade was > > yum - yum upgrade yum - everything else fails like this: > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems > > --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems > > --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 from builder-rpms has depsolving > > problems > > --> Missing Dependency: popt-devel is needed by package > > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) > > Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > > Error: Missing Dependency: popt-devel is needed by package > > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) > > Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package > > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > > > > I cannot find popt-devel anywhere in the rhel or epel repos. Do I need > > to install these rpms manually with rpm rather than with yum? > > Yup, same here, looks like there's more than just what is in the > infrastructure site... I'm currently trying to rebuild locally. I had to: - change requires in rpm.spec from popt-devel to just popt - build rpm package (for x86_64 and i386) - put it in local repository (net-snmp should not need it, I think that is the point, but just in case) - build net-snmp (merged in spec with latest patch from 5.3) with the new rpm in the build environment, x86_64 - but rpm-libs and rpm-devel require libmagic.so.1 in i386, and that seems to not be available in the 5.3 x86_64 standard repository, so install the i386 file from 5.3.i386 in the x86_64 infrastructure repository - rebuild yum - the result installs in a fully updated 5.3 and a f11 root can be created... -- Fernando -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kelly Miller wrote: > Thanks to Apple, that isn't going to be happening. Apple's pushing for the > required default video codec to be the aforementioned nonfree MPEG4/H.264 > codec, and they don't seem to care whether it can be shipped by anybody > else. Nokia argued against it for patent worries. Probably worried that if it did get done, some patent troll would come out of the woodwork with some obscure patent and sue all OGG the distributors. Apple's biggest complaint was that hardware decoders for Theora were far and few between (despite there being specs for it). Their excuse was that H.264 has hardware implementations in current hardware and handhelds don't have the power to do the decoding in software. I'm not aware of any other large companies that lobbied W3C to have no baseline instead of OGG/Theora. As much as I dislike and distrust Apple, it isn't just them. :( However, I think that Firefox offering OGG/Theora everywhere will at least help push some of the more aware video vendors to offer OGG so they don't shove off one side of the Mac/Windows userbase with extra codec messes. I'm sure IE will just play by itself in the corner and Safari will play Apple's game no matter what happens. - --Ben > On Fri, Jun 5, 2009 at 5:57 AM, Jaroslav Reznik wrote: > >> >> In Arora I can hear only audio... So it's not OK - OGG has to be THE MUST - >> basic codec supported on all platforms/browsers. I'm not against >> proprietary >> codecs (I don't want to use them). >> >> Jaroslav >> >> > Matěj >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkothtQACgkQiPi+MRHG3qSMrgCaAhgyXCiXU2t6Idf453deYAxI iO4An1IknF77NJ7u5f8+QBzc3ncyJ/ZG =Oq5t -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
Am Freitag, den 05.06.2009, 11:23 +0100 schrieb Bastien Nocera: > Heya, > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > and saw this: > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > gnome-scan is already packaged by Deji, but I gather that more > integration work could be done to make setting up and using scanners > easier in GNOME and Fedora in general. > > Any takers? > > I think a good start would be making a list of problems seen in setting > up scanners (additional packages required, tweaks), and make sure that > gnome-scan and the necessary plugins are installed in a default > installation. > > Cheers > > /Bastien, who doesn't own a scanner > I have an HP PSC1610 and it works perfectly with xsane and gimp. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Mon, Jun 8, 2009 at 11:30 PM, Gregory Maxwell wrote: > 2009/6/8 Kelly Miller : >> Thanks to Apple, that isn't going to be happening. Apple's pushing for the >> required default video codec to be the aforementioned nonfree MPEG4/H.264 >> codec, and they don't seem to care whether it can be shipped by anybody >> else. > > Perhaps pedantry but for the sake of accuracy: > > Some of the patent holders in the MPEG-LA patent pool (Apple and > Nokia) pushed hard for there to be no royalty-free baseline > recommended in the standard. I'm not aware of anyone, Apple included, > pushing for H.264 in the standard since the adoption of an encumbered > format as formal formal default is simply a complete non-starter. > > What Apple has done is ship systems which can only play H.264 using > the video tag out of the box. You could accurately accuse Apple of > pushing for H.264 as a defacto standard, but not a "required default". > > For desktop Safari usage Ogg/Theora+Vorbis support can be added by > installing the XiphQT codec package. While requiring an install was > unfortunate flash itself is an existence proof that required > installations don't make wide adoption impossible. The apple desktops > also have decent Java support and websites can fall back to java > playback. (Theoretically Flash playback of Ogg/Theora is also possible > now; but the intersection of Flash gurus and free software developers > is nearly the empty set) Or you can simply ship provide multiple video streams and switch them based on the useragent. (this is very likely to be the end result, even thought it sucks). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
2009/6/8 Kelly Miller : > Thanks to Apple, that isn't going to be happening. Apple's pushing for the > required default video codec to be the aforementioned nonfree MPEG4/H.264 > codec, and they don't seem to care whether it can be shipped by anybody > else. Perhaps pedantry but for the sake of accuracy: Some of the patent holders in the MPEG-LA patent pool (Apple and Nokia) pushed hard for there to be no royalty-free baseline recommended in the standard. I'm not aware of anyone, Apple included, pushing for H.264 in the standard since the adoption of an encumbered format as formal formal default is simply a complete non-starter. What Apple has done is ship systems which can only play H.264 using the video tag out of the box. You could accurately accuse Apple of pushing for H.264 as a defacto standard, but not a "required default". For desktop Safari usage Ogg/Theora+Vorbis support can be added by installing the XiphQT codec package. While requiring an install was unfortunate flash itself is an existence proof that required installations don't make wide adoption impossible. The apple desktops also have decent Java support and websites can fall back to java playback. (Theoretically Flash playback of Ogg/Theora is also possible now; but the intersection of Flash gurus and free software developers is nearly the empty set) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On 06/08/2009 01:06 PM, Simon Wesp wrote: > Am Freitag, 05 Juni 2009 12:21:01 schrieb Kevin Fenzi: > KF> 17:28:03 so, we already have -5 to the exception for zsync > KF> 17:28:28 #agreed No exception for zsync. > > Of course shipping internals is very very evil and I really understand the > problems behind them. > > I'm a pessimist and I ask myself: > "What is the consequence, if rsync-upstream is unwilling to drop shipping of > forked zlib as internal dependency?" > a) drop rsync from fedora? > b) build rsync against system and lose compatibility to rsync original? > c) call the dependency rsync-zlib or whatever? > > The zsync difficulty is that zsync tries to be compatible to rsync and needs > a forked zlib, like rsync. It's on the dice, that the zlib-internal is bound > with the zlib of rsync. I beg, again, for the exception of zsync, because the > problem wouldn't be worsened. This is the wrong solution to the problem. > It's just a new child of sorrow, sitting in the front of the closed door and > knows his brother with the same misfeature is in. > If rsync-upstream is unwilling to drop internal zlib, I believe nothing will > happened, because rsync is a centerpiece of every distribution and fedora > can't afford drop this package or can't afford to be incompatible to other > distributions and rsync itself. And renaming the zlib for this project will > bring a flood of *-zlib and that can not be the meaning of it all. > simo told notting that it was possible to fix this. So we need him to give some input on how he's thinking this can be done. However, we are going to fix this somehow. If don't have a clean method, we'll have to fork zlib. Robert, I still haven't heard, what happened when you asked rsync upstream about their releasing their forked zlib separately? Having a flood of zlib-* is unlikely to happen at the distribution level because the effort to maintain all the libraries is painful. It's more likely that we'll make more of an effort to work with upstreams to port their code to vanilla zlib and work with the patches to zlib that they carry to get them merged upstream and if those patches can't be merged, to get them merged into a single fork rather than multiple forks. > I think this is an important question. I don't want to bring trouble upon > fedora project or rsync or anybody else. Additionally, I believe that there > are a few applications in fedora which are using shipped internals, too. > As I said it before, I don't want to start trouble, but it should be very > helpful to find them and collect them in a seperate tracker. I created one > with the bugnumber #504497 to get an overview, about packages/applications > with duplicated libs. Please help to find them. Perhaps we can be succeed in > conversion of upstream, to help all for a better cooperation and better > software. Thank you! > Yes, please, if you know of a package that's shipping an internal version of a library, open a bug and block the tracker so we can fix it (or possibly get FESCo to issue an exception). These things should be getting caught during package review but sometimes they slip through the cracks. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
Toshio Kuratomi wrote: On 06/08/2009 11:48 AM, Fernando Lopez-Lezcano wrote: On Mon, 2009-06-08 at 11:55 -0600, Rich Megginson wrote: Kevin Kofler wrote: Fernando Lopez-Lezcano wrote: On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote: Neal Becker wrote: rpmdb: Program version 4.7 doesn't match environment version 4.5 You need at least RPM 4.6 on the host systems to build Rawhide packages, that's at least F10 + updates. All the Fedora builders are running a custom build of RPM 4.6 on the EL5 hosts. Is this available anywhere? My build host is EL5 and I'm finding it impossible to build F11 packages there You need these: http://infrastructure.fedoraproject.org/builder-rpms/ and python-hashlib from EPEL. I'm not able to install the packages at builder-rpms I'm running RHEL5 x86_64 1) upgrade to latest RHEL5 - reboot 2) added /etc/yum.repos.d/builder-rpms.repo: [builder-rpms] name=builder-rpms description=New rpm and yum in order to use mock on el5 to build f11 and later packages baseurl=http://infrastructure.fedoraproject.org/builder-rpms/x86_64/ 3) yum upgrade - the only package I was able to successfully upgrade was yum - yum upgrade yum - everything else fails like this: 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 from builder-rpms has depsolving problems --> Missing Dependency: popt-devel is needed by package rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) Error: Missing Dependency: popt-devel is needed by package rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) I cannot find popt-devel anywhere in the rhel or epel repos. Do I need to install these rpms manually with rpm rather than with yum? Yup, same here, looks like there's more than just what is in the infrastructure site... I'm currently trying to rebuild locally. The rebuilt net-snmp is also in the builder repo. Unfortunately, the CentOS repository rebuild compares newer than the one in the builder repo: Centos: net-snmp-5.3.2.2-5.el5_3.1.x86_64 builder-repo: net-snmp-5.3.2.2-5.el5.fedorabuilder.x86_64 You could probably replace the centos net-snmp with the builder-repo's and then things will be fine... You'll have to use --exclude with yum afterwards, though, or the net-snmp from centos will keep trying to come in. Ok, that got me further, but I'm still failing. I had to do rpm --force -Uvh net-snmp*.fedorabuilder.x86_64.rpm But I'm stuck on rpm - both yum and rpm install are failing: liblua-5.1.so()(64bit) is needed by rpm-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-build-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 popt-devel is needed by rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-libs-4.6.0-4.0.mitr.1.el5.x86_64 -Toshio smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
On 06/08/2009 11:48 AM, Fernando Lopez-Lezcano wrote: > On Mon, 2009-06-08 at 11:55 -0600, Rich Megginson wrote: >> Kevin Kofler wrote: >>> Fernando Lopez-Lezcano wrote: >>> >>> On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote: > Neal Becker wrote: > >> rpmdb: Program version 4.7 doesn't match environment version 4.5 >> > You need at least RPM 4.6 on the host systems to build Rawhide packages, > that's at least F10 + updates. All the Fedora builders are running a > custom build of RPM 4.6 on the EL5 hosts. > Is this available anywhere? My build host is EL5 and I'm finding it impossible to build F11 packages there >>> >>> You need these: http://infrastructure.fedoraproject.org/builder-rpms/ and >>> python-hashlib from EPEL. >>> >> I'm not able to install the packages at builder-rpms >> I'm running RHEL5 x86_64 >> 1) upgrade to latest RHEL5 - reboot >> 2) added /etc/yum.repos.d/builder-rpms.repo: >> [builder-rpms] >> name=builder-rpms >> description=New rpm and yum in order to use mock on el5 to build f11 and >> later packages >> baseurl=http://infrastructure.fedoraproject.org/builder-rpms/x86_64/ >> >> 3) yum upgrade - the only package I was able to successfully upgrade was >> yum - yum upgrade yum - everything else fails like this: >> 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems >> --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package >> 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) >> 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems >> --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package >> 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) >> rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 from builder-rpms has depsolving >> problems >> --> Missing Dependency: popt-devel is needed by package >> rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) >> Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package >> 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) >> Error: Missing Dependency: popt-devel is needed by package >> rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) >> Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package >> 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) >> >> I cannot find popt-devel anywhere in the rhel or epel repos. Do I need >> to install these rpms manually with rpm rather than with yum? > > Yup, same here, looks like there's more than just what is in the > infrastructure site... I'm currently trying to rebuild locally. > The rebuilt net-snmp is also in the builder repo. Unfortunately, the CentOS repository rebuild compares newer than the one in the builder repo: Centos: net-snmp-5.3.2.2-5.el5_3.1.x86_64 builder-repo: net-snmp-5.3.2.2-5.el5.fedorabuilder.x86_64 You could probably replace the centos net-snmp with the builder-repo's and then things will be fine... You'll have to use --exclude with yum afterwards, though, or the net-snmp from centos will keep trying to come in. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
Thanks to Apple, that isn't going to be happening. Apple's pushing for the required default video codec to be the aforementioned nonfree MPEG4/H.264 codec, and they don't seem to care whether it can be shipped by anybody else. On Fri, Jun 5, 2009 at 5:57 AM, Jaroslav Reznik wrote: > > In Arora I can hear only audio... So it's not OK - OGG has to be THE MUST - > basic codec supported on all platforms/browsers. I'm not against > proprietary > codecs (I don't want to use them). > > Jaroslav > > > Matěj > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Static system level uid/gid's reservations in Fedora/RHEL - how to handle situation?
On Friday 05 June 2009, D. Hugh Redelmeier wrote: > I gave up and renumbered on my newest boxes. It sure is a pain today > when I'm trying to use NFS between an old box and a new one. > > I think that Sun supports UID mapping on NFS but Linux does not. It's supported with NFSv4. That might not help with old boxes though. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
Am Freitag, 05 Juni 2009 12:21:01 schrieb Kevin Fenzi: KF> 17:28:03 so, we already have -5 to the exception for zsync KF> 17:28:28 #agreed No exception for zsync. Of course shipping internals is very very evil and I really understand the problems behind them. I'm a pessimist and I ask myself: "What is the consequence, if rsync-upstream is unwilling to drop shipping of forked zlib as internal dependency?" a) drop rsync from fedora? b) build rsync against system and lose compatibility to rsync original? c) call the dependency rsync-zlib or whatever? The zsync difficulty is that zsync tries to be compatible to rsync and needs a forked zlib, like rsync. It's on the dice, that the zlib-internal is bound with the zlib of rsync. I beg, again, for the exception of zsync, because the problem wouldn't be worsened. It's just a new child of sorrow, sitting in the front of the closed door and knows his brother with the same misfeature is in. If rsync-upstream is unwilling to drop internal zlib, I believe nothing will happened, because rsync is a centerpiece of every distribution and fedora can't afford drop this package or can't afford to be incompatible to other distributions and rsync itself. And renaming the zlib for this project will bring a flood of *-zlib and that can not be the meaning of it all. I think this is an important question. I don't want to bring trouble upon fedora project or rsync or anybody else. Additionally, I believe that there are a few applications in fedora which are using shipped internals, too. As I said it before, I don't want to start trouble, but it should be very helpful to find them and collect them in a seperate tracker. I created one with the bugnumber #504497 to get an overview, about packages/applications with duplicated libs. Please help to find them. Perhaps we can be succeed in conversion of upstream, to help all for a better cooperation and better software. Thank you! -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp The G in GNU stands for GNU http://fedoraproject.org/wiki/SimonWesp 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: More mock problems
On Mon, 2009-06-08 at 11:55 -0600, Rich Megginson wrote: > Kevin Kofler wrote: > > Fernando Lopez-Lezcano wrote: > > > > > >> On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote: > >> > >>> Neal Becker wrote: > >>> > rpmdb: Program version 4.7 doesn't match environment version 4.5 > > >>> You need at least RPM 4.6 on the host systems to build Rawhide packages, > >>> that's at least F10 + updates. All the Fedora builders are running a > >>> custom build of RPM 4.6 on the EL5 hosts. > >>> > >> Is this available anywhere? My build host is EL5 and I'm finding it > >> impossible to build F11 packages there > >> > > > > You need these: http://infrastructure.fedoraproject.org/builder-rpms/ and > > python-hashlib from EPEL. > > > I'm not able to install the packages at builder-rpms > I'm running RHEL5 x86_64 > 1) upgrade to latest RHEL5 - reboot > 2) added /etc/yum.repos.d/builder-rpms.repo: > [builder-rpms] > name=builder-rpms > description=New rpm and yum in order to use mock on el5 to build f11 and > later packages > baseurl=http://infrastructure.fedoraproject.org/builder-rpms/x86_64/ > > 3) yum upgrade - the only package I was able to successfully upgrade was > yum - yum upgrade yum - everything else fails like this: > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems > --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems > --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 from builder-rpms has depsolving > problems > --> Missing Dependency: popt-devel is needed by package > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) > Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > Error: Missing Dependency: popt-devel is needed by package > rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) > Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package > 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) > > I cannot find popt-devel anywhere in the rhel or epel repos. Do I need > to install these rpms manually with rpm rather than with yum? Yup, same here, looks like there's more than just what is in the infrastructure site... I'm currently trying to rebuild locally. Argh.. -- Fernando -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Le lundi 08 juin 2009 à 20:13 +0200, Florian Festi a écrit : > > This approach has several shortcomings (forgetting the technical > details). It requires a lot of data be shipped with each package. I think you misunderstood me. I'd want the definition for %font of % icon-dir to be factored-out and centralized too (and not necessarily in an rpm subpackage BTW, a %lib definition shipped with glibc would be perfectly fine with me). Also, that does not prevent standardising install locations (that's why I ask something that can hook in %install). My example, %doc, already makes file location decisions BTW. What I don't want is 1. something auto-triggered transparently (didn't we learn anything from existing package triggers?). Some of us do not have the luxury of uniform-quality input files. Therefore, I want the decision to launch the processing packager-side. I want the packager to decide and check some processing is right for his files, and not discover at QA time another packager decided his file looked like a candidate for froobing and should be froobed behind his back. The existing auto-processing (for example debuginfo generation) has been wrong so many times the web is littered with way to disable it (often with side-effects). Just because you can write good froobing rules does not mean you understand how to auto-select files to be froobed accurately. 2. something that auto-generates (sub)packages. The packager should decide how big or small his packages will be, if they deserve splitting or not, etc. Auto-package creation leads in many cases to monster packages to big to be installed in any reasonable system. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning planet package
On 06/06/2009 09:49 AM, Seth Vidal wrote: On Sat, 6 Jun 2009, Richard Dawe wrote: Good afternoon, I'm the current maintainer of the planet package, but I don't have to maintain it anymore. I am there going to orphan the planet packages. I've taken ownership of it. ... and I'll be helping seth. --Bret -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Sat, Jun 6, 2009 at 6:01 AM, Panu Matilainen wrote:
>
> The hardest part is getting the design right the first time, there's no
> changing an "api" that is exposed to packages.
It's definitely better to get things "right" the first time, but one
thing missing from the system now is any kind of "versioning" on the
macro API. It would seem fairly straightforward to have a global
"SpecVersion: 2" type header that pulls in an updated set of macros
from a different directory.
If such a thing were to be implemented it'd probably be good to use it
to clean out the wishlist in general, like handling %clean and even
%build automatically (e.g. if we see a configure script, just assume
to call "%{configure}", see a Makefile, just assume to call "make",
etc)
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
Rich Megginson wrote: Kevin Kofler wrote: Fernando Lopez-Lezcano wrote: On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote: Neal Becker wrote: rpmdb: Program version 4.7 doesn't match environment version 4.5 You need at least RPM 4.6 on the host systems to build Rawhide packages, that's at least F10 + updates. All the Fedora builders are running a custom build of RPM 4.6 on the EL5 hosts. Is this available anywhere? My build host is EL5 and I'm finding it impossible to build F11 packages there You need these: http://infrastructure.fedoraproject.org/builder-rpms/ and python-hashlib from EPEL. I'm not able to install the packages at builder-rpms I'm running RHEL5 x86_64 1) upgrade to latest RHEL5 - reboot 2) added /etc/yum.repos.d/builder-rpms.repo: [builder-rpms] name=builder-rpms description=New rpm and yum in order to use mock on el5 to build f11 and later packages baseurl=http://infrastructure.fedoraproject.org/builder-rpms/x86_64/ 3) yum upgrade - the only package I was able to successfully upgrade was yum - yum upgrade yum - everything else fails like this: 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 from builder-rpms has depsolving problems --> Missing Dependency: popt-devel is needed by package rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) Error: Missing Dependency: popt-devel is needed by package rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) I cannot find popt-devel anywhere in the rhel or epel repos. Do I need to install these rpms manually with rpm rather than with yum? Follow up - this doesn't work either: 1) downloaded all of the builder-rpms to a local directory 2) rpm -Uvh /path/to/builder-rpms/*.rpm error: Failed dependencies: liblua-5.1.so()(64bit) is needed by rpm-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-build-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 popt-devel is needed by rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 liblua-5.1.so()(64bit) is needed by rpm-libs-4.6.0-4.0.mitr.1.el5.x86_64 Kevin Kofler smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
On Tue, Apr 28, 2009 at 4:02 PM, Neal Becker wrote: > mock -r fedora-devel-x86_64 --shell > INFO: mock.py version 0.9.14 starting... > State Changed: init plugins > State Changed: start > State Changed: lock buildroot > mock-chroot> rpm -q igraph > rpmdb: Program version 4.7 doesn't match environment version 4.5 > error: db4 error(-30971) from dbenv->open: DB_VERSION_MISMATCH: Database > environment version mismatch > error: cannot open Packages index using db3 - (-30971) > error: cannot open Packages database in /var/lib/rpm > rpmdb: Program version 4.7 doesn't match environment version 4.5 > error: db4 error(-30971) from dbenv->open: DB_VERSION_MISMATCH: Database > environment version mismatch > error: cannot open Packages database in /var/lib/rpm > package igraph is not installed > Seems related to this patch rejected for rpm for RHEL and CENTOS. https://bugzilla.redhat.com/show_bug.cgi?id=464752 Regards > > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Nicolas Mailhot wrote:
Le samedi 06 juin 2009 à 13:01 +0300, Panu Matilainen a écrit :
Yes, having each and every spec carry the %{!?foo:¤%&¤%} macro goo makes
no sense at all.
That is pretty much what we did for fonts in F11. However many packagers
just ignored the change and didn't fix their packages.
...
I personally think it would be a huge mistake to have stuff happen
automatically based on filename/location heuristics.
...
I'd much prefer if the packager
was left in control and specified the processing himself, for example by
allowing more magic %doc-like words in %files.
That shows the problem very well. Full control for the packagers is
demanded but it is difficult to force the right (tm) behavior on the
packagers. The question is do we really win something by leaving the
handling of every file to the packager or do we demand to much when
requiring the knowledge how to handle every type of file.
I btw very much dislike the term "filename/location heuristics" in this
context as it gets things wrong. File triggers is not about guessing
what to do with the different files but to create, implement and then
enforce rules how files of a given type are installed. This includes
where these files need to be placed or how they are named - not exactly
a new concept for a huge number of file types.
With the growing number of packages and file types that need special
handling the burden for Fedora for handling these files is also growing.
While changing/removing 95% of the scriptlets is a huge effort it will
pay off - especially as lowers the level of entry for packaging.
In my ideal pony-land, we could have stuff like
%files somepackage
%font somefont.ttf
%icon-dir somedirectory
...
that injected the correct logic in %install/%pre/%post/%postun/%
posttrans etc
And I suppose some of those magic words would work on files already
installed, others on files in the build root (like %doc), and you'd need
them to interact (for example, consolidate three %font lines in a
package in a single actions, have the %font word be aware of the %
fontconfig word so one could correct font file processing with explicit
fontconfig rules, etc)
This approach has several shortcomings (forgetting the technical
details). It requires a lot of data be shipped with each package. Data
which can be already out of date (method of handling the files changed).
It still requires the packager to know about all file types and whether
they need special handling. And even worse it requires RPM to know about
the different file types.
The nice about file triggers is that the package that actually knows
about the file type ships the file trigger for handling it. glibc would
ship the trigger for calling ldconfig and info the trigger for info
files and so on.
Florian
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
yersinia wrote: > > Enter silverlight :( > > > And monolight > > http://www.mono-project.com/Moonlight > > Two sides of the same miserable coin. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
Kevin Kofler wrote: Fernando Lopez-Lezcano wrote: On Wed, 2009-04-29 at 00:40 +0200, Kevin Kofler wrote: Neal Becker wrote: rpmdb: Program version 4.7 doesn't match environment version 4.5 You need at least RPM 4.6 on the host systems to build Rawhide packages, that's at least F10 + updates. All the Fedora builders are running a custom build of RPM 4.6 on the EL5 hosts. Is this available anywhere? My build host is EL5 and I'm finding it impossible to build F11 packages there You need these: http://infrastructure.fedoraproject.org/builder-rpms/ and python-hashlib from EPEL. I'm not able to install the packages at builder-rpms I'm running RHEL5 x86_64 1) upgrade to latest RHEL5 - reboot 2) added /etc/yum.repos.d/builder-rpms.repo: [builder-rpms] name=builder-rpms description=New rpm and yum in order to use mock on el5 to build f11 and later packages baseurl=http://infrastructure.fedoraproject.org/builder-rpms/x86_64/ 3) yum upgrade - the only package I was able to successfully upgrade was yum - yum upgrade yum - everything else fails like this: 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from installed has depsolving problems --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 from builder-rpms has depsolving problems --> Missing Dependency: popt-devel is needed by package rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) Error: Missing Dependency: popt-devel is needed by package rpm-devel-4.6.0-4.0.mitr.1.el5.x86_64 (builder-rpms) Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (installed) I cannot find popt-devel anywhere in the rhel or epel repos. Do I need to install these rpms manually with rpm rather than with yum? Kevin Kofler smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Mon, 2009-06-08 at 13:31 +0200, Nicolas Mailhot wrote: > Le dimanche 07 juin 2009 à 12:31 +0300, Panu Matilainen a écrit : > > > Btw your initial suggestion of collecting the common stuff into macros > > and converting packages to use them would be useful on several ways: > > a) Finding out the things that *are* common among lots of packages. While > > numerous cases are well and widely known already, I suspect there might > > be some that are only specific groups know about (possibly eg java > > related packages, I dunno). > > b) Making the usages of the common patterns easy to spot by grepping. > > c) The transition period cruft can be hidden inside the common macros > > without polluting every spec with it. > > Won't work IMHO. One characteristic of pre-macroized specs is that their > authors have found lots of "interesting" ways to do about the same thing > with different instructions (usually missing some problems). If you > don't want this old processing to collide and interfere with your new > shiny processing you need the call to the new processing to be explicit, > so packagers can check for problems before enabling it. I'm not planning to re-implement anything, just change things that are currently snippets of code you have to copy and paste from the guidelines to be macros instead. All it involves is taking the snippets and putting them into a /etc/macros.* file. -- 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: the end of life for flash player (HTML5)
> Enter silverlight :( > And monolight http://www.mono-project.com/Moonlight > --CJD > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 14:04 +0300, Nicu Buculei wrote: > I have an old HP ScanJet 5370C, for which according with > sane-project.org the support is "Good" (avision backend). For me the > best was around F9, when it worked 50% of the time Unfortunately SANE support for the 5370C isn't universally "Good" - I asked for the compatibility chart to be updated a year or so ago but I guess that wasn't fixed. There are several hardware revisions sold under the 5370C model number; some may still work, others definitely didn't the last time I tried. We had one with a C5 ASIC, though it sounds like you've had more luck getting any useful functionality out of yours, so I guess you may have a different revision. I spent quite some time trying to track down the problem, but upstream wasn't able to be particularly helpful. The sane-avision mailing list isn't archived, which doesn't help. (also: https://bugzilla.redhat.com/show_bug.cgi?id=206094 ) cheers, Kevin -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Mon, 08 Jun 2009 05:55:43 -0700 John Poelstra wrote: > Kevin Fenzi said the following on 06/05/2009 10:51 AM Pacific Time: > > We are trying out a meeting irc bot plugin to handle meetings in a > > more consisent and timely manner. > > > > You can find a copy of the meeting output at: > > > > http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html > > > > We would appreciate feedback on this format for meeting logs. > > > > If this format is acceptable, I would like to see all irc meetings > > use it, and have them all transfer to a common location with search > > ability. If not, we will come up with something better. > > > > kevin > > > > A small nit, but something I find really helpful reading the logs, is > giving each person a different color. yeah, thats a good idea. This plugin uses 'pygments' to highlight/process the output. It looks like there is already an upstream bug about the irc highlight being too generic, see: http://dev.pocoo.org/projects/pygments/ticket/341 I'll see if there can be some progress made on it, or perhaps we can get the fedora maintainer to add the patch. > > John > 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: Announcing Fedora Activity Day - Fedora Development Cycle 2009
Sorry, was quite busy with other stuff over the past few days and didn't get around to answer this On 03.06.2009 02:15, Josh Boyer wrote: > On Wed, Jun 03, 2009 at 01:08:15AM +0200, Kevin Kofler wrote: >> Thorsten Leemhuis wrote: >>> It IMHO shows a big and more and more pressing problem in Fedora: >>> Packagers and leadership are not working towards the same direction. >> The best solution for that is to change the leadership. :-) So don't vote >> for the same old hats for FESCo and FPB. > > Honestly, that is pretty short-sighted. And Thorsten's statement isn't > entirely accurate either. Entirely new FESCo and FPB would still be faced > with > the same problems we have today. > > Let's look at in a bit more detail. > > 1) I don't recall ever seeing FESCo or FPB state as a committee that they want > fewer packages and updates. If you have a mailing list post to meeting > minutes > that say that, I would be happy to look at it. In short: And that from my point of view is exactly the leadership problem. The verbose version: Fedora obviously has a problem here as some packagers follow a (kind of) debian like update scheme while others are more rolling release scheme. That's bad, as those users that prefer to get the latest version of the software as regular update are not satisfied, as some packages stay on old versions; neither are those that prefer "old, but stable", as they sometimes can't avoid to update to new versions for security reasons (Note that this is the very long story very short and without lots of details/special cases where doing either the first or the second is the better thing to do). The policy that FESCo worked out a few months didn't help much. In fact it's so vague that it's IMHO more confusing then helpful. Not to forget Jesse (as rel-eng lead in a quite important position) and his "quest to reduce the number of updates" (which he gave up -- see earlier this thread), which likely made some packagers wonder "is it right how I do it"? A real leader/leading group would have said guided people better. Like "This is how we want to do it [...], here are a few examples that will help to understand [...]". Or even better: work out a overall solution that changes Fedora into a distribution that satisfies both users groups mentioned above: those that prefer older, but stable packages and those that prefer newer packages, but avoid rawhide because it's to dangerous. > [...] Cu knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
drago01 wrote: > On Fri, Jun 5, 2009 at 9:55 AM, Christof Damian wrote: >> On Fri, Jun 5, 2009 at 09:48, Jaroslav Reznik wrote: >>> Mostly it depends on YouTube - it's 90% of all Flash content for me. So if >>> YouTube (and p0rn variants :D) adopts tag, battle is nearly won. For >>> games - with JS is nice way. But it's missing IDE as Adobe has - my >>> roommate is using some and I have to admit - it's really great tool - if you >>> are more designer than coder. For now - we have technology, now we need >>> tools. >> youtube is testing html5 too: http://www.youtube.com/html5 >> >> as my flash on fedora10 x86_64 is crashing all the time at the moment >> I am really looking forward to this. >> >> I have some other useful flash usages too, for example the open flash >> chart: http://teethgrinder.co.uk/open-flash-chart-2/ , which is used >> by quite a bit of sites. Some google sites, like analytics and finance >> also use flash. > > Can be done with js + svg or js + canvas the only thing that holds > this technologies back is one browser that does not support them at > all but has a significant market share. (MSIE) > Enter silverlight :( --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Mon, 2009-06-08 at 15:45 +0200, Nicolas Mailhot wrote: > Le lundi 08 juin 2009 à 09:34 -0400, Matthias Clasen a écrit : > > On Mon, 2009-06-08 at 13:25 +0200, Nicolas Mailhot wrote: > > > > > I personally think it would be a huge mistake to have stuff happen > > > automatically based on filename/location heuristics. Naming collisions > > > happen all the time (for example GNOME recently decided that a third of > > > our fonts were "ODF templates" and good luck trying to find someone > > > ready to acknowledge it's a problem). > > > > Did you file a bug against shared-mime-info ? I don't recall seeing one > > go by... > > I filed > > http://bugzilla.redhat.com/show_bug.cgi?id=491598 > http://bugzilla.gnome.org/show_bug.cgi?id=576360 > http://bugs.freedesktop.org/show_bug.cgi?id=20854 > > at which point I decided to give up on the bugzilla NOTOURBUG ping pong > game. > Don't give up so easily...I've reopened the right bug and recommended a fix. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
libblkid and BuildRequires: e2fsprogs-devel
The libblkid has been moved from e2fsprogs to util-linux-ng. Please, check your spec files and update BuildRequires: - BuildRequires: e2fsprogs-devel + BuildRequires: libblkid-devel if the package depends on liblkid. Karel -- Karel Zak -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Le lundi 08 juin 2009 à 09:34 -0400, Matthias Clasen a écrit : > On Mon, 2009-06-08 at 13:25 +0200, Nicolas Mailhot wrote: > > > I personally think it would be a huge mistake to have stuff happen > > automatically based on filename/location heuristics. Naming collisions > > happen all the time (for example GNOME recently decided that a third of > > our fonts were "ODF templates" and good luck trying to find someone > > ready to acknowledge it's a problem). > > Did you file a bug against shared-mime-info ? I don't recall seeing one > go by... I filed http://bugzilla.redhat.com/show_bug.cgi?id=491598 http://bugzilla.gnome.org/show_bug.cgi?id=576360 http://bugs.freedesktop.org/show_bug.cgi?id=20854 at which point I decided to give up on the bugzilla NOTOURBUG ping pong game. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Mon, 2009-06-08 at 13:25 +0200, Nicolas Mailhot wrote: > I personally think it would be a huge mistake to have stuff happen > automatically based on filename/location heuristics. Naming collisions > happen all the time (for example GNOME recently decided that a third of > our fonts were "ODF templates" and good luck trying to find someone > ready to acknowledge it's a problem). Did you file a bug against shared-mime-info ? I don't recall seeing one go by... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
Kevin Fenzi said the following on 06/05/2009 10:51 AM Pacific Time: We are trying out a meeting irc bot plugin to handle meetings in a more consisent and timely manner. You can find a copy of the meeting output at: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html We would appreciate feedback on this format for meeting logs. If this format is acceptable, I would like to see all irc meetings use it, and have them all transfer to a common location with search ability. If not, we will come up with something better. kevin A small nit, but something I find really helpful reading the logs, is giving each person a different color. John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More mock problems
Kevin Kofler writes: > You need these: http://infrastructure.fedoraproject.org/builder-rpms/ and > python-hashlib from EPEL. These won't install cleanly on an existing CentOS 5.3 builder, net-snmp is older than the one in CentOS updates. [r...@builder1 ~]# rpm -q rpm net-snmp rpm-4.4.2.3-9.el5 net-snmp-5.3.2.2-5.el5 [r...@builder1 ~]# yum install rpm Loaded plugins: fastestmirror, priorities, versionlock Loading mirror speeds from cached hostfile Reading version lock configuration Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check --> Processing Dependency: rpm = 4.4.2.3-9.el5 for package: rpm-python --> Processing Dependency: rpm = 4.4.2.3-9.el5 for package: rpm-build --> Processing Dependency: rpm = 4.4.2.3-9.el5 for package: rpm-libs ---> Package rpm.x86_64 0:4.6.0-4.0.mitr.1.el5 set to be updated --> Processing Dependency: liblua-5.1.so()(64bit) for package: rpm --> Running transaction check ---> Package lua.x86_64 0:5.1.2-1.el5 set to be updated ---> Package rpm-python.x86_64 0:4.6.0-4.0.mitr.1.el5 set to be updated ---> Package rpm-libs.x86_64 0:4.6.0-4.0.mitr.1.el5 set to be updated ---> Package rpm-build.x86_64 0:4.6.0-4.0.mitr.1.el5 set to be updated --> Processing Dependency: librpm-4.4.so()(64bit) for package: net-snmp --> Processing Dependency: librpmio-4.4.so()(64bit) for package: net-snmp --> Running transaction check ---> Package net-snmp.x86_64 1:5.3.2.2-5.el5_3.1 set to be updated --> Processing Dependency: net-snmp-libs = 1:5.3.2.2-5.el5_3.1 for package: net-snmp --> Processing Dependency: librpm-4.4.so()(64bit) for package: net-snmp --> Processing Dependency: librpmio-4.4.so()(64bit) for package: net-snmp --> Running transaction check ---> Package net-snmp-libs.x86_64 1:5.3.2.2-5.el5_3.1 set to be updated --> Processing Dependency: librpm-4.4.so()(64bit) for package: net-snmp --> Processing Dependency: librpmio-4.4.so()(64bit) for package: net-snmp --> Finished Dependency Resolution 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from update has depsolving problems --> Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (update) 1:net-snmp-5.3.2.2-5.el5.x86_64 from installed has depsolving problems --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (update) 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 from update has depsolving problems --> Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (update) Error: Missing Dependency: librpmio-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (update) Error: Missing Dependency: librpm-4.4.so()(64bit) is needed by package 1:net-snmp-5.3.2.2-5.el5_3.1.x86_64 (update) -- Arnaud -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Le dimanche 07 juin 2009 à 12:31 +0300, Panu Matilainen a écrit : > Btw your initial suggestion of collecting the common stuff into macros > and converting packages to use them would be useful on several ways: > a) Finding out the things that *are* common among lots of packages. While > numerous cases are well and widely known already, I suspect there might > be some that are only specific groups know about (possibly eg java > related packages, I dunno). > b) Making the usages of the common patterns easy to spot by grepping. > c) The transition period cruft can be hidden inside the common macros > without polluting every spec with it. Won't work IMHO. One characteristic of pre-macroized specs is that their authors have found lots of "interesting" ways to do about the same thing with different instructions (usually missing some problems). If you don't want this old processing to collide and interfere with your new shiny processing you need the call to the new processing to be explicit, so packagers can check for problems before enabling it. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Le samedi 06 juin 2009 à 13:01 +0300, Panu Matilainen a écrit :
> Yes, having each and every spec carry the %{!?foo:¤%&¤%} macro goo makes
> no sense at all.
That is pretty much what we did for fonts in F11. However many packagers
just ignored the change and didn't fix their packages.
> >>> For instance, if a file gets dropped under /usr/share/icons/something
> >>> rpm should run gtk-update-icon-cache /usr/share/icons/something
> >>> automatically.
> >>>
> >>> the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
> >>> that makes that happen. likewise, desktop-file-utils should be able
> >>> to drop a file there to make update-desktop-database get run and so
> >>> on.
> >>>
> >>> I don't know how hard it would be to fix rpm to allow for that though.
>
> The hardest part is getting the design right the first time, there's no
> changing an "api" that is exposed to packages.
I personally think it would be a huge mistake to have stuff happen
automatically based on filename/location heuristics. Naming collisions
happen all the time (for example GNOME recently decided that a third of
our fonts were "ODF templates" and good luck trying to find someone
ready to acknowledge it's a problem). I'd much prefer if the packager
was left in control and specified the processing himself, for example by
allowing more magic %doc-like words in %files.
In my ideal pony-land, we could have stuff like
%files somepackage
%font somefont.ttf
%icon-dir somedirectory
...
that injected the correct logic in %install/%pre/%post/%postun/%
posttrans etc
And I suppose some of those magic words would work on files already
installed, others on files in the build root (like %doc), and you'd need
them to interact (for example, consolidate three %font lines in a
package in a single actions, have the %font word be aware of the %
fontconfig word so one could correct font file processing with explicit
fontconfig rules, etc)
--
Nicolas Mailhot
signature.asc
Description: Ceci est une partie de message numériquement signée
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
On Fri, Jun 5, 2009 at 4:43 PM, Mathieu Bridon (bochecha) wrote: > 1. user chooses a language in GDM for the first time > 2. PK tries to install the -support group We need to come up with a system that isn't based on Fedora, as ubuntu might call this something different. In fedora we might install a group, in ubuntu they might install a metapackage. We can't have fedora'isms in upstream PackageKit. > 3. if this group exist and some packages could be installed (i.e. not > already installed), the user is presented a nice PK popup, just like > the font or codec install suggestion, but for the support of his > language Seems a sane idea, it just needs someone to implement it in gnome-packagekit. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-f12 buildroot broken due to conflicting /%{_lib}/libblkid.so.1 versions
On Mon, Jun 08, 2009 at 11:37:15AM +0200, Karel Zak wrote: > On Mon, Jun 08, 2009 at 10:08:23AM +0100, Paul Howarth wrote: > > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1398761 > > > > ... > > Transaction Check Error: > > DEBUG util.py:256:file /lib64/libblkid.so.1 conflicts between > > attempted installs of e2fsprogs-libs-1.41.6-1.fc12.x86_64 and > > libblkid-2.15.1-0.1.fc12.x86_64 > > > > > > I guess one of these packages needs fixing but something will have to be > > untagged before that can be done. Fixed. util-linux-ng-2.15.1-0.1.fc12 untagged from dist-f12 > I'm moving libblkid from e2fsprogs to util-linux-ng right now. It's > expected problem and should be fixed after e2fsprogs rebuild. Hmm... that's problem. There is still huge number of packages that depend on e2fsprogs-libs :-( Karel -- Karel Zak -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-f12 buildroot broken due to conflicting /%{_lib}/libblkid.so.1 versions
Karel Zak wrote, at 06/08/2009 06:37 PM +9:00: On Mon, Jun 08, 2009 at 10:08:23AM +0100, Paul Howarth wrote: Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1398761 ... Transaction Check Error: DEBUG util.py:256:file /lib64/libblkid.so.1 conflicts between attempted installs of e2fsprogs-libs-1.41.6-1.fc12.x86_64 and libblkid-2.15.1-0.1.fc12.x86_64 I guess one of these packages needs fixing but something will have to be untagged before that can be done. I'm moving libblkid from e2fsprogs to util-linux-ng right now. It's expected problem and should be fixed after e2fsprogs rebuild. Karel The problem is that now it is failing on creating minimum buildroot (i.e. you cannot rebuild modified e2fsprogs unless new util-linux-ng is untagged) Mamoru -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-f12 buildroot broken due to conflicting /%{_lib}/libblkid.so.1 versions
On Mon, Jun 08, 2009 at 10:08:23AM +0100, Paul Howarth wrote: > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1398761 > > ... > Transaction Check Error: > DEBUG util.py:256:file /lib64/libblkid.so.1 conflicts between > attempted installs of e2fsprogs-libs-1.41.6-1.fc12.x86_64 and > libblkid-2.15.1-0.1.fc12.x86_64 > > > I guess one of these packages needs fixing but something will have to be > untagged before that can be done. I'm moving libblkid from e2fsprogs to util-linux-ng right now. It's expected problem and should be fixed after e2fsprogs rebuild. Karel -- Karel Zak -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-f12 buildroot broken due to conflicting /%{_lib}/libblkid.so.1 versions
Paul Howarth wrote, at 06/08/2009 06:08 PM +9:00: Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1398761 ... Transaction Check Error: DEBUG util.py:256:file /lib64/libblkid.so.1 conflicts between attempted installs of e2fsprogs-libs-1.41.6-1.fc12.x86_64 and libblkid-2.15.1-0.1.fc12.x86_64 I guess one of these packages needs fixing but something will have to be untagged before that can be done. Paul. Actually all dist-f12 builds are now failing. util-linux-ng-2.15.1-0.1.fc12 should be untagged for now, I guess. Mamoru -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dist-f12 buildroot broken due to conflicting /%{_lib}/libblkid.so.1 versions
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1398761 ... Transaction Check Error: DEBUG util.py:256:file /lib64/libblkid.so.1 conflicts between attempted installs of e2fsprogs-libs-1.41.6-1.fc12.x86_64 and libblkid-2.15.1-0.1.fc12.x86_64 I guess one of these packages needs fixing but something will have to be untagged before that can be done. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Looking for a ucspi-ipc style tool in Fedora
In my neverending quest for the School Server, I am looking for a 'unix socket superserver', something akin to xinetd listening on oldstyle unix sockets. Connecting to the right socket triggers the superserver to spawn a (potentially memory-heavy, privileged) process to handle the connection, with the superserver handling rate limiting, etc. xinetd doesn't seem to know how to do this at all. ucspi-unix and its close cousin ucspi-ipc seem to cover the requirements but are not in Fedora. Are there alternatives that I am overlooking? thanks! m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
After discussion with Ray Strode, I realized that it's difficult to find a common solution that can work across distributions since GDM is an upstream package. Thanks for the discussion Ray. To me it looks an unsolvable problem if we stick to find an upstream solution. Of course, creating a downstream patch and maintaining it for a long time would be difficult too. But, I was wondering if we can have an upstream patch like below: if (fedora) check_for_installed_language_support else if (debian) check_for_abc_things else check_xyz Is it possible? Thanks! -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Sat, 2009-06-06 at 19:01 -0400, Kyle McMartin wrote: > On Sun, Jun 07, 2009 at 12:51:02AM +0200, Lennart Poettering wrote: > > What would be good to have would be a "swap niceness" value that could > > be attached to a processes or memory regions. i.e. some way to > > influence the swapping algorithm in a less binary way than just "swap > > this" or "don't swap this". > I've been working on this along with some enhancements to make fadvise > more than utterly useless... hopefully will be ready for posting soon. Main problem is proving its utility with actual benchmarks - witness the recent first class citizen VM patch thread. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
