Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Nick Coghlan]

On 3 July 2017 at 02:04, Stephen John Smoogen  wrote:
> On 1 July 2017 at 21:42, Nick Coghlan  wrote:
>> On 1 July 2017 at 03:36, Adam Williamson  wrote:
>>> On Fri, 2017-06-30 at 12:07 +1000, Nick Coghlan wrote:
 Even if a 4.0 does happen, the magnitude of the change relative to the
 preceding 3.x release is expected to be comparable to that between any
 given 3.x and 3.x+1 release, so it wouldn't require the parallel stack
 approach that has proven necessary to handle the core data model
 changes that impacted the 2->3 transition.
>>>
>>> I thought it would be tolerably obvious that I didn't mean "literally
>>> the specific conceptual Python 4.0 that at one point was expected to
>>> exist after 3.9" or "any specific Python 4 release that happens".
>>> Clearly what I meant was "any future non-backwards-compatible major
>>> Python release". Maybe *right now* you don't expect there to be one,
>>> but I'm sure there was probably a point during Python 1's lifetime at
>>> which no-one expected there to be a backwards-incompatible Python 2,
>>> and a point during Python 2's lifetime at which no-one expected there
>>> to be a backwards-incompatible Python 3...
>>
>> No, as in the process of maintaining Python 2 & 3 in parallel for over
>> a decade, we've significantly improved our toolset for *not* painting
>> ourselves into similar corners in the future (and we're likely to
>> introduce even more technical capabilities along those lines over
>> time, such as Victor Stinner's proposal for a more flexible runtime
>> code transformation pipeline).
>>
>> Now, obviously, we can't *stop* redistributor communities like Fedora
>> from collectively declaring those process, policy, and technology
>> changes ineffective, and instead investing their time and energy in
>> planning for future disruptions that probably aren't going to happen.
>> However, we *can* provide the advice that we don't believe such
>> endeavours are going to represent a good use of that time and energy.
>>
>
> OK here is the problem with this whole conversation in a nutshell.
> Each side thinks the other one is bikeshedding and stopped listening
> to the other.

Thanks for the excellent summary of the situation Stephen. I'm not
going to respond point by point, but instead use your post as a
launching point for an arguably radical notion: we could explicitly
explore supporting "late binding" of RPM dependency declarations in
order to better support the folks that need old pieces of software to
"just work" when built or run on a newer system, but are also prepared
to keep all the pieces if they end up breaking that system in the
process.

> Here is the distributor problem in a nutshell. You will have people
> come in who are not part of the the upstream community who just want
> to get some old code they have working. They follow some old written
> down instructions and find that boom instead of a working thing they
> now have a broken pile of bolts with no idea why.

Jason's offer to go backfill EPEL with "python2-*" metapackages
prompted a question I hadn't really thought about before: what if we
had a way to effectively generate additional virtual-provides at
*installation time*, rather than all such declarations having to be
baked directly into the RPMs at build time?

That is, suppose we *never* added back build-time virtual provides for
the "python-*" names, and instead added a new config file inside a new
config directory "/etc/yum/aliases.d/" that said "If 'python-(.*)'
isn't found, check for 'python3-\1' instead". DNF would then
automatically convert any given name translation rules into the
appropriate "OR" clauses in the rich dependency system.

The net effect of this would be that, *by default*, unqualified
"python-*" references would resolve to python3-*, just as they would
if we updated the %python_provides macro.

However, the big difference is that an end user could, if they wanted
to, adjust their build environment (e.g. in a mock chroot) such that
unqualified "python-*" references resolved to "python2-*" instead.
That's something they can't readily do when the aliases are defined in
the built RPMs - instead, you have to rebuild the world just to switch
some aliases around.

Such a system may even have more potential uses than just assisting
with the Python 3 migration. For example:

- install-time name translations between different distros (Py2 vs Py3
being just one example)
- working around missing virtual provides in pre-built RPMs (e.g.
missing "distXY(upstream-name)" metadata)
- potentially making it easier to derive parallel-installable SCLs
from mutually-exclusive modules

So while I freely admit the idea is entirely speculative handwaving at
this point, it seems to me like an approach that could even be
integrated into the xdg-alternatives system (such that runtime
switching can have complementary changes to install-time aliases),
whereas anything we do purely at build-time is inherently inflexible
from an

Re: [Modularity] A proposal for stream naming

[Jan Pazdziora]

On Wed, Jun 28, 2017 at 04:07:43PM -0400, Matthew Miller wrote:
> 
> Each such "collection" module MUST have one or both of the following:
> 
>   * A "latest" rolling stream (As above, this would be separate from
> "rawhide", as "latest stable", but could update frequently and
> arbitrarily.)
> 
>   * One or more streams corresponding to "end of life no earlier than",
> in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for
> 'until'? Or "fYYMM" for 'fedora' — which might make sense if we get
> to my dream of mixing and matching with CentOS modules)

Please make the year a full four-digit  value. Typing that extra
"20" will not hurt anybody and the chance for confusion will be much
smaller.

-- 
Jan Pazdziora
Senior Principal Software Engineer, OpenShift Security Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: Samba AD

[Dario Lesca]

Il giorno lun, 03/07/2017 alle 09.29 +0300, Alexander Bokovoy ha
scritto:
> > When the firs (beta) F27 + samba 4.7 AD will be release, I will try
> > the upgrade on a test virtual environment.
> 
> Sure!

Thanks!
I'll let you know

-- 
Dario Lesca
(inviato dal mio Linux Fedora 25 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Flock Funding Decisions

[Brian Exelbierd]

Flock funding decisions will begin being released this week.  Please do
not ask, irc, email, telegram, smoke signal, etc. anyone about the
status of your decision or about when decisions will be released. 
Everytime someone interrupts the funding committee (or me when I am
processing the requests) it slows the whole system down.  We understand
that you have various time pressures and would like answers.  Please
understand that we are working on this as hard as we can and are not
ignoring you.

As you know, we cannot afford to fund everyone.  Additionally, we cannot
afford to do 100% funding for everyone we will fund.

Therefore, we are going to be releasing funding decisions in rounds. 
This will allow us to manage our budget better.  Your release date is
based on many factors, so do not assume that it says anything about you
as a person or the value of your contributions to Fedora.

It is important that you reply within the time limit specified or you
may lose your funding offer.

Thank you.

regards,

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

Re: [Modularity] A proposal for stream naming

[Brian Exelbierd]

On Thu, Jun 29, 2017, at 10:34 PM, Matthew Miller wrote:
> On Thu, Jun 29, 2017 at 10:29:29PM +0200, Brian Exelbierd wrote:
> > However, considering this from a different angle, a LAMP stack module,
> > for example, might just need to make a certain API/ABI promise and then
> > it could roll for quite a while.  This would be without regard to the
> > changes in the underlying software versions, as long as what was
> > promised on the wrapper was still met.  If this is the case then
> > "collections" are no different from "single applications."
> 
> In terms of EOL, right. But collections have no obvious intrinsic
> version number to use as the major stream identifier, whereas
> applications (and environments and stacks) do.

I think we should allow for an arbitrary version number when the
collection is not obviously tied to a specific release/user space. 
However, I think that should strongly be discouraged and if at all
possible the motivating software in the collection's version number
should be used.  This is not something that should ever require heavy
debate, imho.  I trust packagers to make the right decision.

regards,

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

[SONAME change] MySQL, MariaDB

[Michal Schorm]

Hello everybody!

Since MariaDB 10.2 is finally stable and I resolved all issues that blocked
it for Fedora, I'd like to propose an update for Rawhide.

Current version of MariaDB: 10.1.24
Update planned to: 10.2.6 (or newer)

*This change introduces change of library name from "libmysqlclient.so" to
"libmariadb.so".*
*There are many dependant packages affected.*

The current (optimistic) plan is to deliver the update before Fedora 27 mass
rebuild  at 12.7.2017.
Either the rebuild of all depending packages is inevitable.

-

We actively track the issue here
. There is also a list
of affected packages.
We have a work repository in COPR, where you can find builds of your
packages here
.

We go through all of the issues and we are trying to solve all of those,
which are caused by the library change. More information will appear in
bugzillas connected to the tracker.

Issues are also consulted with MariaDB upstream.
I was told, that there should be strong API and ABI compatibility.

-

Notes:
 - this means also drop of symlinks to "libmysqlclient.so.18.0.0" library.
 - the version of the library in MariaDB 10.2.6 is "mariadb.so.3", however
in mariadb-connector-c it is only "mariadb.so.2". That should sync in next
big update in about a month, I believe.

-

Feel free to ask any questinos here or in tracker BZ, I'll try to search
for all answers.

--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SONAME change] MySQL, MariaDB

[Ralf Corsepius]

On 07/03/2017 03:12 PM, Michal Schorm wrote:

Hello everybody!

Since MariaDB 10.2 is finally stable and I resolved all issues that 
blocked it for Fedora, I'd like to propose an update for Rawhide.


Current version of MariaDB: 10.1.24
Update planned to: 10.2.6 (or newer)

*This change introduces change of library name from "libmysqlclient.so" 
to "libmariadb.so".*


In other word mariadb is failing its mission to be a drop-in replacement 
for mysql.


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

Re: [SONAME change] MySQL, MariaDB

[Michal Schorm]

Nope.

MariaDB is a drop-in replacement. In version 5.5.

For quite a time we use MariaDB 10.1, which openly declared "Now we know
what we are doing and now we know where do we want to go".
MariaDB 10.2 just take another step forward in technology and away from
MySQL.

--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

On Mon, Jul 3, 2017 at 3:52 PM, Ralf Corsepius  wrote:

> On 07/03/2017 03:12 PM, Michal Schorm wrote:
>
>> Hello everybody!
>>
>> Since MariaDB 10.2 is finally stable and I resolved all issues that
>> blocked it for Fedora, I'd like to propose an update for Rawhide.
>>
>> Current version of MariaDB: 10.1.24
>> Update planned to: 10.2.6 (or newer)
>>
>> *This change introduces change of library name from "libmysqlclient.so"
>> to "libmariadb.so".*
>>
>
> In other word mariadb is failing its mission to be a drop-in replacement
> for mysql.
>
> Ralf
> ___
> 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

Review swap request for package cvechecker

[Zamir SUN]

Hi all,

Recently I want to continue the package review request of cvechecker[1]
with mine since it has been quiet for a long time.

So I did commented in comment 7 this March. However, there is no update
till now. I dropped an email to packaging list[2] just now and Tomas
suggest me to ask for a review swap request.

So I am writing to see if anyone can help me with the process.

Thanks!

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1062808
[2]
https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/QXKAKW72B73CGBJHHUATW6SMP2F2XORK/?sort=date
-- 
Ziqian SUN (Zamir)
z...@fedoraproject.org
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SONAME change] MySQL, MariaDB

[Ralf Corsepius]

On 07/03/2017 04:02 PM, Michal Schorm wrote:

Nope.

MariaDB is a drop-in replacement. In version 5.5.


What you wrote is an API change
=> MariaDB is not a drop-in replacement for MySQL anymore.

The "many ṕackages requiring changes" you mentioned furtherly manifest this.

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

Re: Review Swaps: Simple golang packages (for syncthing)

[Athos Ribeiro]

On Sat, Jun 17, 2017 at 09:05:23AM +, Fabio Valentini wrote:
> Hi everybody,

Hi Fabio,

> 
> I need somebody to take on the Review Requests of the only 3 golang
> dependencies that are still blocking a syncthing package:
> 
> golang-github-cznic-zappy:
> https://bugzilla.redhat.com/show_bug.cgi?id=1431743
> golang-github-cznic-lldb:
> https://bugzilla.redhat.com/show_bug.cgi?id=1431745
> golang-github-cznic-ql: https://bugzilla.redhat.com/show_bug.cgi?id=1431748
> 
> When that's done, I need somebody to do the package review of syncthing
> itself ;)
> https://bugzilla.redhat.com/show_bug.cgi?id=1427634
> 
> and the inotify extension:
> https://bugzilla.redhat.com/show_bug.cgi?id=1431868
> 

I am taking them all. I am traveling today, but I will start these
reviews later today or tomorrow morning.

I will tell you the packages I would like to get reviewed back in the
tickets!

:)


-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SONAME change] MySQL, MariaDB

[Sérgio Basto]

On Mon, 2017-07-03 at 15:52 +0200, Ralf Corsepius wrote:
> On 07/03/2017 03:12 PM, Michal Schorm wrote:
> > Hello everybody!
> > 
> > Since MariaDB 10.2 is finally stable and I resolved all issues
> > that 
> > blocked it for Fedora, I'd like to propose an update for Rawhide.
> > 
> > Current version of MariaDB: 10.1.24
> > Update planned to: 10.2.6 (or newer)
> > 
> > *This change introduces change of library name from
> > "libmysqlclient.so" 
> > to "libmariadb.so".*
> 
> In other word mariadb is failing its mission to be a drop-in
> replacement 
> for mysql.

At least is behind schedule,  mysql-community supports json fields
while in MariaDB we are waiting 




> Ralf
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swap request for package cvechecker

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 03, 2017 at 10:11:33PM +0800, Zamir SUN wrote:
> Hi all,
> 
> Recently I want to continue the package review request of cvechecker[1]
> with mine since it has been quiet for a long time.
> 
> So I did commented in comment 7 this March. However, there is no update
> till now. I dropped an email to packaging list[2] just now and Tomas
> suggest me to ask for a review swap request.

Zamir,

open a new bug, and close #1062808 as the duplicate of the new one.
Package review bugs are always tied to the name of the original
reporter.

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

Fedora Rawhide-20170703.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 24/128 (x86_64), 2/18 (i386), 1/2 (arm)

ID: 116644  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/116644
ID: 116645  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/116645
ID: 116646  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/116646
ID: 116667  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/116667
ID: 116670  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/116670
ID: 116671  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/116671
ID: 116673  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/116673
ID: 116674  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/116674
ID: 116676  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/116676
ID: 116677  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/116677
ID: 116678  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/116678
ID: 116687  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/116687
ID: 116689  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/116689
ID: 116730  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/116730
ID: 116734  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/116734
ID: 116745  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/116745
ID: 116746  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/116746
ID: 116747  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/116747
ID: 116750  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/116750
ID: 116752  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/116752
ID: 116753  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/116753
ID: 116757  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/116757
ID: 116758  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/116758
ID: 116759  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/116759
ID: 116762  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/116762
ID: 116780  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/116780
ID: 116781  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/116781

Soft failed openQA tests: 62/128 (x86_64), 14/18 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 116634  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/116634
ID: 116635  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/116635
ID: 116636  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/116636
ID: 116637  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/116637
ID: 116654  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/116654
ID: 116656  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/116656
ID: 116657  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/116657
ID: 116658  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/116658
ID: 116691  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/116691
ID: 116692  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/116692
ID: 116693  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/116693
ID: 116694  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/116694
ID: 116696  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/116696
ID: 116697   

Review swaps

[Ben Rosser]

Hi,

I have a handful of packages in the review queue that I'd be willing
to exchange reviews for.  I'm happy to exchange for reviews of
similarly sized packages, or several for a more complicated review.

Two miscellaneous packages (C/C++):

qotd - A simple and lightweight Quote of the Day daemon:
https://bugzilla.redhat.com/show_bug.cgi?id=1462472

xoreos-tools - Tools to help the development of xoreos:
https://bugzilla.redhat.com/show_bug.cgi?id=1465588

Three nodejs packages:

nodejs-net-browserify-alt - A port of the net module for the browser:
https://bugzilla.redhat.com/show_bug.cgi?id=1426962

nodejs-simple-markdown - Javascript markdown parsing, made simple:
https://bugzilla.redhat.com/show_bug.cgi?id=1463821

nodejs-irc-colors - Color and formatting for irc made easy:
https://bugzilla.redhat.com/show_bug.cgi?id=1463797

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

Re: Review swaps

[Sandro Mani]

Hi Ben

I'm happy to take the first two in exchange for

https://bugzilla.redhat.com/show_bug.cgi?id=1461368
https://bugzilla.redhat.com/show_bug.cgi?id=1465676

which are simple C/C++ MinGW packages. Deal?

Thanks
Sandro


On 03.07.2017 19:58, Ben Rosser wrote:

Hi,

I have a handful of packages in the review queue that I'd be willing
to exchange reviews for.  I'm happy to exchange for reviews of
similarly sized packages, or several for a more complicated review.

Two miscellaneous packages (C/C++):

qotd - A simple and lightweight Quote of the Day daemon:
https://bugzilla.redhat.com/show_bug.cgi?id=1462472

xoreos-tools - Tools to help the development of xoreos:
https://bugzilla.redhat.com/show_bug.cgi?id=1465588

Three nodejs packages:

nodejs-net-browserify-alt - A port of the net module for the browser:
https://bugzilla.redhat.com/show_bug.cgi?id=1426962

nodejs-simple-markdown - Javascript markdown parsing, made simple:
https://bugzilla.redhat.com/show_bug.cgi?id=1463821

nodejs-irc-colors - Color and formatting for irc made easy:
https://bugzilla.redhat.com/show_bug.cgi?id=1463797

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

Status report on Flatpaks in Fedora Infrastructure

[Owen Taylor]

I've just submitted a change proposal for creating Flatpaks out of Fedora 
package content:
 
  https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks

This is submitted as a F27 change proposal, but it's expected that it will be 
multiple releases before everything in the final shape. My hope for Fedora 27 
is that by the fall packagers will be able to start experimenting with making 
Flatpaks out of their graphical applications and there will be a small set of 
applications for users to install.

There is more extensive documentation about the technical plan at:

  https://fedoraproject.org/wiki/Workstation/Flatpaks

Building Packages
=
Flatpaks require rebuilding applications and bundled dependencies to be located 
with a prefix of /app rather than /usr. We're using the infrastructure created 
for modules to rebuild packages, and it has worked out very smoothly so far. 
There are prototype runtime and application modules at:

 https://src.fedoraproject.org/cgit/modules/eog.git
 https://src.fedoraproject.org/cgit/modules/flatpak-runtime.git

Building Flatpaks out of Packages
=
After building the packages, they need to be combined into a Flatpak runtime or 
application. There is a python script to do this locally in 
https://pagure.io/flaptak-module-tools, but the goal is do this within the same 
build pipeline as is used for containers, and I've started prototyping out 
changes to atomic-reactor.

One element that is needed to built Flatpaks or containers against modules is 
published composes of modules. This will be provided by the "On Demand Compose 
Service". Development on this by the modularity team started recently, but 
seems to be going well.

Distributing Flatpaks
=
The goal is to distribute Flaptaks from registry.fedoraproject.org. This 
requires passing two hurdles:

 * Flatpaks are OCI Images, not docker containers, and we don't have OCI Image 
support in registry.fedoraproject.org (which is an instance of 
https://github.com/docker/distribution/) There is conceptual agreement to add 
this upstream, and a pull request that is blocked on finalizing the OCI Image 
specification.
 * For GNOME Software to provide a nice installation interface from the 
registry rather than an OSTree repository, we need to have a) an index of all 
flatpaks/containers in the registry b) appstream data for the containers in the 
registry. The cockpit team has similar requirements for their container 
installation interface, and we'll collaborate with them in coming up with a 
solution.

This work is still at the research and discussion phase.

Updates
===
There is work currently underway to add support to Bodhi for filing updates for 
containers rather than for packages should carry directly across to Flatpaks. 
This may be sufficient for F27. However, eventually it seems like we need to 
have automation, where updates of packages automatically cause updates of 
containers/flatpaks for those packages. This workflow still needs to be planned 
out in detail.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[modularity] Some questions about module requires

[Owen Taylor]

The prototype flatpak-runtime module that I’ve been working on is built upon 
the (F26) base-runtime and shared-userspace modules, and I’ve hit some 
conceptual questions about the nature of the “modulemd” requires relationship.
 
* Is a module tied to the exact version of the modules it requires that it was 
built against, or can it be used with an updated version of that module within 
the same stream without a rebuild? (For a module like shared-userspace or 
flatpak-runtime that buildrequires bootstrap rather than base-runtime, this is 
a slightly funny question since it wasn’t actually built against base-runtime, 
but ignoring this current oddity.)
 
* What happens if there are packages in a module that you require that are not 
in the api of that module, but also not filtered out. If you need them, should 
you rebuild them in your module? Is this a packaging error in the module?
 
* How do you properly handle the case where a module filters out some 
subpackages of a package. For example, base-runtime builds 
gobject-introspection but filters out gobject-introspection-devel because it 
brings in a lot of python2 dependencies.
 
These questions interact in some interesting ways. Imagine:
1. My module needs gobject-introspection-devel as a build requirement, so 
includes gobject-introspection in its list of packages. If the NVR is newer 
than the NVR in base-runtime, but they are binary compatible, then the 
gobject-introspection I build will cleanly replace the one from base-runtime.
2. shared-runtime is then updated and rebuilt to have a newer version of 
gobject-introspection than my module. With both modules available in a DNF 
environment, then, as far as I know:
 
 dnf-install gobject-introspection-devel will install the version of 
gobject-introspection from my module (since gobject-introspection-devel 
requires the exact NVR of gobject-introspection)
 dnf-install gobject-introspection will install the version of 
gobject-introspection from base-runtime since it is newer.
 
My general takeaway is that there needs to be pretty strict rules about how you 
create a module that is meant to be used as a dependency of other modules - or 
in fact, any module that is meant to be installed in the same filesystem as 
other modules. Can filtering out subpackages to avoid runtime dependencies work 
in this case?
 
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package suggestions

[rugk]

Oh, nice. In this case I'll take everything back…

I just got the impression, because of the prices list on the main website 
(https://askbot.com/plans/) and on askbot.com I did not find a link to the repo…
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package suggestions

[rugk]

Aha, so the discussion is about the "(not so) free" level packs already. Did 
not know that, indeed. If so, everything is all right. And in any case, you can 
still package it without these level packs. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package suggestions

[rugk]

Ah, thanks. Indeed. It's a bit old, but nice… :) Thanks for packaging it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swaps

[Ben Rosser]

On Mon, Jul 3, 2017 at 7:01 PM, Sandro Mani  wrote:
> Hi Ben
>
> I'm happy to take the first two in exchange for
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1461368
> https://bugzilla.redhat.com/show_bug.cgi?id=1465676
>
> which are simple C/C++ MinGW packages. Deal?
>
> Thanks
> Sandro

Taken both of those, thanks!

The three nodejs packages are still available for anyone else
interested in review swaps.

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

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2017-07-04 from 10:00:00 to 11:00:00 US/Eastern
   At https://meet.jit.si/fedora-modularity

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

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

[Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!

[Adam Williamson]

According to the schedule [1], Fedora 26 Candidate RC-1.4 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

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

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_26_RC_1.4_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.4_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.4_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.4_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.4_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.4_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.4_Security_Lab

All Final priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-26/f-26-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_26_RC_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org