Re: Improving the offline updates user experience
On 10/21/2014 10:08 PM, Lennart Poettering wrote: Offline updates are more for the cases where things need to be reliable, because no well educated admin is available to instantly fix things. I will print it an pin up on my notice board. And the implication is that offline updates are not for readers of devel@lists.fedoraproject.org -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
Am 21.10.2014 um 22:08 schrieb Lennart Poettering: On Fri, 12.09.14 18:37, Reindl Harald (h.rei...@thelounge.net) wrote: 1 out of a million cases needs offline updates really - the only good at it is that you can stick at using YUM and decide what you have to do at your own - rarely updates really require a reboot * lsof | grep DEL | grep /usr and restart services on servers Well, some deps are not visible like that, because they do not involve continuous mappings or open fds. may be true but in practice no problem over many years Moreover, it won't help you much anyway, as some daemons are not restarble right now, most prominently dbus-daemon you repeat that again and again while i restart dbus over years on headless machines for web/file/db-servers and frankly before F15 even messagebus was completly disabled on all that machines And strictly speaking as you cannot restart all daemons at the very same instant, or even at the same instant as you install the new files and remove the old ones you will always have races where daemons might make use of resources or interfaces that are either newer than what they expect or older. interesting is that not so long ago there where just not much such dependencies - mandatory presence of dbus is very recent other services like some webapp talking to a db-server? frankly i wrote 10 years ago db-layers to wait and retry so you can restart the db server after an update offline updates are really about make updates fully reliable. Yes, in most cases a "yum update" during runtime works well enough, and yes, I usually do my updates that way too. But I am actually able to help myself if something goes wrong. And so are you. true Offline updates are more for the cases where things need to be reliable, because no well educated admin is available to instantly fix things. Possibly because the machine is used by noobs only, or because the machine is buried somewhere under the see, or where so many instances of the machine are running that a human admins don't scale Hope that makes some sense yes, but keep in mind not introduce more and more dependencies to make them mandatory somewhere in the future signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Fri, 12.09.14 18:37, Reindl Harald (h.rei...@thelounge.net) wrote: > > Am 12.09.2014 um 18:33 schrieb Nathanael d. Noblet: > > So I don't use Firefox anymore but I do know back in the day if we had > > FF open when we updated it would do a double request for each page/form. > > However when updating we just restarted FF and it would work fine after > > that. I've never noticed any other issues than FF but like I said I > > don't use it anymore. > > > > Granted that doesn't matter obviously we don't want that kind of > > behaviour. > > > > I am curious though. Everyone says the only way to do it securely and > > safely is with nothing running. Why can't updates be applied with stuff > > running prior to a reboot? > > 1 out of a million cases needs offline updates > > really - the only good at it is that you can stick > at using YUM and decide what you have to do at your > own - rarely updates really require a reboot > > * lsof | grep DEL | grep /usr and restart services on servers Well, some deps are not visible like that, because they do not involve continuous mappings or open fds. Moreover, it won't help you much anyway, as some daemons are not restarble right now, most prominently dbus-daemon. And strictly speaking as you cannot restart all daemons at the very same instant, or even at the same instant as you install the new files and remove the old ones you will always have races where daemons might make use of resources or interfaces that are either newer than what they expect or older. offline updates are really about make updates fully reliable. Yes, in most cases a "yum update" during runtime works well enough, and yes, I usually do my updates that way too. But I am actually able to help myself if something goes wrong. And so are you. Offline updates are more for the cases where things need to be reliable, because no well educated admin is available to instantly fix things. Possibly because the machine is used by noobs only, or because the machine is buried somewhere under the see, or where so many instances of the machine are running that a human admins don't scale. Hope that makes some sense. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Fri, 12.09.14 10:46, Stephen Gallagher (sgall...@redhat.com) wrote: > It is very common for users to have systems with encrypted root > partitions (or even just /var and /etc). This may be due to a > personal Nitpicking: we currently do not support split-off /etc on Fedora/Dracut. /var may be split out though. > We could significantly improve this situation by allowing the system > to drop directly from the interactive system into the updater > environment without doing a full reboot or relaunching the kernel. > > Lennart, would it be possible to set up a special systemd target for > performing updates that would essentially stop all processes except > for systemd and then apply the updates? Well, the entire logic we have in place for offline updates is to ensure that they are applied in a well-defined very clean, minimal environment. Actually, that's not just the logic that is in place, that's the whole reason for having them at all! I mean, if it is OK to allow leaking runtime state into the upgrade process we could just run the updates in parallel to normal runtime, how we always did things. Or in even otherwords: offline updates are supposed to make update strictly reliable, and for that I figure a full reset and fresh boot, with everything initialized to the boot-up defaults is the closest if not only option. That all said, we have been discussing supporting a new reboot-mode in systemd, which would essentially shut down userspace, until only PID 1 remains, and then immediately start userspace again on the same kernel. This would be pretty close to what you are asking for here... However, so far we have quite some concerns about adding this, precisely for the reason that it pretends to be a reset of everything to the boot-up defaults, but actually isn't, as a ton of runtime state is retained in /sys and /proc/sys and other runtime objects. > [1] I'm told that this might not be necessary; that systemd can > re-exec itself to pick up its own updates. That would reduce the scope > presumably to "only the kernel" forcing reboots. Well, you cannot really do this atomically. Offline updates are about reliability. But you cannot restart userspace reliably during runtime. Think about this: daemons talk to each other, supporting a variety of APIs and API versions. If we want to do an update, then we'd have to restart all daemons at the same instant to ensure that no daemon starts talking with another daemon at the wrong time where it might be confused by either a too old or too new daemon. However, restarten them all at once is not possible. Moreover, some daemons cannot be restarted at all (for example dbus-daemon; and journald is difficult too, as it will lose connections to all other daemon's stdout/stderr if you do, even though it other works fine). Hence: I'd really recommend leaving offline updates as is. I see the problem though and acknowledge the fact that entering the passwords multiple times is annoying. Interestingly hw hdd encryption is nicer there as the keys are not flushed out on resets... Maybe that's actually a strategy to adopt here: upload the encryption keys into the firmware as efi vars, and then pull them out on next boots or so (assuming that efi vars can be marked to survive soft reboots without making them fully persistent...) I understand this is all unsatisfying. Maybe fixing related problems might improve the situation a bit though. For example, I find it quite annoying if we always ask for both a hdd passphrase and a user passphrase at boot. It has been a long-time todo list item for systemd to add the hdd passphrases (with strict expiry) to the kernel keyring and then optionally pull them out there for gdm's autologin mode, so that they can be used for decrypting the gnome keyring and such. However, so far we haven't worked on that yet... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On 2014-10-21 18:11, Daniel P. Berrange wrote: > On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote: >> I assumed that adding them to KEYUTILS_1.4 would be okay because nothing >> would've tried to use them previously because they didn't exist in any >> version. > > One thing to bear in mind with symbol versioning is that it also interacts > with RPM versioning. ie, if an application links to a symbol foo@MYLIB_X.Y > then the RPM will automatically get a "Requires: mylib.so(MYLIB_X.Y)" > added to it. > > This ensures that when you install the application, it pulls in a version > of the library that is new enough to have all the symbols the application > needs. > > Note that RPM only depends on the version, not the full symbol name. So > by adding new symbols to the existing KEYUTILS_1.4 version section, no new > RPM dependancies will be introduced. So an RPM install of an application > that uses the new symbols, will still be (mistakenly) satisfied by the > an old version of the library that lacks the symbols. Within Debian, library source packages can make use of a special versioning system which is used by other packages to calculate dependencies. In this versioning system, every upstream symbol is mapped to the Debian source package version in which this symbol was introduced into the archive. For example, for the two symbols discussed above, we have [...] recursive_key_scan@KEYUTILS_1.4 1.5.2 recursive_session_key_scan@KEYUTILS_1.4 1.5.2 [...] indicating that the two upstream symbols *@KEYUTILS_1.4 where first introduced into Debian with package version 1.5.2 (apparently upstream releases 1.5.0 and 1.5.1 were skipped). Consequently, packages built against libkeyutils1 using those symbols will always depend on a Debian package version of at least 1.5.2, despite them being marked as 1.4 upstream. This allows for a much finer control of package dependency calculation than the default we use. But, of course, this only applies when the package maintainer actually decides to use this feature. Just thought this might be something interesting to share. Regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Fedora 21 Workstation Fedora 21 Server Fedora 21 Cloud That makes it easy for us remixers - CompJournoStick 21 Workstation, for example. On Tue, Oct 21, 2014 at 11:06 AM, Simo Sorce wrote: > On Tue, 21 Oct 2014 08:28:16 -0400 > Stephen Gallagher wrote: > > > Hello folks, > > > > I raised a question with the Board a couple weeks ago[1] as to how we > > should be branding the different releases. It's been clear that > > different groups have different opinions on whether we should call > > something Fedora Server 21 vs. Fedora 21 Server (and Workstation and > > Cloud, of course). > > > > I was asked by the Board to get input from each of the working groups > > as well as marketing and branding folks. I'm sending this to each of > > these lists, but PLEASE keep all replies on the > > devel@lists.fedoraproject.org list or it will be impossible to keep > > track of the replies. (I've set the reply-to header on this email; > > please try not to lose it). > > > > A few specific comments that have been made on the Board ticket (to > > avoid rehashing them). > > > > * "Fedora Server 21" sounds like we've had 21 releases of Fedora > > Server and we certainly haven't. > > * Should we start all of the Products at version 1 and say "built on > > the Fedora 21 platform"? > > > > Anyway, we need to have a consistent branding decision made for the > > release (and for the Ambassadors). So please come prepared to find a > > consensus (not to win a fight). > > > > > > [1] https://fedorahosted.org/board/ticket/11 > > "Fedora 21 - Server" ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick http://j.mp/CompJournoStickOverview Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Mon, 2014-10-13 at 11:26 -0400, Stephen Gallagher wrote: > > > On Thu, 2014-10-02 at 07:53 -0400, Stephen Gallagher wrote: > > > > > > On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote: > > > == The Problem == > > > > > > It is very common for users to have systems with encrypted root > > > partitions (or even just /var and /etc). This may be due to a personal > > > concern for their data or a corporate policy mandating full-disk > > > encryption. Disk encryption requires a password (or other more > > > complicated credentials) be be presented just after the kernel is > > > booted and before the drives can be mounted and their data read. > > > > > > With the current implementation of the offline updates in Fedora, this > > > leads to a very unpleasant user experience when updating. We offer two > > > ways to perform offline updates in the default user environment of > > > Fedora Workstation: "Install updates and reboot" or "Install updates > > > and shut down". > > > > > > With "Install updates and reboot", the behavior is as follows: > > > > > > 1) The system shuts down and initiates an ACPI reboot. > > > 2) The system presents the kernel boot menu and then starts the > > > updater kernel. > > > 3) The system presents the user with a password prompt for the disk > > > encryption (possibly more than one, if the system is configured with > > > different passwords for different partitions). > > > 4) The offline updates occur. > > > 5) The system shuts down and initiates an ACPI reboot. > > > 6) The system presents the kernel boot menu and then starts the > > > standard (possibly updated) kernel. > > > 7) The system presents the user with a password prompt for the disk > > > encryption (possibly more than one, if the system is configured with > > > different passwords for different partitions). > > > 8) The system completes booting. > > > > > > During this experience, the user has been required to enter their disk > > > encryption password *twice*. The same is true for the "Install and > > > shut down" case, except that the two passwords are separated by some > > > actual wallclock time. > > > > > > == Proposed Improvements == > > > > > > We could significantly improve this situation by allowing the system > > > to drop directly from the interactive system into the updater > > > environment without doing a full reboot or relaunching the kernel. > > > > > > Lennart, would it be possible to set up a special systemd target for > > > performing updates that would essentially stop all processes except > > > for systemd and then apply the updates? > > > > > > In an ideal world, it would then also be possible after update is > > > completed to restore operation to the standard boot targets of systemd > > > so that the system comes back up without having to perform a total > > > reboot. The exceptional case would of course be that in which either > > > the kernel, libc or systemd[1] needed to be updated, in which case a > > > reboot could be performed. > > > > > > In this scenario, we can reduce the number of encrypted disk > > > challenges to at most a single one, and that only if absolutely > > > minimal plumbing packages saw an update. > > > > > > I'd very much like to hear from the plumbers on this matter. > > > > > > > > > [1] I'm told that this might not be necessary; that systemd can > > > re-exec itself to pick up its own updates. That would reduce the scope > > > presumably to "only the kernel" forcing reboots. > > > > > > I'm bumping this thread to get comments from Lennart (CCed). There's a > > lot of chatter in the conversation, but I'd very much like to hear an > > answer to the specific questions I posed in this first email. > > Trying one more time to get Lennart to chime in here. I spotted on another mailing list that Lennart is using a different email address these days. I'm now trying to reach him on that one instead. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Broken deps in rawhide (coreutils)
On Tue, 21 Oct 2014 19:23:29 +0200 Miroslav Suchy wrote: > Today I got report that there are failed builds in Copr for rawhide > chroots. [1] ...snip... > And there may be even more examples. You can try it yourself by: > rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/* > /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ > --releasever rawhide install @buildsys-build > --setopt=tsflags=nocontexts --nogpgcheck > > Few days ago it seemed to work. Does somebody have idea what changed > recently? Is is because of some change in rpm, yum, something else? > Why it work in koji [2]? > Why is pam installed before coreutils even when pam have > Requires(post): coreutils, /sbin/ldconfig This is a fun one. I am pointing the finger right now at icecat. It seems to be providing all the nss libraries and 'winning' the dependency. It's making all the buildroots a good deal larger than they need to be, and possibly making them link to the wrong nss/nspr, etc. ;( I'm not sure why koji buildroots aren't busted however, unless it's somehow the hosts yum (in the case of koji, f20 and copr el6) is doing things differently? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: top in Rawhide
On Tue, 2014-10-21 at 19:26 +0200, Miroslav Suchy wrote: > On 10/21/2014 03:33 PM, Richard W.M. Jones wrote: > > Anyone worked out how to get top to give a normal (ie. old) display in > > Rawhide? > > It is in F21 too. > > Type: >tttmmVbz1W > and you get original look and feel. > > For discussion see bug 1153049. Just as a warning to anyone following these instructions, it will alter (or create) ~/.toprc, so if you just want to try it out, skip the last W (capital-'w') so it doesn't write it out. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, 21 Oct 2014 08:28:16 -0400 Stephen Gallagher wrote: > Hello folks, > > I raised a question with the Board a couple weeks ago[1] as to how we > should be branding the different releases. It's been clear that > different groups have different opinions on whether we should call > something Fedora Server 21 vs. Fedora 21 Server (and Workstation and > Cloud, of course). > > I was asked by the Board to get input from each of the working groups > as well as marketing and branding folks. I'm sending this to each of > these lists, but PLEASE keep all replies on the > devel@lists.fedoraproject.org list or it will be impossible to keep > track of the replies. (I've set the reply-to header on this email; > please try not to lose it). > > A few specific comments that have been made on the Board ticket (to > avoid rehashing them). > > * "Fedora Server 21" sounds like we've had 21 releases of Fedora > Server and we certainly haven't. > * Should we start all of the Products at version 1 and say "built on > the Fedora 21 platform"? > > Anyway, we need to have a consistent branding decision made for the > release (and for the Ambassadors). So please come prepared to find a > consensus (not to win a fight). > > > [1] https://fedorahosted.org/board/ticket/11 "Fedora 21 - Server" ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: top in Rawhide
On 10/21/2014 03:33 PM, Richard W.M. Jones wrote: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? It is in F21 too. Type: tttmmVbz1W and you get original look and feel. For discussion see bug 1153049. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken deps in rawhide (coreutils)
Today I got report that there are failed builds in Copr for rawhide chroots. [1] After investigation I find that coreutils are installed too late, so they are not available to previous postcripts: Installing : crypto-policies-20140905-1.git4649b7d.fc22.noarch 136/239 /usr/bin/update-crypto-policies: line 39: cat: command not found /usr/bin/update-crypto-policies: line 43: cat: command not found Couldn't read current profile warning: %post(crypto-policies-20140905-1.git4649b7d.fc22.noarch) scriptlet failed, exit status 1 Non-fatal POSTIN scriptlet failure in rpm package crypto-policies-20140905-1.git4649b7d.fc22.noarch ... Installing : libblkid-2.25.1-1.fc22.x86_64 138/239 /var/tmp/rpm-tmp.yCcv5b: line 4: mkdir: command not found ... Installing : pam-1.1.8-18.fc22.x86_64 143/239 /var/tmp/rpm-tmp.4J2sJD: line 3: /usr/bin/install: No such file or directory warning: %post(pam-1.1.8-18.fc22.x86_64) scriptlet failed, exit status 127 Non-fatal POSTIN scriptlet failure in rpm package pam-1.1.8-18.fc22.x86_64 Installing : coreutils-8.23-4.fc22.x86_64 144/239 This is just small sample, there is much more errors. And it is not just coreutils (but that produce most errors). E.g. I seen errors caused by ordering of libXft too: Installing : pango-1.36.8-1.fc22.x86_64 133/239 /usr/bin/pango-querymodules-64: error while loading shared libraries: libXft.so.2: cannot open shared object file: No such file or directory Installing : libXft-2.3.2-2.fc22.x86_64 134/239 And there may be even more examples. You can try it yourself by: rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/* /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever rawhide install @buildsys-build --setopt=tsflags=nocontexts --nogpgcheck Few days ago it seemed to work. Does somebody have idea what changed recently? Is is because of some change in rpm, yum, something else? Why it work in koji [2]? Why is pam installed before coreutils even when pam have Requires(post): coreutils, /sbin/ldconfig ? Mirek [1] http://copr-be.cloud.fedoraproject.org/results/jwboyer/kernel-playground/fedora-rawhide-x86_64/kernel-3.18.0-0.rc1.git0.1.playground.fc22/root.log [2] https://kojipkgs.fedoraproject.org//packages/kernel/3.18.0/0.rc1.git0.1.fc22/data/logs/i686/root.log -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote:
> Hmm, not sure I follow here. Since when is systemd an optional
> component in Fedora?
I have been spending much of my time building Fedora-based Docker
containers recently. I've been sticking to the
one-process-per-container model because I think it brings a number of
advantages. One of the biggest, in my opinion, is that "container
management" reduces to "process management", and I already have a
great process manager on my host. It's called "systemd".
Decomposing an application into single-process containers also means
that it's easier to scale individual components. *And* for many
applications -- those that can log to stderr/stdout -- it means
that application logs show up in my host journal *where I want them*.
Running any sort of process manager inside the container can also have
the unintended side-effect of hiding problems from the host. If an
application is failing to start because of a configuration issue, I
don't want that managed inside the container -- I want the host to be
aware of that so that higher-level mechanisms can be involved. I want
a host- or cluster- level container manager to be able to restart
dependent containers, or to have the opportunity to reschedule a
container on another host.
I think it is absolutely essential that systemd is *able* to run
inside a container -- because I think there are invariably going to be
situations in which the one-process-per-container model simply doesn't
pan out. But I also think that in many situations it is not required
and using systemd inside the container simply complicates things.
--
Lars Kellogg-Stedman | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpM0qJf6tF8K.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On 10/21/2014 10:59 AM, David Howells wrote: > Is there a good description of ELF shared library symbol versioning best > practices somewhere? If you haven't already read Uli's paper, that's a start: http://www.akkadia.org/drepper/dsohowto.pdf (section 3 in particular) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote: > Is there a good description of ELF shared library symbol versioning best > practices somewhere? > > In particular, under what conditions do you need to create a new section in > the versioning file given to the linker's --version-script option when new > symbols are added? > > And what do you do if you've done it wrong? > > For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when > I should perhaps have created KEYUTILS_1.5 and added them there: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 > > I have been given a patch to move these symbols to KEYUTILS_1.5, but checking > the keyctl program with "readelf -s", I see: > > 47: 0 FUNCGLOBAL DEFAULT UND > recursive_session_key_sca@KEYUTILS_1.4 (7) > > so I would guess applying this patch would break anything that uses this. > > I assumed that adding them to KEYUTILS_1.4 would be okay because nothing > would've tried to use them previously because they didn't exist in any > version. > > David Honestly, I don't think it matters, since the versions are all just arbitrary stings anyway. The fact that you added a symbol to an older version string rather than a new one isn't at all relevant to pre-existing binaries. And existing source code won't care about it if you happen to relink (as you note, older code won't use the new symbol anyway). The only real pain about it is that you need to keep it there now, since binaries linked against that version reference it as @KEYUTILS_1.4. Irritating, maybe. Catastrophic, no. You certainly can do as libvirt does, and explicitly define the export list for every version, and there are some niceties to that, but its really not necessecary. IIRC, Glibc does exactly as you (meant to) do, in that new symbols are added into new version node piecemeal. Neil > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, Oct 21, 2014 at 12:13:19PM -0400, Adam Jackson wrote: > On Tue, 2014-10-21 at 15:59 +0100, David Howells wrote: > > Is there a good description of ELF shared library symbol versioning best > > practices somewhere? > > > > In particular, under what conditions do you need to create a new section in > > the versioning file given to the linker's --version-script option when new > > symbols are added? > > Every time you add _any_ new exported symbol to the API. Every symbol doesn't have to have a new symbol version, it is just fine if there is just one symbol version per release that added symbols, as long as the development snapshots in between releases are not significantly wide-spread/used as stable versions. On stable branches, if you add symbols there, it typically should be that all symbols added together can share the same new symbol version, but for symbols added at different times different symbol versions should be used. > But symbol versions are also permanent; now that there are apps in the > world that want foo@KEYUTILS_1.4, you can never remove that. You could > add it to _1.5 too, but having made the error it's not really fixing > anything to do that. Yeah. You could have foo@KEYUTILS_1.4 as something users can't link to and foo@@KEYUTILS_1.5 if you want. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, 2014-10-21 at 15:59 +0100, David Howells wrote: > Is there a good description of ELF shared library symbol versioning best > practices somewhere? > > In particular, under what conditions do you need to create a new section in > the versioning file given to the linker's --version-script option when new > symbols are added? Every time you add _any_ new exported symbol to the API. > And what do you do if you've done it wrong? > > For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when > I should perhaps have created KEYUTILS_1.5 and added them there: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 > > I have been given a patch to move these symbols to KEYUTILS_1.5, but checking > the keyctl program with "readelf -s", I see: > > 47: 0 FUNCGLOBAL DEFAULT UND > recursive_session_key_sca@KEYUTILS_1.4 (7) > > so I would guess applying this patch would break anything that uses this. > > I assumed that adding them to KEYUTILS_1.4 would be okay because nothing > would've tried to use them previously because they didn't exist in any > version. Since rpm emits dependencies based on imported symbol versions (and not whole version/symbol tuples), the problem this introduces is that an app using this new symbol will only require KEYUTILS_1.4, and some versions of keyutils will provide that version but not all of the symbols _in_ that version. But symbol versions are also permanent; now that there are apps in the world that want foo@KEYUTILS_1.4, you can never remove that. You could add it to _1.5 too, but having made the error it's not really fixing anything to do that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote: > Is there a good description of ELF shared library symbol versioning best > practices somewhere? > > In particular, under what conditions do you need to create a new section in > the versioning file given to the linker's --version-script option when new > symbols are added? For libvirt, we create a new version section for each new upstream release. ie so all new APIs in a release get tagged with the version number of the release they first appeared in. > And what do you do if you've done it wrong? Cry, and then live with it forever, unless you want to break ABI and force all downstream apps to re-link :-( > For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when > I should perhaps have created KEYUTILS_1.5 and added them there: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 > > I have been given a patch to move these symbols to KEYUTILS_1.5, but checking > the keyctl program with "readelf -s", I see: > > 47: 0 FUNCGLOBAL DEFAULT UND > recursive_session_key_sca@KEYUTILS_1.4 (7) > > so I would guess applying this patch would break anything that uses this. Yes, unfortunately anything which has already linked against your library *and* used these original symbols will have the 1.4 version encoded in their ELF section. So if you change the version to 1.5 you will cause linker loading failures which can only be fixed by rebuilding the downstream apps. > I assumed that adding them to KEYUTILS_1.4 would be okay because nothing > would've tried to use them previously because they didn't exist in any > version. One thing to bear in mind with symbol versioning is that it also interacts with RPM versioning. ie, if an application links to a symbol foo@MYLIB_X.Y then the RPM will automatically get a "Requires: mylib.so(MYLIB_X.Y)" added to it. This ensures that when you install the application, it pulls in a version of the library that is new enough to have all the symbols the application needs. Note that RPM only depends on the version, not the full symbol name. So by adding new symbols to the existing KEYUTILS_1.4 version section, no new RPM dependancies will be introduced. So an RPM install of an application that uses the new symbols, will still be (mistakenly) satisfied by the an old version of the library that lacks the symbols. This is the primary reason why for libvirt, we take the approach of always introducing a new version block for each new release that includes new APIs. BTW, there is one tricky thing to be aware of if you ever backport new APIs to old "stable branches". You likely want to avoid adding a linker version section for the stable branch, since if an app links against the stable branch version of the library, you want a clean upgrade path to the next major version of the library (assuming preserved ABI). I've never found any particularly good docs on symbol versioning when I've looked previously. In case it helps though, here's how we deal with it in libvirt: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/ In summary, I'd probably suggest you just live with the symbols as part of the KEYUTILS_1_4 version block. It isn't a particularly serious hardship that those were added to an old version block, so not worth the pain of changing them (unless you plan to break ABI and change soname version anyway). Then for future API additions just define a new version section for each new release that adds APIs. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
2014-10-21 17:06 GMT+02:00 David Timothy Strauss : > Should be Fedora 21 $PRODUCT because the Fedora version is underneath > the product, and one product can usually convert into another on an > installed system. Caution, there is no guarantee that it will always be supported. As far as the Cloud Product is concerned, only conversion to Server Product (aka adopting a cattle) scenario will be supported. And we haven't ruled out yet, different lifecycles for products in the long term. As long as it makes sense and that our infrastructure could cope with it, off course H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request new package
See, that's easy ! :) H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
2014-10-21 16:39 GMT+02:00 Máirín Duffy : > > > On 10/21/2014 09:36 AM, Matthew Miller wrote: >> >> On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: >>> >>> A few specific comments that have been made on the Board ticket (to >>> avoid rehashing them). >>> >>> * "Fedora Server 21" sounds like we've had 21 releases of Fedora Server >>> and we certainly haven't. >>> * Should we start all of the Products at version 1 and say "built on the >>> Fedora 21 platform"? >> >> >> My opinion is that since we've decided on a unified lifecycle and >> release process for now, we should reflect that in the names, so: >> >> Fedora 21 Cloud >> Fedora 21 Server >> Fedora 21 Workstation >> >> but that we should also allow unversioned naming: >> >> Fedora Cloud >> Fedora Server >> Fedora Workstation >> >> In the future, if we have separated release cycles, I think separate >> numbering might make sense, with the "Built on the Fedora 21 platform" >> wording or similar. Possibily date-based schemes for the products — >> but I don't want to get the cart too far ahead of the horse on that. > > > ^^^ This > > From my POV (the designer / branding person,) this is exactly the plan I > support. > Amen This is a fair compromise between having a consistent numbering and a strong product branding. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Should be Fedora 21 $PRODUCT because the Fedora version is underneath the product, and one product can usually convert into another on an installed system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What are the ELF shared lib symbol versioning best practices?
Is there a good description of ELF shared library symbol versioning best practices somewhere? In particular, under what conditions do you need to create a new section in the versioning file given to the linker's --version-script option when new symbols are added? And what do you do if you've done it wrong? For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when I should perhaps have created KEYUTILS_1.5 and added them there: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 I have been given a patch to move these symbols to KEYUTILS_1.5, but checking the keyctl program with "readelf -s", I see: 47: 0 FUNCGLOBAL DEFAULT UND recursive_session_key_sca@KEYUTILS_1.4 (7) so I would guess applying this patch would break anything that uses this. I assumed that adding them to KEYUTILS_1.4 would be okay because nothing would've tried to use them previously because they didn't exist in any version. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Oct 21, 2014, at 9:36 AM, Matthew Miller wrote: > On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: >> A few specific comments that have been made on the Board ticket (to >> avoid rehashing them). >> >> * "Fedora Server 21" sounds like we've had 21 releases of Fedora Server >> and we certainly haven't. >> * Should we start all of the Products at version 1 and say "built on the >> Fedora 21 platform"? > > My opinion is that since we've decided on a unified lifecycle and > release process for now, we should reflect that in the names, so: > > Fedora 21 Cloud > Fedora 21 Server > Fedora 21 Workstation Yes. Since people have a tendency to shorten, I think we'll see "F21C, F21S, F21W" as a result. That's probably better than "FC21" for cloud where it's confused with .fc21 in all of our RPMS, and even vernacular people still interchange F20 and FC20 calling back to Fedora Core days. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-10-22)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-10-22 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1355 Please select Engineering Representiatve for the new Fedora Council .fesco 1355 https://fedorahosted.org/fesco/ticket/1355 See also https://lists.fedoraproject.org/pipermail/devel/2014-October/203391.html #topic #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline .fesco 1322 https://fedorahosted.org/fesco/ticket/1322 = New business = #topic #1357 please consider django-1.7 as late feature for f21 .fesco 1357 https://fedorahosted.org/fesco/ticket/1357 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request new package
There's a guy that created a script for he's own purposes.
So, just to have an idea:
[Unit]
Description=Sheepdog QEMU/KVM Block Storage
After=syslog.target
[Service]
EnvironmentFile=/etc/conf.d/
sheep.conf
ExecStart=/usr/sbin/sheep --pidfile /var/run/sheep.pid ${SHEEP_OPTS}
${SHEEP_PATH}
PIDFile=/var/run/sheep.pid
Type=forking
[Install]
WantedBy=multi-user.target
sheep.conf have this for example:
SHEEP_OPTS="-c local -D -u"
SHEEP_PATH="/var/lib/sheepdog"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes for Env-and-Stacks WG meeting (2014-10-21)
#fedora-meeting: Env and Stacks (2014-10-21) Meeting started by hhorak at 13:02:31 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-21/env-and-stacks.2014-10-21-13.02.log.html . Meeting summary --- * init process (hhorak, 13:02:48) * Follow-up -- Docker docs (hhorak, 13:04:46) * ACTION: hhorak will sum up what we agreed the last time on Docker doc and will write it on the wiki for someone who picks it (hhorak, 13:12:02) * Integration tests for packages alias Per-component integration tests in Fedora (hhorak, 13:13:33) * IDEA: we can divide the complex issue into smaller pieces delivered independently -- first have method/rules to keep tests somewhere and write them somehow and later solve how to run them automatically in proper environment (hhorak, 13:29:48) * IDEA: we might consider not to support only one way to define tests, since different use cases need something different and one size does not fit all (hhorak, 13:38:52) * various Fedora maintainers use different approaches right now for components -- some maintainers keep specs in different branches the same and include '%if %fedora' stuff and some prefer different content in different branches and rather have clean spec files (hhorak, 13:47:09) * IDEA: it might be fine if we are able to stay flexible in that regard as well with tests and just are able to provide some sane recommendation (hhorak, 13:47:09) * IDEA: for software collections -- the tests would just be part of the collection (hhorak, 13:49:20) * ACTION: hhorak will send proposal about integration tests to the devel list (hhorak, 13:51:23) * IDEA: if we are able to provide the integration tests as real upstream projects that other distros could benefit from as well, we can start some nice collaboration and benefit all from that (pretty challenging idea, but might be worth keep in mind) (hhorak, 14:07:29) * Picking chairman for the next meeting (hhorak, 14:15:13) * hhorak is actually not available the next week.. (hhorak, 14:15:34) * let's skip the next week's meeting, since many of use won't be here (hhorak, 14:19:40) * let's leave picking a new time to ML discussion and try a new whenisgood (hhorak, 14:40:18) * ACTION: hhorak will chair the meeting in two weeks.. (hhorak, 14:41:23) Meeting ended at 14:43:35 UTC. Action Items * hhorak will sum up what we agreed the last time on Docker doc and will write it on the wiki for someone who picks it * hhorak will send proposal about integration tests to the devel list * hhorak will chair the meeting in two weeks.. Action Items, by person --- * hhorak * hhorak will sum up what we agreed the last time on Docker doc and will write it on the wiki for someone who picks it * hhorak will send proposal about integration tests to the devel list * hhorak will chair the meeting in two weeks.. * **UNASSIGNED** * (none) People Present (lines said) --- * hhorak (62) * juhp (60) * nphilipp (33) * sicampbell (19) * bkabrda (9) * zodbot (4) * ncoghlan (3) * Southern_Gentlem (1) * samkottler (0) * vpavlin (0) * tjanez (0) * pkovar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On 10/21/2014 09:36 AM, Matthew Miller wrote: On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: A few specific comments that have been made on the Board ticket (to avoid rehashing them). * "Fedora Server 21" sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say "built on the Fedora 21 platform"? My opinion is that since we've decided on a unified lifecycle and release process for now, we should reflect that in the names, so: Fedora 21 Cloud Fedora 21 Server Fedora 21 Workstation but that we should also allow unversioned naming: Fedora Cloud Fedora Server Fedora Workstation In the future, if we have separated release cycles, I think separate numbering might make sense, with the "Built on the Fedora 21 platform" wording or similar. Possibily date-based schemes for the products — but I don't want to get the cart too far ahead of the horse on that. ^^^ This From my POV (the designer / branding person,) this is exactly the plan I support. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LLVM 3.5 rebase
On Tue, 2014-10-21 at 13:33 +0200, Sergio Pascual wrote: > I have retired python-llvmpy in Rawhide and F21. > Now if the owner of llvm does the "Obsoletes trick " then the rebase > can go ahead, is it right? Hopefully! I still need to get dragonegg building, but that at least does have an active upstream. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: top in Rawhide
On Tue, Oct 21, 2014 at 09:47:45AM -0400, Stephen Gallagher wrote: > FWIW, if you press "1" (numeral one), it collapses all the CPUs to a > single line covering all of them. I find that quite helpful. What I really want is one line showing the collapsed view, and a second line showing me if any of the CPUs are pegged at 100% because of some crazy runaway process. Actually, "is there a crazy runaway process or processes making my CPU fan go full blast, and if so, what are they?" is 95% of what I want when I look at top. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: top in Rawhide
On Tue, 2014-10-21 at 14:33 +0100, Richard W.M. Jones wrote: > Anyone worked out how to get top to give a normal (ie. old) display in > Rawhide? > > The default consumes huge amounts of whitespace with a useless display > of per-CPU stats, and [not shown] is completely static until you press 'P'. > > Rich. > > top - 14:20:04 up 3:46, 3 users, load average: 1.65, 1.18, 1.06 > Tasks: 169 total, 1 running, 167 sleeping, 1 stopped, 0 zombie > %Cpu0 : 2.0/13.2 15[ > ] > %Cpu1 : 0.6/60.4 61[ > ] > %Cpu2 : 0.0/0.7 1[ > ] > %Cpu3 : 0.0/1.3 1[| > ] > %Cpu4 : 0.7/1.3 2[| > ] > %Cpu5 : 0.0/3.4 3[|| > ] > %Cpu6 : 0.0/1.3 1[| > ] > %Cpu7 : 9.1/7.116[| > ] > GiB Mem : 2.8/15.726 [ > ] > GiB Swap: 0.0/16.000 [ > ] > > PID USER PR NIVIRTRES %CPU %MEM TIME+ S COMMAND > 6540 root 20 0 204.7m 86.5m 6.5 0.5 2:35.27 D yum > 465 root 20 0 37.8m 21.4m 2.6 0.1 0:11.91 S systemd-journal > 9 root 20 00.0m 0.0m 2.0 0.0 0:38.04 S rcuos/1 > 7274 root 20 00.0m 0.0m 2.0 0.0 0:01.24 S kworker/5:0 > 16102 rjones20 0 108.1m 3.6m 1.3 0.0 0:00.18 R top > 1 root 20 0 10.8m 7.8m 0.7 0.0 0:09.63 S systemd > [etc] > FWIW, if you press "1" (numeral one), it collapses all the CPUs to a single line covering all of them. I find that quite helpful. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: top in Rawhide
On Tue, Oct 21, 2014 at 09:42:30AM -0400, Matthew Miller wrote: > On Tue, Oct 21, 2014 at 02:33:39PM +0100, Richard W.M. Jones wrote: > > Anyone worked out how to get top to give a normal (ie. old) display in > > Rawhide? > > The default consumes huge amounts of whitespace with a useless display > > of per-CPU stats, and [not shown] is completely static until you press 'P'. > > It doesn't seem to be static for me. (Consider using -d1 or -d0.5 if > you like it to update more frequently.) > > In any case, you can get the old display back by pressing 't' several > times to cycle through the options for cpu stats (mnemonic: "task", I > guess) and the same with 'm' for memory info, and then W (for write) to > save the config when you like it. That works, thanks. > You an also edit the ~/.toprc manually, but... it's a horrible format > not meant to be consumed by humans. I see what you mean. Not even in ASCII by the looks of it?! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: top in Rawhide
On Tue, Oct 21, 2014 at 02:33:39PM +0100, Richard W.M. Jones wrote: > Anyone worked out how to get top to give a normal (ie. old) display in > Rawhide? > The default consumes huge amounts of whitespace with a useless display > of per-CPU stats, and [not shown] is completely static until you press 'P'. It doesn't seem to be static for me. (Consider using -d1 or -d0.5 if you like it to update more frequently.) In any case, you can get the old display back by pressing 't' several times to cycle through the options for cpu stats (mnemonic: "task", I guess) and the same with 'm' for memory info, and then W (for write) to save the config when you like it. You an also edit the ~/.toprc manually, but... it's a horrible format not meant to be consumed by humans. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: top in Rawhide
Am 21.10.2014 um 15:33 schrieb Richard W.M. Jones: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? The default consumes huge amounts of whitespace with a useless display of per-CPU stats, and [not shown] is completely static until you press 'P'. after the first time faced "htop" 8 years ago never started "top" again htop is highly configureable in case what you want to see, where and how ordered signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: > A few specific comments that have been made on the Board ticket (to > avoid rehashing them). > > * "Fedora Server 21" sounds like we've had 21 releases of Fedora Server > and we certainly haven't. > * Should we start all of the Products at version 1 and say "built on the > Fedora 21 platform"? My opinion is that since we've decided on a unified lifecycle and release process for now, we should reflect that in the names, so: Fedora 21 Cloud Fedora 21 Server Fedora 21 Workstation but that we should also allow unversioned naming: Fedora Cloud Fedora Server Fedora Workstation In the future, if we have separated release cycles, I think separate numbering might make sense, with the "Built on the Fedora 21 platform" wording or similar. Possibily date-based schemes for the products — but I don't want to get the cart too far ahead of the horse on that. > > Anyway, we need to have a consistent branding decision made for the > release (and for the Ambassadors). So please come prepared to find a > consensus (not to win a fight). > > > [1] https://fedorahosted.org/board/ticket/11 > -- > desktop mailing list > desk...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/desktop -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, Oct 21, 2014 at 08:25:55AM -0500, Rex Dieter wrote: > Stephen Gallagher wrote: > > > Hello folks, > > > > I raised a question with the Board a couple weeks ago[1] as to how we > > should be branding the different releases. It's been clear that > > different groups have different opinions on whether we should call > > something Fedora Server 21 vs. Fedora 21 Server (and Workstation and > > Cloud, of course). > > At least until release schedules and/or branding diverge, I personally think > it more important to continue to emphasize the version over the product (ie, > version should come first), e.g. go with the > Fedora 21 $PRODUCT > variant +1 The difference between Fedora versions is so far much bigger than the difference between products within one version, so this ordering of distribution.version.product seems right. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
top in Rawhide
Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? The default consumes huge amounts of whitespace with a useless display of per-CPU stats, and [not shown] is completely static until you press 'P'. Rich. top - 14:20:04 up 3:46, 3 users, load average: 1.65, 1.18, 1.06 Tasks: 169 total, 1 running, 167 sleeping, 1 stopped, 0 zombie %Cpu0 : 2.0/13.2 15[ ] %Cpu1 : 0.6/60.4 61[ ] %Cpu2 : 0.0/0.7 1[ ] %Cpu3 : 0.0/1.3 1[|] %Cpu4 : 0.7/1.3 2[|] %Cpu5 : 0.0/3.4 3[|| ] %Cpu6 : 0.0/1.3 1[|] %Cpu7 : 9.1/7.116[|] GiB Mem : 2.8/15.726 [ ] GiB Swap: 0.0/16.000 [ ] PID USER PR NIVIRTRES %CPU %MEM TIME+ S COMMAND 6540 root 20 0 204.7m 86.5m 6.5 0.5 2:35.27 D yum 465 root 20 0 37.8m 21.4m 2.6 0.1 0:11.91 S systemd-journal 9 root 20 00.0m 0.0m 2.0 0.0 0:38.04 S rcuos/1 7274 root 20 00.0m 0.0m 2.0 0.0 0:01.24 S kworker/5:0 16102 rjones20 0 108.1m 3.6m 1.3 0.0 0:00.18 R top 1 root 20 0 10.8m 7.8m 0.7 0.0 0:09.63 S systemd [etc] -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Stephen Gallagher wrote: > Hello folks, > > I raised a question with the Board a couple weeks ago[1] as to how we > should be branding the different releases. It's been clear that > different groups have different opinions on whether we should call > something Fedora Server 21 vs. Fedora 21 Server (and Workstation and > Cloud, of course). At least until release schedules and/or branding diverge, I personally think it more important to continue to emphasize the version over the product (ie, version should come first), e.g. go with the Fedora 21 $PRODUCT variant -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, 2014-10-21 at 08:47 -0400, Máirín Duffy wrote: > > On 10/21/2014 08:42 AM, Jaroslav Reznik wrote: > > - Original Message - > >> Hi, > >> > >> On 10/21/2014 08:28 AM, Stephen Gallagher wrote: > >>> * Should we start all of the Products at version 1 and say "built on the > >>> Fedora 21 platform"? > >> > >> Is there any intention to release the products on different schedules? > > > > Definitely not now or in the near future. > > Does any group want to eventually release on a different cycle than the > others? > > I mean I think this is the critical question. Because if the products > are always going to be in sync, having separate version numbers for > Fedora and each of them is going to confuse way more than it clarifies. I cannot speak for the entirety of the Server Working Group, but I've been advocating for Fedora Server to eventually move to a different major release cadence (doing minor releases aligned with the Fedora base though).[1] That being said, the Server WG agreed unanimously that this was not going to be a near-term goal. I suspect at that point we will end up having to re-brand Server in some way (possibly by re-starting the numbering at 1) [1] https://fedoraserver-wgblog.rhcloud.com/proposal-announcement-fedora-server-lifecycle-stable-and-development/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On 10/21/2014 08:42 AM, Jaroslav Reznik wrote: - Original Message - Hi, On 10/21/2014 08:28 AM, Stephen Gallagher wrote: * Should we start all of the Products at version 1 and say "built on the Fedora 21 platform"? Is there any intention to release the products on different schedules? Definitely not now or in the near future. Does any group want to eventually release on a different cycle than the others? I mean I think this is the critical question. Because if the products are always going to be in sync, having separate version numbers for Fedora and each of them is going to confuse way more than it clarifies. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
- Original Message - > Hi, > > On 10/21/2014 08:28 AM, Stephen Gallagher wrote: > > * Should we start all of the Products at version 1 and say "built on the > > Fedora 21 platform"? > > Is there any intention to release the products on different schedules? Definitely not now or in the near future. Jaroslav > ~m > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Hi, On 10/21/2014 08:28 AM, Stephen Gallagher wrote: * Should we start all of the Products at version 1 and say "built on the Fedora 21 platform"? Is there any intention to release the products on different schedules? ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can you help with making fonts awesome in Fedora 21?
On Tue, Oct 21, 2014 at 2:09 PM, Richard Hughes wrote: > On 21 October 2014 12:55, Rajeesh K Nambiar wrote: >> smc-fonts failed to process with 'unrecognized contents' message >> https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/s/smc-fonts-common.log >> What could be the issue? > > Two things look to be the problem: > > > needs to be: > > > മനുഷ്യരെല്ലാവരും > needs to be: > മനുഷ്യരെല്ലാവരും > > Also, if you're making changes upstream (yay! upstream! thanks!) could > you please fix this: > > appstream-util validate /home/hughsie/smc.metainfo.xml > /home/hughsie/smc.metainfo.xml: FAILED: > • style-invalid : does not end in '.|:|!' > • style-invalid : Not enough tags for a good description > > Basically, the description has to end with a dot, and if possible be a > little longer. Thanks. Okay, will fix it upstream and make a new build. Thanks for the quick resolution! > > Richard > -- -- Rajeesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Hello folks, I raised a question with the Board a couple weeks ago[1] as to how we should be branding the different releases. It's been clear that different groups have different opinions on whether we should call something Fedora Server 21 vs. Fedora 21 Server (and Workstation and Cloud, of course). I was asked by the Board to get input from each of the working groups as well as marketing and branding folks. I'm sending this to each of these lists, but PLEASE keep all replies on the devel@lists.fedoraproject.org list or it will be impossible to keep track of the replies. (I've set the reply-to header on this email; please try not to lose it). A few specific comments that have been made on the Board ticket (to avoid rehashing them). * "Fedora Server 21" sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say "built on the Fedora 21 platform"? Anyway, we need to have a consistent branding decision made for the release (and for the Ambassadors). So please come prepared to find a consensus (not to win a fight). [1] https://fedorahosted.org/board/ticket/11 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 Beta blocker bug status report
On Mon, Oct 20, 2014 at 07:10:01PM -0700, Adam Williamson wrote: > * https://bugzilla.redhat.com/show_bug.cgi?id=1099299 - systemd - "fedup > fails to upgrade F20 to F21 or later - infinite loop when starting udev" > - the expected fix for this has been written, but testing is difficult > without it being included in a compose. QA/releng are asking systemd > devs to provide a koji build and Bodhi update with the fix, and we will > pull it into the next compose for testing. Hi Adam, I amended the updates that was in updates-testing with a build that carries four additional patches for #1099299. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can you help with making fonts awesome in Fedora 21?
On 21 October 2014 12:55, Rajeesh K Nambiar wrote: > smc-fonts failed to process with 'unrecognized contents' message > https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/s/smc-fonts-common.log > What could be the issue? Two things look to be the problem: needs to be: മനുഷ്യരെല്ലാവരും needs to be: മനുഷ്യരെല്ലാവരും Also, if you're making changes upstream (yay! upstream! thanks!) could you please fix this: appstream-util validate /home/hughsie/smc.metainfo.xml /home/hughsie/smc.metainfo.xml: FAILED: • style-invalid : does not end in '.|:|!' • style-invalid : Not enough tags for a good description Basically, the description has to end with a dot, and if possible be a little longer. Thanks. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141021 changes
Compose started at Tue Oct 21 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [gorm] gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23 [hadoop] hadoop-common-2.4.1-5.fc22.noarch requires commons-httpclient [hledger] ghc-hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-hledger-devel-0.19.3-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [idris] idris-0.9.9.1-3.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so idris-0.9.9.1-3.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so idris-0.9.9.1-3.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) idris-0.9.9.1-3.fc22.i686 requires ghc(haskeline-0.
Re: Can you help with making fonts awesome in Fedora 21?
On Tue, Oct 21, 2014 at 1:24 PM, Richard Hughes wrote: > On 17 October 2014 10:22, pravin@gmail.com wrote: >> Will be very helpful if you can add "how to test" information as well. i.e. >> after local install package will appear in gnome-software something in bit >> detail. > > You can't actually "preview" metainfo files in the same way as AppData > files; they have to be run through appstream-builder before they are > useful. If you're technically savvy, you can install > appstream-builder, generate some metadata, and then look at the logs, > but the easier way is just to look at my daily rebuilds of rawhide: > https://github.com/hughsie/createrepo_as_logs/ > > For instance, this is Lato: > https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/l/lato-fonts.log smc-fonts failed to process with 'unrecognized contents' message https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/s/smc-fonts-common.log What could be the issue? > > Richard > -- -- Rajeesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141021 changes
Compose started at Tue Oct 21 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) < 0:3.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires libru
Re: LLVM 3.5 rebase
2014-10-21 12:32 GMT+02:00 Kalev Lember : > On 10/21/2014 10:37 AM, Sergio Pascual wrote: > > Just a question. If I retire the package in F21, will it affect the F20 > > F21 upgrade path for those > > who have python-llvmpy installed? > > > > I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy > > that requires llvm 3.4 > > and... fedup will probably ignore python-llvpmy and will go ahead, but > > those that use yum will need to > > uninstall python-llvmpy by hand. Is this correct? > > The usual fix for this is to have something remove the retired package > on upgrades. llvm should be a good candidate for doing the removal since > all python-llvmpy installations already have llvm installed. > > Something like this in llvm spec file: > > Obsoletes: python-llvmpy < 0.12.7-2 > Obsoletes: python3-llvmpy < 0.12.7-2 > > I have retired python-llvmpy in Rawhide and F21. Now if the owner of llvm does the "Obsoletes trick " then the rebase can go ahead, is it right? > -- > Hope this helps, > Kalev > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can you help with making fonts awesome in Fedora 21?
On 17 October 2014 10:22, pravin@gmail.com wrote: > Will be very helpful if you can add "how to test" information as well. i.e. > after local install package will appear in gnome-software something in bit > detail. You can't actually "preview" metainfo files in the same way as AppData files; they have to be run through appstream-builder before they are useful. If you're technically savvy, you can install appstream-builder, generate some metadata, and then look at the logs, but the easier way is just to look at my daily rebuilds of rawhide: https://github.com/hughsie/createrepo_as_logs/ For instance, this is Lato: https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/l/lato-fonts.log Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 21 Beta Go/No-Go Meeting, Thursday, October 23 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 21 Beta. Thursday, October 23, 2014 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." Release Candidate (RC) availability and good QA coverage are prerequisites for the Go/No-Go decision but meeting itself is held in any case. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 21 Beta Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist Fedora 21 Beta blocker bug status report by adamw https://lists.fedoraproject.org/pipermail/devel/2014-October/203591.html We have very tight schedule this time to make Fedora 21 release this year, please help us with blocker bugs, testing and other tasks needed for successful release. So far, many reviews says F21 Alpha is the best Fedora ever! Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LLVM 3.5 rebase
On 10/21/2014 10:37 AM, Sergio Pascual wrote: > Just a question. If I retire the package in F21, will it affect the F20 > F21 upgrade path for those > who have python-llvmpy installed? > > I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy > that requires llvm 3.4 > and... fedup will probably ignore python-llvpmy and will go ahead, but > those that use yum will need to > uninstall python-llvmpy by hand. Is this correct? The usual fix for this is to have something remove the retired package on upgrades. llvm should be a good candidate for doing the removal since all python-llvmpy installations already have llvm installed. Something like this in llvm spec file: Obsoletes: python-llvmpy < 0.12.7-2 Obsoletes: python3-llvmpy < 0.12.7-2 -- Hope this helps, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LLVM 3.5 rebase
2014-10-20 16:19 GMT+02:00 Adam Jackson : > On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote: > > 2014-10-17 16:00 GMT+02:00 Peter Robinson : > > > So I'm OK with retiring python-llvmpy if a patch doesn't appear soon. > > I would be too, but I'm going to want 3.5 in F21, and we have this whole > thing about not retiring packages in a live release. > > So I will retire the package before the window for F21 closes. Just a question. If I retire the package in F21, will it affect the F20 F21 upgrade path for those who have python-llvmpy installed? I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy that requires llvm 3.4 and... fedup will probably ignore python-llvpmy and will go ahead, but those that use yum will need to uninstall python-llvmpy by hand. Is this correct? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request new package
2014-10-21 8:49 GMT+02:00 Valerio Pachera : > 2014-10-20 15:04 GMT+02:00 Richard Shaw : >> On a side note, I played around building a package and noticed that only a >> sysvinit file is provided. Upstream should develop a systemd service file. > > Hi Richard, thank you very much for this note that I reported in the > developer mailing list. > I'll write back as soon as I know if somebody takes care of systemd > service file. > if you know how to start it by hand, it's very easy to write a basic service file. man systemd.service for more informations H. > Valerio. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
