[faf] bug reports

What is the status of this? Is this still filing bug reports? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

On 05/23/2013 06:05 PM, Simone Caronni wrote: On 23 May 2013 17:38, James Antill mailto:ja...@fedoraproject.org>> wrote: On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote: > mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine > yum reinstall nagios --onlyfile /etc/nagios/na

Re: golang packaging guidelines

I just discussed it on packaging list. Maybe we can let everyone edit it and then summarize them up? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

golang packaging guidelines

Now that golang is packaged (https://bugzilla.redhat.com/show_bug.cgi?id=950281), we might want to have some packaging guidelines. I have never done this, does anyone want to give it a try? renich has started this but it is quite preliminary: https://fedoraproject.org/wiki/User:Renich/Go_Packagin

Re: Software Management call for RFEs

On 05/23/2013 09:34 AM, James Antill wrote: On Wed, 2013-05-22 at 16:55 -0600, Orion Poplawski wrote: I'll get more specific then: python-pyface can use two different graphics backends - either wxPython or pyQt4. In no way do these two packages provide the same thing in any meaningful way oth

Re: Software Management call for RFEs

Am 23.05.2013 20:51, schrieb Sandro Mani: > >> and apparently also not at updates and also not by "yum reinstall" >> which leaves no clean way to get rid if it and additionally >> i am not sure if "tsflags=nodocs" also avoids /usr/share/man >> and not only /usr/share/doc >> > No it does not avoi

Re: Software Management call for RFEs (tsflags=nodocs)

Am 23.05.2013 20:32, schrieb Sandro Mani: > >> Yum's tsflags=nodocs aka --excludedocs on rpm cli only applies to package >> installation. I fail to see how it >> could cause files to be left behind on erasure/update (reinstall might be a >> bit, uh, special though), but if it >> does then plea

Re: Software Management call for RFEs

Am 23.05.2013 19:48, schrieb Panu Matilainen: > On 05/23/2013 08:32 PM, Reindl Harald wrote: >> >> Am 23.05.2013 18:05, schrieb Sandro Mani: >>> or skip manpages/docfiles as default or at least >>> controlled by a option in "yum.conf" >>> >>> tsflags=nodocs in yum.conf should do the job

Re: "Size change" in rawhide report

On Thu, 23 May 2013 14:47:49 -0400 Rahul Sundaram wrote: > Hi > On Thu, May 23, 2013 at 11:15 AM, Kevin Fenzi wrote: > > > > > > > Well, I just thought it would be possibly useful if someone wanted > > to see how much things grow over time. > > > > It's going to be really hard to do that unless

Re: Software Management call for RFEs

On 23.05.2013 20:59, Panu Matilainen wrote: On 05/23/2013 09:51 PM, Sandro Mani wrote: and apparently also not at updates and also not by "yum reinstall" which leaves no clean way to get rid if it and additionally i am not sure if "tsflags=nodocs" also avoids /usr/share/man and not only /usr/

Re: Software Management call for RFEs

On 05/23/2013 09:51 PM, Sandro Mani wrote: and apparently also not at updates and also not by "yum reinstall" which leaves no clean way to get rid if it and additionally i am not sure if "tsflags=nodocs" also avoids /usr/share/man and not only /usr/share/doc No it does not avoid man, but you

Re: Software Management call for RFEs

and apparently also not at updates and also not by "yum reinstall" which leaves no clean way to get rid if it and additionally i am not sure if "tsflags=nodocs" also avoids /usr/share/man and not only /usr/share/doc No it does not avoid man, but you could mount a null-filesystem such as [1] to

Re: "Size change" in rawhide report

Hi On Thu, May 23, 2013 at 11:15 AM, Kevin Fenzi wrote: > > > Well, I just thought it would be possibly useful if someone wanted to > see how much things grow over time. > It's going to be really hard to do that unless it is plotted in some way. Rahul -- devel mailing list devel@lists.fedorapro

Re: Software Management call for RFEs

2013/5/22 Björn Persson : > Jan Zelený wrote: >> what are the changes that you would like to see in the foreseeable >> future (say 2-3 years) and why would you like to see them (what would they >> help you with)? > > Dare I say ... (puts on a helmet) ... Recommends and Suggests? > > We really shoul

Re: Software Management call for RFEs

Yum's tsflags=nodocs aka --excludedocs on rpm cli only applies to package installation. I fail to see how it could cause files to be left behind on erasure/update (reinstall might be a bit, uh, special though), but if it does then please file a bug on rpm with exact reproducer steps. -

Re: Software Management call for RFEs

On 05/23/2013 08:32 PM, Reindl Harald wrote: Am 23.05.2013 18:05, schrieb Sandro Mani: or skip manpages/docfiles as default or at least controlled by a option in "yum.conf" tsflags=nodocs in yum.conf should do the job. Though apparently, if enabled after packages already installed

Re: Software Management call for RFEs

>> No, I was not thinking of reboot/RPM changing anything already >> installed. I was referring to DB solution as static because >> it would stick one configuration forever. Instead, I was >> thinking of RPM to always base its decision on the environment >> where it is running at that point of time

Re: Software Management call for RFEs

Am 23.05.2013 18:05, schrieb Sandro Mani: > or skip manpages/docfiles as default or at least > controlled by a option in "yum.conf" > > > tsflags=nodocs in yum.conf should do the job. Though apparently, if enabled > after packages already installed files > in doc, the files in doc won'

Re: Arduino firmware permissible to include?

On Thu, May 23, 2013 at 9:25 AM, Peter Oliver < lists.fedoraproject@mavit.org.uk> wrote: > > Without access to the build scripts (which the GNU GPL2specifically says > must be included), do we even have a licence to redistribute the firmware? > > It looks like the "build scripts" are provided

Re: Software Management call for RFEs

On 23 May 2013, at 01:27, Björn Persson wrote: Adam Williamson wrote: On Thu, 2013-05-23 at 02:20 +0300, Oron Peled wrote: Thinking about it, the terminology adopted by "comps" is clearer and provides a generalization of this -- if someone select something they get: - Mandatory packages (can

Re: Software Management call for RFEs

2013-05-23 00:30, Richard W.M. Jones skrev: > On Wed, May 22, 2013 at 03:52:22PM -0600, Orion Poplawski wrote: >> Something I'm just now running into - I have a package that can make >> use of one of two different backends, but it definitely needs one of >> them. I don't want to pick which one in

Re: Software Management call for RFEs

On Thu, May 23, 2013 at 03:13:30PM +0200, Jan Zelený wrote: > On 23. 5. 2013 at 13:52:39, Simone Caronni wrote: > > I fiddle around with a new Nagios installation, then something stops > > working. I'm pretty sure it is some modifications in /etc/nagios/nagios.cfg > > but I cannot track it down. >

Re: Software Management call for RFEs

On 23 May 2013 17:38, James Antill wrote: > On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote: > > mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine > > yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg > > How is this functionally different from "yum reinstall nagios" ? > Yes, y

Re: Software Management call for RFEs

> > or skip manpages/docfiles as default or at least > controlled by a option in "yum.conf" > tsflags=nodocs in yum.conf should do the job. Though apparently, if enabled after packages already installed files in doc, the files in doc won't be removed anymore when uninstalling the package. -- deve

Call for test php-fpm 5.5.0RC2 in F19

Hi, I just build php 5.5.0RC2 in F19. A quite interesting change was introduce in this version. php-fpm now collaborate with systemd (work in type=notify) and will report about its health via "systemctl status php-fpm" giving - number of process (active + idle) - number of request (total + slow

Re: Software Management call for RFEs

> From: pmati...@laiskiainen.org > On 05/23/2013 06:09 PM, john.flor...@dart.biz wrote: > > And even though I have to give rpmbuild a tarball, I don't > > believe it ever reuses it "as is". My understanding is that the content > > gets extracted, processed and tarballed again. > > I dont know wh

Re: Software Management call for RFEs

Am 22.05.2013 20:17, schrieb Ravindra Kumar: > I don't know if this feature already exists, so forgive my > ignorance if it is already there. > > I think having an RPM equivalent of Systemd's > "ConditionVirtualization" will be very useful > for controlling packages that are intended for > virtu

Re: Software Management call for RFEs

On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote: > On 23 May 2013 13:47, Jan Zelený wrote: > > > May I ask what is the use case for this? I'm not sure why would you need to > > deal with individual files instead of the entire packages. > > > Maybe to reinstall one default config file ou

Re: Software Management call for RFEs

On Wed, 2013-05-22 at 16:55 -0600, Orion Poplawski wrote: > I'll get more specific then: > > python-pyface can use two different graphics backends - either wxPython or > pyQt4. In no way do these two packages provide the same thing in any > meaningful way other than to pyface. So, while one c

Re: Software Management call for RFEs

On 05/23/2013 06:09 PM, john.flor...@dart.biz wrote: > From: pknir...@redhat.com > On 05/23/2013 04:47 PM, Paul Flo Williams wrote: > > john.flor...@dart.biz wrote: > >>> From: Rahul Sundaram > >>> What I would like to see is > >>> solid git integration. Git has become the standard distrib

[Bug 966622] New: perl-SQL-Statement-1.404 is available

https://bugzilla.redhat.com/show_bug.cgi?id=966622 Bug ID: 966622 Summary: perl-SQL-Statement-1.404 is available Product: Fedora Version: rawhide Component: perl-SQL-Statement Keywords: FutureFeature, Triaged Severity: unspe

Re: "Size change" in rawhide report

On Thu, 23 May 2013 10:45:50 +0200 Vít Ondruch wrote: > I thought so, but if it state "SRPM size change", I would not need to > ask this question :) Indeed. This output is directly from repodiff. Feel free to suggest improvements to the yum-utils package. > BTW, is there a reason for reportin

Re: Software Management call for RFEs

On Thu, 2013-05-23 at 16:54 +0200, Phil Knirsch wrote: > But rpm could just do a git-tar-tree behind the scenes, which sounds > easy enough. It's not quite that easy, given the possible presence of git submodules. http://stackoverflow.com/questions/1591387/need-to-handle-git-submodules-in-git

Re: Software Management call for RFEs

> From: pknir...@redhat.com > On 05/23/2013 04:47 PM, Paul Flo Williams wrote: > > john.flor...@dart.biz wrote: > >>> From: Rahul Sundaram > >>> What I would like to see is > >>> solid git integration. Git has become the standard distributed vcs > >>> and github and google code etc have stopped ho

Re: Software Management call for RFEs

On 05/23/2013 04:47 PM, Paul Flo Williams wrote: john.flor...@dart.biz wrote: From: Rahul Sundaram What I would like to see is solid git integration. Git has become the standard distributed vcs and github and google code etc have stopped hosting tarballs and/or discouraging it and GNOME is plan

Re: Software Management call for RFEs

john.flor...@dart.biz wrote: >> From: Rahul Sundaram >> What I would like to see is >> solid git integration. Git has become the standard distributed vcs >> and github and google code etc have stopped hosting tarballs and/or >> discouraging it and GNOME is planning to do that as well. If Source >

Re: Software Management call for RFEs

Dne 23.5.2013 16:29, Miloslav Trmač napsal(a): On Thu, May 23, 2013 at 4:23 PM, Vít Ondruch > wrote: *It is not possible to convert the packages technically nor philosophically* You might think million times that the sentence is not truth, but that is

Re: Software Management call for RFEs

On Thu, May 23, 2013 at 04:24:01PM +0200, Florian Weimer wrote: > Some of the rationale for multiarch doesn't make much sense anymore. > For example, you can now use IFUNCs to select specialized functions > at run time and don't have to ship separate DSOs anymore. IFUNCs are indeed interesting. A

Re: Software Management call for RFEs

On 05/23/2013 03:30 PM, Stijn Hoop wrote: On Thu, 23 May 2013 14:02:34 +0200 Jan Zelený wrote: The problem is that some of these languages have fundamentally different philosophy than Fedora and unfortunatelly it's not a mix-and-match situation. That being said, there already are different to

Re: Software Management call for RFEs

On Thu, May 23, 2013 at 4:23 PM, Vít Ondruch wrote: > *It is not possible to convert the packages technically nor > philosophically* > > You might think million times that the sentence is not truth, but that is > as it is. I'll give you several examples: > > * Gems cannot express dependencies on

Re: Software Management call for RFEs

On 05/23/2013 02:58 PM, Richard W.M. Jones wrote: The reason I specifically said: On 22 May 2013 23:18, Richard W.M. Jones wrote: (10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu are doing. is that Debian and derivatives are more popular than Fedora and the Linux communi

Re: Software Management call for RFEs

Dne 23.5.2013 15:30, Stijn Hoop napsal(a): On Thu, 23 May 2013 14:02:34 +0200 Jan Zelený wrote: On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote: I would like better integration with domain-specific package managers. By which I mean npm (for node.js), gem (for ruby), pip (for python), cpan (for pe

Re: Software Management call for RFEs

AIUI it would mainly involve *removing* the big hack that is multilib from rpm. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KV

Re: Software Management call for RFEs

Hi, I'd also like support for tuple provides, to expose font font facets to the software updater. For example, a font file can provide a 'bold' variant with support for a list of locales. Right now if I ask rpm to install a bold sans-serif font for russian for example, it will happily install a

Re: Software Management call for RFEs

On 23. 5. 2013 at 15:30:55, Stijn Hoop wrote: > On Thu, 23 May 2013 14:02:34 +0200 > > Jan Zelený wrote: > > On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote: > > > I would like better integration with domain-specific package > > > managers. By which I mean npm (for node.js), gem (for ruby), pip > >

Re: Software Management call for RFEs

On Thu, May 23, 2013 at 03:29:16PM +0200, Simone Caronni wrote: > I'm not the best person to judge, but it looks overcomplicated to me. For > sure existing commercial binary packages shipped in RPM format will have a > lot of problems. For the vast majority of packages, it simply means the library

Re: Software Management call for RFEs

> From: Rahul Sundaram > What I would like to see is > solid git integration. Git has become the standard distributed vcs > and github and google code etc have stopped hosting tarballs and/or > discouraging it and GNOME is planning to do that as well. If Source > URL could point directly to a

Re: Software Management call for RFEs

Hi, I would also like solid proxy support in the software management stack. Metadata that is designed (as per the HTTP RFCS) to be cached cleanly and an updater that does not assume all repository mirrors are perfectly in sync at any given point in time Regards, -- Nicolas Mailhot -- devel m

Re: Soname bump libpng (rawhide) - new libraries libpng.16.so and libpng16.so.16.2.0

On Thu, May 23, 2013 at 15:29:07 +0200, Petr Hracek wrote: That's my misunderstanding. I thought that in side tag compat package will not be needed. All packages will be build up against new libpng package in side tag. Why compat package will be needed? Is there any reason? I think what Pet

Re: Software Management call for RFEs

Le Jeu 23 mai 2013 01:28, Ravindra Kumar a écrit : >>> Having a fake package in DB makes it very static. I think a >>> dynamic (evaluated each time rpm commands are run) implementation >>> will be more useful for the cases like P2V and V2V. > >> The problem I see here is that you can boot the same

Re: Software Management call for RFEs

Le Jeu 23 mai 2013 13:20, Panu Matilainen a écrit : > On 05/22/2013 08:22 PM, Nicolas Mailhot wrote: >> Hi, >> >> Please clean up the distaster package verification is. >> >> rpm -Va is so incomplete it spawned rpmlint, package-cleanup and not >> doubt >> others I forget about. > > There's probabl

Re: Software Management call for RFEs

On Thu, 23 May 2013 14:02:34 +0200 Jan Zelený wrote: > On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote: > > I would like better integration with domain-specific package > > managers. By which I mean npm (for node.js), gem (for ruby), pip > > (for python), cpan (for perl), pecl/pear (for PHP), CRAN (f

Re: Software Management call for RFEs

On 23 May 2013 14:58, Richard W.M. Jones wrote: > Debian (since 7?) has settled on using subdirectories of /usr/lib for > different architectures. See: > > http://wiki.debian.org/Multiarch > > It supports more than just "64 bit or not", such as different kernels, > different endianness, and diff

Re: Soname bump libpng (rawhide) - new libraries libpng.16.so and libpng16.so.16.2.0

On 05/23/2013 10:23 AM, Peter Robinson wrote: On Wed, May 22, 2013 at 7:58 PM, Adam Williamson wrote: On Wed, 2013-05-22 at 11:01 +0200, Petr Hracek wrote: The issue is that once this is in, all the 306 packages above will have broken dependencies. And it's not just simple rebuilds that are r

Re: Software Management call for RFEs

On 23. 5. 2013 at 15:25:23, Michal Schmidt wrote: > On 05/23/2013 03:10 PM, Jan Zelený wrote: > > On 23. 5. 2013 at 14:23:30, Michal Schmidt wrote: > >> On 05/23/2013 01:44 PM, Jan Zelený wrote: > >>> +1 for this, the dependency hell for 32 bit applications is really a > >>> major > >>> pain in the

Re: Software Management call for RFEs

On 05/23/2013 03:10 PM, Jan Zelený wrote: On 23. 5. 2013 at 14:23:30, Michal Schmidt wrote: On 05/23/2013 01:44 PM, Jan Zelený wrote: +1 for this, the dependency hell for 32 bit applications is really a major pain in the new versions of Ubuntu. I have dealt with that multiple times and I wasn't

Arduino firmware permissible to include?

Arduino is an electronics prototyping board, and also a GNU GPL2-licenced IDE for writing and uploading code to such boards. Fedora has packages for the IDE. Recent versions of the IDE include WiFi firmware for Arduino (http://arduino.cc/en/Main/ArduinoWiFiShield). The Arduino "source" bundle

Re: Software Management call for RFEs

On 05/23/2013 06:21 AM, Jan Zelený wrote: > On 22. 5. 2013 at 10:55:14, Michael Ekstrand wrote: >> Performance improvement: improve scaling to 5K+ installed packages. >> Since the TeXLive repackaging, my laptop several thousand packages, >> about half of which are TeX-related (I like to have a fair

Re: Software Management call for RFEs

On 23. 5. 2013 at 13:52:39, Simone Caronni wrote: > On 23 May 2013 13:47, Jan Zelený wrote: > > May I ask what is the use case for this? I'm not sure why would you need > > to > > deal with individual files instead of the entire packages. > > Maybe to reinstall one default config file out of a pa

Re: Software Management call for RFEs

On 23. 5. 2013 at 14:23:30, Michal Schmidt wrote: > On 05/23/2013 01:44 PM, Jan Zelený wrote: > > +1 for this, the dependency hell for 32 bit applications is really a major > > pain in the new versions of Ubuntu. I have dealt with that multiple times > > and I wasn't able to resolve all the problem

F-19 Branched report: 20130523 changes

Compose started at Thu May 23 09:15:02 UTC 2013 Broken deps for x86_64 -- [byzanz] byzanz-0.3-0.5.fc17.x86_64 requires libpanel-applet-4.so.0()(64bit) [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubyge

Re: Software Management call for RFEs

On Thu, May 23, 2013 at 01:33:37PM +0200, Simone Caronni wrote: > might I ask the reasoning behind this? I found the current RHEL/Fedora > approach much better. Debian (since 7?) has settled on using subdirectories of /usr/lib for different architectures. See: http://wiki.debian.org/Multiarch I

rawhide report: 20130523 changes

Compose started at Thu May 23 08:15:03 UTC 2013 Broken deps for x86_64 -- [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [good

Re: Software Management call for RFEs

On 05/23/2013 01:44 PM, Jan Zelený wrote: +1 for this, the dependency hell for 32 bit applications is really a major pain in the new versions of Ubuntu. I have dealt with that multiple times and I wasn't able to resolve all the problems (e.g. Google Earth still doesn't work on Ubuntu for me) Is

Re: Software Management call for RFEs

On 05/23/2013 01:33 PM, Simone Caronni wrote: On 22 May 2013 23:18, Richard W.M. Jones wrote: (10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu are doing. might I ask the reasoning behind this? I found the current RHEL/Fedora approach much better. For example; at wo

Re: Software Management call for RFEs

On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote: > Hi, > > I would like better integration with domain-specific package managers. > By which I mean npm (for node.js), gem (for ruby), pip (for python), > cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and > many more I'm sure. The

Re: Software Management call for RFEs

On 23 May 2013 13:44, Jan Zelený wrote: > +1 for this, the dependency hell for 32 bit applications is really a major > pain in the new versions of Ubuntu. I have dealt with that multiple times > and > I wasn't able to resolve all the problems (e.g. Google Earth still doesn't > work on Ubuntu for

Re: Software Management call for RFEs

On 23 May 2013 13:47, Jan Zelený wrote: > May I ask what is the use case for this? I'm not sure why would you need to > deal with individual files instead of the entire packages. Maybe to reinstall one default config file out of a package that contains some? I found it useful. Example: I fiddl

Re: Software Management call for RFEs

On 22. 5. 2013 at 16:55:50, Orion Poplawski wrote: > On 05/22/2013 04:44 PM, Adam Williamson wrote: > > On Wed, 2013-05-22 at 23:30 +0100, Richard W.M. Jones wrote: > >> different set of dependent packages, leading to some sort of > >> combinatorial explosion of QA. > > > > Right now we have appro

Re: Software Management call for RFEs

May I ask what is the use case for this? I'm not sure why would you need to deal with individual files instead of the entire packages. Thanks Jan On 23. 5. 2013 at 08:07:21, Dan Fruehauf wrote: > Reverting changes to files handled by RPM (or installing a single file out > of the package), for in

Re: Software Management call for RFEs

On 23. 5. 2013 at 13:33:37, Simone Caronni wrote: > Hello, > > On 22 May 2013 23:18, Richard W.M. Jones wrote: > > (10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu > > are doing. > > might I ask the reasoning behind this? I found the current RHEL/Fedora > approach much better

Re: Software Management call for RFEs

On 22. 5. 2013 at 17:08:33, Rahul Sundaram wrote: > Hi > > On Wed, May 22, 2013 at 9:43 AM, Jan Zelený wrote: > > We acknowledge the need for some changes in Software Management stack in > > Fedora but we don't want to make changes just by guessing what our > > users want. Therefore I call to you,

Re: Software Management call for RFEs

Since you have already sent the email, all those requests that make sense are in one way or another on the list of RFEs I referred to. If you are missing something there, feel free to let me know. Thanks Jan On 22. 5. 2013 at 22:18:58, Richard W.M. Jones wrote: > [This is a copy of an email I s

Re: Software Management call for RFEs

Hello, On 22 May 2013 23:18, Richard W.M. Jones wrote: > (10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu > are doing. > might I ask the reasoning behind this? I found the current RHEL/Fedora approach much better. For example; at work we use IBM Lotus Notes, which is a 32 b

Re: Software Management call for RFEs

On 22. 5. 2013 at 21:06:53, Björn Persson wrote: > Jan Zelený wrote: > > what are the changes that you would like to see in the foreseeable > > future (say 2-3 years) and why would you like to see them (what would they > > help you with)? > > Dare I say ... (puts on a helmet) ... Recommends and Su

Re: Software Management call for RFEs

On 22. 5. 2013 at 11:17:16, Ravindra Kumar wrote: > I don't know if this feature already exists, so forgive my > ignorance if it is already there. > > I think having an RPM equivalent of Systemd's > "ConditionVirtualization" will be very useful > for controlling packages that are intended for > vi

Re: Software Management call for RFEs

On 22. 5. 2013 at 10:55:14, Michael Ekstrand wrote: > Performance improvement: improve scaling to 5K+ installed packages. > Since the TeXLive repackaging, my laptop several thousand packages, > about half of which are TeX-related (I like to have a fairly full TeX > install with all the docs). Ther

Re: Software Management call for RFEs

On 05/22/2013 08:22 PM, Nicolas Mailhot wrote: Hi, Please clean up the distaster package verification is. rpm -Va is so incomplete it spawned rpmlint, package-cleanup and not doubt others I forget about. There's probably some overlap in what those utilities do but generally I see them as add

Re: Software Management call for RFEs

On 22. 5. 2013 at 12:47:58, Paulo César Pereira de Andrade wrote: > 2013/5/22 Jan Zelený : > > Dear Fedora community, > > several months ago, at the Developer conference in Brno, Software > > Management team received a whole bunch of proposals for new functionality > > in RPM and related software s

Re: Software Management call for RFEs

On 22. 5. 2013 at 08:38:35, John Reiser wrote: > > Therefore I call to you, consumers of our products (dnf, yum and > > rpm): what are the changes that you would like to see in the foreseeable > > future (say 2-3 years) and why would you like to see them (what would they > > help you with)? > > Fe

Re: Software Management call for RFEs

On 22. 5. 2013 at 23:16:16, Christopher Meng wrote: > What about speeding up the yum running? > > It's a bit slow now. Have you tried using dnf instead of yum? It is much faster. To be perfectly honest we don't plan to invest much effort in developing new things for yum, it will more and more s

Re: "Provides: icon-theme" for *-icon-theme packages

23.05.2013 14:20, Adam Williamson: On Thu, 2013-05-23 at 13:55 +0400, Eugene Pivnev wrote: 16.05.2013 01:26, Orion Poplawski: On 05/15/2013 01:07 PM, Eugene Pivnev wrote: 13.05.2013 19:30, Eugene Pivnev пишет: Subj. For packages that requies _any_ icon theme (something like oxygen provides sy

Re: "Provides: icon-theme" for *-icon-theme packages

On Thu, 2013-05-23 at 13:55 +0400, Eugene Pivnev wrote: > 16.05.2013 01:26, Orion Poplawski: > > On 05/15/2013 01:07 PM, Eugene Pivnev wrote: > >> 13.05.2013 19:30, Eugene Pivnev пишет: > >>> Subj. > >>> For packages that requies _any_ icon theme (something like oxygen > >>> provides > >>> system-

About volatile udev directory

Hi folks, I've found the following in Fedora 18 [root@mpinode02 sergio]# LANG=C ls /run/udev/rules.d ls: cannot access /run/udev/rules.d: No such file or directory I haven't found anything in the changelog about a change about it, is there no more that directory ? Thanks in advance! -- -- Ser

Re: Software Management call for RFEs

On 05/22/2013 11:18 PM, Richard W.M. Jones wrote: (5) Almost all %pre/%post scripts need to be eliminated. There's no reason that RPM can't detect when a shared library is being installed. I'd like to see this for the configuration of the source tree during the build process (up to and inclu

[heads up] Abiword

Hi: While fixing sugar-write[1] I needed to update Abiword/libabiword to recent versions[2]. I made this using a bunch of patches from SugarLabs, with special interests in the gtk3 and instrospection ones. I've made an experimental build[3] which looks promising but would like others give it a tr

Re: Hardcoded TMPDIR - anywhere else?

On Thu, 23 May 2013 03:00:51 -0400, DJ Delorie wrote: > > > ## Use $MOZ_TMPDIR if set. Otherwise use /var/tmp instead of /tmp > > ## because of 1GB /tmp limit in Fedora 18 and later. > > > > It is insane to hardcode /var/tmp. > > Considering the comment, they probably think it's insane to pu

Re: Software Management call for RFEs

Hi, I would like better integration with domain-specific package managers. By which I mean npm (for node.js), gem (for ruby), pip (for python), cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and many more I'm sure. By integrating RPM with these package managers, I feel it wou

Re: "Size change" in rawhide report

Dne 22.5.2013 15:52, Kevin Fenzi napsal(a): On Wed, 22 May 2013 14:29:00 +0200 Vít Ondruch wrote: Dne 22.5.2013 14:20, Fedora Rawhide Report napsal(a): ruby-2.0.0.195-8.fc20 - * Fri May 17 2013 Vít Ondruch - 2.0.0.195-8 - Update to Ruby 2.0.0-p195 (rhbz#917374). - Fix obj

Re: Soname bump libpng (rawhide) - new libraries libpng.16.so and libpng16.so.16.2.0

On Wed, May 22, 2013 at 7:58 PM, Adam Williamson wrote: > On Wed, 2013-05-22 at 11:01 +0200, Petr Hracek wrote: > >> >> The issue is that once this is in, all the 306 packages above will have >> >> broken dependencies. And it's not just simple rebuilds that are >> >> required; we'd need _ordered_

Re: Hardcoded TMPDIR - anywhere else?

> Doesn't Firefox download in $XDG_DOWNLOAD_DIR by default these days? Depends on user's choice in download-dialog: * open with %{app} ---> download goes to the defined %{temp}-location and launches %{app} with downloaded file. * save ---> download goes to ${XDG_

Re: Hardcoded TMPDIR - anywhere else?

On Thu, 2013-05-23 at 03:00 -0400, DJ Delorie wrote: > > ## Use $MOZ_TMPDIR if set. Otherwise use /var/tmp instead of /tmp > > ## because of 1GB /tmp limit in Fedora 18 and later. > > > > It is insane to hardcode /var/tmp. > > Considering the comment, they probably think it's insane to put /tm

Re: Hardcoded TMPDIR - anywhere else?

> ## Use $MOZ_TMPDIR if set. Otherwise use /var/tmp instead of /tmp > ## because of 1GB /tmp limit in Fedora 18 and later. > > It is insane to hardcode /var/tmp. Considering the comment, they probably think it's insane to put /tmp in RAM, and since web browsers are often used to download huge