Re: rawhide users: Do this now if you want to stick with F26 and not F27

[Bowen Wang]

What should I do if I want to use F27 except importing the GPG keys for F27? I 
am currently using rawhide.

Bowen

On Fri, Mar 03, 2017 at 03:59:55PM +0100, Kalev Lember wrote:
> Now that F26 is branched off from rawhide, I know many developers
> (including me) want to stay with F26 instead of F27 to make sure we are
> testing the upcoming release. By default, everyone who has rawhide
> installed stays on the F27 train.
> 
> Here's how to switch to F26:
> 
> $ dnf distro-sync --releasever=26
> 
> -- 
> Kalev
> ___
> 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: Copr && Rawhide -- no "rolling updates" workflow

[Bowen Wang]

So it means that there will be no longer Rawhide version of Fedora, or
it is just a change of repo/target name.

Bowen

On Wed, Oct 12, 2016 at 01:11:42PM -0600, Kevin Fenzi wrote:
> On Tue, 11 Oct 2016 19:14:34 +0200
> Pavel Raiskup  wrote:
> 
> > FYI:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1381790
> > 
> > Seems like the `fedora-rawhide-x86_64` chroot is not going to exist
> > from now, which is IMO unnecessary change ... but what could be other
> > than those "obvious" consequences for both Copr repo maintainers and
> > users? Does this sound like acceptable change?
> 
> Well, its a bit confusing actually, but if I understand it right I
> guess it should be ok. 
> 
> My understanding is that there will no longer be a 'rawhide'
> target/repos. Instead right now they will all become 'f26' ones. Then,
> when we branch f26, those will follow the branch and new f27 ones will
> appear. 
> 
> Whats not at all clear is when/if there's going to be any mass adding
> the new branch and rebuilding on it, or if that is up to the user? 
> 
> Personally, I would say we shouldn't do any mass rebuilding. 
> If a project gets to the point where it has no builds for any active
> targets we could move it to a 'archive' or just delete it as it would
> indicate no one is driving/caring for the software. 
> 
> kevin
> 
> 



> ___
> 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

[Bowen Wang]

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=$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=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

Re: Fedora Rawhide-20160927.n.1 compose check report

[Bowen Wang]

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 <stanl-fedorau...@vfemail.net> wrote:

> On Thu, 29 Sep 2016 09:52:30 +0800
> Christopher Meng <i...@cicku.me> wrote:
>
> > On Thu, Sep 29, 2016 at 1:31 AM, Bowen Wang
> > <bowenwang.tin...@gmail.com> 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

[Bowen Wang]

Hi Chris,
I have clicked the address
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide=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 <stanl-fedorau...@vfemail.net> wrote:

> On Thu, 29 Sep 2016 09:52:30 +0800
> Christopher Meng <i...@cicku.me> wrote:
>
> > On Thu, Sep 29, 2016 at 1:31 AM, Bowen Wang
> > <bowenwang.tin...@gmail.com> 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

[Bowen Wang]

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=$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=$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=$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

[Bowen Wang]

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

[Bowen Wang]

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=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

Re: Fedora Rawhide-20160927.n.1 compose check report

[Bowen Wang]

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