Re: Atomic 29: ostree upgrade failed because of libdnf

[arnaud gaboury]

On Tue, Dec 4, 2018 at 6:57 PM Dusty Mabe  wrote:

>
>
> On 12/4/18 11:40 AM, Dusty Mabe wrote:
>
> >
> > I will look at the configs and see if I can figure out where things are
> going wrong.
> >
>
> I think this a a regression is some of the new yaml parsing in pungi. I
> opened a bug
> to see https://pagure.io/pungi/issue/1092
>
> The updates-testing runs are running right after the updates runs and
> overwriting the ref.
> For now we can disable updates-testing composes for silverblue so that it
> won't overwrite
> the updates run.
>
> Here is a PR for that:
>
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LGL6LPHSOPNKQUWGYHGZVSDOX466WHFH/
>
> Dusty
>

My issue has been solved and could upgrade

---
$ rpm-ostree upgrade
1 metadata, 0 content objects fetched; 569 B transferred in 1 seconds
Checking out tree 6b4bc8e... done
Enabled rpm-md repositories: updates fedora yarn rpm-fusion
rpm-md repo 'updates' (cached); generated: 2018-12-05T02:28:43Z
rpm-md repo 'fedora' (cached); generated: 2018-10-24T22:20:15Z
rpm-md repo 'yarn' (cached); generated: 2018-11-07T20:05:15Z
rpm-md repo 'rpm-fusion' (cached); generated: 2018-10-23T11:05:19Z
Importing metadata [=] 100%
Resolving dependencies... done
No upgrade available.
$  rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-atomic-29:fedora/29/x86_64/silverblue
   Version: 29.20181205.0 (2018-12-05T01:01:39Z)
BaseCommit:
6b4bc8e81acb50897c493154d09afb6f07da3b2d35a1811ab1f121c4447117c1
  GPGSignature: Valid signature by
5A03B4DD8254ECA02FDA1637A20AA56B429476B4
   LayeredPackages: byacc compat-ffmpeg28 dnf
fedora-workstation-repositories ffmpeg ffmpeg-libs flex gcc git
gnome-tweak-tool
gstreamer1-libav gstreamer1-plugins-ugly httpie
hugo kubernetes-client nano nodejs perl-AnyEvent-I3
python2-kobo-rpmlib python3-kobo-rpmlib snapd
vim wmctrl zsh

  ostree://fedora-atomic-29:fedora/29/x86_64/silverblue
   Version: 29.20181205.0 (2018-12-05T01:01:39Z)
BaseCommit:
6b4bc8e81acb50897c493154d09afb6f07da3b2d35a1811ab1f121c4447117c1
  GPGSignature: Valid signature by
5A03B4DD8254ECA02FDA1637A20AA56B429476B4
   LayeredPackages: byacc compat-ffmpeg28 dnf
fedora-workstation-repositories ffmpeg ffmpeg-libs flex gcc git
gnome-tweak-tool
gstreamer1-libav gstreamer1-plugins-ugly httpie
hugo kubernetes-client nano nodejs perl-AnyEvent-I3
python2-kobo-rpmlib python3-kobo-rpmlib snapd
vim wmctrl zsh
-


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 30 Rawhide 20181205.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 30 Rawhide 20181205.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20181130.n.0: anaconda-30.12-2.fc30.src, 20181205.n.0: 
anaconda-30.13-1.fc30.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/30

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181205.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181205.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181205.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181205.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181205.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181205.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181205.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Stalled Review Request - Close it and create new?

[Andrew Bauer]

Somehow I knew this question was documented somewhere in the giant book of 
Fedora. I just couldn't find it. Thanks for pointing it out.

Thanks everyone for the fast response. I'll wait another week before taking 
action, and when I do I'll make sure to file a releng ticket to get it 
unblocked.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
starting in fedora-30/rawhide.

The upstream project doesn't support it. The armv7hl builders don't have
enough memory (or address space) to build some components.

And the other active maintainer (branto) and I don't have cycles to
devote to keeping it building on 32-bit archs.

(FWIW, currently ceph-12.2.9 (luminous) is in rawhide, f29, and f28 and
it has packages for i686 and armv7hl for people who want to run ceph on
32-bit archs.)

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Marcin Juszkiewicz]

W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:

> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
> starting in fedora-30/rawhide.

> The upstream project doesn't support it. The armv7hl builders don't have
> enough memory (or address space) to build some components.

BTW - how much memory is needed to build Ceph 14?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Dan Horák]

On Wed, 5 Dec 2018 14:23:49 +0100
Marcin Juszkiewicz  wrote:

> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
> 
> > Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl
> > archs starting in fedora-30/rawhide.
> 
> > The upstream project doesn't support it. The armv7hl builders don't
> > have enough memory (or address space) to build some components.
> 
> BTW - how much memory is needed to build Ceph 14?

have you tried building with reduced debuginfo, eg. -g1 or even -g0?

I wonder how much broken deps it will cause.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20181205.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181204.n.0
NEW: Fedora-Rawhide-20181205.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  4
Dropped packages:0
Upgraded packages:   63
Downgraded packages: 0

Size of added packages:  9.08 MiB
Size of dropped packages:0 B
Size of upgraded packages:   4.05 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -283.83 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: byte-buddy-1.9.5-2.fc30
Summary: Runtime code generation for the Java virtual machine
RPMs:byte-buddy byte-buddy-agent byte-buddy-javadoc byte-buddy-maven-plugin 
byte-buddy-parent
Size:8.46 MiB

Package: golang-github-linode-linodego-0.7.0-1.fc30
Summary: Go client for Linode REST v4 API
RPMs:golang-github-linode-linodego-devel
Size:68.48 KiB

Package: perl-POSIX-2008-0.16-1.fc30
Summary: Perl interface to POSIX.1-2008
RPMs:perl-POSIX-2008
Size:367.41 KiB

Package: perl-Syntax-Keyword-Try-0.09-1.fc30
Summary: try/catch/finally syntax for perl
RPMs:perl-Syntax-Keyword-Try
Size:201.07 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  anaconda-30.13-1.fc30
Old package:  anaconda-30.12-2.fc30
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-tui anaconda-widgets anaconda-widgets-devel
Size: 18.42 MiB
Size change:  122.15 KiB
Changelog:
  * Tue Dec 04 2018 Martin Kolman  - 30.13-1
  - Extend tests for the configuration support (vponcova)
  - Split the Anaconda configuration handler to more files (vponcova)
  - Add tests for the product configurations (vponcova)
  - Read only *.conf files from /etc/anaconda/conf.d (vponcova)
  - Create the product configuration loader (vponcova)
  - Disable BLS config if new-kernel-pkg script is installed (javierm)
  - Drop xorg-x11-server-Xorg check from graphical target detection (#1583958)
(mkolman)
  - Create a basic structure of the product configuration files (vponcova)
  - Fix pylint errors (vponcova)
  - dracut/parse-kickstart: don't abort on --device=link (lkundrak)
  - Add provides_network_config system property (rvykydal)
  - Get rid of network system capability which does not make sense. (rvykydal)
  - Prohibit network configuration on Live OS. (rvykydal)
  - Use check_supported_locales to filter unsupported locales (vponcova)
  - Replace filterSupportedLangs and filterSupportedLocales (vponcova)
  - Remove help-related constants from install classes (vponcova)
  - Remove setup_on_boot from the install classes (vponcova)
  - Convert a keymap into a list of layouts (vponcova)
  - RPM: anaconda-core requires dbus-daemon (awilliam)
  - Remove use_geolocation_with_kickstart from install classes (vponcova)


Package:  arm-trusted-firmware-2.0-2.20181204.fc30
Old package:  arm-trusted-firmware-2.0-1.fc30
Summary:  ARM Trusted Firmware
RPMs: arm-trusted-firmware-armv8
Size: 121.78 KiB
Size change:  4.20 KiB
Changelog:
  * Tue Dec 04 2018 Peter Robinson  2.0-2.20181204
  - Upstream snapshot
  - Enable Marvell a3700, AMLogic gxbb


Package:  atomic-reactor-1.6.36.1-2.fc30
Old package:  atomic-reactor-1.6.36.1-1.fc30
Summary:  Improved builder for Docker images
RPMs: atomic-reactor python3-atomic-reactor python3-atomic-reactor-koji 
python3-atomic-reactor-metadata python3-atomic-reactor-rebuilds
Size: 806.98 KiB
Size change:  636 B
Changelog:
  * Tue Dec 04 2018 Clement Verna  - 1.6.36.1-2
  - Add Fedora specific patch


Package:  buildah-1.6-9.dev.git01f9ae2.fc30
Old package:  buildah-1.6-8.dev.git9c65e56.fc30
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 23.67 MiB
Size change:  87.79 KiB
Changelog:
  * Wed Dec 05 2018 Lokesh Mandvekar (Bot)  - 
1.6-9.dev.git01f9ae2
  - autobuilt 01f9ae2


Package:  clamav-unofficial-sigs-5.6.2-2.fc30
Old package:  clamav-unofficial-sigs-3.7.2-6.fc29
Summary:  Scripts to download unoffical clamav signatures
RPMs: clamav-unofficial-sigs
Size: 51.17 KiB
Size change:  8.11 KiB
Changelog:
  * Wed Sep 12 2018 Didier Fabert  5.6.2-1
  - Switch to new upstream: extremeshok on github

  * Wed Sep 12 2018 Didier Fabert  5.6.2-2
  - Generate cron, logrotate and man files


Package:  corosync-2.99.4-2.fc30
Old package:  corosync-2.99.4-1.fc30
Summary:  The Corosync Cluster Engine and Application Programming Interfaces
RPMs: corosync corosynclib corosynclib-devel
Size: 2.63 MiB
Size change:  2.12 KiB
Changelog:
  * Tue Dec 04 2018 Jan Friesse  - 2.99.4-2
  - Add libknet1-crypto-nss-plugin dependency


Package:  dbus-1:1.12.12-1.fc30
Old package:  dbus-1:1.12.10-9.fc30
Summary:  D-BUS message bus
RPMs: dbus dbus-common dbus-daemon dbus-devel dbus-doc dbus-libs 
dbus-tests dbus-

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

On 12/5/18 8:34 AM, Dan Horák wrote:
> On Wed, 5 Dec 2018 14:23:49 +0100
> Marcin Juszkiewicz  wrote:
> 
>> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
>>
>>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl
>>> archs starting in fedora-30/rawhide.
>>
>>> The upstream project doesn't support it. The armv7hl builders don't
>>> have enough memory (or address space) to build some components.
>>
>> BTW - how much memory is needed to build Ceph 14?

More — apparently — than the armv7hl builders have. :-) branto may know.

> have you tried building with reduced debuginfo, eg. -g1 or even -g0?

branto told me that he has tried all the different optimization levels.

> I wonder how much broken deps it will cause.

Don't know. Hence this heads up warning.

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Marcin Juszkiewicz]

W dniu 05.12.2018 o 14:45, Kaleb S. KEITHLEY pisze:
> On 12/5/18 8:34 AM, Dan Horák wrote:
>> On Wed, 5 Dec 2018 14:23:49 +0100
>> Marcin Juszkiewicz  wrote:
>>
>>> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
>>>
 Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl
 archs starting in fedora-30/rawhide.
 The upstream project doesn't support it. The armv7hl builders don't
 have enough memory (or address space) to build some components.
>>> BTW - how much memory is needed to build Ceph 14?

> More — apparently — than the armv7hl builders have. :-) branto may know.

Random Fedora armhf builder hardware info:

---
CPU info:
Architecture:armv7l
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Model:   1
Model name:  ARMv7 Processor rev 1 (v7l)
BogoMIPS:100.00
Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
idivt vfpd32 lpae evtstrm


Memory:
  totalusedfree  shared  buff/cache   available
Mem:   24929616  10309224375448 348  45107624524500
Swap:  18869244   2134818847896


Storage:
Filesystem  Size  Used Avail Use% Mounted on
/dev/vda2   135G  5.7G  122G   5% /
---

Seriously 24 GB of ram + 18 GB of swap is not enough to build ceph? That's
more real memory than x86-64 builder have (15 387 432 ram + 134 216 700 swap).

I understand "we drop because upstream does not care about 32bit" reason.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Dan Horák]

On Wed, 5 Dec 2018 15:02:41 +0100
Marcin Juszkiewicz  wrote:

> W dniu 05.12.2018 o 14:45, Kaleb S. KEITHLEY pisze:
> > On 12/5/18 8:34 AM, Dan Horák wrote:
> >> On Wed, 5 Dec 2018 14:23:49 +0100
> >> Marcin Juszkiewicz  wrote:
> >>
> >>> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
> >>>
>  Ceph 14.x.x (Nautilus) will no longer be built on i686 and
>  armv7hl archs starting in fedora-30/rawhide.
>  The upstream project doesn't support it. The armv7hl builders
>  don't have enough memory (or address space) to build some
>  components.
> >>> BTW - how much memory is needed to build Ceph 14?
> 
> > More — apparently — than the armv7hl builders have. :-) branto may
> > know.
> 
> Random Fedora armhf builder hardware info:
> 
> ---
> CPU info:
> Architecture:armv7l
> Byte Order:  Little Endian
> CPU(s):  4
> On-line CPU(s) list: 0-3
> Thread(s) per core:  1
> Core(s) per socket:  4
> Socket(s):   1
> Model:   1
> Model name:  ARMv7 Processor rev 1 (v7l)
> BogoMIPS:100.00
> Flags:   half thumb fastmult vfp edsp neon vfpv3 tls
> vfpv4 idiva idivt vfpd32 lpae evtstrm
> 
> 
> Memory:
>   totalusedfree  shared  buff/cache
> available Mem:   24929616  10309224375448
> 348  45107624524500 Swap:  18869244   21348
> 18847896
> 
> 
> Storage:
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/vda2   135G  5.7G  122G   5% /
> ---
> 
> Seriously 24 GB of ram + 18 GB of swap is not enough to build ceph?
> That's more real memory than x86-64 builder have (15 387 432 ram +
> 134 216 700 swap).
> 
> I understand "we drop because upstream does not care about 32bit"
> reason. ___

The problem is usually in the 4GB address space on 32-bit platforms
(much less is available for user data), when it builds large C++
codebase. Either the compiler OOMs or the linker OOMs. That's why
reducing the generated debuginfos often helps.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Daniel P . Berrangé]

On Wed, Dec 05, 2018 at 08:45:19AM -0500, Kaleb S. KEITHLEY wrote:
> On 12/5/18 8:34 AM, Dan Horák wrote:
> > On Wed, 5 Dec 2018 14:23:49 +0100
> > Marcin Juszkiewicz  wrote:
> > 
> >> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
> >>
> >>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl
> >>> archs starting in fedora-30/rawhide.
> >>
> >>> The upstream project doesn't support it. The armv7hl builders don't
> >>> have enough memory (or address space) to build some components.

Is there any consideration given to only building the ceph client
pieces on 32-bit ?  Presumably those parts are simpler and thus
not likely to hit the address/memory limits, and be more tractable
for supporting ?

I very much doubt people would run ceph server parts on 32-bit,
so any usage of ceph on 32-bit is likely to be limited to the
client pieces

> >> BTW - how much memory is needed to build Ceph 14?
> 
> More — apparently — than the armv7hl builders have. :-) branto may know.
> 
> > have you tried building with reduced debuginfo, eg. -g1 or even -g0?
> 
> branto told me that he has tried all the different optimization levels.
> 
> > I wonder how much broken deps it will cause.
> 
> Don't know. Hence this heads up warning.

repoquery can report on direct dependancies that would be broken by
any ceph packages being removed. There could be transitive ripples
out from there.  From my own POV this would impact qemu  & libvirt,
which would need to conditionally turn off their rbd support for
those archs.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Atomic 29: ostree upgrade failed because of libdnf

[Dusty Mabe]

On 12/5/18 5:14 AM, arnaud gaboury wrote:
> 
> 
> On Tue, Dec 4, 2018 at 6:57 PM Dusty Mabe  > wrote:
> 
> 
> 
> On 12/4/18 11:40 AM, Dusty Mabe wrote:
> 
> >
> > I will look at the configs and see if I can figure out where things are 
> going wrong.
> >
> 
> I think this a a regression is some of the new yaml parsing in pungi. I 
> opened a bug
> to see https://pagure.io/pungi/issue/1092
> 
> The updates-testing runs are running right after the updates runs and 
> overwriting the ref.
> For now we can disable updates-testing composes for silverblue so that it 
> won't overwrite
> the updates run.
> 
> Here is a PR for that:
> 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LGL6LPHSOPNKQUWGYHGZVSDOX466WHFH/
> 
> Dusty
> 
> 
> My issue has been solved and could upgrade

Yep. We put in a workaround yesterday. We should be good now. Sorry about that.

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[HEADS UP] Eclipse dropping 32-bit arches

[Mat Booth]

The message about Ceph [1] reminded me that we should probably make the
same notification for Eclipse Platform.

The Eclipse Platform upstream is in the process of dropping all support for
32bit arches.

The current state is that upstream are no longer building for 32bit arches
upstream for 4.10 (release 2018-12) onwards. I expect them to start
actively removing 32bit specific code in future releases.

You can read more about the decision on the upstream bug [2]

In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
still builds for 32bit arches, but this will not last long. I expect in a
future release (4.11 or later) Eclipse will no longer build on x86/arm and
at that time I will no longer be able to support these architectures in
Fedora -- I expect to exclude those arches from Fedora builds.

If you depend on the ECJ batch compiler, this will continue to be available
on all arches as a noarch package. (It is packaged as a discrete SRPM and
has no build or runtime dependency on the Eclipse Platform itself.)

Regards,
Mat


[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XCQIMO3W3D5XGHQHBVVIBUBPIXKJJJWL/
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Björn Persson]

> ** Rename gnupg package to gnupg1
> ** Rename gpg binary to gpg1
> ** Rename gpg2 binary to gpg
> ** Create gpg2 → gpg symlink

Just for clarity, and in the context of the proposed source file
verification policy (https://pagure.io/packaging-committee/issue/610):

The gnupg2 package will keep that name, right? So if we tell packagers
to write "BuildRequires: gnupg2" in their spec files, that dependency
will remain valid forever?

Björn Persson


pgp9JizII5TyK.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation

[Igor Gnatenko]

Yes, that is the plan.
On Wed, Dec 5, 2018 at 4:45 PM Björn Persson  wrote:
>
> > ** Rename gnupg package to gnupg1
> > ** Rename gpg binary to gpg1
> > ** Rename gpg2 binary to gpg
> > ** Create gpg2 → gpg symlink
>
> Just for clarity, and in the context of the proposed source file
> verification policy (https://pagure.io/packaging-committee/issue/610):
>
> The gnupg2 package will keep that name, right? So if we tell packagers
> to write "BuildRequires: gnupg2" in their spec files, that dependency
> will remain valid forever?
>
> Björn Persson
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Rawhide-20181205.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 19/131 (x86_64), 3/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20181204.n.0):

ID: 316203  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/316203
ID: 316204  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/316204
ID: 316277  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/316277
ID: 316278  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/316278
ID: 316282  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/316282
ID: 316283  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/316283
ID: 316284  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/316284
ID: 316285  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/316285
ID: 316300  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/316300
ID: 316306  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/316306

Old failures (same test failed in Rawhide-20181204.n.0):

ID: 316185  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/316185
ID: 316196  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/316196
ID: 316206  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/316206
ID: 316207  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/316207
ID: 316210  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/316210
ID: 316211  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/316211
ID: 316226  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/316226
ID: 316292  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/316292
ID: 316293  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/316293
ID: 316294  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/316294
ID: 316295  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/316295
ID: 316296  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/316296
ID: 316297  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/316297

Soft failed openQA tests: 2/24 (i386), 1/131 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20181204.n.0):

ID: 316188  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/316188

Old soft failures (same test soft failed in Rawhide-20181204.n.0):

ID: 316189  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/316189
ID: 316213  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/316213

Passed openQA tests: 110/131 (x86_64), 19/24 (i386)

New passes (same test did not pass in Rawhide-20181204.n.0):

ID: 316168  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/316168
ID: 316173  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/316173
ID: 316177  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/316177
ID: 316192  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/316192
ID: 316202  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/316202
ID: 316216  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/316216
ID: 316260  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/316260
ID: 316274  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/316274
ID: 316280  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/316280
ID: 316303  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/316303

Skipped openQA tests: 1 of 157

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 197 MiB to 170 MiB
Previous test data: https://openqa.fedoraproject.org/tests/315770#downloads
Cu

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Richard W.M. Jones]

On Wed, Dec 05, 2018 at 02:31:10PM +, Daniel P. Berrangé wrote:
> On Wed, Dec 05, 2018 at 08:45:19AM -0500, Kaleb S. KEITHLEY wrote:
> > On 12/5/18 8:34 AM, Dan Horák wrote:
> > > On Wed, 5 Dec 2018 14:23:49 +0100
> > > Marcin Juszkiewicz  wrote:
> > > 
> > >> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze:
> > >>
> > >>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl
> > >>> archs starting in fedora-30/rawhide.
> > >>
> > >>> The upstream project doesn't support it. The armv7hl builders don't
> > >>> have enough memory (or address space) to build some components.
> 
> Is there any consideration given to only building the ceph client
> pieces on 32-bit ?  Presumably those parts are simpler and thus
> not likely to hit the address/memory limits, and be more tractable
> for supporting ?
> 
> I very much doubt people would run ceph server parts on 32-bit,
> so any usage of ceph on 32-bit is likely to be limited to the
> client pieces

As Dan says, I'd like to know if you (Kaleb) considered building only
the client bits (librbd1 I think?).  It's something which libguestfs
needs too albeit indirectly.

Assuming I've got the right command, the complete list of reverse
dependencies for the client side of Ceph is:

# repoquery -q --whatrequires 'librbd.so.1()(64bit)'
ceph-common-1:12.2.8-1.fc29.x86_64
ceph-common-1:12.2.9-1.fc29.x86_64
ceph-test-1:12.2.8-1.fc29.x86_64
ceph-test-1:12.2.9-1.fc29.x86_64
fio-0:3.7-2.fc29.x86_64
librbd-devel-1:12.2.8-1.fc29.x86_64
librbd-devel-1:12.2.9-1.fc29.x86_64
libvirt-daemon-driver-storage-rbd-0:4.7.0-1.fc29.x86_64
python-rbd-1:12.2.8-1.fc29.x86_64
python-rbd-1:12.2.9-1.fc29.x86_64
python3-rbd-1:12.2.8-1.fc29.x86_64
python3-rbd-1:12.2.9-1.fc29.x86_64
qemu-block-rbd-2:3.0.0-1.fc29.x86_64
qemu-block-rbd-2:3.0.0-2.fc29.x86_64
rbd-fuse-1:12.2.8-1.fc29.x86_64
rbd-fuse-1:12.2.9-1.fc29.x86_64
rbd-nbd-1:12.2.8-1.fc29.x86_64
rbd-nbd-1:12.2.9-1.fc29.x86_64
scsi-target-utils-rbd-0:1.0.70-4.fc28.x86_64

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [fedora-java] [HEADS UP] Eclipse dropping 32-bit arches

[Aleksandar Kurtakov]

On Wed, Dec 5, 2018 at 5:32 PM Mat Booth  wrote:

> The message about Ceph [1] reminded me that we should probably make the
> same notification for Eclipse Platform.
>
> The Eclipse Platform upstream is in the process of dropping all support
> for 32bit arches.
>
> The current state is that upstream are no longer building for 32bit arches
> upstream for 4.10 (release 2018-12) onwards. I expect them to start
> actively removing 32bit specific code in future releases.
>

Speaking as upstream representative here - even if we don't have plans to
start removing 32 bit specific code, we are not planning to check that the
whole pointer size magic to support 32 bit is done proper in new code so
native bits of Eclipse will probably fail to compile and it would be up to
Fedora maintainers providing these fixes and keep maintaining them as it
makes  no sense to upstream such changes when support is on its way out.
What is worse though is that sometimes these issues are not catched at
compile time but at runtime resulting in crashing the whole Eclipse -
experience that would give bad name for both Eclipse and Fedora thus
definetely not wanted.


> You can read more about the decision on the upstream bug [2]
>
> In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
> still builds for 32bit arches, but this will not last long. I expect in a
> future release (4.11 or later) Eclipse will no longer build on x86/arm and
> at that time I will no longer be able to support these architectures in
> Fedora -- I expect to exclude those arches from Fedora builds.
>

That's the best thing to do IMHO.


> If you depend on the ECJ batch compiler, this will continue to be
> available on all arches as a noarch package. (It is packaged as a discrete
> SRPM and has no build or runtime dependency on the Eclipse Platform itself.
> )
>
> Regards,
> Mat
>
>
> [1]
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XCQIMO3W3D5XGHQHBVVIBUBPIXKJJJWL/
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Richard W.M. Jones]

Forgot about librados, so there's actually a much bigger list:

# dnf repoquery -q --whatrequires 'librados.so.2()(64bit)'
ceph-common-1:12.2.8-1.fc29.x86_64
ceph-common-1:12.2.9-1.fc29.x86_64
ceph-radosgw-1:12.2.8-1.fc29.x86_64
ceph-radosgw-1:12.2.9-1.fc29.x86_64
ceph-test-1:12.2.8-1.fc29.x86_64
ceph-test-1:12.2.9-1.fc29.x86_64
fio-0:3.7-2.fc29.x86_64
librados-devel-1:12.2.8-1.fc29.x86_64
librados-devel-1:12.2.9-1.fc29.x86_64
libradosstriper1-1:12.2.8-1.fc29.x86_64
libradosstriper1-1:12.2.9-1.fc29.x86_64
librbd1-1:12.2.8-1.fc29.x86_64
librbd1-1:12.2.9-1.fc29.x86_64
librgw2-1:12.2.8-1.fc29.x86_64
librgw2-1:12.2.9-1.fc29.x86_64
libvirt-daemon-driver-storage-rbd-0:4.7.0-1.fc29.x86_64
nfs-ganesha-0:2.7.0-3.fc29.x86_64
nfs-ganesha-0:2.7.1-2.fc29.x86_64
nfs-ganesha-rados-grace-0:2.7.0-3.fc29.x86_64
nfs-ganesha-rados-grace-0:2.7.1-2.fc29.x86_64
python-rados-1:12.2.8-1.fc29.x86_64
python-rados-1:12.2.9-1.fc29.x86_64
python-rbd-1:12.2.8-1.fc29.x86_64
python-rbd-1:12.2.9-1.fc29.x86_64
python-rgw-1:12.2.8-1.fc29.x86_64
python-rgw-1:12.2.9-1.fc29.x86_64
python2-cradox-0:2.1.0-2.fc29.x86_64
python3-cradox-0:2.1.0-2.fc29.x86_64
python3-rados-1:12.2.8-1.fc29.x86_64
python3-rados-1:12.2.9-1.fc29.x86_64
python3-rbd-1:12.2.8-1.fc29.x86_64
python3-rbd-1:12.2.9-1.fc29.x86_64
python3-rgw-1:12.2.8-1.fc29.x86_64
python3-rgw-1:12.2.9-1.fc29.x86_64
qemu-block-rbd-2:3.0.0-1.fc29.x86_64
qemu-block-rbd-2:3.0.0-2.fc29.x86_64
rbd-fuse-1:12.2.8-1.fc29.x86_64
rbd-fuse-1:12.2.9-1.fc29.x86_64
rbd-mirror-1:12.2.8-1.fc29.x86_64
rbd-mirror-1:12.2.9-1.fc29.x86_64
rbd-nbd-1:12.2.8-1.fc29.x86_64
rbd-nbd-1:12.2.9-1.fc29.x86_64
scsi-target-utils-rbd-0:1.0.70-4.fc28.x86_64
xrootd-ceph-1:4.8.4-2.fc29.x86_64
xrootd-ceph-1:4.8.5-2.fc29.x86_64

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Tomasz Torcz]

  “Client bits” also means stuff needed for accessing file-system
  interface of Ceph:
  – nfs-ganesha-ceph.x86_64
  – ceph-fuse

  and for some users – the rados gateway bits:
  – nfs-ganesha-rgw.x86_64
  - ceph-radosgw.x86_64

-- 
Tomasz Torcz   72->|   80->|
xmpp: zdzich...@chrome.pl  72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Mon, 2018-12-03 at 22:16 +0100, Jan Pokorný wrote:
> On 16/11/18 22:07 +, Jonathan Dieter wrote:
> > The core idea behind zchunk is that a file is split into independently
> > compressed chunks and the checksum of each compressed chunk is stored
> > in the zchunk header.  When downloading a new version of the file, you
> > download the zchunk header first, check which chunks you already have,
> > and then download the rest.
> 
> Just one more thought I reliazed in hindsight, there are ways to cut down
> the installed files in RPM ecosystem, currently with a request to omit
> documentation (%doc tagged files, see --nodocs/--excludedocs).
> 
> Indeed, that's a sort of files you can usually omit without hesitation
> in containers/VMs.  Perhaps there are some more bits that are de facto
> optional without losing anything from the functionality.
> 
> So with clever separation, such bits wouldn't even need to be downloaded
> when they will not eventually make it to the disk.  That might make
> things like customizing a base container image tiny bit more swift,
> e.g. in CI/CD context without many connectivity guarantees (up to
> mirrors anyway).  But might not be worth it if the trade-off
> is already predictably suboptimal in other aspects.

I think this is very interesting and definitely feasible (assuming the
core concept of zchunked rpms is reasonable).

On a tangent, I realized something else about metadata generation (and
I think someone else had picked up on it, but it hadn't quite
registered with me).  Currently generating metadata for RPMs involves
reading the full RPM to calculate the checksum.  With zchunk, the
header checksum is stored at the beginning of the file and is all you
need to verify a zchunk file. 

Jonathan


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jeff Johnson]

An entire *.rpm file needs to be read only because rpm-metadata chose the file 
digest to be included in metadata.

There is no way for a plaintext file to contain its own digest, true for zchunk 
as well as current rpm format.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal : Use OSBS to build the fedora container base image

[Mohan Boddu]

+1 to the change proposal.

Someone still need to submit updates in bodhi and rel-eng would be happy to
own that task and it is much simpler than what we have today.

On Mon, Dec 3, 2018 at 1:39 PM Clement Verna 
wrote:

> Hi all,
>
> I would like to get feedbacks on the following proposal. Use OSBS to
> build the fedora container base image, indeed OSBS has the capability
> to build a base container image using a kickstart file.
> To do this OSBS needs a Dockerfile, a kickstart file and an
> image-build.conf file stored in dist-git, then OSBS will trigger an
> ImageFactory task in Koji in order to build to base image and then it
> will build the base container based on the artifacts built in Koji.
>
> Here a the few advantages I see in moving forward with this proposal :
>
>   - Use of a single dist-git repo for the base image, allowing use of
> fedora-ci.
>   - Using OSBS will allow us to make use of bodhi updates to release
> new versions of the image
>   - OSBS deals with multi-arches (we currently use a custom script in
> releng to build manifest list)
>   - Does not requires releng to run a script to release the images
>
> Before I start looking at the implementation details, I would
> appreciate feedbacks.
>
> Thanks
> Clément
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 29 Elections — Voting now open

[Ben Cotton]

Voting is now open for the Fedora 29 election cycle. You can vote in
the Elections app[1]. Interviews with candidates are available on the
Fedora Community Blog[2], with links available in the Elections app.
Voting ends at 23:59 UTC on 20 December.

[1] https://admin.fedoraproject.org/voting/
[2] http://communityblog.fedoraproject.org/

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30 Self-Contained Change Proposal: Erlang 21

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Erlang_21

= Erlang 21 =

== Summary ==
Update Erlang/OTP to version 21.

== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemen...@gmail.com, erl...@lists.fedoraproject.org,
bowlofe...@fedoraproject.org, jcl...@fedoraproject.org

== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.

== Dependencies ==

The following packages must be rebuilt:
see https://fedoraproject.org/wiki/Changes/Erlang_21#Dependencies


== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]]),
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]], and
[[Changes/Erlang_20|Erlang 20]]. It should be noted that this change
consists from an independent or loosely coupled smaller changes. If we
fail to deliver some changes in time, we should reschedule these exact
changes to the future Fedora release while keeping already implemented
ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A

== Documentation ==
* [http://www.erlang.org/news/123 Erlang/OTP 21.0 release notes]
* [http://www.erlang.org/news/124 Erlang/OTP 21.1 release notes]

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30 System-Wide Change Proposal: Boost 1.69 Upgrade

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/F30Boost169

== Summary ==
This change brings Boost 1.69 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.

== Owner ==
* Name: [[User:jwakely|Jonathan Wakely]]
* Email: jwakely at fedoraproject dot org


== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.

== Benefit to Fedora ==
Fedora 29 includes Boost 1.67 but the latest upstream release, Boost
1.68, was released on August 9th, 2018 (the 1.69 release is scheduled
for mid-November 2018, so it should be in time for F30).

Fedora will stay relevant, as far as Boost clients are concerned.
Boost 1.68 brings two new libraries:
* [https://www.boost.org/doc/libs/1_68_0/doc/html/yap.html YAP], an
expression template library for C++14 and later, from Zach Laine.

== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f30-boost" build system tag
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]): https://pagure.io/releng/issue/7614
** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).

* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.

* Release engineering: [https://pagure.io/releng/issue/7595] (a check
of an impact with Release Engineering is needed)
** 
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: All deliverables will include updated Boost
packages.

* Policies and guidelines:
** Apart from scope, this is business as usual, so no policies, no guidelines.

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* No impact on system upgrade.
* No manual configuration or data migration needed.
* Some impact on other packages. Historically this hasn't been too big
of a problem and could always be resolved before deadline.

== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(dnf install boost) on Fedora and checking that it does
not break other packages (see below for a way to obtain a list of
boost clients).

== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.

== Dependencies ==
Packages that must be rebuilt:
$ repoquery -s --releasever=rawhide --whatrequires libboost\*
--disablerepo=* --enablerepo=fedora | sort -u

All clients:
$ repoquery --releasever=rawhide --archlist=src --whatrequires
boost-devel --disablerepo='*' --enablerepo=fedora-source

== Contingency Plan ==
* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F30 with Boost 1.67, which is already in rawhide.

* Contingency deadline: We will know whether the change can be made
once the rebuilds in the side tag are done, which will be January
2019, ideally before the mass rebuild.

* Blocks release? No
* Blocks product? None

== Documentation ==
* https://www.boost.org/users/history/version_1_68_0.html
* https://www.boost.org/development/index.html


-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Peter Robinson]

Kaleb,

Firstly the title is misleading as there was no heads up, a heads up
is notice before you actually push the change, not when you do the
change.

> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
> starting in fedora-30/rawhide.
>
> The upstream project doesn't support it. The armv7hl builders don't have
> enough memory (or address space) to build some components.
>
> And the other active maintainer (branto) and I don't have cycles to
> devote to keeping it building on 32-bit archs.
>
> (FWIW, currently ceph-12.2.9 (luminous) is in rawhide, f29, and f28 and
> it has packages for i686 and armv7hl for people who want to run ceph on
> 32-bit archs.)

As others have asked in the thread can we possibly build client only?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org