Re: Splitting AppStream data into Workstation/Server

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2017-09-05 at 08:37 +0200, Vít Ondruch wrote:
> 
> Dne 5.9.2017 v 08:31 Nicolas Chauvet napsal(a):
> > 2017-09-04 19:20 GMT+02:00 Richard Hughes :
> > > On 4 September 2017 at 17:56, Neal Gompa 
> > > wrote:
> > > > It sounds like it would make more sense for createrepo_c to
> > > > link to
> > > > the AppStream builder library to handle AppStream metadata
> > > > processing
> > > > as part of the createrepo_c repodata generation, wouldn't it?
> > > 
> > > 100% agree. This does take some time currently (as we have to
> > > decompress some files from the lzma archives) but this is
> > > currently
> > > done using my AMD Athlon Neo Microserver with spinning rust
> > > drives.
> > > Using something XEONy and SSDy it'd be orders of magnitude
> > > faster. Are
> > > we sure that we're using createrepo_c for composes? I know we
> > > *used*
> > > to be the old python one for some reason.
> > 
> > As I understand, the problem with the decompression is that it
> > fetches
> > the payload.
> > And if a rpm weight 100MB, it will downloads (RPMs are often stored
> > on
> > nfs, so network is involved) and decompress the whole 100MB
> > (including
> > the header, although this last might be uncompressed).
> > On the opposite, storing information on the RPM header means
> > grabbing
> > only the first KB out of the whole RPM.
> > 
> > As one can see, this might work for few RPMs, but this doesn't
> > scale
> > at all on a big whole repository with many arches, specially if the
> > work from a previous appdata-builder run cannot be cached for a
> > later
> > updates.
> > 
> > So I wonder if it would be possible to have a "second payload" with
> > only the appdata (xml, imgs) that it would be possible to fetch
> > along
> > the header without having to get the rest of the RPM ?
> > On the second tough, with the effort needed to extract this
> > information out of the rpm, is it really worth to store them there
> > in
> > the first step ? Over storing an URL (for xml and/or imgs) in the
> > RPM
> > header ?
> > 
> > Thx for correcting me where I'm wrong.
> > 
> 
> Just another idea reading this ... could we move the AppStream data
> into
> subpackage?
It is possible and probably even possible to add something like
Provides: metainfo-handler() in appstream consumers (e.g. gnome-
software) and automatically generate Recommends: (foo-metainfo if
metainfo-handler()).. But I'm not sure if
* it's worth it
* we can add such things with current RPM (because it involves lookup
of subpackage which IIRC is possible only to do in RPM code itself now)

And as usual, before trying to do something "new" we should really look
how our friends are solving such issues (e.g. openSUSE). Unfortunately
we do a lot of things without doing so and then end up in bad
situations.
> 
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmuWsMACgkQaVcUvRu8
X0w6KxAAiOVFG7f91m+sOPJFkRlmx3Minlv1QJobxymv0bdDVDnAdbrBaTGbvY4b
GL8D6FocqSMDUBwMxS/2gM2gstEVis5Ho0g2rLcde/fbDBhG4XKd2kdCm2egqMOd
g/PFpCxmG9csrI040EaZ7bRYLeeClJPNyC99W3BTN2NOFbTH5/+Y86fu2wLTzuJI
rMw1AiSWQLRzwcDvGoK7c5qOOsHiykLYDUGF68hBB2SvQKWqiIBKuOgxJ5v44X1I
sMDo6QZq1h0kaYl3ezyXZ9Ssu7QrOfYxmQk+XPF29zz2PY0hyblmUIht536W5JLZ
Km3J3N3ksQlP4GVh8WMRUTOiLnT2fYznD4IWhJqPlFcNavwSCebMq+g4VvT8JHPC
A13OhbkbEVvDIO/WupiI+/sNmfjLAL4MzrVZS/lV0BNiwHdQis5+tsrJHLm02O/4
ytf8Jw9NzL99GGpaK9TaqxHs2KIyTNTTE1c2bglWyuf7JHuwNNgcOKlTL20gRiJe
qcxs3KqhO2zniWLpxnA0zJPzavV8E+mBkB4ODqYUlPgCJy10jrVAJcrpqJreCUBG
zrhWncmLxqDfsKCQsbtG4ZmTw/dtvhu+82BTWFCnWxJ/mVcCYyYWQwG403MqMdB7
yV9WgqSDBtoHZsJZvW2UPgm2mfGV+4ATYHICmBnvPYI08cnAvnw=
=Yy6i
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Nonresponsive maintainer: attempting to contact kanarip

[Vít Ondruch]

Dne 22.8.2017 v 11:22 James Hogarth napsal(a):
>
>
> On 27 June 2017 at 12:40, Vít Ondruch  > wrote:
>
>
>
> Dne 27.6.2017 v 10:41 Jeroen van Meeuwen (Kolab Systems) napsal(a):
> > On Fri, 2017-06-23 at 11:39 +0100, James Hogarth wrote:
> >> Hi,
> >>
> >> Has anyone heard from kanarip or able to contact him?
> >>
> > Most people do hear from kanarip at undetermined intervals -- and my
> > @fedoraproject.org  address works just
> fine -- I have no messages from
> > you.
> >
> > I'm also on IRC, where people occasionally contact me, albeit it be
> > about phabricator/arcanist for QA.
> >
> >> For ruby maintainers please note that this has a significant impact
> >> on you, if you want to keep track of this, as he owns puppet,
> >> rubygems and ruby ...
> >>
> > To be honest, ruby and a plethora of related packages are
> maintained by
> > Vit Ondruch and members of the Ruby SIG, much more so then they are
> > maintained by "the owner".
>
> But honestly, I'd be glad if you reconsidered being POC of
> packages you
> don't maintain. It would help to avoid this annual "non-responsive
> kanarip" emails.
>
>
>
>
> Hmm okay it's been a couple of months now and the facter bug that
> lead me to this is still unaddressed...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1223593
>
> It remains at 2.4.3 in all branches whilst the current is 3.8.0
>
> Unless you respond with a specific reason that this is being ignored
> by August 31st I'll be updating this in the first week of September.
>
> I urge you to listen to your colleagues in the Ruby SIG and change the
> POC so that bug reports will go where they are going to be reviewed
> and so that key packages like this get updated.
>
> I'm genuinely surprised the very old facter hasn't hit the puppet or
> similar guys before now.
>
> James
>
>
>

I filled the FESCo ticket here:

https://pagure.io/fesco/issue/1771


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

Re: Better to bundle a library or package different version than upstream?

[James Hogarth]

On 5 September 2017 at 00:27, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Dear all,
>
> About ten days ago I asked a question on this list, but I guess on one
> hand it was too specific, while on the other it coincided with people
> travelling to Flock or being on vacation. As I really want to get the
> package in question back in Fedora, I will ask again and I will try to
> be more abstract and concise. For anyone interested, there is a link
> to the original post at the end of this message.
>
> Package foo, which depends on library bar for importing a certain type
> of files, was retired a couple of releases ago. The library is still
> in Fedora, in two different versions, with different functionality
> (bar2-2.0.0 & bar-oldsnapshot), but no other package depends on it.
>
> Since the retirement, both foo and bar saw active development with
> both projects sharing a few contributors; foo has had a number of
> public releases whereas bar hasn't had any, but there is an unreleased
> newer version (bar-3.0.0) in its VCS.
>
> Up to a specific release, the bar version bundled with foo was
> identical with upstream bar; that is no longer the case, as the
> bundled library is closer to that of the final public release, while
> the upstream version has been tweaked to work with a third program,
> which is also included in Fedora, but does not make use of the bar
> library. The upstream bar version won't work with foo for the moment.
>
> I have spoken with the upstream developers and I was told that both
> branches will merge back before the bar-3.0.0 public release.
>
> So what I am asking is this: Is it OK if I (re)introduce two packages,
> foo and bar3, obsoleting bar and bar2 at the same time, but using
> foo's source for bar or should I opt to keep bar bundled with foo,
> until the two different forks are reunited?
>
> Best regards
> Alex
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/thread/EMVB3JGM5AZVVO7NA3E7DHJLB32CMJJW/
>
>
>
Given the history there and the intended roadmap from upstream for both
projects I'd use foo as the source for bar3 until such time bar gets a 3
release
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Splitting AppStream data into Workstation/Server

[Richard Hughes]

On 5 September 2017 at 07:37, Vít Ondruch  wrote:
> Just another idea reading this ... could we move the AppStream data into
> subpackage?

First, that would be another ~2000 subpackages clogging up the mirrors
and metadata -- second it's really only a rel-eng artifact. Either we
pass the artifact around from koji to the metadata composer, or we
just extract the payload in the generator. The advantage of the latter
is that it works when you're not building rpms using koji, e.g. at
home, in copr, or in a corporate environment. Also note, there are
very few 100Mb packages, the vast majority are a few hundred kb in
size.

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

mandb takes forever to run during package updates

[Richard W.M. Jones]

I've noticed for a while that updates get "stuck" in the scriptlets
phase.  For example I've got an update running now which has taken
3+ minutes of wallclock time (on a 16 core Xeon) in the scriptlets.
Looking in ‘top’ I can see:

  29490 root  20   0  156620  28352   2684 S  25.7  0.0   1:41.52 mandb

I suspect this runs from the following trigger in the man-db package:

  # update cache
  %transfiletriggerpostun -- %{_mandir}
  MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q

It creates or updates a set of databases under /var/cache/man.

The databases are not used by the regular ‘man’ command.  They are
only used by ‘apropos’ and ‘whatis’ which are (I suppose) quite rarely
used commands for searching all man pages.

You can prove this by moving /var/cache/man out of the way, and you'll
notice that ‘man’ continues to work just fine.  However ‘whatis’
always prints ‘nothing appropriate’ if no database is available.

There is a man-db-cron package, although it's not installed by
default.  Perhaps we could install the cron job by default and drop
the trigger?

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

Re: mandb takes forever to run during package updates

[Yanko Kaneti]

On Tue, 2017-09-05 at 11:25 +0100, Richard W.M. Jones wrote:
> I've noticed for a while that updates get "stuck" in the scriptlets
> phase.  For example I've got an update running now which has taken
> 3+ minutes of wallclock time (on a 16 core Xeon) in the scriptlets.
> Looking in ‘top’ I can see:
> 
>   29490 root  20   0  156620  28352   2684 S  25.7  0.0   1:41.52 mandb
> 
> I suspect this runs from the following trigger in the man-db package:
> 
>   # update cache
>   %transfiletriggerpostun -- %{_mandir}
>   MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q
> 
> It creates or updates a set of databases under /var/cache/man.
> 
> The databases are not used by the regular ‘man’ command.  They are
> only used by ‘apropos’ and ‘whatis’ which are (I suppose) quite rarely
> used commands for searching all man pages.
> 
> You can prove this by moving /var/cache/man out of the way, and you'll
> notice that ‘man’ continues to work just fine.  However ‘whatis’
> always prints ‘nothing appropriate’ if no database is available.
> 
> There is a man-db-cron package, although it's not installed by
> default.  Perhaps we could install the cron job by default and drop
> the trigger?

It has been a thorn in the backside for a while:
https://bugzilla.redhat.com/show_bug.cgi?id=1318058

It does seem to make wholesale database rebuilds instead of partial
updates way too often.

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

Re: F26 and kernel-4.13

[Sérgio Basto]

https://copr.fedorainfracloud.org/coprs/jforbes/kernel-stabilization/builds/

Sometimes appears here before go to updates-testing 


On Mon, 2017-09-04 at 11:39 +0200, Joachim Backes wrote:
> Hi guys,
> 
> my question: is it planned to make and release kernel-4.13 for F26?
> I 
> saw that it has been declared as mainline and stable on kernel.org.
> 
> Kind regards
> 
> Joachim Backes
> 
> -- 
> 
> Fedora release 26 (Twenty Six)
> Kernel-4.12.9-300.fc26.x86_64
> 
> 
> Joachim Backes 
> https://www-user.rhrk.uni-kl.de/~backes/
> ___
> 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: Providing ABI/API assurances for the base runtime in Fedora.

[Carlos O'Donell]

On 09/01/2017 10:00 AM, Igor Gnatenko wrote:
> On Fri, 2017-09-01 at 09:28 -0500, Carlos O'Donell wrote:
>> Fedora Developers,
> 
>> I am working on a way to provide concrete ABI/API assurances for
>> parts of the base runtime.
> Note that Base Runtime is F26-only thing and in F27 it is called Host
> and Platform[0]..

Thanks! I've updated the proposal based on the new split of host, platform,
and bootstrap.

>> I've written up some of the key ideas here:
>> https://fedoraproject.org/wiki/BaseRuntimeInterface
> 
>> Any feedback would be appreciated, including bikeshed on component
>> name prefix for frozen interface pakcages e.g. base-*.

> Why do we need separate components? Can't we adjust main packages to
> install into separate paths? In theory, it should be just setting
> differeng %_prefix variable for RPM.

I have added a "Questions" section to address this.

There are two reasons to split the packages completely:

* Reduce validation cost for each build e.g. build and validate the interface
  fewer times.

* Reduce storage costs e.g. build the interface only once for each important
  transition point including package rebase.
 
> Another thing to mention is that libabigail currently (as far as I
> know) doesn't handle python code/python extensions (read DNF). Also I
> guess it doesn't handle GObject Introspected code.

Correct, Python and any code that does dynamic introspection (which causes
cross-compilation problems) are currently out of scope for such separation.

libabigail can only look at the binary artifacts (DSOs) which would be generated
from a Python build and characterize those.

In the case of GObject code, I already knew that we could not support such
separation with that kind of code. Effectively what I am suggesting is a small
amount of cross-compilation compatibility with the low-level runtimes in order
that we can upgrade them if required in the Platform module.

Does that answer your questions?

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

Re: Providing ABI/API assurances for the base runtime in Fedora.

[Carlos O'Donell]

On 09/04/2017 07:31 AM, Petr Pisar wrote:
> On 2017-09-01, Carlos O'Donell  wrote:
>> I've written up some of the key ideas here:
>> https://fedoraproject.org/wiki/BaseRuntimeInterface
>>
>> Any feedback would be appreciated, including bikeshed on component
>> name prefix for frozen interface pakcages e.g. base-*.

Thank you for your feedback!

> What if there is a bug in the behavior of the frozen base-* packages? Do
> we have to live with the bug for the rest of the life time of the base
> (=platform)? Or do we break this rule and replace the broken package
> with a patched one?

We get this question a lot in glibc.

There is a natural tension to want to break the API/ABI in a stable release
to fix a bug that is known.

In general we live by an "exceptions based policy" which is to say that we
follow the stable API/ABI rules very strictly, but the community can be
convinced to grant an exception.

I think if the platform module releases with a base-glibc package (defines
the interface to build against) that has a bug, say it has the wrong ABI
for a given function, then you need to look at the specifics of the failure
to decide if base-glibc should be fixed and rebuilt.

I added a Q&A question about this. Please tell me if that answers your
question.

> If the second one is the answer, do we know how it will affect packages
> whose build script does run-time checks (i.e. every ./configure script)
> to tune compile-time options?

It depends on how each package implements the split of interface/implementation.

> More strictly speaking, will we be adding new features into the same stream of
> the base module? I guess we won't. Otherwise we have to update the
> frozen base-* packages accordingly to make the new features available at
> build-time of packages that want to use the new features.

The interface base-* or platform-* (whatever we call them) packages would remain
frozen for the lifetime of say the platform modules specific major version.
However, we could rebase the implementation package without specifically 
impacting
the existing components.

In the case of glibc, because we alter the linker path, package configure checks
will only ever see the interface glibc provided by the platform-glibc package.
At present the platform-glibc is a full glibc which can run in the system.

If we were to trim platform-glibc into just some stripped DSOs then we might run
into configure check problems. We would have to make all such configure checks
be cross-compile safe, which is not something I'm going to target at this stage,
but it would be an interesting project to consider.

Does that answer your question?

I added another Q&A item for this.

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

GNOME 3.25.92 megaupdate

[Kalev Lember]

Hi all,

It's GNOME 3.25.92 release this week, which is going to be quickly
followed by final 3.26.0 next week.

To help prepare the updates, we have a f27-gnome side tag / build target
for Fedora 27 as usual. If you are helping with the builds, please use
'fedpkg build --target f27-gnome' for F27, and I'll make sure to collect
everything tagged with f27-gnome and submit them as a single megaupdate
to Bodhi.

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

Fedora 27 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Jan Kurik]

Today, on 2017-Sep-05, we reach two important milestones of the Fedora
27 release [1]:

== Change Checkpoint: 100% Code Complete Deadline [2] ==
* New accepted changes must be code complete, meaning all the code
required to enable a new Change is finished.
* The level of code completeness is reflected in tracker bug as state
"ON_QA". The change does not have to be fully tested by this deadline.

== Beta Freeze [3] ==
Only packages fixing a bug approved as Accepted Blocker or Freeze
Exception [4] will be marked as 'stable' and included in Beta
composes. Other builds will remain in updates-testing until the Beta
release is approved, at which point the Beta Freeze is lifted and
packages can move to 'stable' as usual until the Final Freeze.

[1] https://fedoraproject.org/wiki/Releases/27/Schedule
[2] https://fedoraproject.org/wiki/Changes/Policy
[3] https://fedoraproject.org/wiki/Milestone_freezes
[4] https://qa.fedoraproject.org/blockerbugs/milestone/27/beta/buglist

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: MinGW MiniDebugInfo

[Jan Kurik]

= Proposed Self Contained Change: MinGW MiniDebugInfo =
https://fedoraproject.org/wiki/Changes/MingwMiniDebugInfo

Change owner(s):
* Sandro Mani 

Analogously to the MiniDebugInfo change [1] for native packages,
install minimal debuginfos by default also for MinGW packages.

== Detailed Description ==
Currently the debuginfo data of MinGW binaries is completely stripped
from the binary and placed in the respective .debuginfo file. This
change proposes keeping the PE symbols in the binary, similarly to
what was done for native binaries [1].

The change basically involves changing mingw-find-debuginfo.sh as follows:

diff --git a/mingw-filesystem/mingw-find-debuginfo.sh
b/mingw-filesystem/mingw-find-debuginfo.sh
index de6dee1..261385f 100755
--- a/mingw-filesystem/mingw-find-debuginfo.sh
+++ b/mingw-filesystem/mingw-find-debuginfo.sh
@@ -25,7 +25,10 @@ do
echo extracting debug info from $f
mingw-objcopy --only-keep-debug $f $f.debug || :
pushd `dirname $f`
-   mingw-objcopy --add-gnu-debuglink=`basename $f.debug`
--strip-unneeded `basename $f` || :
+   keep_symbols=`mktemp`
+  mingw-nm $f.debug --format=sysv --defined-only | awk -F \| '{ if
($4 ~ "Function") print $1 }' | sort > "$keep_symbols"
+   mingw-objcopy --add-gnu-debuglink=`basename $f.debug`
--strip-unneeded `basename $f` --keep-symbols="$keep_symbols" || :
+   rm -f "$keep_symbols"
popd
 done

A test with some packages in this COPR repo [2] shows that the price
is a size increase of in average 17%:


== Scope ==
* Proposal owners:
- Change mingw-binutils toalso install a generic mingw-nm, which will
be used by mingw-find-debuginfo.sh
- Change mingw-find-debuginfo.sh as outlined above
- Rebuild all mingw packages

* Other developers: N/A (not a System Wide Change)

* Release engineering: #7005 https://pagure.io/releng/issue/7005

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

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


[1] https://fedoraproject.org/wiki/Features/MiniDebugInfo
[2] https://copr.fedorainfracloud.org/coprs/smani/mingw-debuginfo-test/builds/
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Petr Stodulka]

On 4.9.2017 19:27, Michal Novotny wrote:
> I might contact you for more information, but alright, if you feel the custom 
> script is more convenient,
> then I am all for it. But first, I would like to make a proposal of each 
> option (with screenshots and
> just complete feature request description) so that users can clearly see  the 
> options and pick what
> they like the best. We can work with Pavel on it.
> 
> If you agree, I would post the two proposals here before actual 
> implementation. 
>  

Yes, it would be fine see concrete proposals to discuss it before 
implementation. Thanks.

P.



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

Modularity Working Group IRC Meeting Minutes (2017-09-05)

[Nils Philippsen]

=
#fedora-meeting-3: Meeting of the Modularity Working Group (once every two 
weeks)
=


Meeting started by nils at 14:01:09 UTC.

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2017-09-05/modularity_wg.2017-09-05-14.01.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-3/2017-09-05/modularity_wg.2017-09-05-14.01.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2017-09-05/modularity_wg.2017-09-05-14.01.log.html


Meeting summary
---
* Roll Call  (nils, 14:01:19)

* Agenda  (nils, 14:03:12)

* Open Floor  (nils, 14:06:34)
  * ACTION: langdon to create an etherpad for contribution to report
(langdon, 14:16:35)
  * ACTION: langdon to follow up with mary and martin for feedback
report  (langdon, 14:17:50)
  * ACTION: langdon send report to devel@  (langdon, 14:17:57)
  * LINK: https://board.net/p/modularity-flock-report modularity flock
report  (langdon, 14:18:24)

Meeting ended at 14:24:44 UTC.




Action Items

* langdon to create an etherpad for contribution to report
* langdon to follow up with mary and martin for feedback report
* langdon send report to devel@




Action Items, by person
---
* langdon
  * langdon to create an etherpad for contribution to report
  * langdon to follow up with mary and martin for feedback report
  * langdon send report to devel@
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* langdon (30)
* nils (22)
* contyk (14)
* zodbot (12)
* karsten_ (3)
* mikedep333 (2)
* tflink (1)
* dgilmore (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Kernel 4.13 rebase plans

[Laura Abbott]

Hi,

Kernel 4.13 was released this past weekend. This kernel has been
built for rawhide and is building for F27 as well. We will be
following the same upgrade procedure as in the past. F25 and F26
will get rebased to 4.13 after a few stable releases, typically
4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.

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

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 5 Sep 2017 5:42 pm, "Laura Abbott"  wrote:

Hi,

Kernel 4.13 was released this past weekend. This kernel has been
built for rawhide and is building for F27 as well. We will be
following the same upgrade procedure as in the past. F25 and F26
will get rebased to 4.13 after a few stable releases, typically
4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.


Thanks for the heads up Laura

Will there be a stabilization COPR for us to test the builds against/on F26?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Laura Abbott]

On 09/05/2017 09:59 AM, James Hogarth wrote:
> 
> 
> On 5 Sep 2017 5:42 pm, "Laura Abbott"  > wrote:
> 
> Hi,
> 
> Kernel 4.13 was released this past weekend. This kernel has been
> built for rawhide and is building for F27 as well. We will be
> following the same upgrade procedure as in the past. F25 and F26
> will get rebased to 4.13 after a few stable releases, typically
> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> does not give release dates for stable release but given past
> timings, this will probably happen towards the end of September.
> As always, if you have any questions please let me know.
> 
> 
> Thanks for the heads up Laura
> 
> Will there be a stabilization COPR for us to test the builds against/on F26?
> 

Yes, I can throw that in the stabilization copr once I start working on
the rebase. I might have a very early 4.13.0 to test by the end of
the week but no promises.

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

Re: Kernel 4.13 rebase plans

[Thorsten Leemhuis]

On 05.09.2017 18:59, James Hogarth wrote:
> On 5 Sep 2017 5:42 pm, "Laura Abbott"  > wrote:
>
> Kernel 4.13 was released this past weekend. This kernel has been
> built for rawhide and is building for F27 as well. We will be
> following the same upgrade procedure as in the past. F25 and F26
> will get rebased to 4.13 after a few stable releases, typically
> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> does not give release dates for stable release but given past
> timings, this will probably happen towards the end of September.
> As always, if you have any questions please let me know.
> Thanks for the heads up Laura
> Will there be a stabilization COPR for us to test the builds against/on F26?

Shameless plug: If you want to get Linux 4.13 now you can also run this:

curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo |
sudo tee /etc/yum.repos.d/kernel-vanilla.repo
sudo dnf --enablerepo=kernel-vanilla-stable update

This will install a vanilla kernel from the kernel vanilla stable repo,
where is landed yesterday. For more details and other kernel vanilla
repos (mainline, mainline-wo-mergew & fedora) please see
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories &
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories-FAQ

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

Re: GNOME 3.25.92 megaupdate

[Tomasz Kłoczko]

On 5 September 2017 at 15:02, Kalev Lember  wrote:
> Hi all,
>
> It's GNOME 3.25.92 release this week, which is going to be quicklynecessary 
> chaith all
> followed by final 3.26.0 next week.

It would be good to start remove on this cycle execution of all
glib-compile-schemas, gtk-update-icon-cache and
update-desktop-database  from all %post/%postun as all necessary
changes are done over rpm triggers.
All this stuff only makes upgrades longer by executing at least two
times per package.

Here are numbers showing scale of those issue:

[tkloczko@domek SPECS.fedora]$ for i in glib-compile-schemas
gtk-update-icon-cache update-desktop-database; do echo -n $i " "; grep
-l $i *spec |wc -l; done
glib-compile-schemas  205
gtk-update-icon-cache  1393
update-desktop-database  528

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 5 September 2017 at 18:26, Laura Abbott  wrote:

> On 09/05/2017 09:59 AM, James Hogarth wrote:
> >
> >
> > On 5 Sep 2017 5:42 pm, "Laura Abbott"  labb...@redhat.com>> wrote:
> >
> > Hi,
> >
> > Kernel 4.13 was released this past weekend. This kernel has been
> > built for rawhide and is building for F27 as well. We will be
> > following the same upgrade procedure as in the past. F25 and F26
> > will get rebased to 4.13 after a few stable releases, typically
> > 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> > does not give release dates for stable release but given past
> > timings, this will probably happen towards the end of September.
> > As always, if you have any questions please let me know.
> >
> >
> > Thanks for the heads up Laura
> >
> > Will there be a stabilization COPR for us to test the builds against/on
> F26?
> >
>
> Yes, I can throw that in the stabilization copr once I start working on
> the rebase. I might have a very early 4.13.0 to test by the end of
> the week but no promises.
>
>
>
>
That's great thanks ... I'd be happy to test the builds and provide early
feedback on my laptop ... but as I can't risk it going boom I'm not able to
update it to F27 until further through the release schedule.

Having an F26 build of the upcoming kernel makes early testing simple
though :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Better to bundle a library or package different version than upstream?

[Alexander Ploumistos]

Thank you James, this did feel like the proper course of action.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Chris Murphy]

On Tue, Sep 5, 2017 at 3:13 PM, James Hogarth  wrote:
>
>
> On 5 September 2017 at 18:26, Laura Abbott  wrote:
>>
>> On 09/05/2017 09:59 AM, James Hogarth wrote:
>> >
>> >
>> > On 5 Sep 2017 5:42 pm, "Laura Abbott" > > > wrote:
>> >
>> > Hi,
>> >
>> > Kernel 4.13 was released this past weekend. This kernel has been
>> > built for rawhide and is building for F27 as well. We will be
>> > following the same upgrade procedure as in the past. F25 and F26
>> > will get rebased to 4.13 after a few stable releases, typically
>> > 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
>> > does not give release dates for stable release but given past
>> > timings, this will probably happen towards the end of September.
>> > As always, if you have any questions please let me know.
>> >
>> >
>> > Thanks for the heads up Laura
>> >
>> > Will there be a stabilization COPR for us to test the builds against/on
>> > F26?
>> >
>>
>> Yes, I can throw that in the stabilization copr once I start working on
>> the rebase. I might have a very early 4.13.0 to test by the end of
>> the week but no promises.
>>
>>
>>
>
> That's great thanks ... I'd be happy to test the builds and provide early
> feedback on my laptop ... but as I can't risk it going boom I'm not able to
> update it to F27 until further through the release schedule.
>
> Having an F26 build of the upcoming kernel makes early testing simple though
> :)

FWIW, you can just download the F27 kernel, kernel-core,
kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
that same download directory and it will install it without complaint.
I routinely run Fedora built n+1 (typically rawhide) kernels on
current release OS.


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

Re: Kernel 4.13 rebase plans

[Chris Murphy]

On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy  wrote:

> FWIW, you can just download the F27 kernel, kernel-core,
> kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
> that same download directory and it will install it without complaint.
> I routinely run Fedora built n+1 (typically rawhide) kernels on
> current release OS.

Small gotcha is that you can't upgrade perf, dnf will complain. But
usually rudimentary use of current perf will work with a newer kernel.


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

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 5 September 2017 at 22:40, Chris Murphy  wrote:

> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
> wrote:
>
> > FWIW, you can just download the F27 kernel, kernel-core,
> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
> > that same download directory and it will install it without complaint.
> > I routinely run Fedora built n+1 (typically rawhide) kernels on
> > current release OS.
>
> Small gotcha is that you can't upgrade perf, dnf will complain. But
> usually rudimentary use of current perf will work with a newer kernel.
>
>
>
>
Right ... with kernel-tools and perf I'd rather have something built
against the F26 userspace ... but I have run the rawhidenodebug kernels in
the past for testing ... it's just nicer and more representative for
testing what will end up in the F26 repos to have the kernel built against
F26 in the stabilization COPR
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Better to bundle a library or package different version than upstream?

[James Hogarth]

On 5 September 2017 at 22:17, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Thank you James, this did feel like the proper course of action.
> ___
>
>
No worries ... special cases do come up and it's important to be responsive
to upstream intentions.

I do suggest popping a comment in the spec at the appropriate point
explaining why for anyone that runs into it and is confused
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth  wrote:
>
>
> On 5 September 2017 at 22:40, Chris Murphy  wrote:
>>
>> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
>> wrote:
>>
>> > FWIW, you can just download the F27 kernel, kernel-core,
>> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
>> > that same download directory and it will install it without complaint.
>> > I routinely run Fedora built n+1 (typically rawhide) kernels on
>> > current release OS.
>>
>> Small gotcha is that you can't upgrade perf, dnf will complain. But
>> usually rudimentary use of current perf will work with a newer kernel.
>>
>>
>>
>
> Right ... with kernel-tools and perf I'd rather have something built against
> the F26 userspace ... but I have run the rawhidenodebug kernels in the past
> for testing ... it's just nicer and more representative for testing what
> will end up in the F26 repos to have the kernel built against F26 in the
> stabilization COPR

I've suggested in the past that we ship the userspace tools in a
completely separate package, leaving ONLY kernel bits in the kernel
SRPM and subpackages.  Partly for this reason, and also because there
is no NEED to build e.g. perf daily.  I'm willing to put my money
where my mouth is and do the maintenance on the userspace side if
people want to pursue this.

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

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth  wrote:
>
>
> On 5 September 2017 at 22:40, Chris Murphy  wrote:
>>
>> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
>> wrote:
>>
>> > FWIW, you can just download the F27 kernel, kernel-core,
>> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
>> > that same download directory and it will install it without complaint.
>> > I routinely run Fedora built n+1 (typically rawhide) kernels on
>> > current release OS.
>>
>> Small gotcha is that you can't upgrade perf, dnf will complain. But
>> usually rudimentary use of current perf will work with a newer kernel.
>>
>>
>>
>
> Right ... with kernel-tools and perf I'd rather have something built against
> the F26 userspace ... but I have run the rawhidenodebug kernels in the past
> for testing ... it's just nicer and more representative for testing what
> will end up in the F26 repos to have the kernel built against F26 in the
> stabilization COPR

I've suggested in the past that we ship the userspace tools in a
completely separate package, leaving ONLY kernel bits in the kernel
SRPM and subpackages.  Partly for this reason, and also because there
is no NEED to build e.g. perf daily.  I'm willing to put my money
where my mouth is and do the maintenance on the userspace side if
people want to pursue this.

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

Re: Better to bundle a library or package different version than upstream?

[Alexander Ploumistos]

On Wed, Sep 6, 2017 at 1:27 AM, James Hogarth  wrote:
> I do suggest popping a comment in the spec at the appropriate point
> explaining why for anyone that runs into it and is confused

I have a comment in the spec file in copr, perhaps I should also add a
link to the discussion upstream.

By the way, is it possible to somehow submit scratch builds of
dependent packages in koji? Will the copr builds be enough for the
review process? As far as I can tell copr is still missing the f27
mock configs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Better to bundle a library or package different version than upstream?

[James Hogarth]

On 5 September 2017 at 23:43, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> On Wed, Sep 6, 2017 at 1:27 AM, James Hogarth 
> wrote:
> > I do suggest popping a comment in the spec at the appropriate point
> > explaining why for anyone that runs into it and is confused
>
> I have a comment in the spec file in copr, perhaps I should also add a
> link to the discussion upstream.
>
> By the way, is it possible to somehow submit scratch builds of
> dependent packages in koji? Will the copr builds be enough for the
> review process? As far as I can tell copr is still missing the f27
> mock configs.
>


No as you can't modify the buildroot with a scratch package since it's not
tagged

Don't worry about that though ... any reviewer doing the review can use the
srpm directly with fedora-review instead of doing -b  and with that
the reviewer can pass a directory of dependency packages to allow the test
builds to work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GNOME 3.25.92 megaupdate

[Rex Dieter]

Tomasz Kłoczko wrote:

> On 5 September 2017 at 15:02, Kalev Lember  wrote:
>> Hi all,
>>
>> It's GNOME 3.25.92 release this week, which is going to be
>> quicklynecessary chaith all followed by final 3.26.0 next week.
> 
> It would be good to start remove on this cycle execution of all
> glib-compile-schemas, gtk-update-icon-cache and
> update-desktop-database  from all %post/%postun as all necessary
> changes are done over rpm triggers.
> All this stuff only makes upgrades longer by executing at least two
> times per package.

FYI, at least in the case of gtk-update-icon-cache, those scriptlets should 
run only once *per transaction*, not per package.

(the others I don't believe have been optimized similarly)

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

Re: Urgent attention required; ImageMagick update breakage

[Moez Roy]

On Mon, Sep 4, 2017 at 4:11 PM, Adam Williamson 
wrote:

> On Mon, 2017-09-04 at 20:07 +0100, Sérgio Basto wrote:
> >
> > That is the point, how many package fail to build with ImageMagick7 ?
> > we "just" need change requires on FTBFS packages (with ImageMagick7)
>
> No it isn't the point. More things actually use the ImageMagick *CLI*
> than use the library, and the CLI of ImageMagick 7 is very different
> from the CLI of ImageMagick 6. This is the *main* reason we do not just
> want to make the ImageMagick package suddenly become ImageMagick 7 -
> because IM 7 does not provide the CLI people currently expect from the
> package called 'ImageMagick'. It's not primarily about things which
> build against the libraries.
> --
>
>
​You are wrong about this. I tested convert and identify in my v7 builds,
and they work fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Tue, 2017-09-05 at 21:30 -0700, Moez Roy wrote:
> On Mon, Sep 4, 2017 at 4:11 PM, Adam Williamson 
> wrote:
> 
> > On Mon, 2017-09-04 at 20:07 +0100, Sérgio Basto wrote:
> > > 
> > > That is the point, how many package fail to build with ImageMagick7 ?
> > > we "just" need change requires on FTBFS packages (with ImageMagick7)
> > 
> > No it isn't the point. More things actually use the ImageMagick *CLI*
> > than use the library, and the CLI of ImageMagick 7 is very different
> > from the CLI of ImageMagick 6. This is the *main* reason we do not just
> > want to make the ImageMagick package suddenly become ImageMagick 7 -
> > because IM 7 does not provide the CLI people currently expect from the
> > package called 'ImageMagick'. It's not primarily about things which
> > build against the libraries.
> > --
> > 
> > 
> 
> You are wrong about this. I tested convert and identify in my v7 builds,
> and they work fine.

Uh...read this:

https://www.imagemagick.org/script/porting.php#cli

There's two-three pages (depending on your browser settings) of changes
to how the CLI works, many of them backwards-incompatible.

Just because there's still a command called 'convert' doesn't mean
everything is the same.
-- 
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

Schedule for Wednesday's FPC Meeting (2017-09-06 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Wednesday at 2017-09-06 17:00 UTC in #fedora-meeting-2 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Wednesday =
2017-09-06 10:00 PDT  US/Pacific
2017-09-06 13:00 EDT  --> US/Eastern <--
2017-09-06 17:00 UTC  UTC   
2017-09-06 18:00 BST  Europe/London 
2017-09-06 19:00 CEST Europe/Berlin 
2017-09-06 19:00 CEST Europe/Paris  
2017-09-06 22:30 IST  Asia/Calcutta 
--- New Day: Thursday 
2017-09-07 01:00 HKT  Asia/Hong_Kong
2017-09-07 01:00 +08  Asia/Singapore
2017-09-07 02:00 JST  Asia/Tokyo
2017-09-07 03:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followups =

#topic #654 glibc file triggers
.fpc 654
https://pagure.io/packaging-committee/issue/654

#topic #691 noarch *sub*packages with arch-specific dependencies
.fpc 691
https://pagure.io/packaging-committee/issue/691

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://pagure.io/packaging-committee,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org