Re: Software management: Call for RFEs results!

Vít Ondruch wrote: > It is interesting to see such response from somebody who appears to be > maintainer of Qt. Don't we ship 3 parallel installable version of Qt? We indeed ship major (first digit!) versions of Qt as parallel-installable versions. They are for all practical purposes different li

Re: Software management: Call for RFEs results!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/16/2013 07:15 PM, Kevin Kofler wrote: > Vít Ondruch wrote: >> Sorry, this has nothing to do with FPC yet. RPM/YUM/DNF should >> first provide reasonable support. For example this issue [1] >> could take us closer as a first approximation. >> >>

Re: Software management: Call for RFEs results!

Dne 17.10.2013 10:05, Jiri Moskovcak napsal(a): On 10/17/2013 09:15 AM, Vít Ondruch wrote: To be honest, the Kernel is the last package, which should be paraller installable, since you can run just one kernel at time. Yeah, admins will love that, when after updating the kernel the machine w

Re: Software management: Call for RFEs results!

On 10/17/2013 09:15 AM, Vít Ondruch wrote: Dne 17.10.2013 01:15, Kevin Kofler napsal(a): Vít Ondruch wrote: Sorry, this has nothing to do with FPC yet. RPM/YUM/DNF should first provide reasonable support. For example this issue [1] could take us closer as a first approximation. Vít [1] https

Re: Software management: Call for RFEs results!

Dne 17.10.2013 01:15, Kevin Kofler napsal(a): Vít Ondruch wrote: Sorry, this has nothing to do with FPC yet. RPM/YUM/DNF should first provide reasonable support. For example this issue [1] could take us closer as a first approximation. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=84524

Re: Software management: Call for RFEs results!

Vít Ondruch wrote: > Sorry, this has nothing to do with FPC yet. RPM/YUM/DNF should first > provide reasonable support. For example this issue [1] could take us > closer as a first approximation. > > Vít > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=845247 Parallel-installing multiple v

Re: Software management: Call for RFEs results!

Tom Hughes wrote: > That hasn't stopped us saying that they don't provide a good experience > to Fedora users however, and that it is better to repackage things as > RPMs so that our users only have to deal with a single interface to > installing and updating packages and that they will get a set o

Re: Software management: Call for RFEs results!

On Wed, Oct 16, 2013 at 10:04 AM, Jan Zelený wrote: > Ok then, talk to FPC about this. Personally I'd be against creating the wild > west from Fedora itself and I'd rather like to have have it in COPRs. Fedora > should keep its high standard of Software packaging (which usually doesn't > apply for

Re: Software management: Call for RFEs results!

On 16/10/13 13:57, Matthew Miller wrote: We have a mantra of "upstream! upstream! upstream!" for software development and patches. In the olden days, we didn't do that for packaging, because there was no consistent upstream packaging at all (just the occasional upstream shipping terrible distro-

Re: Software management: Call for RFEs results!

On Wed, Oct 16, 2013 at 10:04:55AM +0200, Jan Zelený wrote: > > I won't speak for Michael, but I think the answer is no. COPRs fills a > > need, but it's _too_ wild west (no package signatures, for example). We > > need to support multiple language runtimes and native upstream packaging > > *in* Fe

Re: Software management: Call for RFEs results!

On 16. 10. 2013 at 10:46:01, Vít Ondruch wrote: > Dne 16.10.2013 10:04, Jan Zelený napsal(a): > > On 15. 10. 2013 at 09:40:41, Matthew Miller wrote: > >> On Tue, Oct 15, 2013 at 01:15:26PM +0200, Jan Zelený wrote: > >>> Not to be only negative here, take a look at the COPR initiative, I > >>> expec

Re: Software management: Call for RFEs results!

Dne 16.10.2013 10:04, Jan Zelený napsal(a): On 15. 10. 2013 at 09:40:41, Matthew Miller wrote: On Tue, Oct 15, 2013 at 01:15:26PM +0200, Jan Zelený wrote: Not to be only negative here, take a look at the COPR initiative, I expect it will solve the problem you are talking about by offering exter

Re: Software management: Call for RFEs results!

On 15. 10. 2013 at 09:40:41, Matthew Miller wrote: > On Tue, Oct 15, 2013 at 01:15:26PM +0200, Jan Zelený wrote: > > Not to be only negative here, take a look at the COPR initiative, I expect > > it will solve the problem you are talking about by offering external > > repositories that will be easi

Re: Software management: Call for RFEs results!

On Tue, Oct 15, 2013 at 01:15:26PM +0200, Jan Zelený wrote: > Not to be only negative here, take a look at the COPR initiative, I expect > it will solve the problem you are talking about by offering external > repositories that will be easily reachable from Fedora but won't be a part > of the Fedor

Re: Software management: Call for RFEs results!

On 13. 10. 2013 at 22:19:16, Michael Stahnke wrote: > On Fri, Oct 4, 2013 at 5:34 AM, Jan Zelený wrote: > > Hello everyone, > > as you might remember I issued a call for RFEs on this list during the > > spring. The participation was not bad at all, we have collected so many > > data that it took u

Re: Software management: Call for RFEs results!

On 13. 10. 2013 at 03:05:20, Alek Paunov wrote: > On 04.10.2013 15:34, Jan Zelený wrote: > > If you have any other questions, comments or notes regarding the document, > > feel free to to use this list for the discussion. > > Where (list threads, wikis, sources) one should seek more details about

Re: Software management: Call for RFEs results!

On Mon, Oct 14, 2013 at 6:46 AM, Matthew Miller wrote: > On Sun, Oct 13, 2013 at 10:19:16PM -0700, Michael Stahnke wrote: >> Developers don't do deployments with RPM...at least not inside Fedora. >> Anything sane is actually against Packaging Guidelines. So that >> becomes a problem, and developer

Re: Software management: Call for RFEs results!

On 10/14/2013 05:19 AM, Michael Stahnke wrote: On Fri, Oct 4, 2013 at 5:34 AM, Jan Zelený wrote: Hello everyone, as you might remember I issued a call for RFEs on this list during the spring. The participation was not bad at all, we have collected so many data that it took us several months to

Re: Software management: Call for RFEs results!

On Sun, Oct 13, 2013 at 10:19:16PM -0700, Michael Stahnke wrote: > Developers don't do deployments with RPM...at least not inside Fedora. > Anything sane is actually against Packaging Guidelines. So that > becomes a problem, and developers skip it. If developers (or Can you elaborate on "anything

Re: Software management: Call for RFEs results!

On Fri, Oct 4, 2013 at 5:34 AM, Jan Zelený wrote: > Hello everyone, > as you might remember I issued a call for RFEs on this list during the spring. > The participation was not bad at all, we have collected so many data that it > took us several months to discuss and process it. > > Now I have som

Re: Software management: Call for RFEs results!

On 04.10.2013 15:34, Jan Zelený wrote: If you have any other questions, comments or notes regarding the document, feel free to to use this list for the discussion. Where (list threads, wikis, sources) one should seek more details about the DB aspects of the plan, e.g.: * A1: Delta metadat

Re: Software Management call for RFEs

On Wed, May 22, 2013 at 03:43:32PM +0200, Jan Zelený wrote: > Please send your requests as replies to this email so they can be properly > discussed. I know I'm a little slow on this, and I hope I didn't miss a duplicate in the big thread, but here's mine: Better handling of documentation and l

Re: Software Management call for RFEs

On Sun, Jun 02, 2013 at 02:43:15PM +0200, enclair wrote: > I'd like a tool similar to portaudit in FreeBSD or debscan in Debian. This > tool should list all packages which have a security issue. Currently there > is yum-security-plugin but it lists packages only if an update is > available. The new

Re: Software Management call for RFEs

On 06/02/2013 02:43 PM, enclair wrote: I'd like a tool similar to portaudit in FreeBSD or debscan in Debian. This tool should list all packages which have a security issue. I don't know about portaudit, but debsecan works completely out of the usual software management stack. Part of the reas

Re: Software Management call for RFEs

On 2. 6. 2013 at 14:43:15, enclair wrote: > I'd like a tool similar to portaudit in FreeBSD or debscan in Debian. This > tool should list all packages which have a security issue. Currently there > is yum-security-plugin but it lists packages only if an update is > available. The new tool would lis

Re: Software Management call for RFEs

I'd like a tool similar to portaudit in FreeBSD or debscan in Debian. This tool should list all packages which have a security issue. Currently there is yum-security-plugin but it lists packages only if an update is available. The new tool would list vulnerable packages even if no update is availab

Re: Software Management call for RFEs

On 05/29/2013 11:06 PM, James Antill wrote: On Wed, 2013-05-29 at 20:33 +0200, Florian Weimer wrote: I did some tests and cold cache performance tests on an old Debian installation. Performance with cold caches is more than adequate. Full-text searches take about two seconds. Package installa

Re: Software Management call for RFEs

On Wed, May 29, 2013 at 08:33:16PM +0200, Florian Weimer wrote: > Users sometimes misdiagnose issues, *especially* when complaining. 8-) > > I did some tests and cold cache performance tests on an old Debian > installation. Performance with cold caches is more than adequate. > Full-text searches

Re: Software Management call for RFEs

Am 30.05.2013 16:13, schrieb Bill Nottingham: > drago01 (drag...@gmail.com) said: >> How about improving delta rpm performance? Currently we save download >> time but require a lot of time to rebuild the rpms. >> Can we just sign the deltas and then don't compress the generated >> rpms? We waste

Re: Software Management call for RFEs

On Thu, May 30, 2013 at 4:13 PM, Bill Nottingham wrote: > drago01 (drag...@gmail.com) said: >> How about improving delta rpm performance? Currently we save download >> time but require a lot of time to rebuild the rpms. >> Can we just sign the deltas and then don't compress the generated >> rpms?

Re: Software Management call for RFEs

drago01 (drag...@gmail.com) said: > How about improving delta rpm performance? Currently we save download > time but require a lot of time to rebuild the rpms. > Can we just sign the deltas and then don't compress the generated > rpms? We waste time and cycles building xz > compressed rpms (from t

Re: Software Management call for RFEs

On Wed, May 22, 2013 at 3:43 PM, Jan Zelený wrote: > 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 stack. > > We acknowledge the need for some chan

Re: Software Management call for RFEs

On Tue, 2013-05-28 at 14:18 -0400, seth vidal wrote: > > * Why the sql schema is so denormalized (IMO, leads to both > > bandwidth and disk overspending without speed benefits)?. For > > example: Why provides and requires tables do not use the common > > domain table? > > B/c it was designed 8y

Re: Software Management call for RFEs

On Wed, 2013-05-29 at 20:33 +0200, Florian Weimer wrote: > I did some tests and cold cache performance tests on an old Debian > installation. Performance with cold caches is more than adequate. > Full-text searches take about two seconds. Package installation reaches > the confirmation prompt

Re: Software Management call for RFEs

On 05/27/2013 10:24 AM, Jan Zelený wrote: As far as I can tell, the main difference is that apt-get and apt-cache read very few, relatively large files at the beginning, so they don't block on disk reads early. dpkg, on the other hand, uses a database scatter across many small files on disk, so

Re: Software Management call for RFEs

On Wed, 29 May 2013 11:48:14 +0100 "Richard W.M. Jones" wrote: > On Tue, May 28, 2013 at 11:51:21AM -0400, seth vidal wrote: > > I simply got tired of tilting at that particular windmill when > > confronted with some particularly egregious cases (see libguestfs > > sometime). > > $ rpm -qR libgu

Re: Software Management call for RFEs

On Wed, 29 May 2013 11:52:04 +0100 "Richard W.M. Jones" wrote: > > Also do we know how many mirrors support byte ranges? > > We could go all the way and have a relatively large uncompressed > database stored on the mirrors, but have the client only access small > byte ranges from it. > We use

Re: Software Management call for RFEs

Also do we know how many mirrors support byte ranges? We could go all the way and have a relatively large uncompressed database stored on the mirrors, but have the client only access small byte ranges from it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjon

Re: Software Management call for RFEs

On Tue, May 28, 2013 at 11:51:21AM -0400, seth vidal wrote: > I simply got tired of tilting at that particular windmill when > confronted with some particularly egregious cases (see libguestfs > sometime). $ rpm -qR libguestfs|grep ^/ /sbin/ldconfig /sbin/ldconfig /lib64/rtkaio/librt.so.1 /usr/lib

Re: Software Management call for RFEs

On 28.05.2013 21:18, seth vidal wrote: On Tue, 28 May 2013 20:42:13 +0300 Alek Paunov wrote: So, it seems that yum already have the "filelists on demand" optimization implemented. Why you are asking for removing a feature, which do not make the things worse ... ? I'm not. But when you downlo

Re: Software Management call for RFEs

Dne Út 28. května 2013 11:51:21, seth vidal napsal(a): > On Tue, 28 May 2013 08:51:03 +0200 > > Jan Zelený wrote: > > > after a "yum clean metadata && yum update" on a slow line you > > > have to wait a very long time and even the download of the > > > presto-metadata often is larger and takes lo

Re: Software Management call for RFEs

Dne Út 28. května 2013 14:59:20, Alek Paunov napsal(a): > On 28.05.2013 13:54, Jan Zelený wrote: > > On 28. 5. 2013 at 11:39:35, Alek Paunov wrote: > >> On 28.05.2013 09:51, Jan Zelený wrote: > >>> I couldn't agree more. But as I have said, we need to find the most > >>> simple > >>> and unintrusiv

Re: Software Management call for RFEs

Dne Út 28. května 2013 09:33:11, Fernando Nasser napsal(a): > This is basically the major impediment to the "uninstall" of a product that > consists of several packages. Some of these packages may be, at time of > uninstall, also required by other packages, so the "and no other package > requires

Re: Software Management call for RFEs

Dne Út 28. května 2013 10:11:55, Miroslav Suchý napsal(a): > On 05/27/2013 09:32 AM, Jan Zelený wrote: > > Unfortunately there is not much we can do about this. Debian has > > completely > > different repository policy - they keep all versions of packages in the > > repo so there is no need to upda

Re: Software Management call for RFEs

On Tue, 28 May 2013 20:42:13 +0300 Alek Paunov wrote: > > So, it seems that yum already have the "filelists on demand" > optimization implemented. Why you are asking for removing a feature, > which do not make the things worse ... ? I'm not. But when you download the filelists - it is A LOT

Re: Software Management call for RFEs

On 28.05.2013 18:51, seth vidal wrote: On Tue, 28 May 2013 08:51:03 +0200 Jan Zelený wrote: after a "yum clean metadata && yum update" on a slow line you have to wait a very long time and even the download of the presto-metadata often is larger and takes longer as the packages which are upda

Re: Software Management call for RFEs

On Tue, 2013-05-28 at 13:14 +0200, Miroslav Suchý wrote: > On 05/22/2013 03:43 PM, Jan Zelený wrote: > > Please send your requests as replies to this email so they can be properly > > discussed. > > Have equivalent of apt-get autoremove. Try "yum autoremove" in F19. -- devel mailing list devel

Re: Software Management call for RFEs

On Tue, 28 May 2013 08:51:03 +0200 Jan Zelený wrote: > > > after a "yum clean metadata && yum update" on a slow line you > > have to wait a very long time and even the download of the > > presto-metadata often is larger and takes longer as the > > packages which are updated in reality > > > > h

Re: Software Management call for RFEs

On 05/24/2013 09:20 PM, Rahul Sundaram wrote: On 05/23/2013 07:08 AM, Jan Zelený wrote: 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 shift towards maintenance mode a

Re: Software Management call for RFEs

--- Original Message - > From: "Ales Kozumplik" > To: "Development discussions related to Fedora" > > Sent: Tuesday, May 28, 2013 9:27:23 AM > Subject: Re: Software Management call for RFEs > > On 05/28/2013 01:14 PM, Miroslav Suchý wrote: > >d

Re: Software Management call for RFEs

On 05/28/2013 01:14 PM, Miroslav Suchý wrote: dnf autoremove should tell me that packages "bar" and "bra" were installed as dependencies for package, which is no more present on disk (and no other package requires them) and can be removed. There's an RFE for this already: https://bugzilla.r

Re: Software Management call for RFEs

Am 28.05.2013 13:14, schrieb Miroslav Suchý: > On 05/22/2013 03:43 PM, Jan Zelený wrote: >> Please send your requests as replies to this email so they can be properly >> discussed. > > Have equivalent of apt-get autoremove. > > I.e. If you run > yum install foo > and it will install packages

Re: Software Management call for RFEs

On 05/28/2013 06:25 AM, Mathieu Bridon wrote: > On Tue, 2013-05-28 at 13:14 +0200, Miroslav Suchý wrote: >> On 05/22/2013 03:43 PM, Jan Zelený wrote: >>> Please send your requests as replies to this email so they can be properly >>> discussed. >> >> Have equivalent of apt-get autoremove. > > That'

Re: Software Management call for RFEs

On 28.05.2013 13:54, Jan Zelený wrote: On 28. 5. 2013 at 11:39:35, Alek Paunov wrote: On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a consid

Re: Software Management call for RFEs

On Tue, 2013-05-28 at 13:14 +0200, Miroslav Suchý wrote: > On 05/22/2013 03:43 PM, Jan Zelený wrote: > > Please send your requests as replies to this email so they can be properly > > discussed. > > Have equivalent of apt-get autoremove. That's what yum-plugin-remove-with-leaves does. -- Mathi

Re: Software Management call for RFEs

On 05/22/2013 03:43 PM, Jan Zelený wrote: Please send your requests as replies to this email so they can be properly discussed. Have equivalent of apt-get autoremove. I.e. If you run yum install foo and it will install packages "bar" and "bra" for dependencies. Then when I remove package "fo

Re: Software Management call for RFEs

On 28. 5. 2013 at 11:39:35, Alek Paunov wrote: > On 28.05.2013 09:51, Jan Zelený wrote: > > I couldn't agree more. But as I have said, we need to find the most simple > > and unintrusive things that can be done to improve this. For instance: > > file lists take a considerable portion of the entire

Re: Software Management call for RFEs

On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like

Re: Software Management call for RFEs

On 05/27/2013 09:32 AM, Jan Zelený wrote: Unfortunately there is not much we can do about this. Debian has completely different repository policy - they keep all versions of packages in the repo so there is no need to update metadata on client machines every time. Actually we can do something.

Re: Software Management call for RFEs

On 05/22/2013 05:47 PM, Paulo César Pereira de Andrade wrote: As a packager, some way to transparently handle an upgrade when a directory changes to a symlink or vice-versa. +1 -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https

Re: Software Management call for RFEs

On 27. 5. 2013 at 10:31:29, Reindl Harald wrote: > Am 27.05.2013 09:32, schrieb Jan Zelený: > > On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: > >> On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand > > > > wrote: > >>> Performance improvement: improve scaling to 5K+ installed packages. > >

Re: Software Management call for RFEs

Well, another thought is that if some software has a lot of optional dependencies, how to handle them from the view of end-users? Should we list these optionals or add a option for install all with deps? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/

Re: Software Management call for RFEs

Hey, On Wed, May 22, 2013 at 05:08:33PM -0400, Rahul Sundaram wrote: > 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. There

Re: Software Management call for RFEs

> Can you point me to the primary.xml -> SQLite translation in yum? I've > got a fairly efficient primary.xml parser. Just set mddownloadpolicy=xml in yum.conf. It should work, but since downloading sqlite.bz2 is much better, very few use this. Yum uses fairly efficient parser, written in C, usi

Re: Software Management call for RFEs

Am 27.05.2013 09:32, schrieb Jan Zelený: > On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: >> On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand > wrote: >>> Performance improvement: improve scaling to 5K+ installed packages. >> >> * Amen. This is particularly compounded by poor caching de

Re: Software Management call for RFEs

On Mon, May 27, 2013 at 6:17 AM, Florian Weimer wrote: > On 05/27/2013 11:48 AM, Zdenek Pavlas wrote: >>> >>> And there package diffs, which are ed-style diffs of the >>> Packages file I mentioned above. This approach would work quite well >>> for primary.xml because it doesn't contain cross-refe

Re: Software Management call for RFEs

On 05/27/2013 11:48 AM, Zdenek Pavlas wrote: And there package diffs, which are ed-style diffs of the Packages file I mentioned above. This approach would work quite well for primary.xml because it doesn't contain cross-references between packages using non-natural keys. It doesn't work for the

Re: Software Management call for RFEs

> And there package diffs, which are ed-style diffs of the > Packages file I mentioned above. This approach would work quite well > for primary.xml because it doesn't contain cross-references between > packages using non-natural keys. It doesn't work for the SQLite > database, either in binary or

Re: Software Management call for RFEs

Le Dim 26 mai 2013 11:10, Lars Seipel a écrit : > On Sat, May 25, 2013 at 09:34:32AM -0400, Nico Kadel-Garcia wrote: >> I think this can be addressed by moving the metadata updates to a >> different function, and calling it *separately* only as needed. The >> Debian "apt" tool does this quite effe

Re: Software Management call for RFEs

On 05/27/2013 10:24 AM, Jan Zelený wrote: Debian repository policy varies quite a bit. Some repositories keep old versions, some don't. Mostly the latter, actually, because not all repository managers (there a couple of implementations) can deal with multiple versions for a single package/archi

Re: Software Management call for RFEs

On 27. 5. 2013 at 09:43:15, Florian Weimer wrote: > On 05/27/2013 09:32 AM, Jan Zelený wrote: > > On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: > >> On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand > > > > wrote: > >>> Performance improvement: improve scaling to 5K+ installed packages. >

Re: Software Management call for RFEs

On 24. 5. 2013 at 15:20:24, Rahul Sundaram wrote: > On 05/23/2013 07:08 AM, Jan Zelený wrote: > > 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 shift towards

Re: Software Management call for RFEs

On 05/27/2013 09:32 AM, Jan Zelený wrote: On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand wrote: Performance improvement: improve scaling to 5K+ installed packages. * Amen. This is particularly compounded by poor caching default behavi

Re: Software Management call for RFEs

On 25. 5. 2013 at 09:34:32, Nico Kadel-Garcia wrote: > On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand wrote: > > Performance improvement: improve scaling to 5K+ installed packages. > > * Amen. This is particularly compounded by poor caching default > behavior, so that a few yum commands in a

Re: Software Management call for RFEs

On Sat, May 25, 2013 at 09:34:32AM -0400, Nico Kadel-Garcia wrote: > I think this can be addressed by moving the metadata updates to a > different function, and calling it *separately* only as needed. The > Debian "apt" tool does this quite effectively. You can kind of simulate that by forcing yum

Re: Software Management call for RFEs

On Sat, 25 May 2013 01:42:44 +0300 Oron Peled wrote: > I think you missed the whole point of Debian's multi-arch -- instead > of special handling for "sister" architectures (e.g: x86/x86_64), or > proving there aren't (e.g: aarch64/armv7) -- it creates a symmetric > world. > > The *huge* benefit

Re: Software Management call for RFEs

On 05/24/2013 09:26 AM, Michael Scherer wrote: Le vendredi 24 mai 2013 à 07:08 +0200, Ralf Corsepius a écrit : 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:

Re: Software Management call for RFEs

On 24 May 2013 22:02, Przemek Klosowski wrote: > On 05/23/2013 07:52 AM, 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. >> As an example I

Re: Software Management call for RFEs

On Thu, May 23, 2013 at 4:53 AM, 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.

Re: Software Management call for RFEs

On Thu, May 23, 2013 at 9:52 AM, 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.

Re: Software Management call for RFEs

On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand wrote: > Performance improvement: improve scaling to 5K+ installed packages. * Amen. This is particularly compounded by poor caching default behavior, so that a few yum commands in a row each wind up reaching out to downloading metadata again, an

Re: Software Management call for RFEs

Le vendredi 24 mai 2013 à 07:08 +0200, Ralf Corsepius a écrit : > On 05/23/2013 06:05 PM, Simone Caronni wrote: > > 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.cf

Re: Software Management call for RFEs

On Sat, 2013-05-25 at 08:36 +0200, David Tardon wrote: > Hi, > > On Fri, May 24, 2013 at 10:08:06AM -0700, Adam Williamson wrote: > > A 'metapackage' is an actual package shipped in the repositories which > > contains no files, and whose raison d'etre is to express some > > dependencies. There are

Re: Software Management call for RFEs

Hi, On Fri, May 24, 2013 at 10:08:06AM -0700, Adam Williamson wrote: > A 'metapackage' is an actual package shipped in the repositories which > contains no files, and whose raison d'etre is to express some > dependencies. There are a few of these in Fedora, xorg-x11-drivers being > the classic exa

Re: Software Management call for RFEs

On Friday 24 May 2013 13:41:41 Kevin Fenzi wrote: > On Fri, 24 May 2013 15:15:30 -0400 Rahul Sundaram wrote: > > Not really. We are focusing only on the x86_64/x86 case and ignoring > > the broader problem which Debian has tackled. Jumping to the > > conclusion that because you had some multi-li

Re: Software Management call for RFEs

On Fri, 2013-05-24 at 10:11 -0700, Adam Williamson wrote: > We could of course build the smarts into the fedpkg layer - have some > fedpkg commands for checking out and building tarballs of SCM-hosted > content - but then you've just moved the security risk Panu mentioned to > that layer; if we do

Re: Software Management call for RFEs

On Fri, May 24, 2013 at 01:41:41PM -0600, Kevin Fenzi wrote: > It was my understanding that arm is not going to do any multilib. > > aarch64 cannot run other stuff, so you cannot run armv7 or whatever on > a aarch64 box, it's just completely different. > > (I sure hope this is the case) Looks

Re: Software Management call for RFEs

On 05/23/2013 07:52 AM, 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. As an example I could do: mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.m

Re: Software Management call for RFEs

On Fri, 24 May 2013 15:15:30 -0400 Rahul Sundaram wrote: > On 05/23/2013 09:10 AM, Jan Zelený wrote: > > TBH I'm not perfectly sure what causes the problem but since the new > > "multilib" in Ubuntu started I am dealing with a whole bunch of > > issues like the one I described. So to sum up, I pe

Re: Software Management call for RFEs

On 05/23/2013 07:08 AM, Jan Zelený wrote: 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 shift towards maintenance mode and the focus will be on dnf. What does the "w

Re: Software Management call for RFEs

On 05/23/2013 09:10 AM, Jan Zelený wrote: TBH I'm not perfectly sure what causes the problem but since the new "multilib" in Ubuntu started I am dealing with a whole bunch of issues like the one I described. So to sum up, I personally think we are doing much better with the way how things work in

Re: Software Management call for RFEs

On Thu, 2013-05-23 at 18:29 +0300, Panu Matilainen wrote: > Rpm >= 4.10 can automatically download remote sources and patches over > http and ftp, but since there's (currently) no way to verify downloaded > content the feature is disabled by default as its quite a security risk > to download ar

Re: Software Management call for RFEs

On Thu, 2013-05-23 at 15:36 -0300, Paulo César Pereira de Andrade wrote: > 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)? > >

Re: Software Management call for RFEs

On Fri, 2013-05-24 at 10:37 +, Petr Pisar wrote: > On 2013-05-24, Jonathan Dieter wrote: > > On Fri, 2013-05-24 at 08:03 +, Petr Pisar wrote: > >> Do you know virtual packages are forbidden in Fedora? > > > > Sorry, I just scanned through the guidelines and didn't see this > > anywhere. D

Re: Software Management call for RFEs

On 05/24/2013 01:37 PM, Petr Pisar wrote: On 2013-05-24, Jonathan Dieter wrote: On Fri, 2013-05-24 at 08:03 +, Petr Pisar wrote: Do you know virtual packages are forbidden in Fedora? Sorry, I just scanned through the guidelines and didn't see this anywhere. Do you mind citing a referenc

Re: Software Management call for RFEs

On 2013-05-24, Jonathan Dieter wrote: > On Fri, 2013-05-24 at 08:03 +, Petr Pisar wrote: >> Do you know virtual packages are forbidden in Fedora? > > Sorry, I just scanned through the guidelines and didn't see this > anywhere. Do you mind citing a reference, please? > Well it's probably not f

Re: Software Management call for RFEs

On 05/24/2013 10:21 AM, Reindl Harald wrote: Am 24.05.2013 07:08, schrieb Ralf Corsepius: By doing "yum reinstall nagios" I don't have the the default config files (i.e. nagios.cfg.rpmnew is not created). This happens only on upgrades. yum remove yum install should do what you want (backu

Re: Software Management call for RFEs

Dne Čt 23. května 2013 16:41:04, Vít Ondruch napsal(a): > 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* > >

Re: Software Management call for RFEs

Dne Čt 23. května 2013 18:05:40, Till Maas napsal(a): > 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 modification

Re: Software Management call for RFEs

On Fri, 2013-05-24 at 08:03 +, Petr Pisar wrote: > Do you know virtual packages are forbidden in Fedora? Sorry, I just scanned through the guidelines and didn't see this anywhere. Do you mind citing a reference, please? Thanks, Jonathan -- devel mailing list devel@lists.fedoraproject.org

  1   2   3   >