Fedora Rawhide-20160927.n.1 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 4/102 (x86_64), 3/17 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20160926.n.0): ID: 36663 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/36663 ID: 36702 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/36702 Old failures (same test failed in Rawhide-20160926.n.0): ID: 36650 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/36650 ID: 36651 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/36651 ID: 36664 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/36664 ID: 36732 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/36732 ID: 36741 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/36741 ID: 36752 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/36752 Soft failed openQA tests: 1/102 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test softfailed in Rawhide-20160926.n.0): ID: 36658 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/36658 Passed openQA tests: 97/102 (x86_64), 14/17 (i386) New passes (same test did not pass in Rawhide-20160926.n.0): ID: 36642 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/36642 ID: 36714 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/36714 ID: 36738 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/36738 ID: 36751 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/36751 Skipped openQA tests: 1 of 121 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Wed, 2016-09-28 at 00:06 +, Fedora compose checker wrote: > Missing expected images: > > Cloud_base raw-xz i386 > Atomic raw-xz x86_64 > > Failed openQA tests: 4/102 (x86_64), 3/17 (i386), 1/2 (arm) > > New failures (same test did not fail in Rawhide-20160926.n.0): > > ID: 36663 Test: i386 KDE-live-iso install_default > URL: https://openqa.fedoraproject.org/tests/36663 This looks like a window manager issue of some kind; the anaconda window is squished into the top-left hand corner, which makes the needle match fail. However, the same test passed on staging, so it may be not a new bug but some kind of inconsistent bug (I hate those). I guess we'll see what it does tomorrow. > ID: 36702 Test: x86_64 universal install_simple_encrypted@uefi > URL: https://openqa.fedoraproject.org/tests/36702 This is a goddamn typing failure. I have restarted the test and we will never, ever speak of this again. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
I saw the 20160927 images in the wesite, but I when I ran the dnf upgrade --refresh, it says nothing to do, is that normal? Thanks. Bowen On Tue, Sep 27, 2016 at 05:14:31PM -0700, Adam Williamson wrote: > On Wed, 2016-09-28 at 00:06 +, Fedora compose checker wrote: > > Missing expected images: > > > > Cloud_base raw-xz i386 > > Atomic raw-xz x86_64 > > > > Failed openQA tests: 4/102 (x86_64), 3/17 (i386), 1/2 (arm) > > > > New failures (same test did not fail in Rawhide-20160926.n.0): > > > > ID: 36663 Test: i386 KDE-live-iso install_default > > URL: https://openqa.fedoraproject.org/tests/36663 > > This looks like a window manager issue of some kind; the anaconda > window is squished into the top-left hand corner, which makes the > needle match fail. However, the same test passed on staging, so it may > be not a new bug but some kind of inconsistent bug (I hate those). I > guess we'll see what it does tomorrow. > > > ID: 36702 Test: x86_64 universal install_simple_encrypted@uefi > > URL: https://openqa.fedoraproject.org/tests/36702 > > This is a goddamn typing failure. I have restarted the test and we will > never, ever speak of this again. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Tue, 2016-09-27 at 19:39 -0500, Bowen Wang wrote: > I saw the 20160927 images in the wesite, but I when I ran the dnf > upgrade --refresh, it says nothing to do, is that normal? Thanks. It's not unusual...there's some other stuff that happens between the compose 'completing' and you actually seeing updated packages... OK, I wrote a really long explanation which is below, but I'll put a summary up here: there's some clever stuff that goes on involving the Fedora mirror system and the repository metadata, a consequence of which is that with a default configuration you *definitely won't* start getting the new packages until an hour or two after the compose 'completes', and you *may* not get them until several hours later. So to break it down, here's what happens (for Rawhide): 1. The compose process itself completes: what that basically means is that in the directory under https://kojipkgs.fedoraproject.org/compose/rawhide/ we have complete repositories, installer images, and all the other bits that get produced by the compose process 2. Most (but not quite all) of the output of the compose process gets synced to the 'master mirror' location, basically meaning it goes to https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/ . Some of it instead goes to https://dl.fedoraproject.org/pub/alt/development/rawhide/ . 3a. checksums for some of the repository metadata files are generated and stored in the mirrormanager system. You can see these by hitting this URL: https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 . 3b. The public mirrors start syncing the content of the new compose from the primary mirror (mirrors vary in how often they do this, hence how long it takes for them to pick up the new compose) 3a is actually quite an important point. In a standard Fedora system, using the mirrormanager setup for the official repositories, when you ask it to refresh metadata, dnf will get both a list of mirrors and a list of metadata checksums from mirrormanager. It will go to the first mirror on the list and grab the metadata, then it will *check it against the checksums* and if it doesn't match, it will move on to the next mirror on the list and get the metadata again. Once it's got metadata that matches the checksums from mirrormanager, it'll be happy, and it'll then be offering the packages listed in that metadata (when it actually goes to download the packages, it just hits up each mirror in the list in sequence until it finds one which has the file listed in the metadata it's working from; if the expected path 404s, it goes to the next mirror). The primary *reason* for this system is: it's an attempt to make sure you don't get really old metadata from stale mirrors. Before this system was set up, mirrormanager would just send you a list of mirrors, and dnf would grab the metadata from the first mirror on the list, and it would assume it was up to date. If you happened to hit a 'bad' mirror which wasn't syncing regularly enough or was somehow broken, you could get really stale metadata, which would mean you'd get really old packages (if that mirror or some other mirror on the list actually carried the packages matching the metadata) or no packages at all (if the package versions listed in the metadata couldn't be found on any mirror). So this checksumming system is an attempt to avoid that. mirrormanager keeps metadata checksums for (IIRC) the last two or three composes, so if the first mirror you hit has metadata that's older than that, dnf will ignore it and go to another mirror. There's a slight *drawback* to this system, though, which is: with the default repo configuration, you will not get packages from a new compose until mirrormanager has synced the metadata checksums for that new compose and is serving them out. Because obviously, if the new checksums aren't on mirrormanager when you get the metadata from a fast-syncing mirror, dnf will just figure the metadata is *old* (there's no way it can tell it's actually new) and move on to the next mirror. I know about this in quite a bit of detail because it's a problem openQA ran into (and still does, to a degree) all the time :) Because the openQA tests trigger from the fedmsg that's sent when step 1. finishes, the openQA test process is basically racing with steps 2. and particularly with 3a (it doesn't race with 3b because openQA always uses the primary mirror). This was why, until a couple of weeks back, openQA tests would frequently have issues because they were racing with the sync process, and thus getting old packages or even getting stuck at a particularly unfortunate point in the race and not completing the install (or a post-install package transaction) at all. What we did to mitigate this was tweak how the openQA tests work so that *most* of them edit their repository configuration and/or pass anaconda an 'inst.repo' parameter to use the compose directory directly as a repository, instead of using the 'nor
Re: Fedora Rawhide-20160927.n.1 compose check report
Okay, that makes sense. I just run the command: dnf upgrade --refresh to update my rawhide system. It only downloaded one package, the package name is Fedora Rawhide, after that, there isn't any installation process, then the command just output complete, and quit. I think there must be one installation because my kernel is older than the current one. But there is none. Then I reboot my laptop, it seems that the kernel is not upgraded to the newest version. Did I do something wrong? Bowen On Tue, Sep 27, 2016 at 07:06:30PM -0700, Adam Williamson wrote: > On Tue, 2016-09-27 at 19:39 -0500, Bowen Wang wrote: > > I saw the 20160927 images in the wesite, but I when I ran the dnf > > upgrade --refresh, it says nothing to do, is that normal? Thanks. > > It's not unusual...there's some other stuff that happens between the > compose 'completing' and you actually seeing updated packages... > > OK, I wrote a really long explanation which is below, but I'll put a > summary up here: there's some clever stuff that goes on involving the > Fedora mirror system and the repository metadata, a consequence of > which is that with a default configuration you *definitely won't* start > getting the new packages until an hour or two after the compose > 'completes', and you *may* not get them until several hours later. > > So to break it down, here's what happens (for Rawhide): > > 1. The compose process itself completes: what that basically means is > that in the directory under > https://kojipkgs.fedoraproject.org/compose/rawhide/ we have complete > repositories, installer images, and all the other bits that get > produced by the compose process > > 2. Most (but not quite all) of the output of the compose process gets > synced to the 'master mirror' location, basically meaning it goes to > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/ . > Some of it instead goes to > https://dl.fedoraproject.org/pub/alt/development/rawhide/ . > > 3a. checksums for some of the repository metadata files are generated > and stored in the mirrormanager system. You can see these by hitting > this URL: > https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 . > > 3b. The public mirrors start syncing the content of the new compose > from the primary mirror (mirrors vary in how often they do this, hence > how long it takes for them to pick up the new compose) > > 3a is actually quite an important point. In a standard Fedora system, > using the mirrormanager setup for the official repositories, when you > ask it to refresh metadata, dnf will get both a list of mirrors and a > list of metadata checksums from mirrormanager. It will go to the first > mirror on the list and grab the metadata, then it will *check it > against the checksums* and if it doesn't match, it will move on to the > next mirror on the list and get the metadata again. Once it's got > metadata that matches the checksums from mirrormanager, it'll be happy, > and it'll then be offering the packages listed in that metadata (when > it actually goes to download the packages, it just hits up each mirror > in the list in sequence until it finds one which has the file listed in > the metadata it's working from; if the expected path 404s, it goes to > the next mirror). > > The primary *reason* for this system is: it's an attempt to make sure > you don't get really old metadata from stale mirrors. Before this > system was set up, mirrormanager would just send you a list of mirrors, > and dnf would grab the metadata from the first mirror on the list, and > it would assume it was up to date. If you happened to hit a 'bad' > mirror which wasn't syncing regularly enough or was somehow broken, you > could get really stale metadata, which would mean you'd get really old > packages (if that mirror or some other mirror on the list actually > carried the packages matching the metadata) or no packages at all (if > the package versions listed in the metadata couldn't be found on any > mirror). > > So this checksumming system is an attempt to avoid that. mirrormanager > keeps metadata checksums for (IIRC) the last two or three composes, so > if the first mirror you hit has metadata that's older than that, dnf > will ignore it and go to another mirror. > > There's a slight *drawback* to this system, though, which is: with the > default repo configuration, you will not get packages from a new > compose until mirrormanager has synced the metadata checksums for that > new compose and is serving them out. Because obviously, if the new > checksums aren't on mirrormanager when you get the metadata from a > fast-syncing mirror, dnf will just figure the metadata is *old* > (there's no way it can tell it's actually new) and move on to the next > mirror. > > I know about this in quite a bit of detail because it's a problem > openQA ran into (and still does, to a degree) all the time :) Because > the openQA tests trigger from the fedmsg that's sent when step 1. > finishes
Re: Fedora Rawhide-20160927.n.1 compose check report
On Tue, 2016-09-27 at 23:22 -0500, Bowen Wang wrote: > Okay, that makes sense. > I just run the command: > dnf upgrade --refresh > to update my rawhide system. It only downloaded one package, the package > name is Fedora Rawhide, after that, there isn't any installation > process, then the command just output complete, and quit. That's not a package, it's the name of the repository: it's telling you it's refreshing the metadata for that repository. When you pass -- refresh it forces it to go out and re-fetch the metadata, and that's what you see happening. > I think there > must be one installation because my kernel is older than the current > one. But there is none. > Then I reboot my laptop, it seems that the kernel is not upgraded to the > newest version. Did I do something wrong? Nope, you likely just hit a mirror which didn't have the new metadata yet. If you try again in a few hours you may get a different result. When there are actually package updates to apply, dnf will list them and require you to say '(y)es' to approve the installation. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Tue, Sep 27, 2016 at 07:06:30PM -0700, Adam Williamson wrote: > OK, I wrote a really long explanation which is below, but I'll put a > summary up here: there's some clever stuff that goes on involving the > Fedora mirror system and the repository metadata, a consequence of > which is that with a default configuration you *definitely won't* start > getting the new packages until an hour or two after the compose > 'completes', and you *may* not get them until several hours later. > > [supersnip!] Thanks Adam for the explanation. This was long, but really interesting. Is this thing documented somewhere? If not, I'd suggest your email goes in some wiki page! Thanks -- 010 Giovanni [dacav] Simoni 001 111 OpenPGP key: 93FC 2A6A 43A4 AAC2 0D8E 5411 2F99 ABB6 BA14 DF9E ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
I just got up and run dnf upgrade --refresh It still didn't work, then I tried dnf system-upgrade download --releasever=rawhide The terminal output is error: no kernel packages were found. After that I run dnf upgrade --refresh again. My system start to upgrade. I found it pretty weird because I think I slept for 7 hours, and it will be enough for the mirror sync the latest packages, maybe there is still something wrong with my rawhide configuration? Bowen On Tue, Sep 27, 2016 at 09:38:28PM -0700, Adam Williamson wrote: > On Tue, 2016-09-27 at 23:22 -0500, Bowen Wang wrote: > > Okay, that makes sense. > > I just run the command: > > dnf upgrade --refresh > > to update my rawhide system. It only downloaded one package, the package > > name is Fedora Rawhide, after that, there isn't any installation > > process, then the command just output complete, and quit. > > That's not a package, it's the name of the repository: it's telling you > it's refreshing the metadata for that repository. When you pass -- > refresh it forces it to go out and re-fetch the metadata, and that's > what you see happening. > > > I think there > > must be one installation because my kernel is older than the current > > one. But there is none. > > Then I reboot my laptop, it seems that the kernel is not upgraded to the > > newest version. Did I do something wrong? > > Nope, you likely just hit a mirror which didn't have the new metadata > yet. If you try again in a few hours you may get a different result. > When there are actually package updates to apply, dnf will list them > and require you to say '(y)es' to approve the installation. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Wed, 2016-09-28 at 10:43 -0500, Bowen Wang wrote: > I just got up and run > dnf upgrade --refresh > It still didn't work, then I tried > dnf system-upgrade download --releasever=rawhide > The terminal output is error: no kernel packages were found. > After that I run > dnf upgrade --refresh again. My system start to upgrade. > I found it pretty weird because I think I slept for 7 hours, and it will > be enough for the mirror sync the latest packages, maybe there is still > something wrong with my rawhide configuration? Hum, hard to say, I've never really done any methodical checking of how long mirrors take to sync. Which mirrors you get, also, depends to an extent on where you are: mirrormanager guesses where you are based on your IP address, and sends you servers from your region, so when you go to that metalink URL I sent in my previous mail, the list you get is different from the list I get. I wouldn't recommend doing that 'system-upgrade to the same release you're running' thing, it's not likely to make anything work better. It just sounds like you happened to get the older metadata the first time you did 'dnf upgrade --refresh', and the new metadata the second time... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
This is the content of the file /etc/yum.repos.d/fedora.repo on my laptop: [fedora] name=Fedora $releasever - $basearch failovermethod=priority #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch enabled=0 #metadata_expire=7d repo_gpgcheck=0 type=rpm gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch skip_if_unavailable=False [fedora-debuginfo] name=Fedora $releasever - $basearch - Debug failovermethod=priority #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/ metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&arch=$basearch enabled=0 metadata_expire=7d repo_gpgcheck=0 type=rpm gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch skip_if_unavailable=False [fedora-source] name=Fedora $releasever - Source failovermethod=priority #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/source/tree/ metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-source-$releasever&arch=$basearch enabled=0 metadata_expire=7d repo_gpgcheck=0 type=rpm gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch skip_if_unavailable=False I think maybe it is just a coincidence, after I run the dnf upgrade --refrsh at the first time, the mirror I am using just got the latest update. So I can upgrade my system when running the second time. Bowen On Wed, Sep 28, 2016 at 08:50:40AM -0700, Adam Williamson wrote: > On Wed, 2016-09-28 at 10:43 -0500, Bowen Wang wrote: > > I just got up and run > > dnf upgrade --refresh > > It still didn't work, then I tried > > dnf system-upgrade download --releasever=rawhide > > The terminal output is error: no kernel packages were found. > > After that I run > > dnf upgrade --refresh again. My system start to upgrade. > > I found it pretty weird because I think I slept for 7 hours, and it will > > be enough for the mirror sync the latest packages, maybe there is still > > something wrong with my rawhide configuration? > > Hum, hard to say, I've never really done any methodical checking of how > long mirrors take to sync. Which mirrors you get, also, depends to an > extent on where you are: mirrormanager guesses where you are based on > your IP address, and sends you servers from your region, so when you go > to that metalink URL I sent in my previous mail, the list you get is > different from the list I get. > > I wouldn't recommend doing that 'system-upgrade to the same release > you're running' thing, it's not likely to make anything work better. It > just sounds like you happened to get the older metadata the first time > you did 'dnf upgrade --refresh', and the new metadata the second > time... > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Wed, 2016-09-28 at 12:31 -0500, Bowen Wang wrote: > I think maybe it is just a coincidence, after I run the > dnf upgrade --refrsh > at the first time, the mirror I am using just got the latest update. So > I can upgrade my system when running the second time. To be clear, the mirror system is - intentionally - not deterministic (in most cases); each time you hit the metalink URL it will give you a slightly different list of mirrors (usually the same handful of mirrors in your geographic area, but in a different order). You can see this easily by just opening e.g. this URL: https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 in a browser and refreshing it a few times. You'll see different mirrors from me, for a start - I get North American ones - but each time you refresh the page, the order will change. This is done to ensure that load is spread around between mirrors. So you probably simply got a different server the second time you ran 'dnf --refresh update' compared to the first. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Thu, Sep 29, 2016 at 1:31 AM, Bowen Wang wrote: > This is the content of the file /etc/yum.repos.d/fedora.repo on my > laptop: > [fedora] > name=Fedora $releasever - $basearch > failovermethod=priority > #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ Would you please use your web browser to visit this link[1] and tell us the URL it actually redirects to? Just hazard a guess nearby mirrors are not up2date. [1]---http://download.fedoraproject.org -- Yours sincerely, Christopher Meng http://cicku.me ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Thu, 29 Sep 2016 09:52:30 +0800 Christopher Meng wrote: > On Thu, Sep 29, 2016 at 1:31 AM, Bowen Wang > wrote: > > This is the content of the file /etc/yum.repos.d/fedora.repo on my > > laptop: > > [fedora] > > name=Fedora $releasever - $basearch > > failovermethod=priority > > #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ > > I noticed earlier that every one of them was disabled in that message, enabled=0. But these are the standard repositories, and it sounded like you wanted the rawhide repositories which will be under rawhide rather than fedora. What do those show? > Would you please use your web browser to visit this link[1] and tell > us the URL it actually redirects to? > > Just hazard a guess nearby mirrors are not up2date. > > [1]---http://download.fedoraproject.org https://mirrors.kernel.org/fedora// ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
Hi Chris, I have clicked the address https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 I got the following stuff: # repo = rawhide arch = x86_64 country = US country = CA http://mirror.n5tech.com/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirrors.mit.edu/fedora/linux/development/rawhide/Everything/x86_64/os/https://mirrors.xmission.com/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirror.math.princeton.edu/pub/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/development/rawhide/Everything/x86_64/os/https://mirrors.kernel.org/fedora/development/rawhide/Everything/x86_64/os/https://mirror.steadfast.net/fedora/development/rawhide/Everything/x86_64/os/http://mirror.metrocast.net/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirrors.rit.edu/fedora/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirror.nexcess.net/fedora/development/rawhide/Everything/x86_64/os/http://linux.mirrors.es.net/fedora/development/rawhide/Everything/x86_64/os/http://mirror.cc.vt.edu/pub/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirror.uoregon.edu/fedora/linux/development/rawhide/Everything/x86_64/os/http://repo.atlantic.net/fedora/linux/development/rawhide/Everything/x86_64/os/http://kdeforge2.unl.edu/mirrors/fedora/linux/development/rawhide/Everything/x86_64/os/http://fedora.mirror.lstn.net/development/rawhide/Everything/x86_64/os/http://fedora.mirrors.tds.net/fedora/development/rawhide/Everything/x86_64/os/http://mirror.datto.com/fedora/primary/development/rawhide/Everything/x86_64/os/http://mirror.cs.pitt.edu/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirror.web-ster.com/fedora/development/rawhide/Everything/x86_64/os/https://mirror.chpc.utah.edu/pub/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirror.prgmr.com/pub/fedora/linux/development/rawhide/Everything/x86_64/os/http://mirror.utexas.edu/fedora/linux/development/rawhide/Everything/x86_64/os/http://archive.linux.duke.edu/pub/fedora/linux/development/rawhide/Everything/x86_64/os/https://mirrors.cat.pdx.edu/fedora/linux/development/rawhide/Everything/x86_64/os/https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/https://muug.ca/mirror/fedora/linux/development/rawhide/Everything/x86_64/os/http://fedora.bhs.mirrors.ovh.net/linux/development/rawhide/Everything/x86_64/os/https://mirror.csclub.uwaterloo.ca/fedora/linux/development/rawhide/Everything/x86_64/os/http://fedora.mirror.gtcomm.net/development/rawhide/Everything/x86_64/os/https://mirror.its.sfu.ca/mirror/fedora/linux/development/rawhide/Everything/x86_64/os/ BTW, I live in Missouri, USA. Bowen On Wed, Sep 28, 2016 at 9:12 PM, stan wrote: > On Thu, 29 Sep 2016 09:52:30 +0800 > Christopher Meng wrote: > > > On Thu, Sep 29, 2016 at 1:31 AM, Bowen Wang > > wrote: > > > This is the content of the file /etc/yum.repos.d/fedora.repo on my > > > laptop: > > > [fedora] > > > name=Fedora $releasever - $basearch > > > failovermethod=priority > > > #baseurl=http://download.fedoraproject.org/pub/fedora/ > linux/releases/$releasever/Everything/$basearch/os/ > > I noticed earlier that every one of them was disabled in that message, > enabled=0. But these are the standard repositories, and it sounded > like you wanted the rawhide repositories which will be under rawhide > rather than fedora. What do those show? > > > Would you please use your web browser to visit this link[1] and tell > > us the URL it actually redirects to? > > > > Just hazard a guess nearby mirrors are not up2date. > > > > [1]---http://download.fedoraproject.org > > https://mirrors.kernel.org/fedora// > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
Hi Stan, I am not sure if I know what you are saying, can you explain it again? Thanks. Bowen On Wed, Sep 28, 2016 at 9:12 PM, stan wrote: > On Thu, 29 Sep 2016 09:52:30 +0800 > Christopher Meng wrote: > > > On Thu, Sep 29, 2016 at 1:31 AM, Bowen Wang > > wrote: > > > This is the content of the file /etc/yum.repos.d/fedora.repo on my > > > laptop: > > > [fedora] > > > name=Fedora $releasever - $basearch > > > failovermethod=priority > > > #baseurl=http://download.fedoraproject.org/pub/fedora/ > linux/releases/$releasever/Everything/$basearch/os/ > > I noticed earlier that every one of them was disabled in that message, > enabled=0. But these are the standard repositories, and it sounded > like you wanted the rawhide repositories which will be under rawhide > rather than fedora. What do those show? > > > Would you please use your web browser to visit this link[1] and tell > > us the URL it actually redirects to? > > > > Just hazard a guess nearby mirrors are not up2date. > > > > [1]---http://download.fedoraproject.org > > https://mirrors.kernel.org/fedora// > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Wed, 28 Sep 2016 21:43:21 -0500 Bowen Wang wrote: > Hi Stan, > I am not sure if I know what you are saying, can you explain it again? > Thanks. I wasn't really paying attention to the conversation, but it sounded like you wanted to have rawhide on your machine. But rawhide uses its own repo, fedora-rawhide.repo. If you don't have that in your /etc/yum.repos.d, dnf won't be able to find rawhide. There is a package named like fedora-repos-rawhide-25-0.5.noarch that will put that repo in /etc/yum.repos.d. I was running rawhide when f25 was rawhide, so I have that package for f25 installed. You probably want the one for f26. Then, enable that repo, and leave the others disabled, and you should update to rawhide the next time you run dnf update. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Thu, 2016-09-29 at 09:52 +0800, Christopher Meng wrote: > On Thu, Sep 29, 2016 at 1:31 AM, Bowen Wang > wrote: > > This is the content of the file /etc/yum.repos.d/fedora.repo on my > > laptop: > > [fedora] > > name=Fedora $releasever - $basearch > > failovermethod=priority > > #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ > > > Would you please use your web browser to visit this link[1] and tell > us the URL it actually redirects to? That line is commented out. It is not using it, but the 'metalink' line below, which works as I described in my earlier email. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
These are all the files in /etc/yum.repos.d/ fedora-cisco-openh264.repo fedora-rawhide.repo fedora.repo fedora-updates.repo fedora-updates-testing.repo Is this correct? Bowen On Wed, Sep 28, 2016 at 10:36:53PM -0700, stan wrote: > On Wed, 28 Sep 2016 21:43:21 -0500 > Bowen Wang wrote: > > > Hi Stan, > > I am not sure if I know what you are saying, can you explain it again? > > Thanks. > > I wasn't really paying attention to the conversation, but it sounded > like you wanted to have rawhide on your machine. But rawhide uses its > own repo, fedora-rawhide.repo. If you don't have that in > your /etc/yum.repos.d, dnf won't be able to find rawhide. There is a > package named like fedora-repos-rawhide-25-0.5.noarch that will put > that repo in /etc/yum.repos.d. I was running rawhide when f25 was > rawhide, so I have that package for f25 installed. You probably want > the one for f26. Then, enable that repo, and leave the others > disabled, and you should update to rawhide the next time you run dnf > update. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
On Thu, 2016-09-29 at 00:56 -0500, Bowen Wang wrote: > These are all the files in /etc/yum.repos.d/ > > fedora-cisco-openh264.repo > fedora-rawhide.repo > fedora.repo > fedora-updates.repo > fedora-updates-testing.repo > > Is this correct? Yes, that's fine. If you look in fedora-rawhide.repo you will likely see this: #baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/$basearch/os/ metalink=https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch which is the default configuration, and behaves as I described. It tells dnf to fetch the 'metalink' file from the specified URL - $basearch is a special value which dnf will replace with your system's architecture, so the real URL will be: https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 if you have an x86_64 system. If you download the file at that URL, you'll see an XML file. It contains three sets of checksums for the 'repomd.xml' metadata file, one for each of the last three Rawhide composes (with three different types of checksum in each set), and then a list of mirrors. This is the data that causes dnf to act as I described before: it will go to the first mirror in the list, download the repomd.xml file, checksum it, and compare the value to each of the three corresponding values in the metalink file. If the checksum matches, it will consider that mirror's metadata up to date, and use it; if not, it will go to the next mirror on the list and start the process again. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160927.n.1 compose check report
Thanks for being so patient and explaining so much stuff to me! Bowen On Wed, Sep 28, 2016 at 11:10:33PM -0700, Adam Williamson wrote: > On Thu, 2016-09-29 at 00:56 -0500, Bowen Wang wrote: > > These are all the files in /etc/yum.repos.d/ > > > > fedora-cisco-openh264.repo > > fedora-rawhide.repo > > fedora.repo > > fedora-updates.repo > > fedora-updates-testing.repo > > > > Is this correct? > > Yes, that's fine. If you look in fedora-rawhide.repo you will likely > see this: > > #baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/$basearch/os/ > metalink=https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch > > which is the default configuration, and behaves as I described. It > tells dnf to fetch the 'metalink' file from the specified URL - > $basearch is a special value which dnf will replace with your system's > architecture, so the real URL will be: > > https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 > > if you have an x86_64 system. If you download the file at that URL, > you'll see an XML file. It contains three sets of checksums for the > 'repomd.xml' metadata file, one for each of the last three Rawhide > composes (with three different types of checksum in each set), and then > a list of mirrors. This is the data that causes dnf to act as I > described before: it will go to the first mirror in the list, download > the repomd.xml file, checksum it, and compare the value to each of the > three corresponding values in the metalink file. If the checksum > matches, it will consider that mirror's metadata up to date, and use > it; if not, it will go to the next mirror on the list and start the > process again. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
