date:20160927

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

2016-09-27 Thread Adam Williamson

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

2016-09-27 Thread 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

2016-09-27 Thread Adam Williamson

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

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

2016-09-27 Thread 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

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

2016-09-27 Thread Adam Williamson

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

Fedora Rawhide-20160927.n.1 compose check report

2016-09-27 Thread Fedora compose checker

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

Cloud and Server Q

2016-09-27 Thread Chris Murphy

Hi,

I was asked to start this in today's Server meeting. The genesis for
me was, I have more questions than answers and I'm fairly convinced
I'm not the only person who's kinda shrugging not knowing what all the
questions even are. Answers are important too, but good questions to
properly explore scope and liabilities have to come first.

Cloud WG folks had decided a while ago to focus on Atomic Host, and
sounds like now they only want to do that, and form a new Atomic WG.
[1][2]

I see 8 base images for Cloud that aren't rpm-ostree based. Are they
in need of a new home? Who's using them? Are they all needed? Does it
make sense for Server WG to produce the non-Atomic Cloud deliverable
images?

At the last Cloud meeting, it was floated whether some Cloud people
should move over to Server, or vice versa. Should there be an
Atomic/Container WG? i.e. a fourth product deliverable?

Being contrary, I wondered about consolidation as a solution rather
than adding another WG and product. [3] Does anyone see Cloud WG, or
Server WG as spread too thinly? What estimate do you have for overlap
in work between Cloud and Server? Is there an economy of scale by
combining them? And is it both useful and practical to have subgroups
within a WG, to split out the sub variants of Server: hardware, cloud,
atomic host?

Server and Workstation WGs have expressed interest in moving to
rpm-ostree based deployments also. So I'm confused by what an Atomic
WG would produce that's unique. There are huge differences between
conventional and rpm-ostree deployments. Does it make sense for an
Atomic WG to have no outputs? And instead is liason with Server and
Workstation WGs, QA, Docs, releng, and others, to help in the
transition to this new way of delivering and maintaining Fedora?

It might be that the Cloud and Server PRD refreshes help sort some of
this stuff out too.

OK I have more questions but this is long enough. I'm certain others
can ask better questions, or versions of these ones, and in particular
the questions I haven't asked.

[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-21/fedora_cloud_wg.2016-09-21-17.00.log.html

[2]
https://fedorahosted.org/cloud/ticket/170

[3]
(Combining) Cloud Atomic Server WGs
https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/Z2P2ARN6AMMAW52F6KSOFGELQFKXHCFY/

--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Attempting to contact unresponsive maintainers - zeenix, theinric, ifarkas, mchalk

2016-09-27 Thread Kevin Fenzi

On Tue, 20 Sep 2016 10:39:28 -0600
Kevin Fenzi  wrote:

> Greetings, we've been told that the email addresses
> for these package maintainers are no longer valid.  I'm starting the
> unresponsive maintainer policy to find out if they are still
> interested in maintaining their packages (and if so, have them update
> their email addresses in FAS).  If they're not interested in
> maintaining or we can't locate them I'll have FESCo orphan the
> packages so that others can take them over.
> 
> If you have a way to contact these maintainers, please let them
> know that we'd appreciate knowing what to do with their packages.
> Thanks!
> 
> zeenix: 

(have updated their address in fas)

> theinric:

I reassigned some of these to co-maintainers, but these three are
available for a new point of contact: 

> rpms/ceelog
> rpms/libumberlog
> rpms/libmongo-client

> ifarkas:

No answer here, so I have orphaned: 

> rpms/rubygem-simple_form -- Flexible and powerful components to
> create forms ( master f25 f24 f23 )
> 
> mchalk: 

No answer here either, so I have orphaned:

> rpms/drpm -- A library for making, reading and applying deltarpm
> packages ( master f25 f24 f23 )


Thanks, 

kevin

kevin
 



pgp1eJm8ujQIA.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

2016-09-27 Thread buildsys



perl-Data-Alias has broken dependencies in the rawhide tree:
On aarch64:
perl-Data-Alias-1.20-2.fc24.aarch64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.aarch64 requires perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Alien-ROOT

2016-09-27 Thread buildsys



perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-1.fc26.noarch requires root-core
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Missing dependency in glibc package

2016-09-27 Thread Björn Esser


Am 27.09.2016 um 22:08 schrieb Roman Tsisyk:

On Tue, Sep 27, 2016 at 10:53 PM, Björn Esser  wrote:

Forgot to mention:  Explicit dependencies are usually the better way,
instead of relying on implicit dependencies…


Of course.


File Dependencies
RPM gives you the ability to depend on files instead of packages. Whenever 
possible you should avoid file dependencies as they slow down dependency 
resolution and require the package manager to download file lists in addition 
to to regular dependency information. There are, however, times when other 
technical considerations outweigh these considerations. If the files you need 
are prone to moving between packages of different names, it can be useful to 
depend on those files directly.

I found that a dependency on "setup" package is not common practice:

# dnf repoquery --whatrequires setup|wc -l
19



Yes, because it usually gets installed by `basesystem` and `filesystem` 
packages; if those packages are missing, you broke your system anyways…

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

81 matches

Mail list logo