Re: polkit changes in f19
Matthias Clasen wrote: > I just realized that there is a change to the way polkit is packaged in > f19 that spin maintainers should be aware of: the polkit package is just > the service, which only provides the default policy as specified in the > action definitions now. If you want or need support for js rules, you need > to pull in the polkit-js-engine package. I've just made this change for > the desktop spin. I added the dependency to kde-settings, which ships a .rules file. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Hi On Mon, Feb 4, 2013 at 2:31 AM, Kevin Kofler wrote: > For a starter, I propose excluding all new uses of Conflicts (except with > < someEVR versioning where an EVR >= someEVR is already available in the > repository, or if the item being conflicted with is not in Fedora), and > trying to get the existing ones fixed in a reasonable timeframe. > You are putting the cart before the horse. You have to demonstrate its feasible to fix them before excluding future uses. I don't see how it is possible to fix the entire distribution to never use conflicts. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
PPS: Oh, and this: > The /usr/bin/soffice alias is still a problem since (in the Fedora > packages) it would conflict between LibreOffice and Apache OpenOffice: it > is recommended to fix it in the LibreOffice packages too, at least using > the Alternatives system. is just not acceptable. Alternatives is the wrong solution for this (in fact, I'd argue it's always the wrong solution), because it is systemwide. Why can't you just rename or delete /usr/bin/soffice? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
David Tardon wrote: > Hi, > > On Sun, Feb 03, 2013 at 11:26:35PM -0600, Chris Adams wrote: >> Once upon a time, Stephen John Smoogen said: >> > My understanding is that /usr/bin/soffice is a symlink in order to >> > keep backwards maintainability. Personally I say both packages drop it >> > because star office is s 1999. :) >> >> There's more than just soffice: >> >> $ rpm -ql libreoffice-core | grep bin/ | xargs ls -ld >> -rwxr-xr-x. 1 root root 362 Dec 6 18:37 /usr/bin/libreoffice >> -rwxr-xr-x. 1 root root 32 Dec 6 18:37 /usr/bin/ooffice >> -rwxr-xr-x. 1 root root 39 Dec 6 18:37 /usr/bin/ooviewdoc >> lrwxrwxrwx. 1 root root 11 Jan 9 12:46 /usr/bin/openoffice.org -> >> libreoffice >> lrwxrwxrwx. 1 root root 38 Jan 9 12:46 /usr/bin/soffice -> >> /usr/lib64/libreoffice/program/soffice >> -rwxr-xr-x. 1 root root 360 Dec 6 18:37 /usr/bin/unopkg > > There is also /usr/bin/oowriter, oocalc, ooimpress, oodraw and oobase > that belong to other libreoffice-* subpackages. Ugh. That's just one more reason to not allow the Apache fork to be packaged. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
I wrote: > Sandro Mani wrote: >> Can't we simply re-organize the fedoraproject website in such way that >> the download button points to something similar to the current "More >> options" page, maybe with a small description for each desktop like "easy >> to use" / "feature rich and customizable" / "based on the traditional >> desktop" / etc and possibly sorted by popularity, i.e. number of >> downloads? > > +1, I've been asking for that ever since the get-fedora redesign and the > introduction of that misguided direct link to the wrong ISO (GNOME-only > and 32-bit-only). PS: It's actually 64-bit-only now, but that doesn't solve the issue, it'll just be wrong for a different category of users. Whatever you pick, it's always wrong for somebody, which is why bypassing the choice of ISO doesn't make any sense whatsoever. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Rahul Sundaram wrote: > Do you have a proposal to solve it other than excluding all possible > alternative implementations? If so, you should post it and let FPC vote on > it. For a starter, I propose excluding all new uses of Conflicts (except with < someEVR versioning where an EVR >= someEVR is already available in the repository, or if the item being conflicted with is not in Fedora), and trying to get the existing ones fixed in a reasonable timeframe. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Command line arguments depend on locale
Richard W.M. Jones wrote: > You should *always* set LC_ALL=C when running an external command from > another program (and most probably from a shell script too). I think LC_NUMERIC is probably what's wanted in this case, not LC_ALL. Still, command-line arguments depending on LC_NUMERIC (or worse, LC_MESSAGES, which would be entirely the wrong setting to key this off) is very broken. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using rpms for non-root installs
Mátyás Selmeci wrote: > This may be a long shot, but I am interested in repackaging some > RPMs (for example, some of the Globus packages in EPEL, as well as > grid software that my group builds) such that the software in them > may be installed by unprivileged users, or into a non-standard > location such as an NFS share. I'd like to use existing RPMs, > preferably binaries, as a starting point to avoid duplicating work. > (Naturally a lot of post-install scripting would be needed to fix > binaries such that they'd work with the path they were installed > into). For the "unprivileged users" part, it is possible for the admin to give out the org.freedesktop.packagekit.package-install PolicyKit permission, then users can install (but not remove) trusted packages (packages signed with GPG keys already known to the system) systemwide using gnome-packagekit or Apper. But of course, there are drawbacks to that, which is why it's not the default (in fact, it had been the default for a short moment in Fedora 12 and got dropped due to user uproar), and so admins will generally not enable that, unfortunately. :-( In addition, it also only works for third-party repositories if the admin imported the key for them, and at that point he might as well install the packages, too. (There's also an org.freedesktop.packagekit.package-install-untrusted permission, but as an admin, you'd have to be insane to give that permission to your users, it's essentially the same as giving them root access, because they can craft any package running any arbitrary code and install it with that permission.) So in your case, it's not all that helpful, unfortunately. But I still wanted to point out the possibility. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Jaroslav Reznik wrote: > = Features/ApacheOpenOffice = > https://fedoraproject.org/wiki/Features/ApacheOpenOffice > > Feature owner(s): Andrea Pescetti > > Add Apache OpenOffice, the free productivity suite, to Fedora. A big -1 to this feature, and in fact I'd urge FESCo to veto that package outright (or if it somehow already made it into Fedora, to get it blocked in Koji and Obsoleted by libreoffice ASAP). Rationale: * What benefit does this package have over LibreOffice, to justify carrying 2 packages doing essentially the same thing? * OpenOffice is a huge package and a big strain on our build system (Koji); IMHO, having 2 versions of it would be a gigantic waste of resources. * LibreOffice is clearly the community version to be preferred: - All major distros support it. - Red Hat people work on it. - AFAIK, it has more features. whereas Apache OpenOffice is the fork Oracle created to remove control over the project from the community, after Oracle had refused for months to cooperate with the community (and for those months, LibreOffice had been the only version being developed at all). (I consider it a big mistake on the part of Apache to have accepted that trojan horse "donation". They should have pointed Oracle to the existing LibreOffice project instead. I really don't see why OpenOffice.org had to be donated to Apache when basically all the existing non-Oracle developers were involved in LibreOffice instead and when all that was needed was assigning the OpenOffice trademark to them.) PS: I wonder if there's any connection between this feature and the MariaDB feature (or rather, Oracle's negative response to it). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Matej Cepl wrote: > We don’t (unfortunately?) have policy to stop somebody from packaging > whatever they want (if it satisfies Fedora packaging policy). FESCo can explicitly veto a package or category of packages, see kernel modules. Why would it not be possible to ban forks of LibreOffice by FESCo decision? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi,
On Sun, Feb 03, 2013 at 11:26:35PM -0600, Chris Adams wrote:
> Once upon a time, Stephen John Smoogen said:
> > My understanding is that /usr/bin/soffice is a symlink in order to
> > keep backwards maintainability. Personally I say both packages drop it
> > because star office is s 1999. :)
>
> There's more than just soffice:
>
> $ rpm -ql libreoffice-core | grep bin/ | xargs ls -ld
> -rwxr-xr-x. 1 root root 362 Dec 6 18:37 /usr/bin/libreoffice
> -rwxr-xr-x. 1 root root 32 Dec 6 18:37 /usr/bin/ooffice
> -rwxr-xr-x. 1 root root 39 Dec 6 18:37 /usr/bin/ooviewdoc
> lrwxrwxrwx. 1 root root 11 Jan 9 12:46 /usr/bin/openoffice.org ->
> libreoffice
> lrwxrwxrwx. 1 root root 38 Jan 9 12:46 /usr/bin/soffice ->
> /usr/lib64/libreoffice/program/soffice
> -rwxr-xr-x. 1 root root 360 Dec 6 18:37 /usr/bin/unopkg
There is also /usr/bin/oowriter, oocalc, ooimpress, oodraw and oobase
that belong to other libreoffice-* subpackages.
>
> I expect that AOO would want oofice, ooviewdoc, and openoffice.org. I
> don't know what unopkg is.
unopkg is a standalone tool for managing extensions. It can be used from
command line (e.g., "unopkg list --bundled") or as GUI ("unopkg gui").
D.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Martin Sourada wrote: > and supposedly AOO is rather popular, though I don't have any hard > numbers, just a hearsay Apache OpenOffice is popular because some people missed the LibreOffice rename and don't realize they're actually using an inferior fork when they download "OpenOffice". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Kevin Fenzi wrote: > Because the current mysql maintainers are keeping it around for f19 as > an option and others have expressed interest in taking over maintaining > it. Do we really have to do this? Having 2 conflicting packages which are drop- in replacements of each other in the repository is just useless! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Jaroslav Reznik wrote: > = Features/Cinnamon as Default Desktop = > https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop > > Feature owner(s): Eric Smith > > This feature proposes that Fedora switch the default desktop interface > from Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that is > more familiar to Windows and Gnome 2 users than the standard Gnome Shell > interface, while being built from Gnome 3 components. So my feelings about this are mixed: While: * I disagree about the need for a default, or at least about emphasizing the default as much as we do now (direct ISO link etc.), * I think KDE Plasma Desktop would be the better default (see also https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default , which I had proposed for Fedora 16, but which got summarily rejected due to lack of endorsement by the rest of KDE SIG), I support this feature anyway, just because it is not GNOME 3 ;-) , or more accurately, because it is about defaulting to a more traditional desktop than the very unconventional gnome-shell. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Adam Williamson wrote: > 2. Can't we just not have a default? > > Not really. Others have touched on this, but the websites team really > wants the simplicity of a straightforward 'Download' link that gets you > a live image, and that pretty much requires a default desktop. And just because the websites team "wants" that nonsense, we have to keep it? Seriously? That one-click download is utter nonsense: No matter what you pick, it will always be the wrong thing for many people. The step to actually pick the correct download cannot be skipped. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Matthias Clasen wrote: > - Cinnamon started out as 'using GNOME components', but it is [now] a full > fork of mutter, gnome-shell and nautilus, at least, and bug-fixes are not > going either way... Those are applications which form the workspace, not random "components". I'm fairly sure that when they speak about reusing GNOME components, they really mean the libraries and the standalone applications, not the workspace. (For those familiar with KDE, what they're forking is only the GNOME equivalent of kde-workspace and not all the other components of GNOME.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Sandro Mani wrote: > Can't we simply re-organize the fedoraproject website in such way that the > download button points to something similar to the current "More options" > page, maybe with a small description for each desktop like "easy to use" / > "feature rich and customizable" / "based on the traditional desktop" / etc > and possibly sorted by popularity, i.e. number of downloads? +1, I've been asking for that ever since the get-fedora redesign and the introduction of that misguided direct link to the wrong ISO (GNOME-only and 32-bit-only). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Eric Smith wrote: > On 01/28/2013 08:47 AM, Máirín Duffy wrote: >> I think switching the desktop that has been our default for over 10 >> years and 18 releases requires just a bit more research and reason >> than that. ~m > > I don't disagree with the "more research and reason" part, but the > current default desktop has only been "our default" for four releases, > F15 through F18. I don't recall any serious "research and reason" > having been involved in the switch that occurred when F15 was being > developed. As far as I can tell, it was just thrust upon us without > much consideration as to whether it was good, bad, or indifferent. My > proposal is at least only that, a proposal, and is not being thrust upon > anyone without discussion and ultimately a vote. +1, what is the default now is a very different (and much less popular) beast from what had been the default for "over 10 years". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
M. Edward (Ed) Borasky wrote: > I love GNOME 3 and detest KDE 4. I've tried MATE and Cinnamon on both > Linux Mint and Fedora and don't really see the point of either of them > as long as GNOME 3 offers fallback mode. Fallback mode is going away in F19, it's already gone upstream. > When you come right down to it, nearly all Linux desktops can be > easily customized to provide a Windows-like workflow (menu at lower > left, panel at bottom) or a Mac-like workflow (menu at upper left, > panel at top). All the major Linux desktops can do this. I've even > done this with OpenBox and fbpanel. I don't think that'd be suitable for end users at all. > You *do* need a good terminal app - I'd pick gnome-terminal over > konsole or lxterminal or the XFCE terminal if I had a choice but I > could live with any of them. Xterm is even acceptable if you have a > 3-button mouse. ;-) But other than that, an awful lot of the > "innovation" in Linux desktops seems to me to be wasted effort. End users are NOT terminal junkies. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Once upon a time, Stephen John Smoogen said: > My understanding is that /usr/bin/soffice is a symlink in order to > keep backwards maintainability. Personally I say both packages drop it > because star office is s 1999. :) There's more than just soffice: $ rpm -ql libreoffice-core | grep bin/ | xargs ls -ld -rwxr-xr-x. 1 root root 362 Dec 6 18:37 /usr/bin/libreoffice -rwxr-xr-x. 1 root root 32 Dec 6 18:37 /usr/bin/ooffice -rwxr-xr-x. 1 root root 39 Dec 6 18:37 /usr/bin/ooviewdoc lrwxrwxrwx. 1 root root 11 Jan 9 12:46 /usr/bin/openoffice.org -> libreoffice lrwxrwxrwx. 1 root root 38 Jan 9 12:46 /usr/bin/soffice -> /usr/lib64/libreoffice/program/soffice -rwxr-xr-x. 1 root root 360 Dec 6 18:37 /usr/bin/unopkg I expect that AOO would want oofice, ooviewdoc, and openoffice.org. I don't know what unopkg is. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Hi > > But the fact that the packages conflict should stand in the way. > We don't have any guidelines that forbids it. > I don't see how having 2 packages which are drop-in replacements of each > other and ship conflicting files (requiring the packages to Conflict with > each other at RPM level) is helpful in any way. We already have too many > Conflicts in the repository. > Do you have a proposal to solve it other than excluding all possible alternative implementations? If so, you should post it and let FPC vote on it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Remi Collet wrote: > - if you don't like fork of MySQL, why do you fork other projects ? > MW include a forked version of vsqlite++ > (and AFAIK, upstream is not aware of your changes / need) Another project Oracle effectively forked in OpenOffice.org, by refusing to donate the OpenOffice.org trademark to the LibreOffice project that had formed (with basically all the non-Oracle OpenOffice.org contributors), but donating the whole thing to Apache instead (who sadly accepted that poisoned "donation"). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Jóhann B. Guðmundsson wrote: > If the current maintainers orphan mysql anyone can pick it up including > Oracle employees and continue it's maintenance within the distribution. > > Any beef, competition or what not between Red Hat and Oracle ( or anyone > else for that matter ) is between Red Hat and Oracle not Fedora and I > cant imagine FESCO/Board standing in the way of Oracle wanting to > packaging and maintain anything in the distribution unless it breaks > some legal jargon just like everyone else. But the fact that the packages conflict should stand in the way. I don't see how having 2 packages which are drop-in replacements of each other and ship conflicting files (requiring the packages to Conflict with each other at RPM level) is helpful in any way. We already have too many Conflicts in the repository. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Jóhann B. Guðmundsson wrote: > Users are better of keeping /home on a separated partition and re-use it > with an fresh install then those poor attempts to "support" upgrades one > way or another which at this point in time we cant do since the bits for > that aren't properly aligned to make that happen... Reinstalling all the time is a no go. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
drago01 wrote: > I doubt that you can install all packages without hitting conflicts. That just shows again how Conflicts are evil and how we're way too tolerant about them. There should be NO conflicting packages in the official repositories. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
drago01 wrote: > And the major issue with yum upgrades is that online upgrades can fail > not only based on what you have installed but also what is currently > running and it cannot handle stuff like usermove without user > intervention. 1. That's a problem with UsrMove, not with yum! 2. UsrMove CAN be done online, e.g. with a C program (which won't care if you move ld.so under it after it's already in memory), or – with some trickery – even in shell. It was an explicit decision to require that useless dracut step. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Jaroslav Reznik wrote: > = Features/FedoraUpgrade = > https://fedoraproject.org/wiki/Features/FedoraUpgrade > > Feature owner(s): Miroslav Suchý > > Upgrade Fedora to next version using yum upgrade. I agree this should be officially supported, but: > I propose to have FedUp and FedoraUpgrade in Fedora 19. not using that FedoraUpgrade script. Sorry, but IMHO, that script causes more problems than it solves. For one, it's a one step approach, whereas the IMHO nicest solution, which is IMHO the best compromise between safety and minimum downtime, and which also works if you don't have working networking outside of user sessions (NM user connection), is the following: yum --releasever=n+1 --downloadonly distro-sync telinit 3 yum --releasever=n+1 -C distro-sync which cannot be done in a single script (the telinit would kill the script if it's run from the graphical session). (And sorry Lennart for using telinit 3 rather than whatever the native systemd equivalent is. ;-) ) In addition, not all the things the script does are strictly required and wanted by all users, and finally, I don't think the steps are so tedious as to deserve automation. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Lennart Poettering wrote: > Ah, so you have to reboot anyway, so where is the difference between > your approach and proper offline updates then? Either way you have to > interrupt your work to reboot the machine. One just takes a slight bit > longer for rebooting... That yum is tested every day and known to work, whereas FedUp is experimental and incomplete (no signature checking) code. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Lennart Poettering wrote: > The thing is that doing on-line updates only works for stuff you can > restart, and that doesn't mind that things are not atomically > updated. However, much (most?) of our code isn't like that. Anybody who > tried to update the Firefox RPM while it is running knows that this > doesn't end well, and you frequently have to manually kill firefox to > get it back into a usual state. Strawman alert! Who ever said that this feature is about online upgrades? Even the "Upgrading Fedora using yum" wiki page clearly says that upgrades should be done in runlevel 3 (multi-user.target), not in runlevel 5 (graphical.target). The point of using yum to upgrade is not to do it in a running user session, but to use the same frequently-tested code paths as for normal updates rather than a special distro-upgrade-only one where half of the functionality has to be reimplemented differently (see e.g. FedUp not supporting something as basic as signature checks; why do we even bother signing our packages if we're happy to deliver an "official" and "recommended" upgrade method which won't even bother checking them?). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Bruno Wolff III wrote: > Note that this doesn't fix problems caused by dropped packages, that block > other packages from being updated. That's a problem for all upgrade methods, they might leave your system with broken dependencies instead of erroring out, but in the end the problem is always there. It's not solvable as long as we're as happy to drop packages as we are now, rather than keeping them working by rebuilding them even if there's no active maintainer. > One possiblity here would be to create a special package that obsoletes > all of the dropped packages from the last release (or two depending on how > far back you want to yum update from). Please no! Many of those packages keep working just fine. And where not, it's better to get a clear error message and to remove the offending packages manually and explicitly than to have the upgrade silently (well, with a one-line notice buried under many other lines of text) removing a package one may be depending on! > There are going to be some releases where you need to do things outside of > yum to upgrade. Then that's a problem with the feature which requires you to do that, and should be a showstopper! (Yes, I think UsrMove should not have been allowed.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Sun, Feb 3, 2013 at 8:04 PM, Toshio Kuratomi wrote: > On Mon, Feb 04, 2013 at 12:15:43AM +0400, Pavel Alexeev wrote: > > 01.02.2013 00:17, drago01 wrote: > > > > On Thu, Jan 31, 2013 at 8:10 PM, Adam Williamson < > awill...@redhat.com> wrote: > > > > On Thu, 2013-01-31 at 14:20 +0100, Robert Mayr wrote: > > > > > > I think that's not the point, one of the two suites will be > dominant > > and you can't provide both of them on a live image for > example. > > LibreOffice was introduced to our live images and we hit > target 1GB, > > do you really think it could be useful having a larger image > just > > because you want to provide both of the office suites? > > > > The proposal explicitly says that it doesn't envisage including > OO on > > any images or in any default install configurations, simply > adding it as > > an option in the package repositories. > > > > Which doesn't really need a FESCo approval ... just a package review. > > > > Meantime there one sentence which optionally require changes in > LibreOffice > > too: " The /usr/bin/soffice alias is still a problem since (in the Fedora > > packages) it would conflict between LibreOffice and Apache OpenOffice: > it is > > recommended to fix it in the LibreOffice packages too, at least using the > > Alternatives system." > > > > I think it should be approved first if it really required. > > alternatives is the wrong technology for end user facing applications. > Why can't our apache openoffice package rename /usr/bin/soffice? > > -Toshio > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Why not LibreOffice? It doesn't make a lot of sense to retain the soffice binary name for LibreOffice anyway. Besides, I think LibreOffice would be more amenable to a permanent binary name change than Apache OpenOffice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On 3 February 2013 19:04, Toshio Kuratomi wrote: >> I think it should be approved first if it really required. > > alternatives is the wrong technology for end user facing applications. > Why can't our apache openoffice package rename /usr/bin/soffice? > My understanding is that /usr/bin/soffice is a symlink in order to keep backwards maintainability. Personally I say both packages drop it because star office is s 1999. :) -- Stephen J Smoogen. "Don't derail a useful feature for the 99% because you're not in it." Linus Torvalds "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Mon, Feb 04, 2013 at 12:15:43AM +0400, Pavel Alexeev wrote: > 01.02.2013 00:17, drago01 wrote: > > On Thu, Jan 31, 2013 at 8:10 PM, Adam Williamson > wrote: > > On Thu, 2013-01-31 at 14:20 +0100, Robert Mayr wrote: > > > I think that's not the point, one of the two suites will be > dominant > and you can't provide both of them on a live image for example. > LibreOffice was introduced to our live images and we hit target > 1GB, > do you really think it could be useful having a larger image just > because you want to provide both of the office suites? > > The proposal explicitly says that it doesn't envisage including OO on > any images or in any default install configurations, simply adding it > as > an option in the package repositories. > > Which doesn't really need a FESCo approval ... just a package review. > > Meantime there one sentence which optionally require changes in LibreOffice > too: " The /usr/bin/soffice alias is still a problem since (in the Fedora > packages) it would conflict between LibreOffice and Apache OpenOffice: it is > recommended to fix it in the LibreOffice packages too, at least using the > Alternatives system." > > I think it should be approved first if it really required. alternatives is the wrong technology for end user facing applications. Why can't our apache openoffice package rename /usr/bin/soffice? -Toshio pgp0b3m5XWHyJ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi Martin, Am Donnerstag, den 31.01.2013, 13:28 +0100 schrieb Martin Sourada: > Also, since Apache took over OpenOffice.org and put it out of > incubation, it seems the development has been progressing rather well > and in a different direction than LibreOffice. While both started from > the same point, they're going to be different office suites with > different feature sets, different UIs, different devs, etc. > I hope it's not to far OT: Could you give a link about the (future) differences between OO and LO (besides the Symphony donation / Symphony UI), especially the different feature set? I tried Google hard but couldn't find distinctive information. By the way: As I learnt on Linux Day last year, LibreOffice still depends on OpenOffice and is in the process to rebase their code to OpenOffice 3.4 (or something alike). So I'm wondering about different set of features. Thanks Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: libkkc - a new Japanese Kana Kanji input library
Jaroslav Reznik wrote, at 01/28/2013 08:27 PM +9:00: = Features/libkkc = https://fedoraproject.org/wiki/Features/libkkc Feature owner(s): Daiki Ueno libkkc, a new Japanese Kana Kanji input library, will be available in Fedora 19, along with an IBus input method engine which uses libkkc as backend (ibus- kkc). Hello, Ueno-san: I tried ibus-kkc and it seems to be working to a certain degree. So does this Feature mean that the default input method (for Japanese) will be changed from ibus-anthy to ibus-kkc? If so, I think it is better that wiki page explicitly suggest so. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership
03.02.2013 21:48, Kevin Fenzi wrote: On Sun, 03 Feb 2013 18:32:58 +0400 Pavel Alexeev wrote: 29.01.2013 10:59, lakshminaras2...@gmail.com wrote: I am releasing ownership of the following packages due to lack of time chm2pdf -- A tool to convert CHM files to PDF files I have taken this one. Strange, but can't do it for Fedora 17. It somehow got marked depreciated instead of just orphaned. I've fixed it and you should be able to take it now... Thank you. I have taken it too. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
01.02.2013 17:38, Matej Cepl wrote: On 2013-01-31, 22:07 GMT, Chris Adams wrote: I'm not saying having both is a bad thing, but I would like to think that there's some thought given to "does Fedora gain from having both", since there is a cost involved. We don’t (unfortunately?) have policy to stop somebody from packaging whatever they want (if it satisfies Fedora packaging policy). Unfortunately? Isn't it is freedom really? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
01.02.2013 00:17, drago01 wrote: On Thu, Jan 31, 2013 at 8:10 PM, Adam Williamson wrote: On Thu, 2013-01-31 at 14:20 +0100, Robert Mayr wrote: I think that's not the point, one of the two suites will be dominant and you can't provide both of them on a live image for example. LibreOffice was introduced to our live images and we hit target 1GB, do you really think it could be useful having a larger image just because you want to provide both of the office suites? The proposal explicitly says that it doesn't envisage including OO on any images or in any default install configurations, simply adding it as an option in the package repositories. Which doesn't really need a FESCo approval ... just a package review. Meantime there one sentence which optionally require changes in LibreOffice too: " The /usr/bin/soffice alias is still a problem since (in the Fedora packages) it would conflict between LibreOffice and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too, at least using the Alternatives system." I think it should be approved first if it really required. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130203 changes
Misc stuff: [bootconf] - was deprecated without properly blocking. Filed: https://fedorahosted.org/rel-eng/ticket/5466 to have it blocked. [epiphany-extensions] - still needs blocking/EOL See bug: https://bugzilla.redhat.com/show_bug.cgi?id=875234 [ghc-wai-extra] - still needs some new packages to land. ghc-searchstring - https://bugzilla.redhat.com/show_bug.cgi?id=885348 (done) ghc-wai-logger - https://bugzilla.redhat.com/show_bug.cgi?id=885349 (in review) ghc-data-cache - https://bugzilla.redhat.com/show_bug.cgi?id=885350 (in review) ghc-byte-logger - https://bugzilla.redhat.com/show_bug.cgi?id=894558 (new) [mysql] - fallout from MariaDB landing? [eclipse-linuxtools] - This will never work. kernel-debuginfo doesn't really exist anywhere. Needs maintainer help. [spacewalk-web] - Nothing provides perl(Spacewalk::Setup) [rubygem-net-ping] - Nothing provides rubygem(net-ldap) < 0:0.3 [mygui] - Nothing provides libCommon.so() anymore [root] - needs gfal fixed. Rebuilt by me: 4ti2 bibletime springlobby leechcraft gearbox mapnik octave Failed scratch builds: compat-gcc-34 - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925378 couchdb - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925381 dragonegg - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925384 fawkes - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925393 fcitx-keyboard - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925395 flowcanvas - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925397 frysk - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925402 gcc-python-plugin - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925404 gdcm - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925409 gfal - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925413 gnome-applets - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925421 libextractor - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925429 libgda - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925432 maliit-plugins - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925433 matreshka - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925443 media-explorer - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925446 meshmagic - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925448 mingw-qpid-cpp - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925454 mumble - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925456 openttd - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925470 plplot - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925473 ppl - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925476 pyicu - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925477 rygel - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925487 scala - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925492 tex-musitex - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925499 the-board - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925500 vfrnav - http://koji.fedoraproject.org/koji/taskinfo?taskID=4925504 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Hi On Sun, Feb 3, 2013 at 2:29 PM, Reindl Harald wrote: > useful to count what? > > you need users ACTIVELY use it > you need users ACTIVELY use it after dist-upgrades > This isn't true. There is a cron job that continues to keep the profile updated > > the only thing smolt stats are showing is that someone > used something with no reference if he still use the > same after a year - these numbers does not prove anything > We aren't looking for proof or 100% reliable numbers as much as observing some general trends because that's the best we can do without violating the privacy of users. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Am 03.02.2013 20:22, schrieb Pierre-Yves Chibon: > On Sun, 2013-02-03 at 17:53 +0100, Reindl Harald wrote: >> >> Am 03.02.2013 17:50, schrieb M. Edward (Ed) Borasky: >>> Fedora used to have Smolt and there are tools to figure out what >>> packages people use. There's no reason Fedora *can't* be data driven, >>> but there's a whole lot of "business" process stuff you'd need to >>> commit to for it to work without wasting precious energy and hours of >>> pointless arguments. ;-) >> >> data like from smolt are useless! > > For you maybe, but I have had a discussion at the last FUDCon where > someone actually said it was useful to him. > Please avoid generalization. useful to count what? you need users ACTIVELY use it you need users ACTIVELY use it after dist-upgrades the only thing smolt stats are showing is that someone used something with no reference if he still use the same after a year - these numbers does not prove anything signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Sun, 2013-02-03 at 17:53 +0100, Reindl Harald wrote: > > Am 03.02.2013 17:50, schrieb M. Edward (Ed) Borasky: > > Fedora used to have Smolt and there are tools to figure out what > > packages people use. There's no reason Fedora *can't* be data driven, > > but there's a whole lot of "business" process stuff you'd need to > > commit to for it to work without wasting precious energy and hours of > > pointless arguments. ;-) > > data like from smolt are useless! For you maybe, but I have had a discussion at the last FUDCon where someone actually said it was useful to him. Please avoid generalization. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Am 03.02.2013 19:18, schrieb Rahul Sundaram: > Hi > > On Sun, Feb 3, 2013 at 11:53 AM, Reindl Harald wrote: > > data like from smolt are useless! > > i maintain around 40 fedora-setups which are never touching > any fedora-machine because of internal repos and it is countless > how many machines are often installed with one ISO download > > > Smolt profiles are not based on ISO downloads or repository connections, so I > am not sure why you bring these up to show that all this stats are useless? 98% of all machines i maintain are CLONES virtual ones as also phyical ones you believe someone starts smolt manually on a clone to raise up any statistics? not really! fact is you have NO NUMBERS at all for opensource you only could have them with spyware - god beware signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
> you believe someone starts smolt manually on a clone > to raise up any statistics? not really! > > fact is you have NO NUMBERS at all for opensource > That is not true. We have some numbers. They are not 100% accurate and we never claim it will be. You are misleading users by talking about ISO downloads when noone is counting those. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Hi On Sun, Feb 3, 2013 at 11:53 AM, Reindl Harald wrote: > data like from smolt are useless! > > i maintain around 40 fedora-setups which are never touching > any fedora-machine because of internal repos and it is countless > how many machines are often installed with one ISO download > Smolt profiles are not based on ISO downloads or repository connections, so I am not sure why you bring these up Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using rpms for non-root installs
Hello. Yum also may be used with --installroot=root I have used yum and rpm on that kind with aliases for current user to install software from repositories on shared hosting absolutely without root privileges. In most cases it works, except some cases when particular binaries looks say own config files by fixed path (/etc/appname/default.conf). In such situation you may deep look documentation about config configuration options, environment variables and so. As last alternative before start patching source code you may also just patch elf binary to replace that path by some with the same length (I have done it by compose symlynks appropriately). In any case, it some sort of hacks and depend from you really needs. If it intended for other users and predictable reproducible results you should patch software to bring them configurability in some way. And offer such patches to upstream also will be good idea. 31.01.2013 11:40, Michael Stahnke пишет: You actually may have an option. It's dirty, and here be dragons. I know this from working on RPM on AIX, so again, it's hacky. I did this on a CentOS 6.3 box for my example, should work on Fedora. You can do something like: ls zip-3.0-1.el6.x86_64.rpm mkdir $HOME/.myrpm cp -pr /var/lib/rpm/* $HOME/.myrpm/ chown -R $USER $HOME/.myrpm/ rpm -Uvh --justdb --dbpath $HOME/.myrpm zip-3.0-1.el6.x86_64.rpm rpm2cpio < zip-3.0-1.el6.x86_64.rpm | cpio -idmv rpm -q --dbpath $HOME/.myrpm zip Results: [vagrant@localhost ~]$ rpm -q --dbpath /home/vagrant/.myrpm zip zip-3.0-1.el6.x86_64 [vagrant@localhost ~]$ rpm -q zip package zip is not installed You now have zip installed (and rooted) in $HOME. You'd have to add the --dbpath option to rpm any time you used it, and it would get out of sync with the system rpm database unless you wrote some tooling around that. But it's completely do-able. Again, it's ugly and I don't recommend it. stahnma -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership
On Sun, 03 Feb 2013 18:32:58 +0400 Pavel Alexeev wrote: > 29.01.2013 10:59, lakshminaras2...@gmail.com wrote: > > I am releasing ownership of the following packages due to lack of > > time > > > > chm2pdf -- A tool to convert CHM files to PDF files > > > I have taken this one. > Strange, but can't do it for Fedora 17. It somehow got marked depreciated instead of just orphaned. I've fixed it and you should be able to take it now... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
01.02.2013 00:42, James Hogarth wrote: Is it? http://blog.mariadb.org/explanation-on-mariadb-10-0/ and http://blog.mariadb.org/mariadb-10-0-and-mysql-5-6/ seem to suggest that MariaDB will no longer be following Mysql as religiously as the feature suggests I'd still say yes since the context of this discussion is mysql 5.5 to mariadb 5.5 and nothing to do with mysql 5.6 and the time for mariadb 10/11 to become fully compatible to what's brought to the table in that which was the relevant discussion in those blog posts... And if someone is using upstream themselves they are responsible to manage that ... and assuming the versioned obsoletes is used as discussed yesterday then there would be no accidental overwrite and compatibility if mysql-5.6 is on the system and the admin updated without thinking... Is it really hard maintain both? May be it have worth also package and support Percona with XtraDB? James -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Am 03.02.2013 17:50, schrieb M. Edward (Ed) Borasky: > Fedora used to have Smolt and there are tools to figure out what > packages people use. There's no reason Fedora *can't* be data driven, > but there's a whole lot of "business" process stuff you'd need to > commit to for it to work without wasting precious energy and hours of > pointless arguments. ;-) data like from smolt are useless! i maintain around 40 fedora-setups which are never touching any fedora-machine because of internal repos and it is countless how many machines are often installed with one ISO download signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, Feb 1, 2013 at 12:46 PM, Peter Jones wrote: > On Tue, Jan 29, 2013 at 04:25:05AM -0800, Dan Mashal wrote: >> I'm sure QA, releng, docs, etc will go with what the community decides. >> >> Lets have a poll. A very public one. >> >> On the main website. Not somebody's blog. And let's let the users decide >> what they want. > > Do we have any significant data that even a plurality of our *users* visit > our main website on a regular - or any - basis? > > I have my doubts that all that many do, much less that we've got data that > tells us that such a poll would result in meaningful data. > > -- > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Do we have a team dedicated to goals and objectives for the website, SEO, social media "marketing", analytics, key performance indicators, marketing funnel, all that good stuff? Fedora used to have Smolt and there are tools to figure out what packages people use. There's no reason Fedora *can't* be data driven, but there's a whole lot of "business" process stuff you'd need to commit to for it to work without wasting precious energy and hours of pointless arguments. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick http://j.mp/CompJournoStick/ The National Coal Institute reminds you, "There's no fuel like an old fuel." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.8: error: invalid use of undefined type
W dniu 02.02.2013 10:55, Orcan Ogetbil pisze: > On Sat, Feb 2, 2013 at 4:33 AM, Julian Sikorski wrote: >> Hi, >> >> I am having issues building mplayer using gcc-4.8. An updated srpm [1] >> builds fine in mock for fedora-18-x86_64-rpmfusion_free target (when >> chain-built with ffmpeg-1.1.1), but on >> fedora-rawhide-x86_64-rpmfusion_free, it fails with the following error: >> >> libvo/vo_png.c: In function 'config': >> libvo/vo_png.c:135:9: error: invalid use of undefined type 'enum >> AVPixelFormat' >> avctx->pix_fmt = imgfmt2pixfmt(format); >> ^ >> >> Full build log is attached. How do I fix this issue? Thank you in advance. >> > > First, it would be easier to get an answer from the mplayer or ffmpeg > mailing lists. My second suggestion is to search for the definition of > that enum (AVPixelFormat) and add an #include to the corresponding > header file. > > Good luck, > Orcan > Problem solved, it was a false alarm. Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Corrected license specification of the gprolog package
hello, due a mistake the license tag of the gprolog package specify a wrong license. The gprolog package should be licensed under the GPLv2+ instead of GPLv2. I have corrected the wrong license specification on all currently maintained fedora distributions. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Virtio RNG
On 02/01/2013 04:39 PM, Bill Nottingham wrote: > Jaroslav Reznik (jrez...@redhat.com) said: >> Feature owner(s): Cole Robinson , Amit Shah >> >> >> Provide a paravirtual random number generator to virtual machines, to >> prevent >> entropy starvation in guests. >> >> == Detailed description == >> The linux kernel collects entropy from various non-deterministic hardware >> events, like mouse and keyboard input, and network traffic. This entropy is >> then >> exposed through /dev/random, commonly used by cryptographic applications >> that >> need true randomness to maintain security. However if more entropy is being >> consumed than is being produced, we have entropy starvation: reading from >> /dev/random will block, which can cause a denial of service. A common >> example >> here is use of /dev/random by SSL in various services. >> >> VirtIO RNG (random number generator) is a paravirtualized device that is >> exposed as a hardware RNG device to the guest. Virtio RNG just appears as a >> regular hardware RNG to the guest, which the kernel reads from to fill its >> entropy pool. This effectively allows a host to inject entropy into a guest >> via >> several means: The default mode uses the host's /dev/random, but a physical >> HW >> RNG device or EGD (Entropy Gathering Daemon) source can also be used. > Amit can give more authoritative answers, but here's my understanding: > What exactly feeds /dev/random in the guest in the cases where this doesn't > exist, Same things that feed entropy on a physical machine: VM keyboard + mouse movement, VM hardware events, etc. The entropy starvation risk isn't much different for a headless server VM than for a headless server physical machine, AIUI. > and how do we cope with this obviously making /dev/random exhaustion > in the host much more likely? (Other than assume that a HW RNG is in the > host.) > The default mode of pulling from host /dev/random certainly does not scale unless there's something feeding your host's entropy pool. And this won't be enabled by default, just new opt in functionality. I think anyone with a non-trivial setup and need for more entropy in their guests will use this to share a single hwrng or a more involved setup with EGD. Peter Krempa, who is implementing the libvirt side of things, had some ideas about a virt entropy daemon that could do more advanced rate limiting to stave off entropy exhaustion across hosts/guests: https://www.redhat.com/archives/libvir-list/2012-December/msg00937.html > Given FIPS paranoia about RNG sources, does this have knock-on effects in > the FIPS compliance of guests depending on how it's fed in the host? No clue about that, I've added that to the comments section of the feature page. Thanks, cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: releasing ownership (maintainers/co-maintainers required)
I would like take dvtm and pstreams-devel. 29.01.2013 05:37, Rakesh Pandit wrote: Hi, I haven't been able to keep up maintenance of packages for year plus now and I don't see myself doing that for next 6-7months more. Right now I am too busy with university course work. But I will come back and contribute in free time after summers. My co-maintainers have done wonderful work in taking care of some of important packages. I request existing fedora packagers if they can take up these packages. For packages which already have active co-maintainers already, you can collaborate with them. Some of these packages will need lot of work and few are worth even dropping. As soon as packagers can claim them in this thread I will drop ownership. I will keep myself co-maintain for few packages (will request from new owners). Mayavi -- The Mayavi scientific data 3-dimensional visualizer acheck -- Check common localisation mistakes acheck-rules -- Rules for acheck bunny -- Instrumented C code security fuzzer code2html -- Convert source code to HTML coredumper -- Library to create core dumps cpptest -- A portable and powerful and simple unit testing framework for C++ ctemplate -- A simple but powerful template language for C++ dayplanner -- An easy and clean Day Planner django-mako -- Mako Templates Plugin for Django djvulibre -- DjVu viewers, encoders, and utilities dnrd -- A caching, forwarding DNS proxy server dvtm -- Tiling window management for the console enet -- Thin, simple and robust network layer on top of UDP examiner -- Utility to disassemble and comment foreign executable binaries flickcurl -- C library for the Flickr API freeimage -- Multi-format image decoder library fuse-zip -- Fuse-zip is a fs to navigate, extract, create and modify ZIP archives gedit-plugins -- Plugins for gedit gflags -- Library for commandline flag processing ginac -- C++ library for symbolic calculations gnaural -- A multi-platform programmable binaural-beat generator gnucap -- The Gnu Circuit Analysis Package jed -- Fast, compact editor based on the S-Lang screen library libao -- Cross Platform Audio Output Library libeXosip2 -- A library that hides the complexity of using the SIP protocol libkml -- A KML library written in C++ with bindings to other languagues libogg -- The Ogg bitstream file format library libosip2 -- oSIP is an implementation of SIP linphone -- Phone anywhere in the whole world by using the Internet lynis -- Security and system auditing tool nebula -- Intrusion signature generator ntop -- A network traffic probe similar to the UNIX top command octave -- A high-level language for numerical computations opencv -- Collection of algorithms for computer vision ortp -- A C library implementing the RTP protocol (RFC3550) pdf2djvu -- PDF to DjVu converter perl-Search-Xapian -- Xapian perl bindings php-markdown -- Markdown implementation in PHP php-oauth -- PHP Authentication library for desktop to web applications php-pear-Auth -- Authentication provider for PHP php-xmpphp -- XMPPHP is the successor to Class.Jabber.PHP pstreams-devel -- POSIX Process Control in C++ python-AppTools -- Enthough Tool Suite Application Tools python-EnthoughtBase -- Core package for the Enthought Tool Suite python-EnvisageCore -- Extensible Application Framework python-EnvisagePlugins -- Plug-ins for the Envisage framework python-Traits -- Explicitly typed attributes for Python python-TraitsBackendQt -- PyQt backend for Traits and TraitsGUI python-TraitsGUI -- Traits-capable windowing framework python-durus -- A Python Object Database python-setupdocs -- Setuptools plugin ratproxy -- A passive web application security assessment tool sitecopy -- Tool for easily maintaining remote web sites stardict-dic-hi -- Hindi dictionary for stardict svgalib -- Low-level fullscreen SVGA graphics library taskcoach -- Your friendly task manager tinyxml -- A simple, small, C++ XML parser txt2rss -- Convert from txt to rss unhide -- Tool to find hidden processes and TCP/UDP ports from rootkits up-imapproxy -- University of Pittsburgh IMAP Proxy uriparser -- URI parsing library - RFC 3986 xsel -- Command line clipboard and X selection tool zile -- Zile Is Lossy Emacs Regards, -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: releasing ownership (maintainers/co-maintainers required)
29.01.2013 06:51, Richard Shaw wrote: On Mon, Jan 28, 2013 at 7:37 PM, Rakesh Pandit wrote: tinyxml -- A simple, small, C++ XML parser I've requested this one in pkgdb. It is interesting and small library and there I found tends to bundle it in other packages which is not listed as exception: $ repoquery --whatprovides '*/tinyxml.h' | sort -u aqsis-debuginfo-0:1.8.2-1.fc18.x86_64 astromenace-debuginfo-0:1.2-17.fc18.x86_64 cal3d-devel-0:0.11.0-13.fc18.i686 cal3d-devel-0:0.11.0-13.fc18.x86_64 clish-debuginfo-0:0.7.3-4.1.i686 clish-debuginfo-0:0.7.3-4.1.x86_64 clish-devel-0:0.7.3-4.1.i686 clish-devel-0:0.7.3-4.1.x86_64 fife-devel-2:0.3.3r3-3.fc18.i686 fife-devel-2:0.3.3r3-3.fc18.x86_64 gource-debuginfo-0:0.38-1.fc18.x86_64 ldview-debuginfo-0:4.2-34.1.i686 ldview-debuginfo-0:4.2-34.1.x86_64 openclonk-debuginfo-0:5.2.2-14.1.i686 openclonk-debuginfo-0:5.2.2-14.1.x86_64 simspark-debuginfo-0:0.2.3-3.fc18.x86_64 tinyxml-devel-0:2.6.1-4.fc18.i686 tinyxml-devel-0:2.6.1-4.fc18.x86_64 I think you should address it, at least fill appropriate bugs for corresponded maintainers. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130203 changes
On 02/03/2013 10:25 PM, Fedora Rawhide Report wrote: Compose started at Sun Feb 3 08:17:07 UTC 2013 Broken deps for x86_64 -- [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) With the fallback mode being dropped for GNOME 3.8, should this be retired? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership
29.01.2013 10:59, lakshminaras2...@gmail.com wrote: I am releasing ownership of the following packages due to lack of time chm2pdf -- A tool to convert CHM files to PDF files I have taken this one. Strange, but can't do it for Fedora 17. emacs-slime -- The superior lisp interaction mode for emacs gnome-guitar -- A small suite of applications for the guitarist griffith -- Media collection manager phatch -- Photo batch processor python-chm -- Python package for CHM files handling stow -- Manage the installation of software packages from source xcftools -- Command-line tools for extracting information from XCF files xcftools not orphaned. -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130203 changes
Compose started at Sun Feb 3 08:17:07 UTC 2013 Broken deps for x86_64 -- [4ti2] 4ti2-1.3.2-12.fc18.x86_64 requires libglpk.so.0()(64bit) [bibletime] bibletime-2.9.1-3.fc18.x86_64 requires libicuuc.so.49()(64bit) bibletime-2.9.1-3.fc18.x86_64 requires libicui18n.so.49()(64bit) [bootconf] bootconf-1.4-6.fc18.noarch requires grub [compat-gcc-34] compat-gcc-34-c++-3.4.6-24.fc17.x86_64 requires libstdc++ < 0:4.8.0 [couchdb] couchdb-1.2.1-2.fc19.x86_64 requires libicuuc.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicui18n.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicudata.so.49()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eclipse-linuxtools] eclipse-systemtap-1.2.0-4.fc19.noarch requires kernel-debuginfo [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [fawkes] fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) [fcitx-keyboard] fcitx-keyboard-0.1.3-1.fc18.x86_64 requires libicuuc.so.49()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [frysk] frysk-0.4-37.fc19.x86_64 requires libgcj.so.13()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gearbox] gearbox-10.11-2.fc18.i686 requires libIceUtil.so.34 gearbox-10.11-2.fc18.x86_64 requires libIceUtil.so.34()(64bit) [gfal] gfal-1.14.0-1.fc18.i686 requires libgsoap.so.2 gfal-1.14.0-1.fc18.x86_64 requires libgsoap.so.2()(64bit) gfal-doc-1.14.0-1.fc18.x86_64 requires libgsoap.so.2()(64bit) gfal-python-1.14.0-1.fc18.x86_64 requires libgsoap.so.2()(64bit) [ghc-wai-extra] ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSwai-1.2.0.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSvoid-0.5.6-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSvault-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSunix-2.5.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHStime-1.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHStext-0.11.2.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSparsec-3.1.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSmtl-2.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSmonad-control-0.3.1.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSlifted-base-0.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSinteger-gmp-0.4.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHShttp-types-0.6.11-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHShashable-1.1.2.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.fc18.x86_64 requires libHSfilepath-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-5.f
Re: Proposed F19 Feature: Virtio RNG
Il 02/02/2013 14:49, Björn Persson ha scritto: > Paolo Bonzini wrote: >> If you're talking about RDRAND, it doesn't hand out entropy. That's >> RDSEED, which will only come with Haswell. >> >> RDRAND only hands out random numbers. > > Huh? "Random numbers" is pretty much synonymous to "entropy" in the > cryptographic language I'm used to. > > Ah, according to this: > http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed > RDRAND doesn't output random numbers, only pseudorandom numbers. I > suppose that's what you meant. Yes, you're right. Paolo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Public apology the community
It takes a brave soul to publicly apologize. And thank you Jared for the great advice, I feel like I owe one as well but not in this thread. Dan On Sunday, February 3, 2013, Jared K. Smith wrote: > On Sat, Feb 2, 2013 at 6:32 PM, "Jóhann B. Guðmundsson" > > wrote: > > Last night I let my feelings getting best of me got drunk, went out of > line, > > generally behaved dishonorably and in the process disrespected the > community > > and the people in it. > > Thank you for realizing you had stepped over the line, and issuing a > public apology. I think that was a very noble thing to do... I know > you get frustrated at times, but if you don't mind some unsolicited > advice from Fedora contributor to another, please try to keep your > comments focused on the technical details of what's wrong or right, > and not on *who* is wrong or right. > > -- > Jared Smith > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Public apology the community
On Sat, Feb 2, 2013 at 6:32 PM, "Jóhann B. Guðmundsson" wrote: > Last night I let my feelings getting best of me got drunk, went out of line, > generally behaved dishonorably and in the process disrespected the community > and the people in it. Thank you for realizing you had stepped over the line, and issuing a public apology. I think that was a very noble thing to do... I know you get frustrated at times, but if you don't mind some unsolicited advice from Fedora contributor to another, please try to keep your comments focused on the technical details of what's wrong or right, and not on *who* is wrong or right. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glpk soname bump expected?
On Sat, 02 Feb 2013 19:54:23 -0700, Orion Poplawski wrote: > Looks like going from glpk 4.47 to 4.48 bumped the soname from > libglpk.so.0 to libglpk.so.33. Something tells me this was not expected > and is not correct. Can this be verified? > Could be an accident in the upstream tarball indeed, because I only checked that it's not a package where the spec file messes with the soname and the library links. rpmsodiff and rpmsoname are helpful for library maintainers! http://koji.fedoraproject.org/koji/rpminfo?rpmID=3671777 /usr/lib64/libglpk.so 17 /usr/lib64/libglpk.so.3317 /usr/lib64/libglpk.so.33.0.0978392 http://koji.fedoraproject.org/koji/rpminfo?rpmID=3220245 /usr/lib64/libglpk.so 17 /usr/lib64/libglpk.so.0 17 /usr/lib64/libglpk.so.0.32.0962056 -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc5.git2.1.fc19.x86_64 loadavg: 0.63 0.56 0.38 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, Feb 1, 2013 at 12:46 PM, Peter Jones wrote: > On Tue, Jan 29, 2013 at 04:25:05AM -0800, Dan Mashal wrote: >> I'm sure QA, releng, docs, etc will go with what the community decides. >> >> Lets have a poll. A very public one. >> >> On the main website. Not somebody's blog. And let's let the users decide >> what they want. > > Do we have any significant data that even a plurality of our *users* visit > our main website on a regular - or any - basis? > > I have my doubts that all that many do, much less that we've got data that > tells us that such a poll would result in meaningful data. > > -- > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Why would they when all they see is Gnome Gnome Gnome? It's much easier to google "Fedora 18 DVD" or just go to http://dl.fedoraproject.org Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
