About the proposed final blocker regarding DrKonqi (1301092)
Hi folks. Just a note for the next blocker review... Yesterday I've proposed this: https://bugzilla.redhat.com/show_bug.cgi? id=1301092 As Rex pointed out, this bug is present on F23 and it isn't reproducible on Rawhide. I can confirm the app seems to work properly on F24 (should have paid more attention before proposing, sorry!) So... For the next meeting... Please remember it clearly isn't a blocker and should be rejected; there is no need to investigate further. It's just a mystake of mine :-). Thank you --- Giulio (juliuxpigface) -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Fedora 22 updates-testing report
The following Fedora 22 Security updates need testing: Age URL 319 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5878 echoping-6.1-0.beta.r434svn.1.fc22 268 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9185 ceph-deploy-1.5.25-1.fc22 201 https://bodhi.fedoraproject.org/updates/FEDORA-2015-12781 python-kdcproxy-0.3.2-1.fc22 155 https://bodhi.fedoraproject.org/updates/FEDORA-2015-16239 nagios-4.0.8-1.fc22 149 https://bodhi.fedoraproject.org/updates/FEDORA-2015-05490fc42d squid-3.4.13-3.fc22 144 https://bodhi.fedoraproject.org/updates/FEDORA-2015-2d37e7dacf openstack-swift-2.2.0-6.fc22 113 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0552500cd7 python-pygments-2.0.2-3.fc22 113 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9039c25f1d miniupnpc-1.9-6.fc22 95 https://bodhi.fedoraproject.org/updates/FEDORA-2015-7dfbe09bb4 libpng-1.6.16-4.fc22 95 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6c07ab1fa6 libpng-1.6.16-5.fc22 77 https://bodhi.fedoraproject.org/updates/FEDORA-2015-3a5cebb105 ImageMagick-6.9.2.7-1.fc22 67 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6efa349a85 subversion-1.8.15-1.fc22 62 https://bodhi.fedoraproject.org/updates/FEDORA-2015-b9e4c97ff1 sos-3.2-2.fc22 36 https://bodhi.fedoraproject.org/updates/FEDORA-2015-f683150aa0 thttpd-2.25b-37.fc22 30 https://bodhi.fedoraproject.org/updates/FEDORA-2016-1323b9078a bind99-9.9.8-2.P3.fc22 24 https://bodhi.fedoraproject.org/updates/FEDORA-2016-4c57c232c0 xulrunner-44.0-1.fc22 12 https://bodhi.fedoraproject.org/updates/FEDORA-2016-560802e52b xdelta-3.0.7-7.fc22 11 https://bodhi.fedoraproject.org/updates/FEDORA-2016-3a2606f993 rubygem-rails-html-sanitizer-1.0.1-2.fc22 11 https://bodhi.fedoraproject.org/updates/FEDORA-2016-cb30088b06 rubygem-activesupport-4.2.0-4.fc22 11 https://bodhi.fedoraproject.org/updates/FEDORA-2016-fa0dec2360 rubygem-actionview-4.2.0-3.fc22 11 https://bodhi.fedoraproject.org/updates/FEDORA-2016-94e71ee673 rubygem-activemodel-4.2.0-2.fc22 rubygem-actionpack-4.2.0-3.fc22 11 https://bodhi.fedoraproject.org/updates/FEDORA-2016-73fe05d878 rubygem-activerecord-4.2.0-2.fc22 10 https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0c2412ab2 postgresql-9.4.6-1.fc22 7 https://bodhi.fedoraproject.org/updates/FEDORA-2016-49bf88cd29 GraphicsMagick-1.3.23-1.fc22 gdl-0.9.5-10.fc22 octave-3.8.2-19.fc22 vdr-skinenigmang-0.1.2-27.fc22 vdr-skinnopacity-1.1.3-9.fc22 vdr-tvguide-1.2.2-9.fc22 7 https://bodhi.fedoraproject.org/updates/FEDORA-2016-0609474cf6 389-ds-base-1.3.4.8-1.fc22 7 https://bodhi.fedoraproject.org/updates/FEDORA-2016-5cb344dd7e community-mysql-5.6.29-1.fc22 7 https://bodhi.fedoraproject.org/updates/FEDORA-2016-e21be93421 gummi-0.6.6-1.fc22 5 https://bodhi.fedoraproject.org/updates/FEDORA-2016-868c170507 mariadb-10.0.23-1.fc22 5 https://bodhi.fedoraproject.org/updates/FEDORA-2016-1c08d77b96 qt-creator-3.6.0-6.fc22 qca-2.1.1-4.fc22 code-editor-2.8.1-13.fc22 monotone-1.1-13.fc22 botan-1.10.12-1.fc22 5 https://bodhi.fedoraproject.org/updates/FEDORA-2016-c97f297cd6 hamster-time-tracker-2.0-0.3.rc1.fc22 5 https://bodhi.fedoraproject.org/updates/FEDORA-2016-be042f7e6f qemu-2.3.1-12.fc22 5 https://bodhi.fedoraproject.org/updates/FEDORA-2016-a25ee90150 graphite2-1.3.5-1.fc22 1 https://bodhi.fedoraproject.org/updates/FEDORA-2016-11c1d0fc69 pcs-0.9.149-1.fc22 1 https://bodhi.fedoraproject.org/updates/FEDORA-2016-24d134e494 mingw-nsis-2.50-1.fc22 1 https://bodhi.fedoraproject.org/updates/FEDORA-2016-962c0d156d libreoffice-4.4.7.2-3.fc22 1 https://bodhi.fedoraproject.org/updates/FEDORA-2016-6a006e78d9 thunderbird-38.6.0-1.fc22 The following Fedora 22 Critical Path updates have yet to be approved: Age URL 194 https://bodhi.fedoraproject.org/updates/FEDORA-2015-13210 yum-3.4.3-508.fc22 113 https://bodhi.fedoraproject.org/updates/FEDORA-2015-2123de044f libgphoto2-2.5.8-1.fc22 109 https://bodhi.fedoraproject.org/updates/FEDORA-2015-48f718ed1b vim-7.4.909-1.fc22 95 https://bodhi.fedoraproject.org/updates/FEDORA-2015-6c07ab1fa6 libpng-1.6.16-5.fc22 95 https://bodhi.fedoraproject.org/updates/FEDORA-2015-7dfbe09bb4 libpng-1.6.16-4.fc22 49 https://bodhi.fedoraproject.org/updates/FEDORA-2016-46b611abb8 httpd-2.4.18-1.fc22 24 https://bodhi.fedoraproject.org/updates/FEDORA-2016-4c57c232c0 xulrunner-44.0-1.fc22 21 https://bodhi.fedoraproject.org/updates/FEDORA-2016-16a5625f33 kernel-4.3.5-200.fc22 19 https://bodhi.fedoraproject.org/updates/FEDORA-2016-d3fce30d64 mobile-broadband-provider-info-1.20151214-1.fc22 11 https://bodhi.fedoraproject.org/updates/FEDORA-2016-1ec4dabbd5 pcre-8.38-2.fc22 11 https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a3cd0a405 enca-1.18-1.fc22 5
Re: A modest proposal: Pungi 4 compose process (what we call composes, when we do them, what information we need about them)
On Mon, 2016-02-22 at 10:04 -0800, Adam Williamson wrote: > > > Also not visible in the mockup: "compose override" packages are *always > > > included in all types of compose*. This is the concept Dennis and I > > > came up with for handling blocker / freeze exception fixes; it's just a > > > more formal version of the current process, really, whereby we mark > > > packages that should be pulled into composes. At present these are only > > > pulled into TCs and RCs, they never appear in the old-style "nightly > > > composes". I believe we should *always* pull them in; it makes the > > > system a good deal simpler. > > > I'm a bit confused here. The override packages were used for TCs and > > RCs, but not for Live nightlies done in Koji. Pungi4 will now do all > > of that as part of a single compose, daily, right? So are you just > > saying those override packages will end up used in all compose > > artifacts produced, and we no longer need to care about the TC+RC vs > > Live nightly difference? In that case that's great. > > Yes, that is what I'm suggesting. If we still have the difference, it > makes things quite messy primarily for constructing an "order" of > composes, because say we do a snapshot the morning after an RC is > blessed; if we haven't done the stable push by then, the snapshot will > inarguably have been built *later* than the RC, but will contain older > packages than it. So what's the order? This is how things work ATM, and > I kinda hate it. And it just makes sense to me that "compose override" > packages should wind up in all the composes, anyhow. There's no reason > to leave them out of snapshots. So Dennis explained that, unfortunately, we can't do this at least for now. When I think about 'composes' I tend to just think about a sort of isolated thing with a bunch of images in it, but of course that's not (all) a "snapshot compose" is. The snapshot composes are what will ultimately be staged out to the public mirrors as the 'official' tree for the release. We cannot put the "compose override" packages into the repositories in those trees, because to do so would be effectively to push them out as stable updates. In theory we could consider putting the "compose override" packages into the images but not the repositories, but we might still think that was a mistake, and in any case, Dennis says, the tools just don't work like that at present. The images are built from the packages in the repos; any "override" packages for a compose *must* be in the repositories for that compose, practically speaking. So for the medium term I think we're stuck with including "override" packages in "candidates" but not "snapshots", and things that do stuff with composes are going to have to understand that distinction. It also means that we're going to have keep doing "snapshots" at the same time as "candidates", as that's how we sync out the stuff that gets pushed stable during freezes to the mirrors. So we're kinda gonna have to treat the "snapshots" and the "candidates" as two separate streams of things, and accept that we can't entirely reliably construct a sequence of them mixed together in some senses (because a "snapshot" built after a "candidate" may have older packages, just as is the case now). There are various ways we can think about dealing with this in the long term, but for now at least we'll just have to live with it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: A modest proposal: Pungi 4 compose process (what we call composes, when we do them, what information we need about them)
On Mon, 2016-02-22 at 10:04 -0800, Adam Williamson wrote: > This hasn't been a problem so far, because I actually built Wikitcms > and fedfind kinda backwards - their conception of how composes should > be identified is actually derived directly from how we name release > validation events. :P In A World Where my tools don't control the > compose naming concept, and for all the reasons stated above we might > want to give composes very uninformative 'names', this doesn't work any > more. Sorry, I should expand on this. Technically speaking, of course, it still "works". We *can* still do it. The problem is that a page name like: Test Results: Fedora 20160401.n.2 Installation isn't great for humans; it gives you no idea of the meaning of that compose, what testing process it's actually a part of. Even worse would be: Test Results: Fedora 864356 Installation to which the human response is...huh. In a *sane* manual testing system, of course, the compose ID would simply be an internal property that a certain set of validation tests could be mapped to in all sorts of exciting and interesting ways, you can put all kinds of abstraction in there to handle all the possibilities in terms of how we want to relate test instances to composes and what we want to be able to show the user in the UI. But it's a problem in the current Wikitcms design because the page name is where we maintain the mapping between the compose and the event as things stand. (There are various ways I can fix this, all of them fitting in nicely with Wikitcms' general level of stupidity. :>) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: A modest proposal: Pungi 4 compose process (what we call composes, when we do them, what information we need about them)
On Mon, 2016-02-22 at 08:09 -0500, Kamil Paral wrote: > > or it's relatively easy to do a numeric sort > > instead (just filter all the non-digit characters and do a numeric sort > > on the rest). > I don't follow you here. If we have > 24-20160510.2.c > 24-20160510.10.c > Then after filtering out non-digit characters we have: > 24201605102 > 242016051010 > which still sorts incorrectly: > 242016051010 > 24201605102 > > Unless you meant to parse the compose index out and then do a numeric > sort just on that. That works. Sorry, yes, that's what I meant. Didn't explain it very well. > > Note that we don't really *need* to indicate the compose 'type' in the > > ID. We could instead just have it in the compose metadata. I don't care > > strongly either way, though I think it's maybe slightly more convenient > > to have it in the ID. > Originally I wanted to say I like it, because it's then easy to go > through the list of all the composes and still see where Alpha > candidates started (if you roughly know the date) and which was the > final Alpha compose (the last candidate). But then I realized that > doesn't have to be true, the last candidate doesn't have to be the > one accepted for release. So I don't know if we're not making it easy > with the TYPE tag to do the same mistake by other people. (OTOH, the > same problem is with our usual Alpha RCx names, the last one doesn't > have to be the release one). > > Still, it seems to help humans, and we should document how to do it > properly with "automata". That's a good point, yeah. Another reason we have to explicitly track the candidate selected as the release somewhere. > > Also not visible in the mockup: "compose override" packages are *always > > included in all types of compose*. This is the concept Dennis and I > > came up with for handling blocker / freeze exception fixes; it's just a > > more formal version of the current process, really, whereby we mark > > packages that should be pulled into composes. At present these are only > > pulled into TCs and RCs, they never appear in the old-style "nightly > > composes". I believe we should *always* pull them in; it makes the > > system a good deal simpler. > I'm a bit confused here. The override packages were used for TCs and > RCs, but not for Live nightlies done in Koji. Pungi4 will now do all > of that as part of a single compose, daily, right? So are you just > saying those override packages will end up used in all compose > artifacts produced, and we no longer need to care about the TC+RC vs > Live nightly difference? In that case that's great. Yes, that is what I'm suggesting. If we still have the difference, it makes things quite messy primarily for constructing an "order" of composes, because say we do a snapshot the morning after an RC is blessed; if we haven't done the stable push by then, the snapshot will inarguably have been built *later* than the RC, but will contain older packages than it. So what's the order? This is how things work ATM, and I kinda hate it. And it just makes sense to me that "compose override" packages should wind up in all the composes, anyhow. There's no reason to leave them out of snapshots. > > There's also another issue we could use 'nominated' to answer. That is: > > when exactly do we build 'CANDIDATES'? Do we follow the current process > > and build them only on manual request, meaning that effectively every > > 'CANDIDATE' is equivalent to a current RC? Or do we build a 'CANDIDATE', > > say, *every time the "compose overrides" set changes*, and then > > 'nominate' RCs from the larger set of CANDIDATEs? If we want to do that, > > then the 'nominated' attribute for CANDIDATE composes would indicate > > which were selected as RCs. > I like the latter. More automation, less manual work for releng. I tend to agree. I guess I should make it explicit here that I'm kind of expecting releng, QA and any other relevant teams to be building tooling around this which causes the relevant actions to happen either automatically based on fedmsg's, or manually triggered. And I was mostly considering the "do it automatically" case. i.e., my driving consideration here was "how can we make it so every time a compose appears, the whole chain of appropriate actions kicks off and runs entirely automatically" - releng tools decide whether to stage the compose somewhere else, openQA etc. fire up and start testing, relval (or in future something less dumb) decides whether to create a manual validation "event", etc etc. > > > > That's pretty much the entire system. I had thought about things like > > storing compose "identifiers" like RC2, RC3 etc. in the compose metadata > > or in PDC directly, and stuff like requiring PDC to construct and store > > "sequences" of releases. But with this design, I don't *think* any of > > that is necessary. I believe the constraints specified in the proposal > > and the information in the compose IDs and the extra PDC fields is > >
Fedora Rawhide 20160222 compose check report
No missing expected images. Images in this compose but not Rawhide 20160221: Cloud_atomic disk raw x86_64 Games live x86_64 Design_suite live x86_64 Games live i386 Kde disk raw armhfp Kde live i386 Scientific_kde live x86_64 Cloud_atomic disk qcow x86_64 Scientific_kde live i386 Design_suite live i386 Kde live x86_64 Images in Rawhide 20160221 but not this: Cloud docker x86_64 Server disk raw armhfp Failed openQA tests: 11 of 69 ID: 5789Test: x86_64 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/5789 ID: 5794Test: i386 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/5794 ID: 5790Test: x86_64 workstation_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/5790 ID: 5785Test: x86_64 kde_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/5785 ID: 5783Test: i386 kde_live default_install URL: https://openqa.fedoraproject.org/tests/5783 ID: 5784Test: x86_64 kde_live default_install URL: https://openqa.fedoraproject.org/tests/5784 ID: 5759Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/5759 ID: 5774Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/5774 ID: 5776Test: i386 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/5776 ID: 5761Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/5761 ID: 5775Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/5775 Passed openQA tests: 52 of 69 6 openQA tests may be still running or broken! -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: glibc in tet repos
Den 2016-02-22 kl. 15:29, skrev Jonathan Calloway: > Hello! > > Has the glibc patch been placed in the test repos? Yes! $ rpm -qi glibc Name: glibc Version : 2.21 Release : 11.fc22 Architecture: x86_64 Install Date: tor 18 feb 2016 10:50:15 Group : System Environment/Libraries Size: 14206232 License : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ Signature : RSA/SHA256, tis 16 feb 2016 23:30:04, Key ID 11adc0948e1431d5 Source RPM : glibc-2.21-11.fc22.src.rpm Build Date : tis 16 feb 2016 16:03:15 Build Host : buildhw-05.phx2.fedoraproject.org Relocations : (not relocatable) Packager: Fedora Project Vendor : Fedora Project URL : http://www.gnu.org/software/glibc/ Summary : The GNU libc libraries Description : The glibc package contains standard libraries which are used by multiple programs on the system. In order to save disk space and memory, as well as to make upgrading easier, common system code is kept in one place and shared between programs. This particular package contains the most important sets of shared libraries: the standard C library and the standard math library. Without these two libraries, a Linux system will not function. > > Thanks! > > Jonathan > > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org > -- Regards Jon Ingason -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
glibc in tet repos
Hello! Has the glibc patch been placed in the test repos? Thanks! Jonathan -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: A modest proposal: Pungi 4 compose process (what we call composes, when we do them, what information we need about them)
> # tl;dr > > (LATER) OK, this email got really long, so here's my tl;dr summary. > Proposed compose ID scheme: (RELEASE)-(DATE).(INDEX).(TYPE), e.g. > 24-20160401.0.s (types are SNAPSHOT, CANDIDATE, POSTRELEASE). > Alternatively: type is stored as separate bit of metadata instead of > / as well as in the compose ID. > > Proposed additional metadata in PDC: 'nominated' (bool, whether a > SNAPSHOT was nominated for manual validation testing or a CANDIDATE > nominated as an RC), 'release' (one of a set of consts, 'ALPHA', > 'BETA', 'FINAL', 'POSTRELEASE', indicating that a CANDIDATE was > released as that milestone). > > Rules: all 'override' packages go in all composes, we never build more > than one compose type for one release at a time, we switch from > SNAPSHOT to CANDIDATE when all blockers are addressed and back to > SNAPSHOT after the milestone release, we switch to POSTRELEASE after > Final. > > Location: we can either have PDC be the canonical store of location > information, or just have some kind of engine (whether it's still my > 'fedfind' or something else) which can work out where to find a given > compose based on all the metadata mentioned in this proposal. I like the proposal, great job, thanks. Minor questions below. > The basic ideas here are pretty simple. The naming scheme for composes > is: > > (RELEASE)-(DATE).(INDEX).(TYPE) > > The compose 'types' are SNAPSHOT, CANDIDATE, and POSTRELEASE. Their > shortenings for the compose IDs are 's', 'c' and 'p'. (These don't > sort "correctly" alphabetically, but that shouldn't be a problem). This > is similar to the scheme currently used for snapshots, but with a type > identifier after the index number (I don't know if '.n.' in the current > IDs is supposed to indicate "nightly" or "number" or what, but if we > want to indicate the type in the compose ID, it makes much more sense > to have it after the index than before). > > Importantly, the compose IDs for a given release sort into their > release order. The only potential issue is if we have more than 9 of a More than 10, the index starts from 0. > compose type on a day. To deal with that we could just make the index > two digits instead of one, Can we easily adjust the numbering scheme if it ever happens that we need more than 10 composes per day? I wouldn't do it right away since it doesn't seem likely we would need it, but if we ever hit that point, we should make sure it's fairly simply to change it even during our release cycle. > or it's relatively easy to do a numeric sort > instead (just filter all the non-digit characters and do a numeric sort > on the rest). I don't follow you here. If we have 24-20160510.2.c 24-20160510.10.c Then after filtering out non-digit characters we have: 24201605102 242016051010 which still sorts incorrectly: 242016051010 24201605102 Unless you meant to parse the compose index out and then do a numeric sort just on that. That works. If we don't intend to bump up number of digits (at least potentially), we should document in PDC docs that the index is supposed to be sorted numerically, that can save us troubles in some tools in the future. > > Note that we don't really *need* to indicate the compose 'type' in the > ID. We could instead just have it in the compose metadata. I don't care > strongly either way, though I think it's maybe slightly more convenient > to have it in the ID. Originally I wanted to say I like it, because it's then easy to go through the list of all the composes and still see where Alpha candidates started (if you roughly know the date) and which was the final Alpha compose (the last candidate). But then I realized that doesn't have to be true, the last candidate doesn't have to be the one accepted for release. So I don't know if we're not making it easy with the TYPE tag to do the same mistake by other people. (OTOH, the same problem is with our usual Alpha RCx names, the last one doesn't have to be the release one). Still, it seems to help humans, and we should document how to do it properly with "automata". > Also not visible in the mockup: "compose override" packages are *always > included in all types of compose*. This is the concept Dennis and I > came up with for handling blocker / freeze exception fixes; it's just a > more formal version of the current process, really, whereby we mark > packages that should be pulled into composes. At present these are only > pulled into TCs and RCs, they never appear in the old-style "nightly > composes". I believe we should *always* pull them in; it makes the > system a good deal simpler. I'm a bit confused here. The override packages were used for TCs and RCs, but not for Live nightlies done in Koji. Pungi4 will now do all of that as part of a single compose, daily, right? So are you just saying those override packages will end up used in all compose artifacts produced, and we no longer need to care about the TC+RC vs Live nightly difference? In
rawhide report: 20160222 changes
Compose started at Mon Feb 22 05:15:03 UTC 2016 Broken deps for i386 -- [3Depict] 3Depict-0.0.18-3.fc24.i686 requires libmgl.so.7.4.0 [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [R-Rcpp] R-Rcpp-examples-0.12.3-2.fc24.i686 requires /usr/bin/r [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [bluetile] bluetile-0.6-30.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) bluetile-0.6-30.fc24.i686 requires ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) [bustle] bustle-0.4.8-6.fc24.i686 requires libHSdbus-0.10.10-ghc7.8.4.so bustle-0.4.8-6.fc24.i686 requires ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13) bustle-0.4.8-6.fc24.i686 requires ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d) bustle-0.4.8-6.fc24.i686 requires ghc(dbus-0.10.10-ce57b03294c6f66038470cc2325ff718) [castxml] castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangSerialization.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangSema.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangParse.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangLex.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangFrontend.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangEdit.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangDriver.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangBasic.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangAnalysis.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangAST.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMXCoreInfo.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMXCoreDisassembler.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMXCoreDesc.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMXCoreCodeGen.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMXCoreAsmPrinter.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMX86Info.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMX86Disassembler.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMX86Desc.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMX86CodeGen.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMX86AsmPrinter.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMX86AsmParser.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSystemZInfo.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSystemZDisassembler.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSystemZDesc.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSystemZCodeGen.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSystemZAsmPrinter.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSystemZAsmParser.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSupport.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSparcInfo.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSparcDisassembler.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSparcDesc.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSparcCodeGen.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSparcAsmPrinter.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMSparcAsmParser.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMPowerPCInfo.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMPowerPCDisassembler.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMPowerPCDesc.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMPowerPCCodeGen.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMPowerPCAsmPrinter.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMPowerPCAsmParser.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMOption.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMNVPTXInfo.so.3.7 castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libLLVMNVPTXDesc.so.3.7
Re: GDM failing to start…
> …just checking in before reporting a bug. > > From what I can see GDM is trying to start, Xorg is starting… hummm is > that a problem in itself? Then the sad screen appears allowing me to > log out (except that I haven't logged in as yet! > > The machines are working fine per se, so no problems other than no > GNOME. Which is, obviously, a massive problem. ;-) > > -- > Russel. When spotting such issue, check our blocker bugs app (look at all milestones): https://qa.fedoraproject.org/blockerbugs/milestone/24/alpha/buglist This one appears to be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1308771 -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
