Hardcoded TMPDIR - anywhere else?
Hello everyone!
I wonder whether any other application does a similar thing?
/usr/bin/firefox contains this nasty piece:
##
## Use $MOZ_TMPDIR if set. Otherwise use /var/tmp instead of /tmp
## because of 1GB /tmp limit in Fedora 18 and later.
## See: https://bugzilla.redhat.com/show_bug.cgi?id=867073
##
TMPDIR=${MOZ_TMPDIR:-/var/tmp}
export TMPDIR
Originally, it had hardcoded TMPDIR to /var/tmp already, overriding
the users TMPDIR setting (if any) - https://bugzilla.redhat.com/867073 -
and passing that altered env to programs it starts, too.
The Firefox source would respect TMPDIR, TEMP and TMP, then fall back
to /tmp if no env var is set.
Searching a bit in Fedora Wiki pages, I've found:
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs
| My CD burning application writes huge .iso files to /tmp,
| and this breaks on tmpfs!
The application should be fixed to use /var/tmp.
| My application writes temporary files to /tmp and they are
| gone after a reboot!
The application should be fixed to use /var/tmp. FHS recommends
that /tmp is flushed on reboot, and that's what we do here.
It is insane to hardcode /var/tmp. Also, GNOME Shell (F19) here
defaults to /tmp, and I guess other parts of the OS do too, not
only if they use glib2 (g_get_tmp_dir() or similar).
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.3-301.fc19.x86_64
loadavg: 0.02 0.11 0.13
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 files and /tmp is the default non-hardcoded dir, they're trying to avoid users complaining about failed downloads. Note that this is one of the cases the opponents of the tmp-in-tmpfs change predicted. No surprise that they want to avoid bug reports due to unexpected (to the user) behavior, and in fact, this is what the tmp-in-tmpfs proponents suggested (using /var/tmp) for such cases anyway. For reference, see the very long debate about tmp-in-tmpfs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 /tmp in RAM, and since web browsers are often used to download huge files and /tmp is the default non-hardcoded dir, they're trying to avoid users complaining about failed downloads. Doesn't Firefox download in $XDG_DOWNLOAD_DIR by default these days? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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_DOWNLOAD_DIR}.
Mathieu
Cheers,
Björn
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 awill...@redhat.com 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_ rebuilds in dependency order: build deps that require the old libpng can't be installed in the koji build roots without rebuilding them first. And this means individual package maintainers can't fix their packages before someone has fixed things down in the dep chain. The way it was done last time on the 1.5 upgrade was to have a compat-libpng package that had the 1.5 release so that nothing broke while things were rebuilt and then once the vast majority of the rebuild happened it was then dropped to avoid this problem. Peter well but when side tag is used then no compatibility package is needed Rawhide will not be broken in that case. I think that there are two ways how to handled that issue: - create side tag and after finishing merge changes into the rawhide - create a compatibility package in rawhide and when migration will be done that compatibility package will be dropped. From my point of view side tag is better to handlling. Either works. The drawback of a side tag is that it's slightly more complex to work with. The drawback of a compat library is the lack of motivation to complete the migration: there's a danger when you introduce a compat library that there isn't sufficient motivation for people to migrate their packages to the new library, because hey, everything works, right? What's the big rush? You still need a compat package with the old API in the side tag as well as you still need to have the old soname around until at least all the packages in the core build root can install. I think we've got into situations in the past where we've had to retire a compat library before everything was migrated off it, just to force people to _actually migrate things off it_. Yea, ultimately the compat package is there primarily to get all the core build systems stuff built against the new soname so that things will work and then there's not much point in keeping it around because it ultimately allows procrastination. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 vondr...@redhat.com 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 vondr...@redhat.com - 2.0.0.195-8 - Update to Ruby 2.0.0-p195 (rhbz#917374). - Fix object taint bypassing in DL and Fiddle (CVE-2013-2065). - Fix build against OpenSSL with enabled ECC curves. - Add aarch64 support (rhbz#926463). Size change: -2514434 bytes Just out of curiosity, what does this value mean? Size of what changed? I was wondering when anyone would notice this and ask. ;) It's comparing the size of src.rpms. So, the new package src.rpm here is that much smaller than the old one. ;) I thought so, but if it state SRPM size change, I would not need to ask this question :) BTW, is there a reason for reporting the total size changes at the end of the report? Or are the package size change and the total size change just informative/sanity values? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 would be possible to provide a consistent view of the system, as well as a consistent management interface for sysadmins as opposed to application developers. The latter I might expect to continue to use the domain specific package managers, simply because they add value to domain experts -- but for the common usecase install this app on the server it would be nice to use RPM only. Another advantage that I see is that it saves Fedora packager manpower -- if the translation is good enough, it should be possible to work with upstream packages and simply automate the fedora rpm process as much as possible. Current examples are R2spec and the TeXLive package scripts. And maybe, in the future, it might even be possible for new domains to rely on RPM itself instead of writing Yet-Another-Package-Manager etc. But again, that is not the goal itself. To succesfully integrate RPM implies (to me) at least the following, some of which are already on the feature page: - convert the basic package metadata from $domain to RPM (it is OK to go back to $domain package manager for exotic use cases, but list/update/remove packages should be doable from RPM) - reproducible environment (Gemfile / pip requirements.txt / ...) - both system- and per-user installation tracked and supported - more I can't think of right now? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 put /tmp in RAM, and since web browsers are often used to download huge files and /tmp is the default non-hardcoded dir, they're trying to avoid users complaining about failed downloads. There's no guarantee that /var/tmp is larger than 1 GB. Making an application default to /var/tmp would be acceptable, if it respected $TMPDIR and didn't export the changed env var to programs it launches. In parts of the Firefox source code even $TEMP and $TMP are examined, if $TMPDIR is unset. Firefox upstream evaluates $TMPDIR. It doesn't know $MOZ_TMPDIR. Do we want $FOO_TMPDIR for every program that defaults to storing large/huge files in /tmp. Hopefully we want to make it evaluate $TMPDIR instead, or make Fedora default to /var/tmp instead of /tmp. For reference, see the very long debate about tmp-in-tmpfs. That one is not for ordinary human beings. ;-) -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.3-301.fc19.x86_64 loadavg: 0.29 0.09 0.07 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[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 try. Thanks. [1] https://bugzilla.redhat.com/show_bug.cgi?id=962238 [2] https://bugzilla.redhat.com/show_bug.cgi?id=605573 [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=5411912 -- Ismael Olea http://olea.org/diario/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 including the %prep stage). Right now, just applying the patches can require a system image which provides the build dependencies. Many %prep scripts also leave behind random stuff for developer convenience (think patch -b), and this interferes with things like generating diffs or source tree indexing. And right now, accessing the actual source code is computationally expensive. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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-kde-icon-theme). Prehistory: as we started RazorQt rpms - some people was crying I have no any icon in main menu!. So we deside to add _any_ icon theme to Razor's Requires. And now 10MB razorqt requies 30MB oxygen-icon-theme :-) Seems I have to make bugeports/featurerequest for _each_ *-icon-theme package :-( Perhaps bring it up with the packaging committee, figure out a plan, and then have a provenpackager make the changes? How to do this? BTW - seems anaconda requires gnome-icon-theme. Or not? At present, yeah (actually also gnome-icon-theme-symbolic). See also https://bugzilla.redhat.com/show_bug.cgi?id=965365 . For F20, we may wind up just having anaconda carry copies of the icons it wants; upstream doesn't seem too keen on providing any guarantees that they won't change appearance at any moment (see https://bugzilla.redhat.com/show_bug.cgi?id=963958 ). If anyone wants a really weird icon bug to try and fix, see https://bugzilla.redhat.com/show_bug.cgi?id=964019 . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 system-kde-icon-theme). Prehistory: as we started RazorQt rpms - some people was crying I have no any icon in main menu!. So we deside to add _any_ icon theme to Razor's Requires. And now 10MB razorqt requies 30MB oxygen-icon-theme :-) Seems I have to make bugeports/featurerequest for _each_ *-icon-theme package :-( Perhaps bring it up with the packaging committee, figure out a plan, and then have a provenpackager make the changes? How to do this? BTW - seems anaconda requires gnome-icon-theme. Or not? At present, yeah (actually also gnome-icon-theme-symbolic). See also https://bugzilla.redhat.com/show_bug.cgi?id=965365 . For F20, we may wind up just having anaconda carry copies of the icons it wants; upstream doesn't seem too keen on providing any guarantees that they won't change appearance at any moment (see https://bugzilla.redhat.com/show_bug.cgi?id=963958 ). If anyone wants a really weird icon bug to try and fix, see https://bugzilla.redhat.com/show_bug.cgi?id=964019 . I found that my spin already contains as gnome-icon-theme as *-symbolic. But anaconda not use it (?). I tried to make: echo gtk-icon-theme-name=\GNOME\ /etc/gtk-2.0/gtkrc No effect. What to do? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 shift towards maintenance mode and the focus will be on dnf. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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)? Feature: facility for atomic upgrade of an entire set of packages. Either all succeed, or none succeed; and in bounded time. This would help with maintaining consistent development environments: gcc+binutils+gdb, etc. In practice it matters (especially for cross-platform development, and reproducing bugs reported by remote machines), even if in theory it shouldn't. I can recommend you the yum-fs-snapshot plugin for that. Doing snapshots is currently the only feasible way to ensure atomicity of multi-package transactions. It's important to note that restrictions for this don't come from rpm but rather from kernel (e.g. filesystem features). Feature: faster performance. rpm install/upgrade is 2X too slow. yum install/upgrade is 3X too slow. The disk should be 100% busy from start to finish, and at all times each CPU core should be either busy or waiting for the disk. Specific goal: a full install of 1200 packages totaling 1.5GB of .rpm expanding to 3.6GB on the target takes five minutes on a common desktop/laptop. This averages 5MB/s input (4X DVD, 32X CD), and 12MB/s output. Speed rpm install/upgrade by parallel and pipeline: Topological sort into tiers. tier 0: no dependencies; tier K+1: dependencies only in tiers 0..K. Within a tier: all packages are independent, thus can be done in parallel. Within a package: all of the reads that occur before the first write can be done in parallel with *ANY* other package, regardless of dependencies. Thus parsing and decompression of .rpm into memory (or a unique staging directory within a tmpfs) can be parallel regardless of dependencies. Perhaps writes to database must be restricted to one package at a time (despite logical parallelism within a tier), but this can be pipelined with the read phase. Speed yum install/upgrade by speeding rpm, plus distribute Verifying ... and symlink data-basing out of a separate pass and into the rpm pipeline. I'm pretty sure we don't have the manpower for this sort of optimization but we'll take it into consideration. Thank you Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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ý jzel...@redhat.com: 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. As a packager, some way to transparently handle an upgrade when a directory changes to a symlink or vice-versa. A minor, extra checking one that I was hit recently was lack of checking a package that have a symlink to /builddir/some-where, and would only work on my computer because the symlink did point to /home/pcpa/rpmbuild/BUILD/... As an user, some way to, but mostly adding some policy, to have multiple sonames of a library installed. Usually only useful to avoid a window of time with broken dependencies, but sometimes useful to have some package that only works with an older version of some library functional, without blocking an update. I'm not sure I understand you correctly. Do you actually ask for multiple versions of a single package to be installed simultaneously? If that's the case, I can say no right away ;-) The other thing I sense you might have on your mind is to remove from update transaction those packages that are held back by some requirements and continue with the transaction. Is that correct? Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 addressing different kinds of issues. 'rpm -Va' is about verifying the installed packages are intact wrt what the package originally contained. rpmlint on the other hand is more about detecting common packaging mistakes - things that are technically legal packages but ones that are not packaged by best practises, including distro policies and all. Even for the most basic checks its output is so useless and difficul to parse we've seen a critical path package like gdm shipped with the wrong file permissions without anyone noticing. No disagreement there... if you have concrete proposal on how 'rpm -Va' output should look like to be easily parsable and sane, I'm all ears. Ditto if you know of some other tool performing similar function with sane(r) output. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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). There are two noticable problems: yum slows down considerably (esp. in transaction check operations), and PackageKit can't handle upgrades of more than 2500 packages at a time. Well, PackageKit is already out of our scope but I will talk to Richard about this. On the rpm side - we are already working on that On the yum side - have you tried dnf? It should handle this much better. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 virtualized environments. It could gracefully warn users about unsupported environments. It can also be overridden using some switch to force ignore the warning. For example, it would be very clean to say if I can specify Requires: ConditionVirtualization=vmware to disallow my RPM installation on non-VMware environments and at the same time have a switch to force install in case that is what I really want to do because I'm building an image for different runtime environment. Conditional dependencies is one of the original requests we discussed on the DevConf and it will most likely be addressed in the future. We realize the great potential this feature set would bring, we just want to do it right and that will take some time to design and implement. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 Suggests? We really should have a way for Yum and Packagekit to say Hey, if you're installing that, maybe you also want this?. A -devel package and its corresponding -doc package should recommend each other for example. They shouldn't require each other, because then they could just as well be the same package, but usually you want to install them together and it would be helpful to at least notify users who install the -devel package that the -doc package also exists. Another example is a database server and its command line client, which you often but not always want to install together. The server should recommend the client, while the client might only suggest the server. A third example is graphical administration tools for some daemon that are in a separate package so that the daemon can be installed without pulling in half a desktop environment. In this case the daemon should suggest the tools, but perhaps not recommend them. See my reply above in the thread about dynamic dependencies. Short version: already being discussed :-) Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
Hello, On 22 May 2013 23:18, Richard W.M. Jones rjo...@redhat.com 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 bit package. To install it in a 32 bit or 64 bit environment the command is the same (i.e. yum localinstall) as it will pull in the correct 32 bit dependencies. Basically hassle free. The guys that run Debian/Ubuntu notebooks, have to go through a series of dependency problems just to install the package in a 64 bit environment with getlibs and the like: http://usablesoftware.wordpress.com/2012/11/09/install-lotus-notes-8-5-3-on-ubuntu-12-10-64bit-quick-n-dirty-installation-notes/ http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllThreadedWeb/69b50f2db7bb7b0b85257659005ab79e?OpenDocument Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 sent to an internal Red Hat list last month]
In no particular order:
(1) Yum should not be so slow. In particular yum install takes ages
compared to apt-get install. I don't want to argue about how yum
has to download metadata or whatever, the fact of the matter is the
yum experience is slow and the apt experience is faster. Play with
Debian some time to see what I mean.
(2) DNF's dependency resolver should be the default.
(3) RPM's spec file format needs to be redone using a Real Parser. At
the moment it has all sorts of strange corner cases (for example, how
to define a macro containing an arch-dependent list?). It'd be a good
opportunity to fix brokenness such as global meaning define, lack
of direct support for configuration flags, writing 0%{?rhel},
complexity of non-trivial %setup's, etc.
(4) Get rid of %{bindir} etc. There's no need for it. It didn't even
help during UsrMove, the one time ever that it plausibly might have helped.
(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.
Related to this, things like users/groups/services should be written
declaratively, not imperatively:
%need-user kvm.kvm
%need-service nfsd.service
and have RPM work out how to implement it most efficiently.
(6) It should be possible to install into a chroot, and this should be
a supported configuration. Needed by LXC.
(7) %changelog section of RPM should be abandoned. Instead, you
should only have to write a changelog once (ideally in the upstream
VCS, which is then propagated everywhere it is needed).
Developers or packagers may also need to write summary notes for each
release, but again they should only have to be written once.
(8) Base packages like 'filesystem', 'setup' should include
everything. At the moment mock contains extra rules for device files
and things like that, for no reason I can understand. (See
mock/backend.py '_setupDev' function).
(9) Get rid of yum's pretend transactions. Either implement real,
ACID transactions where the filesystem allows it, or don't pretend.
(10) Get rid of multilib, /usr/lib64 etc and copy what Debian/Ubuntu
are doing.
(11) Make it easier for yum to be consumed from other programs. DNF
fixes this.
(12) Suggests/Recommends.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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, 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)? Thanks for taking on this effort. 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 git url with a hash or git tag, we would benefit. Interesting idea however I'm not sure if this shouldn't be targeted somewhere else. Anyway, thanks for the suggestion, we will consider it. Also, if would could make it easy to easier to do things like updating the icon cache etc only once per transaction instead of per package would help with the speed of the initial Fedora installation or any large updates Honestly, I'm not completely sure what do you mean by icon cache. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 rjo...@redhat.com 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 bit package. To install it in a 32 bit or 64 bit environment the command is the same (i.e. yum localinstall) as it will pull in the correct 32 bit dependencies. Basically hassle free. The guys that run Debian/Ubuntu notebooks, have to go through a series of dependency problems just to install the package in a 64 bit environment with getlibs and the like: +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) . Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 instance: rpm -qp some-rpm.rpm --revert/--extract /etc/some-rpm.conf /etc/another-file.conf I know it can be done with rpm2cpio, just a suggestion to implement it natively and extract the files to their correct location. On Thu, May 23, 2013 at 7:52 AM, Orion Poplawski or...@cora.nwra.comwrote: On 05/22/2013 07:43 AM, 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 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, 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)? There is already a list of some RFEs on rpm.org wiki, you can use it as an inspiration, to see what RFEs we have already received: http://rpm.org/wiki/**FeaturePlanninghttp://rpm.org/wiki/FeaturePlanning The only limitation for your requests is our manifest which defines the scope of SW management stack for the future. It is attached to this email (note that it's quite extensive but the first part should give you a good image of what is the planned scope of SW management stack). Please send your requests as replies to this email so they can be properly discussed. After your proposals are filed and discussed, all will be evaluated by our team and a roadmap with priorities will be created with those selected as doable and meaningful. Thank you in advance for your participation Jan 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 the package. Also, it is explicitly referencing specific implementations, not a generic interface, so a generic Provides in the backend packages is not appropriate. But something like: Requires: ( pkgA || pkgB ) might do the trick. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 approximately seven zillion combinatorial explosions of QA, so one more on the pile is not going to make much of an appreciable difference...though it could spell all kinds of fun for image composes, I suspect. Still, I don't see how that's really worth doing instead of just using a virtual provide. The OP's reasoning for not using a virtual provide sounded rather specious to me. The two things are functionally equivalent so far as I can see. Just different syntax. 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 could go the provides route, it doesn't seem to make sense to me. I suppose I could ask for: Provides: pyface-backend in both PyQt4 and wxPython. Think that would make sense? Yes :-) Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 23 May 2013 13:47, Jan Zelený jzel...@redhat.com 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 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.mine yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg Thanks, --Simone -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 23 May 2013 13:44, Jan Zelený jzel...@redhat.com 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) Actually the first time I stepped onto this (Notes installation, in fact; which we could never get to work) it reminded me a lot of the Windows SysWOW64 mess. For those that do not know: 32 bit: C:\WINDOWS\system32 64 bit: C:\WINDOWS\system32 32 on 64 bit: C:\WINDOWS\SysWOW64 + the 32 bit software sees that folder as C:\WINDOWS\system32. Argh. --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 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 tools to create spec files from those upstream representations (gem2spec, cpan2spec, ...) By integrating RPM with these package managers, I feel it would be possible to provide a consistent view of the system, as well as a consistent management interface for sysadmins as opposed to application developers. The latter I might expect to continue to use the domain specific package managers, simply because they add value to domain experts -- but for the common usecase install this app on the server it would be nice to use RPM only. Another advantage that I see is that it saves Fedora packager manpower -- if the translation is good enough, it should be possible to work with upstream packages and simply automate the fedora rpm process as much as possible. Current examples are R2spec and the TeXLive package scripts. You can't really do this because of all the Fedora packaging policies. It might be feasible in some private repositories though. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 work we use IBM Lotus Notes, which is a 32 bit package. To install it in a 32 bit or 64 bit environment the command is the same (i.e. yum localinstall) as it will pull in the correct 32 bit dependencies. Basically hassle free. The guys that run Debian/Ubuntu notebooks, have to go through a series of dependency problems just to install the package in a 64 bit environment with getlibs and the like: http://usablesoftware.wordpress.com/2012/11/09/install-lotus-notes-8-5-3-on-ubuntu-12-10-64bit-quick-n-dirty-installation-notes/ http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllThreadedWeb/69b50f2db7bb7b0b85257659005ab79e?OpenDocument These examples both suggest the use of the ia32-libs package. The package was an ugly workaround for the missing multilib support in Debian, but it should be obsolete with full multiarch in Debian 7.0. See http://wiki.debian.org/Multiarch Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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) Isn't that simply because deb packages do not express library dependencies in as detailed way as rpm packages do? I'm sure Richard was not suggesting to get rid of that rpm feature. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lua-logging] lua-logging-1.3.0-1.fc20.noarch requires lua = 0:5.2 [lua-rex] lua-rex-2.7.2-1.fc20.x86_64 requires lua = 0:5.2 [luadoc] luadoc-3.0.1-8.fc20.noarch requires lua = 0:5.2 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 lutok-devel-0.2-4.fc19.x86_64 requires lua-devel 0:5.2 [ooo2gd] ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-docs] python-docs-2.7.4-1.fc20.noarch requires python = 0:2.7.4 [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [qpid-cpp] qpid-cpp-server-xml-0.20-6.fc20.x86_64 requires libxqilla.so.5()(64bit) [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [syncevolution] 1:syncevolution-libs-1.3.99.3-1.fc20.i686 requires libedata-book-1.2.so.17 1:syncevolution-libs-1.3.99.3-1.fc20.x86_64 requires libedata-book-1.2.so.17()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [dragonegg] dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19 [ekiga] ekiga-4.0.1-1.fc19.i686 requires libedata-book-1.2.so.17 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lua-logging] lua-logging-1.3.0-1.fc20.noarch requires lua = 0:5.2 [lua-rex] lua-rex-2.7.2-1.fc20.i686 requires lua = 0:5.2 [luadoc] luadoc-3.0.1-8.fc20.noarch requires lua = 0:5.2 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 [ooo2gd] ooo2gd-3.0.0-6.fc19.i686 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.i686 requires libgdmsimplegreeter.so.1 [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-docs] python-docs-2.7.4-1.fc20.noarch requires python = 0:2.7.4 [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [qpid-cpp] qpid-cpp-server-xml-0.20-6.fc20.i686 requires libxqilla.so.5 [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [syncevolution] 1:syncevolution-libs-1.3.99.3-1.fc20.i686 requires libedata-book-1.2.so.17 [zarafa] php-mapi-7.0.13-1.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-mapi-7.0.13-1.fc19.i686 requires php(api) = 0:20100412-x86-32 New package: brise-0.22-2.fc20 The official Rime schema repository New package: lfcxml-1.1.3-2.fc20 Lemke Foundation Classes XML extension New package: monitorix-3.2.0-2.fc20 A
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 It supports more than just 64 bit or not, such as different kernels, different endianness, and different instruction set extensions. There's a link which explains better than I can why they did it: http://wiki.debian.org/Multiarch/TheCaseForMultiarch The reason I specifically said: On 22 May 2013 23:18, Richard W.M. Jones rjo...@redhat.com 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 community ought to settle on one way of doing this, which just by virtue of popularity and completeness of the proposal means doing it the Debian way in this case. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [fence-virt] fence-virtd-libvirt-qmf-0.3.0-11.fc19.x86_64 requires libvirt-qmf [freeipa] freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires pki-ca = 0:10.0.1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires krb5-server = 0:1.11.2-1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires 389-ds-base = 0:1.3.0.5 [glusterfs] glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [ooo2gd] ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-AppTools] python-AppTools-3.4.0-5.fc19.noarch requires python-TraitsGUI [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [tntnet] tntnet-2.1-15.fc19.i686 requires libcxxtools.so.8 tntnet-2.1-15.fc19.x86_64 requires libcxxtools.so.8()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [byzanz] byzanz-0.3-0.5.fc17.i686 requires libpanel-applet-4.so.0 [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19 [fence-virt] fence-virtd-libvirt-qmf-0.3.0-11.fc19.i686 requires libvirt-qmf [freeipa] freeipa-server-strict-3.2.0-0.3.beta1.fc19.i686 requires pki-ca = 0:10.0.1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.i686 requires krb5-server = 0:1.11.2-1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.i686 requires 389-ds-base = 0:1.3.0.5 [glusterfs] glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-kolab-0.4.1-3.fc19.i686 requires php(api) = 0:20100412-x86-32 [ooo2gd] ooo2gd-3.0.0-6.fc19.i686 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) [python-AppTools]
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 problems (e.g. Google Earth still doesn't work on Ubuntu for me) Isn't that simply because deb packages do not express library dependencies in as detailed way as rpm packages do? I'm sure Richard was not suggesting to get rid of that rpm feature. 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 Fedora. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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ý jzel...@redhat.com 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 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.mine yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg Thanks for the explanation. I will mark the email and make sure to put the use case to the updated list of RFEs. Thanks Jan -- 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: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 fairly full TeX install with all the docs). There are two noticable problems: yum slows down considerably (esp. in transaction check operations), and PackageKit can't handle upgrades of more than 2500 packages at a time. Well, PackageKit is already out of our scope but I will talk to Richard about this. OK. Relevant bug report: https://bugzilla.redhat.com/show_bug.cgi?id=894731 On the rpm side - we are already working on that On the yum side - have you tried dnf? It should handle this much better. Not yet. I plan to upgrade my laptop to F19 sometime in the beta or RC time frame, and was thinking of trying dnf then. - Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 bundles include the binary firmware. Source code for the firmware is also included, but there are no build scripts, and the firmware is not built when the IDE itself is built. Is it permissible to include this firmware in the Fedora packages? My impression is that it's not firmware in the sense described at https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware, because it's not firmware for hardware on which Fedora runs. Rather, I believe that it is content (https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content). Without access to the build scripts (which the GNU GPL2specifically says must be included), do we even have a licence to redistribute the firmware? -- Peter Oliver -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 able to resolve all the problems (e.g. Google Earth still doesn't work on Ubuntu for me) Isn't that simply because deb packages do not express library dependencies in as detailed way as rpm packages do? I'm sure Richard was not suggesting to get rid of that rpm feature. 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 Fedora. In some ways we are, in other aspects we are not. Drawing conclusions from your experience with Google Earth without real understanding is a mistake. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 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) Isn't that simply because deb packages do not express library dependencies in as detailed way as rpm packages do? I'm sure Richard was not suggesting to get rid of that rpm feature. 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 Fedora. In some ways we are, in other aspects we are not. Drawing conclusions from your experience with Google Earth without real understanding is a mistake. That's completely true. But again I'm not even sure this is something that: a) can be fixed on rpm level b) is other than a policy issue All in all I think this is something that should be brought to FESCO (maybe proposed as a Fedora Feature?) before anything else. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 awill...@redhat.com 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_ rebuilds in dependency order: build deps that require the old libpng can't be installed in the koji build roots without rebuilding them first. And this means individual package maintainers can't fix their packages before someone has fixed things down in the dep chain. The way it was done last time on the 1.5 upgrade was to have a compat-libpng package that had the 1.5 release so that nothing broke while things were rebuilt and then once the vast majority of the rebuild happened it was then dropped to avoid this problem. Peter well but when side tag is used then no compatibility package is needed Rawhide will not be broken in that case. I think that there are two ways how to handled that issue: - create side tag and after finishing merge changes into the rawhide - create a compatibility package in rawhide and when migration will be done that compatibility package will be dropped. From my point of view side tag is better to handlling. Either works. The drawback of a side tag is that it's slightly more complex to work with. The drawback of a compat library is the lack of motivation to complete the migration: there's a danger when you introduce a compat library that there isn't sufficient motivation for people to migrate their packages to the new library, because hey, everything works, right? What's the big rush? You still need a compat package with the old API in the side tag as well as you still need to have the old soname around until at least all the packages in the core build root can install. 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? Proven packager will rebuild affected packages against the newest libpng. It is really not so clear for me. After merging to the rawhide we will have only the newest libpng package and all packages will be build up against new libpng. Another question: Let's say that in rawhide I will create libpng compat package. What is the good time to make them deprecated? I think we've got into situations in the past where we've had to retire a compat library before everything was migrated off it, just to force people to _actually migrate things off it_. Yea, ultimately the compat package is there primarily to get all the core build systems stuff built against the new soname so that things will work and then there's not much point in keeping it around because it ultimately allows procrastination. Peter -- Best regards / S pozdravem Petr Hracek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 23 May 2013 14:58, Richard W.M. Jones rjo...@redhat.com 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 different instruction set extensions. There's a link which explains better than I can why they did it: http://wiki.debian.org/Multiarch/TheCaseForMultiarch Thanks for the links. 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. Thanks, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Thu, 23 May 2013 14:02:34 +0200 Jan Zelený jzel...@redhat.com 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 (for R), CTAN (for TeX), and many more I'm sure. 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 tools to create spec files from those upstream representations (gem2spec, cpan2spec, ...) Yes, it is true that there sometimes is a different philosophy, but fundamentally is in the eye of the beholder. If there are domain2spec tools available NOW, why would it not be possible technically? And if the non-technical philosophical differences are too big, maybe it is also a sign that Fedora needs to change the requirements? After all, an OS that does not help developers with development might not be a good environment to keep. By integrating RPM with these package managers, I feel it would be possible to provide a consistent view of the system, as well as a consistent management interface for sysadmins as opposed to application developers. The latter I might expect to continue to use the domain specific package managers, simply because they add value to domain experts -- but for the common usecase install this app on the server it would be nice to use RPM only. Another advantage that I see is that it saves Fedora packager manpower -- if the translation is good enough, it should be possible to work with upstream packages and simply automate the fedora rpm process as much as possible. Current examples are R2spec and the TeXLive package scripts. You can't really do this because of all the Fedora packaging policies. It might be feasible in some private repositories though. I disagree. Why are the domain2spec and TeXLive approaches in the repository then? I know that some domain2spec tools do need hand-editing, but that is a problem that can be worked on. Either by integrating more knowledge in the tools, or working with upstream on providing more metadata for the package. I do acknowledge that all of this will not be EASY. But then, I did not see that in your list of requirements. If it is really impossible, can you give an practical example why? (Sidenote: I really do appreciate the call for features and the considered feature page. Thank you for that!) Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 probably some overlap in what those utilities do but generally I see them as addressing different kinds of issues. 'rpm -Va' is about verifying the installed packages are intact wrt what the package originally contained. rpmlint on the other hand is more about detecting common packaging mistakes - things that are technically legal packages but ones that are not packaged by best practises, including distro policies and all. Sure, but there is no reason the two kinds of problems must be addressed with different tools and different output conventions. And in fact (as seen in the gdm case) the fact that a runtime script changed the permissions after install (rpm -Va perimeter) was a symptom of a packaging problem (rpmlint perimeter). The perimeter limits exist in our mind, the actual problems rarely appear at just one point in the package lifecycle. Even for the most basic checks its output is so useless and difficul to parse we've seen a critical path package like gdm shipped with the wrong file permissions without anyone noticing. No disagreement there... if you have concrete proposal on how 'rpm -Va' output should look like to be easily parsable and sane, I'm all ears. Ditto if you know of some other tool performing similar function with sane(r) output. I'd like rpm -Va output to be libified so: 1. it can be plugged into emacs or eclipse and provide run-time spec edition checking 2. a service can periodically execute system sanity checks, log errors to journald (or even to an healthcheck gui indicator) and warn about dangerous modifications to installed packages or packages that do not respect sanity checks and pollute the system 3. it can still be called with a CLI And the output should have some verbosity level, at sparsest level just one status line per problem package, then one line per problem in a package, then detailed description per problem (for example file permission is XXX, should be YYY) then full howto-like explanation per problem Non-problems like timestamps should not be reported at all (only report actual problems something can be done at). I'm quite sure trying to actually do something with the error output will help define how it should look like. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 OS on different hypervisors or (with P2V) transfer it from physical to virtual. Should RPM start (un-)installing things when this happens? Could a reboot result in broken dependencies? 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 and provide a way to override RPM behavior so that advanced users can make a choice. This is the logic windows installers use but I don't think it's the correct one. The installer should never change behaviour based on a system state that can change over time (unless this state is under its control which is not the case here) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 phra...@redhat.com 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 Peter is suggesting is that there is no good order to do the rebuilds in because libpng is needed by the packages used to rebuild packages. So as soon as the new libpng is being used (with a compat version), the build root won't be installable, so you won't be able to do any more builds. With many libraries this wouldn't be the case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
From: Rahul Sundaram methe...@gmail.com 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 git url with a hash or git tag, we would benefit. Amen to that! I roll my own rpms daily from locally developed sources where we have no policy of pushing tarballs. From everything I've ever been able to figure out, it's necessary for me to make temporary tarballs just to feed rpmbuild. It always seems such a huge waste of time, especially for very large packages. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 moves from /usr/lib64 to /usr/lib/x86_64-linux-gnu. That's not complicated. It can certainly be made complicated -- eg. by having a library that is compiled multiple times with different SSE extensions. But that's something that cannot be done at all on Fedora without using package-specific hacking. 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 KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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ý jzel...@redhat.com 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 (for R), CTAN (for TeX), and many more I'm sure. 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 tools to create spec files from those upstream representations (gem2spec, cpan2spec, ...) Yes, it is true that there sometimes is a different philosophy, but fundamentally is in the eye of the beholder. If there are domain2spec tools available NOW, why would it not be possible technically? And if the non-technical philosophical differences are too big, maybe it is also a sign that Fedora needs to change the requirements? After all, an OS that does not help developers with development might not be a good environment to keep. I will give a simple example: Fedora - Ruby. Those are two completely different worlds that will probably never synchronize their philosophies. And you can't say which one should take a step back because they both have valid points in their philosophies. By integrating RPM with these package managers, I feel it would be possible to provide a consistent view of the system, as well as a consistent management interface for sysadmins as opposed to application developers. The latter I might expect to continue to use the domain specific package managers, simply because they add value to domain experts -- but for the common usecase install this app on the server it would be nice to use RPM only. Another advantage that I see is that it saves Fedora packager manpower -- if the translation is good enough, it should be possible to work with upstream packages and simply automate the fedora rpm process as much as possible. Current examples are R2spec and the TeXLive package scripts. You can't really do this because of all the Fedora packaging policies. It might be feasible in some private repositories though. I disagree. Why are the domain2spec and TeXLive approaches in the repository then? I know that some domain2spec tools do need hand-editing, but that is a problem that can be worked on. Either by integrating more knowledge in the tools, or working with upstream on providing more metadata for the package. I do acknowledge that all of this will not be EASY. But then, I did not see that in your list of requirements. Well, technically it might be possible. It's just that I have strong doubts that the domain2spec tools can be improved to the degree where they can handle *any* domain-based package and produce rpm package that can be accepted to Fedora. Again, with private repositories, this won't be a concern and we can happily go for it, as there is no such thing as policy there ;-) (Sidenote: I really do appreciate the call for features and the considered feature page. Thank you for that!) Don't thank me yet, we still don't have neither the roadmap nor the list of accepted RFEs ;-) Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 package with an italic serif russian font, a bold japanese font and some other unrelated sans-serif stuff. There is no way to tell it I want both properties in the same provides. (I'm sure there are other use cases) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 rjo...@redhat.com 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 community ought to settle on one way of doing this, which just by virtue of popularity and completeness of the proposal means doing it the Debian way in this case. The Debian way (not sure if it's actually the Ubuntu way) hasn't been widely upstreamed. GCC didn't build for a year or two, and many upstream configure-type scripts still fail. The lib64 approach appears to be less invasive (or Fedora was just better at upstreaming support for it 8-). 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. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Thu, May 23, 2013 at 4:23 PM, Vít Ondruch vondr...@redhat.com 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 system libraries such sqlite3, libxml2, etc. Doesn't matter for the system administrator who has already installed the gem. * Gems does not undergoing legal review, i.e. you have to trust to the author of the gem, that the license is correct, which sadly may not true. Doesn't matter for the system administrator who has already installed the gem. * Bundling, quite common phenomenon. Doesn't matter for the system administrator who has already installed the gem. Just this short list of issues should be enough. It might work for you, when you decide to neglect all the issue mentioned above and probably several else, but it does not work for distribution. Sorry. I don't think this is necessarily targeted at changing how _Fedora_ distributes things; just giving system administrators a single command that works on an installed system might be an useful improvement. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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ý jzel...@redhat.com 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 tools to create spec files from those upstream representations (gem2spec, cpan2spec, ...) Yes, it is true that there sometimes is a different philosophy, but fundamentally is in the eye of the beholder. If there are domain2spec tools available NOW, why would it not be possible technically? The main difference is that most other packaging systems consider it perfectly acceptable to depend on specific version (or even a specific build of a specific version) of package. Fedora generally only ships a single version of every package. Reverse dependencies are expected to be rebuilt against the most recent version. If that is not possible, those reverse dependencies have to be ported over. This is a fundamental cultural difference. The Fedora way requires more work upfront, but in the long term, it scales much better, and it is the only approach that can guarantee you can fix critical bugs for all users who are potentially affected by them. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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. An explanation of them is here: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/IFunc Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 vondr...@redhat.com mailto:vondr...@redhat.com 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 system libraries such sqlite3, libxml2, etc. Doesn't matter for the system administrator who has already installed the gem. * Gems does not undergoing legal review, i.e. you have to trust to the author of the gem, that the license is correct, which sadly may not true. Doesn't matter for the system administrator who has already installed the gem. * Bundling, quite common phenomenon. Doesn't matter for the system administrator who has already installed the gem. Just this short list of issues should be enough. It might work for you, when you decide to neglect all the issue mentioned above and probably several else, but it does not work for distribution. Sorry. I don't think this is necessarily targeted at changing how _Fedora_ distributes things; just giving system administrators a single command that works on an installed system might be an useful improvement. Mirek Ok, so speaking for gem2rpm, it might be made more dumber to include automatically * and if no license is found, then put there foo for example. Actually, everybody is free to do such a template for himself, or even submit such patch upstream, but then the RPM kind of loosing its purpose. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
john.flor...@dart.biz wrote: From: Rahul Sundaram methe...@gmail.com 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 git url with a hash or git tag, we would benefit. Amen to that! I roll my own rpms daily from locally developed sources where we have no policy of pushing tarballs. From everything I've ever been able to figure out, it's necessary for me to make temporary tarballs just to feed rpmbuild. It always seems such a huge waste of time, especially for very large packages. RPM would still be making tarballs behind the scenes, even with better integration with git, wouldn't it? -- you still need the ability to make SRPMs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 methe...@gmail.com 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 git url with a hash or git tag, we would benefit. Amen to that! I roll my own rpms daily from locally developed sources where we have no policy of pushing tarballs. From everything I've ever been able to figure out, it's necessary for me to make temporary tarballs just to feed rpmbuild. It always seems such a huge waste of time, especially for very large packages. RPM would still be making tarballs behind the scenes, even with better integration with git, wouldn't it? -- you still need the ability to make SRPMs. But rpm could just do a git-tar-tree behind the scenes, which sounds easy enough. Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 methe...@gmail.com 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 git url with a hash or git tag, we would benefit. Amen to that! I roll my own rpms daily from locally developed sources where we have no policy of pushing tarballs. From everything I've ever been able to figure out, it's necessary for me to make temporary tarballs just to feed rpmbuild. It always seems such a huge waste of time, especially for very large packages. RPM would still be making tarballs behind the scenes, even with better integration with git, wouldn't it? -- you still need the ability to make SRPMs. But rpm could just do a git-tar-tree behind the scenes, which sounds easy enough. Exactly. 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'd like to see it behave more the way I expected it to when I naively first started rolling my own packages. Specifically, it would be nice if the %Source URI was processed intelligently to automatically retrieve the content via HTTP, FTP, GIT, FILE or whatever (within reason) happens to be specified there. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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-archive There are scripts out there though, it's not a huge amount of engineering. However if you take the next step and ask yourself, why not actually just use git repositories instead of the lookaside pile of tarballs, then you get into the part I found the most tricky with doing continuous integration (and complying with the GPL by mirroring the source you're building), which is recursively mirroring the submodules, and changing the submodule references to point to your local mirror: https://git.gnome.org/browse/gnome-ostree/tree/src/js/vcs.js#n213 Even the Jenkins git plugin doesn't really handle this quite correctly, but the above code has survived a lot of real-world testing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size change in rawhide report
On Thu, 23 May 2013 10:45:50 +0200 Vít Ondruch vondr...@redhat.com 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 reporting the total size changes at the end of the report? Or are the package size change and the total size change just informative/sanity values? Well, I just thought it would be possibly useful if someone wanted to see how much things grow over time. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[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: unspecified Priority: unspecified Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.404 Current version in Fedora Rawhide: 1.402 URL: http://search.cpan.org/dist/SQL-Statement/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=8N8Ga4mfhua=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
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 methe...@gmail.com 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 git url with a hash or git tag, we would benefit. Amen to that! I roll my own rpms daily from locally developed sources where we have no policy of pushing tarballs. From everything I've ever been able to figure out, it's necessary for me to make temporary tarballs just to feed rpmbuild. It always seems such a huge waste of time, especially for very large packages. RPM would still be making tarballs behind the scenes, even with better integration with git, wouldn't it? -- you still need the ability to make SRPMs. But rpm could just do a git-tar-tree behind the scenes, which sounds easy enough. Exactly. 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 what gave you such an idea, rpm certainly does nothing of the sort. The tarball is obviously extracted for building, but what ends up in the src.rpm is the original tarball and the patches defined in the spec - this is the pristine sources principle: http://rpm.org/max-rpm-snapshot/ch-rpm-philosophy.html#S1-RPM-PHILOSOPHY-PRISTINE-SOURCES I'd like to see it behave more the way I expected it to when I naively first started rolling my own packages. Specifically, it would be nice if the %Source URI was processed intelligently to automatically retrieve the content via HTTP, FTP, GIT, FILE or whatever (within reason) happens to be specified there. 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 arbitrary content from the internet without checking checksums at least. - Panu - -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 could go the provides route, it doesn't seem to make sense to me. I suppose I could ask for: Provides: pyface-backend in both PyQt4 and wxPython. Think that would make sense? Add a layer, and it works perfectly: python-pyface: Requires: python-pyface-backend python-pyface-backend-wxPython: Provides: python-pyface-backend Requires: wxPython python-pyface-backend-pyQt4: Provides: python-pyface-backend Requires: pyQt4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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ý jzel...@redhat.com 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 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.mine yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg How is this functionally different from yum reinstall nagios ? Yes, yum/rpm will currently replace files with identical copies but functionally the extra copies are just wasting reinstall time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 virtualized environments. It could gracefully warn users about unsupported environments. It can also be overridden using some switch to force ignore the warning or skip manpages/docfiles as default or at least controlled by a option in yum.conf that would greatly reduce the space on virtualized clusters with 20, 30, 40... fedora setups and in such environemnts you typically need no man command on any of the machines because you maintain them remote from your workstation signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 what gave you such an idea Me neither. Perhaps the apparent slowness with large packages and/or a lack of coffee this morning. , rpm certainly does nothing of the sort. The tarball is obviously extracted for building, but what ends up in the src.rpm is the original tarball and the patches defined in the spec - this is the pristine sources principle: http://rpm.org/max-rpm-snapshot/ch-rpm-philosophy.html#S1-RPM- PHILOSOPHY-PRISTINE-SOURCES You are, of course, right. I actually knew that for srpms. I just tend not to think about the srpms much since for nearly all the builds I do, *I am the upstream* source so I'm really only interested in the binary rpms. I'd like to see it behave more the way I expected it to when I naively first started rolling my own packages. Specifically, it would be nice if the %Source URI was processed intelligently to automatically retrieve the content via HTTP, FTP, GIT, FILE or whatever (within reason) happens to be specified there. 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 arbitrary content from the internet without checking checksums at least. That seems sensible. I guess my biggest wish here in this sub-thread is that building rpms was more streamlined/efficient for use case such as mine where I author and package and only distribute via rpm. The current model imposes a need to self-publish tarballs, even if they only have very short life span in /tmp. If I've got a git clone with everything needed, including a spec file there, I'd like to build an rpm directly from that. I've scripted to meet my use case but it always seems quite hackish for some reason. I guess with the above knowledge about srpms, it's not as bad as first thought. RPM is a great container/delivery system, but it definitely feels like it might be generalized more to handle both the common FOSS model and internal private uses. PS. When I speak of large packages, I don't joke. One terrifying example is something I call mayflower (think early American settlers) which ships an entire livecd-tools generated image along with some magic glue which when this package is installed causes a special initrd to be generated with a dracut module for doing a swap of two livecd images. Install the mayflower rpm, reboot and you get an in-place upgrade just like that. (This is unbelievably useful if you have hundreds or more of nodes running such images in an embedded hardware.) Yeah, I forced a round peg into a very square hole, but it works beautifully. I'm both embarrassed and proud! :-) -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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) - current traffic (req/sec since last refresh). Ex: Status: Processes active: 1, idle: 5, Requests: 765, slow: 2, Traffic: 3.4req/sec Refresh interval is configurable using systemd_interval new option in php-fpm.conf. (systemd WatchDogSec is also honored, but this will require more tests to find a good config.) Please, give it a try (and karma) Remi. P.S. : we'll probably have another RC, and I still hope final 5.5.0 will available, at least as a 0day update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 23 May 2013 17:38, James Antill 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/nagios.cfg How is this functionally different from yum reinstall nagios ? Yes, yum/rpm will currently replace files with identical copies but functionally the extra copies are just wasting reinstall time. 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. -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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. As an example I could do: mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg Thanks for the explanation. I will mark the email and make sure to put the use case to the updated list of RFEs. I would like it even more if RPM keeps a backup copy of every %config file somewhere protected to allow to restore config files even without having the original RPM available, because the RPM might not be available anymore. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 the package. Also, it is explicitly referencing specific implementations, not a generic interface, so a generic Provides in the backend packages is not appropriate. But something like: Requires: ( pkgA || pkgB ) might do the trick. FWIW dpkg can express this kind of dependency, eg: Depends: exim | mail-transport-agent [from: http://www.debian.org/doc/debian-policy/ch-relationships.html] If I remember this right, Debian's implementation uses the short-circuiting OR operator. This makes it possible to express dependencies with an order of preference. For instance, with the example from above: Depends: exim | mail-transport-agent (note that exim has virtual 'mail-transport-agent' provides) If no mail-transport-agent is installed, it drags in exim; otherwise it is happy with any package that has virtual mail-transport-agent provides. This is a case that is not possible to solely express with rpm's virtual provides. If implemented, this would have implications for Fedora. You could have two people who have installed the same package, with a very different set of dependent packages, leading to some sort of combinatorial explosion of QA. yum's depsolver already has some logic that resolves Provides differently depending on what packages are already installed, which makes it highly unpredictable. I don't think QA would get any harder if we get the ability to explicitly express this in the spec files. From http://yum.baseurl.org/wiki/CompareProviders : 1) Candidates from the same srpm as the requiring package are preferred 2) Candidates with names that start the same as the requiring package are favored 3a) Candidates with the same (or similar) arch as the requiring package have more pull than those with a less similar arch 3b) Candidates with the same (or similar) arch as the system have more pulls than those with a less similar arch 3c) Candidates with close relationships to the already installed system (and transaction/requestor) have more pull than those that would require more changes to the installed system 4) In the event of a tie, candidates with very long names will lose the tie 5) In the event they are still tied, they are sorted alphabetically and highest wins (zpkg is picked over apkg). -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 (cannot be deselected) - Default packages (selected, but the user may deselect) - Optional packages (deselected, but the user may select) Borrowing similar logic for rpm we could have in the spec file: Name: acme Requires: foo, foo-utils InstallDefault: bar, perl-bar, python-bar InstallOptional: baz, baz-ldap Now it would be classic to use --with/--without as command line flags, but it's already taken :-( I'm pretty sure that's precisely the distinction expressed by Suggests and Recommends, FWIW. For interactive operations that's how I envision it, yes. When yum lists the packages it's going to install and asks for confirmation, it would list recommended packages and their requirements under Installing because of recommendations, and suggested packages under Suggested packages not being installed. The user can then choose to abort the operation and run the command again, adding some suggested packages to the command line or using --exclude on some of the recommended ones. Because this is an interactive operation, rather than aborting, why not change (y/N) to (y/N/m). If the user chooses m for modify, then yum could ask whether the user wanted to delete a recommended package and, if response is y, show the recommended packages one line at a time for a y or n response. Then yum could ask whether the user wanted to add a suggested package and, if response is y, show the suggested packages one line at a time for a y or n response. Dealing with the modifications interactively would be less annoying than aborting and typing a new yum command full of -- excludes or additional package names. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 in the form of AvrStudio project files. But I think there's a bigger problem here: are you sure that the firmware is GPLv2? It looks like the firmware is under this license[1]. A closer look at that license is probably warranted. The redistribution rights granted look like they're predicated on the purchase of an Arduino, I don't know what that means for Fedora project redistribution. The reverse engineering clause is kind of odd since all of the source is included. The github repo linked seems to match the wifi shield files in the arduino 1.0.5 source distribution (in the folder arduino-1.0.5/hardware/arduino/firmwares/wifishield) Rich [1] https://github.com/arduino/wifishield/blob/master/firmware/wifi_dnld/src/license.txt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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't be removed anymore when uninstalling the package 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 and provide a way to override RPM behavior so that advanced users can make a choice. This is the logic windows installers use but I don't think it's the correct one. The installer should never change behaviour based on a system state that can change over time (unless this state is under its control which is not the case here) I think of this like two categories of machine: 1. Systems that will not change the environment for a very long time and continue to run in either a physical or a virtual environment. 2. Systems that will change the runtime environment occasionally. DB approach works for #1 and fails miserably for #2 (example below). At the same time runtime detection approach works for #1 and works almost right for #2 with few exceptions. Exceptions can be addressed through an override switch. Example: Fedora image running in 'X' virtual environment is moved to 'Y' virtual environment. If 'X' is sticking in the RPM DB, packages intended for 'Y' can't be installed because RPM DB thinks otherwise. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 files in doc, the files in doc won't be removed anymore when uninstalling the package 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 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. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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. - Panu - Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=966715 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
2013/5/22 Björn Persson bj...@xn--rombobjrn-67a.se: 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 should have a way for Yum and Packagekit to say Hey, if you're installing that, maybe you also want this?. A -devel package and its corresponding -doc package should recommend each other for example. They shouldn't require each other, because then they could just as well be the same package, but usually you want to install them together and it would be helpful to at least notify users who install the -devel package that the -doc package also exists. Another example is a database server and its command line client, which you often but not always want to install together. The server should recommend the client, while the client might only suggest the server. A third example is graphical administration tools for some daemon that are in a separate package so that the daemon can be installed without pulling in half a desktop environment. In this case the daemon should suggest the tools, but perhaps not recommend them. The only few times I used Suggests (in Mandriva) was to suggest optional, but better experience/functionality if installed, packages in non-free, but I think I never fully understood what it is supposed to mean, just that it is a Requires that does not break dependencies. Björn Persson Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 /usr/share/man ;) [1] https://github.com/xrgtn/nullfs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 could mount a null-filesystem such as [1] to /usr/share/man ;) Yum's tsflags=nodocs aka rpm's --excludedocs applies to all files flagged as documentation (try 'rpm -qd package' to see them), this happens automatically for man pages as long as they live in normal paths. For example: [pmatilai@mursu ~]$ rpm -qd telnet /usr/share/doc/telnet-0.17/README /usr/share/man/man1/telnet.1.gz [pmatilai@mursu ~]$ - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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/share/doc No it does not avoid man, but you could mount a null-filesystem such as [1] to /usr/share/man ;) Yum's tsflags=nodocs aka rpm's --excludedocs applies to all files flagged as documentation (try 'rpm -qd package' to see them), this happens automatically for man pages as long as they live in normal paths. For example: [pmatilai@mursu ~]$ rpm -qd telnet /usr/share/doc/telnet-0.17/README /usr/share/man/man1/telnet.1.gz [pmatilai@mursu ~]$ - Panu - Whoops, I guess I tried by reinstalling a package, which has the reported side effect... But thanks for clarifying! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size change in rawhide report
On Thu, 23 May 2013 14:47:49 -0400 Rahul Sundaram methe...@gmail.com 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 it is plotted in some way. Yeah, but now the data is there for anyone who would like to do so. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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. Though apparently, if enabled after packages already installed files in doc, the files in doc won't be removed anymore when uninstalling the package 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 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 the much cleaner solution would be as said split packages to packagename and packagename-manuals and tsflags=nodocs is only a hack and if we speak about Software Management call for RFEs it would make a lot of sense if someone uninstalled the man-packages itself not pull -manuals as trigger signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 please file a bug on rpm with exact reproducer steps. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=966715 thanks, i added my comments if i understand this correctly tsflags=nodocs in /etc/yum.conf has the potential to make much more harm by never get rid of docs even if packages are uninstalled after get orphaned or removed or do i get something wrong here? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 avoid man, but you could mount a null-filesystem such as [1] to /usr/share/man ;) sorry but this is a bad bad hack and off-topic in case of Software Management call for RFEs because nobody knows to what this would lead after some dist-upgrades in case of consistency signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 other than to pyface. So, while one could go the provides route, it doesn't seem to make sense to me. I suppose I could ask for: Provides: pyface-backend in both PyQt4 and wxPython. Think that would make sense? Add a layer, and it works perfectly: python-pyface: Requires: python-pyface-backend python-pyface-backend-wxPython: Provides: python-pyface-backend Requires: wxPython python-pyface-backend-pyQt4: Provides: python-pyface-backend Requires: pyQt4 Took me a little bit to realize that no actual code needed to be split out to do this (Sandro's suggestion too much in my mind). But yes, this does the trick nicely, at the expense of some extra dummy packages. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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_Packaging_Guidelines Thanks, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
Re: Software Management call for RFEs
On 05/23/2013 06:05 PM, Simone Caronni wrote: On 23 May 2013 17:38, James Antill ja...@fedoraproject.org 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/nagios.cfg How is this functionally different from yum reinstall nagios ? Yes, yum/rpm will currently replace files with identical copies but functionally the extra copies are just wasting reinstall time. 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 pkg yum install pkg should do what you want (backups of modified config files). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[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
[perl-SOAP-Lite] Add a comment about the bundled IO modules
commit de25d989801c413ad21fae90dfb6c1aab205cabd
Author: Petr Šabata con...@redhat.com
Date: Thu May 23 11:51:23 2013 +0200
Add a comment about the bundled IO modules
perl-SOAP-Lite.spec |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
---
diff --git a/perl-SOAP-Lite.spec b/perl-SOAP-Lite.spec
index 6cbe932..9cae16f 100644
--- a/perl-SOAP-Lite.spec
+++ b/perl-SOAP-Lite.spec
@@ -6,6 +6,7 @@ License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/SOAP-Lite/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MK/MKUTTER/SOAP-Lite-%{version}.tar.gz
+# This shouldn't be needed with 0.717+ (#78489)
Patch0: perl-SOAP-Lite-0.715-IO-modules.patch
Patch1: perl-SOAP-Lite-0.716-test.patch
BuildArch: noarch
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 966500] New: Update Devel-Cover to 1.03
https://bugzilla.redhat.com/show_bug.cgi?id=966500 Bug ID: 966500 Summary: Update Devel-Cover to 1.03 Product: Fedora Version: rawhide Component: perl-Devel-Cover Severity: unspecified Priority: unspecified Assignee: tcall...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com Current perl-Devel-Cover-0.89-5.fc18 will not work with perl 5.18. Please update to latest upstream version 1.03 that fixes this bug. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=HIL7eLgqqIa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Simple] Specify all dependencies
commit 2493421f90a9353911db32a6a321bff6dd7df948
Author: Petr Písař ppi...@redhat.com
Date: Thu May 23 17:06:54 2013 +0200
Specify all dependencies
perl-Pod-Simple.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Pod-Simple.spec b/perl-Pod-Simple.spec
index 23e24f3..7f90bed 100644
--- a/perl-Pod-Simple.spec
+++ b/perl-Pod-Simple.spec
@@ -2,7 +2,7 @@ Name: perl-Pod-Simple
# Epoch to compete with perl.spec
Epoch: 1
Version:3.28
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Framework for parsing POD documentation
License:GPL+ or Artistic
Group: Development/Libraries
@@ -27,6 +27,7 @@ BuildRequires: perl(Symbol)
BuildRequires: perl(Text::Wrap) = 98.112902
BuildRequires: perl(vars)
# Tests:
+BuildRequires: perl(base)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(File::Find)
BuildRequires: perl(lib)
@@ -64,6 +65,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu May 23 2013 Petr Pisar ppi...@redhat.com - 1:3.28-2
+- Specify all dependencies
+
* Mon May 06 2013 Petr Pisar ppi...@redhat.com - 1:3.28-1
- 3.28 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
