[Test-Announce] Fedora 27 Beta Freeze

[Mohan Boddu]

Hi all,

Today is an important day on the Fedora 27 schedule[1], with two
 significant cut-offs.

Today is the Beta freeze[2]. This means that only packages which fix
accepted blocker or freeze exception bugs[3][4] will be marked as 'stable'
and included in the 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.

Today is also '100% code complete deadline' Change Checkpoint[5], meaning
that Fedora 27 Changes must now be code complete, meaning all the code
required to enable to the new change is finished. The level of code
completeness is reflected as tracker bug state ON_QA. The change does not
have to be fully tested by this deadline'.

Finally, Fedora is not doing Alpha releases[6] anymore by keeping Rawhide
at alpha quality.

Regards

Mohan Boddu

[1] https://fedoraproject.org/wiki/Releases/27/Schedule
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5] https://fedoraproject.org/wiki/Changes/Policy
[6] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
___
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

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

[Petr Pisar]

On Tue, Sep 05, 2017 at 08:57:24AM -0500, Carlos O'Donell wrote:
> On 09/04/2017 07:31 AM, Petr Pisar wrote:
> > 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.
>
Fine.

> > 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?
> 
In other words no new features because the interface packages will remain the GA
packages (minus bug fixes on exception policy).

Does it mean that when a need for a new feature arises, e.g. adding
getrandom(3) into glibc 
we will produce a new platform stream distinct from the GA stream?

-- Petr


signature.asc
Description: PGP signature
___
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 6 September 2017 at 03:16, Rex Dieter  wrote:
[..]
>> 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.

This is exactly what I wrote.
Running those binaries per package is no longer needed as already
implemented triggers are doing all what is needs to be done.

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: GNOME 3.25.92 megaupdate

[Björn 'besser82' Esser]

Am 06.09.2017 um 09:51 schrieb Tomasz Kłoczko:

On 6 September 2017 at 03:16, Rex Dieter  wrote:
[..]

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.

This is exactly what I wrote.
Running those binaries per package is no longer needed as already
implemented triggers are doing all what is needs to be done.


That is NOT true for gtk-update-icon-cache.  There is currently no 
trigger for it, at least when I look at the recent information on the 
wiki [1].


Setting automatic triggers for this might be tricky, since we simply 
have more icon sets as just hicolor; there are plenty of others among 
just that one.  For that reason the automatic triggers would need to 
iterate over all direct subdirs in %{_datadir}/icons and run the update 
for all of them, like:


```
for _dir in $(find /usr/share/icons -mindepth 1 -maxdepth 1 -type d) ; do
  /bin/touch --no-create $_dir &>/dev/null || :
  /usr/bin/gtk-update-icon-cache $_dir &>/dev/null || :
done
```

to make sure all possibly changed icon sets are covered.

For that reason, I think, there are still no automatic triggers for the 
icon cache.



[1]  https://fedoraproject.org/wiki/Packaging:Scriptlets#Icon_Cache
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GNOME 3.25.92 megaupdate

[Neal Gompa]

On Wed, Sep 6, 2017 at 4:24 AM, Björn 'besser82' Esser
 wrote:
> Am 06.09.2017 um 09:51 schrieb Tomasz Kłoczko:
>>
>> On 6 September 2017 at 03:16, Rex Dieter  wrote:
>> [..]

 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.
>>
>> This is exactly what I wrote.
>> Running those binaries per package is no longer needed as already
>> implemented triggers are doing all what is needs to be done.
>
>
> That is NOT true for gtk-update-icon-cache.  There is currently no trigger
> for it, at least when I look at the recent information on the wiki [1].
>
> Setting automatic triggers for this might be tricky, since we simply have
> more icon sets as just hicolor; there are plenty of others among just that
> one.  For that reason the automatic triggers would need to iterate over all
> direct subdirs in %{_datadir}/icons and run the update for all of them,
> like:
>
> ```
> for _dir in $(find /usr/share/icons -mindepth 1 -maxdepth 1 -type d) ; do
>   /bin/touch --no-create $_dir &>/dev/null || :
>   /usr/bin/gtk-update-icon-cache $_dir &>/dev/null || :
> done
> ```
>
> to make sure all possibly changed icon sets are covered.
>
> For that reason, I think, there are still no automatic triggers for the icon
> cache.
>
>
> [1]  https://fedoraproject.org/wiki/Packaging:Scriptlets#Icon_Cache
>

I think we implemented file triggers in Mageia for this, I'll need to
do some checking. I know that we're pretty aggressive on package,
transaction, and file trigger usage compared to Fedora... Heck, we
don't even need ldconfig runs in Mageia, since they're run
automatically through file triggers.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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.

[Petr Pisar]

On 2017-09-06, Petr Pisar  wrote:
> Does it mean that when a need for a new feature arises, e.g. adding
> getrandom(3) into glibc
>  we will produce
> a new platform stream distinct from the GA stream?
>
I will answer to myself: Yes, we will because modules should be fully
compatible inside one stream to allow users to downgrade to a previous
stream release (e.g. in case of a regression).

This is not something we support in classical Fedora (because we do not
retain previous releases in repositories. Will we support it in modular
Fedora?).

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

Re: [Test-Announce] Fedora 27 Beta Freeze

[Vít Ondruch]

Dne 5.9.2017 v 16:28 Mohan Boddu napsal(a):
> Hi all,  
> Today is an important day on the Fedora 27 schedule[1], with two
>  significant cut-offs.  
> Today is the Beta freeze[2]. This means that only packages which fix
> accepted blocker or freeze exception bugs[3][4] will be marked as
> 'stable' and included in the 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.

May be it would be good to point out that Bodhi was enabled for F27? I
just checking my yesterday build (done prior this announcement) and it
is in f27-updates-candidate indeed ...


Vít

> Today is also '100% code complete deadline' Change Checkpoint[5],
> meaning that Fedora 27 Changes must now be code complete, meaning all
> the code required to enable to the new change is finished. The level
> of code completeness is reflected as tracker bug state ON_QA. The
> change does not have to be fully tested by this deadline'. 
> Finally, Fedora is not doing Alpha releases[6] anymore by keeping Rawhide
> at alpha quality.
> Regards  
> Mohan Boddu 
>
> [1] https://fedoraproject.org/wiki/Releases/27/Schedule
> [2] https://fedoraproject.org/wiki/Milestone_freezes 
> [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process 
> [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process 
> [5] https://fedoraproject.org/wiki/Changes/Policy
> [6] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
>
>
> ___
> 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

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

Re: [Test-Announce] Fedora 27 Beta Freeze

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2017-09-06 at 12:17 +0200, Vít Ondruch wrote:
> 
> Dne 5.9.2017 v 16:28 Mohan Boddu napsal(a):
> > Hi all,  
> > Today is an important day on the Fedora 27 schedule[1], with two
> >  significant cut-offs.  
> > Today is the Beta freeze[2]. This means that only packages which
> > fix
> > accepted blocker or freeze exception bugs[3][4] will be marked as
> > 'stable' and included in the 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.
> 
> May be it would be good to point out that Bodhi was enabled for F27?
> I
> just checking my yesterday build (done prior this announcement) and
> it
> is in f27-updates-candidate indeed ...
It actually was!

See "Fedora 27 Bodhi Activation Point" mail which was sent on "Tue, 29
Aug 2017 11:05:17 -0400 (08/29/2017 05:05:17 PM)" 😉
> 
> 
> Vít
> 
> > Today is also '100% code complete deadline' Change Checkpoint[5],
> > meaning that Fedora 27 Changes must now be code complete, meaning
> > all
> > the code required to enable to the new change is finished. The
> > level
> > of code completeness is reflected as tracker bug state ON_QA. The
> > change does not have to be fully tested by this deadline'. 
> > Finally, Fedora is not doing Alpha releases[6] anymore by keeping
> > Rawhide
> > at alpha quality.
> > Regards  
> > Mohan Boddu 
> > 
> > [1] https://fedoraproject.org/wiki/Releases/27/Schedule
> > [2] https://fedoraproject.org/wiki/Milestone_freezes 
> > [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process 
> > [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_proc
> > ess 
> > [5] https://fedoraproject.org/wiki/Changes/Policy
> > [6] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
> > 
> > 
> > ___
> > test-announce mailing list -- test-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to test-announce-leave@lists.fedorapro
> > ject.org
> > 
> > 
> > ___
> > 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

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

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmv0FsACgkQaVcUvRu8
X0yv5BAAkmugft4wQy3Loz8nT3vTe8H6iFUVqmh+hkFZPqxHFhMt96JFBVnuGW3m
srAL0u2lvVsDhScMLwbr8JbFB5Poy6uFIB6Htrj/Z+HPuyUHVh4O8vXvy+vNnkax
YvOdc0d2LIvBRC90+HkX3EHMFKL/vWHFhkIGGKQXhcbB3FU4I8ztXQtw5wXc8tTN
nj0+98CHZYzBquvA8MwYBmxoxXzPGQdzaEgvwzFaCQJ1345enA21sfOpylPZHYHM
+N5SVb1ZlqHiY701dsfTcF/qGbvNAmB5t/AW1veH6I2ikNV4n7oNUWjPvxDM4I1I
1P7Ox5E6VHiEG9Z+bmWpip7kzKJFXqmaU4gpT6An8kjmWOgQZIaaTMt6EKzKs2tT
rb5oHYAdgE82TUYxbcfkQKQ8yGP1WL0ms17+fQ76gKZ3gEGY2TlHBg+yVFaPg4bu
3/C3DrybWVE3i31lnyvhJmfFgmVe7UTltiRikUy+c4mDfaV3YnHkH38me04TG5ta
abfX4xl9G24rGp2WJrkPkVzUgi6kU1/vh7dvQxJhYFZOMFCvFdrn+rePenPWXfNf
iaAnZ7tAGIEoWe7X+9UV14d7wiVJK8zIVQKpqjpO+RxSCK7iPHsYUsIMcyna7wLR
56gyyjvi1r0ESv/PE2wjAozHfu76W6cmZRqwAAoIRmLIETP2eow=
=c46T
-END PGP SIGNATURE-
___
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 6 September 2017 at 09:24, Björn 'besser82' Esser
 wrote:
[..]
> That is NOT true for gtk-update-icon-cache.  There is currently no trigger
> for it, at least when I look at the recent information on the wiki [1].

OK. Just started working on add this (I see a lot other things which
can be improved in gtk3.spec).

> Setting automatic triggers for this might be tricky, since we simply have
> more icon sets as just hicolor; there are plenty of others among just that
> one.  For that reason the automatic triggers would need to iterate over all
> direct subdirs in %{_datadir}/icons and run the update for all of them,
> like:
>
> ```
> for _dir in $(find /usr/share/icons -mindepth 1 -maxdepth 1 -type d) ; do
>   /bin/touch --no-create $_dir &>/dev/null || :
>   /usr/bin/gtk-update-icon-cache $_dir &>/dev/null || :
> done
> ```
>
> to make sure all possibly changed icon sets are covered.
>
> For that reason, I think, there are still no automatic triggers for the icon
> cache.

Correct any of my below thinking if anything is wrong.

1) It is not possible to use only icon theme without actual switching
to other theme.

2) If it is correct updating theme icons cache should be placed in
main package installing theme.

3) As long as hicolor theme is default theme updating its cache can
still be in gtk-update-icon-cache package.

What happens with other directories than /usr/share/icons/hicolor is
in this case secondary and can be treated as an exception.
Running above script will make updates oft the hicolor theme
potentially longer and only occasionally it will be possible to save
some time.
if yes let's allow update other themes caches to packages installing
those themes).

If above is kind of wrong you script is correct.

BTW. Looks like now when "Settings" application has been changes to
much less readable list view looks like change theme gone and now it
is not possible to switch to other theme without installing some
extensions :/
In this situation number of people experiencing any issues with
incorrect icons caches has been "dramatically reduced" ;-)

And yet anther "small" issue:

$ rpm -qf /usr/share/icons/*
adwaita-cursor-theme-3.25.91-1.fc28.noarch
adwaita-icon-theme-3.25.91-1.fc28.noarch
fedora-logos-26.0.1-3.fc27.x86_64
libXcursor-1.1.14-10.fc27.x86_64
gnome-icon-theme-3.12.0-7.fc27.noarch
fedora-logos-26.0.1-3.fc27.x86_64
gnome-themes-standard-3.22.3-4.fc27.x86_64
file /usr/share/icons/locolor is not owned by any package
fedora-logos-26.0.1-3.fc27.x86_64

Hmm why libXcursor has its own settings witin icons themes directories?

defailt points to Inherits=Adwaita but I don't see how with this
hicolor is linked?
Is this all correct?

On first looks what is currently is a bit messy (?)

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: GNOME 3.25.92 megaupdate

[Tomasz Kłoczko]

On 6 September 2017 at 11:43, Tomasz Kłoczko 
wrote:
[..]

> 3) As long as hicolor theme is default theme updating its cache can
> still be in gtk-update-icon-cache package.
>
> What happens with other directories than /usr/share/icons/hicolor is
> in this case secondary and can be treated as an exception.
> Running above script will make updates oft the hicolor theme
> potentially longer and only occasionally it will be possible to save
> some time.
> if yes let's allow update other themes caches to packages installing
> those themes).
>

Just made quick check:

[tkloczko@domek SPECS.fedora]$ grep filetrigger * | grep icons
adwaita-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/Adwaita
adwaita-icon-theme.spec:%transfiletriggerpostun -- %{_datadir}/icons/Adwaita
gnome-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/gnome
gnome-icon-theme.spec:%transfiletriggerpostun -- %{_datadir}/icons/gnome
gnome-themes-standard.spec:%transfiletriggerin --
%{_datadir}/icons/HighContrast
gnome-themes-standard.spec:%transfiletriggerpostun --
%{_datadir}/icons/HighContrast
hicolor-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/hicolor
hicolor-icon-theme.spec:%transfiletriggerpostun -- %{_datadir}/icons/hicolor

Seems like packages installing other themes *already* are doing exactly
what I've been thinking that they should be doing so updating per icon
theme strategy should be OK.

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: GNOME 3.25.92 megaupdate

[Tomasz Kłoczko]

On 6 September 2017 at 09:32, Neal Gompa  wrote:
[..]
> I think we implemented file triggers in Mageia for this, I'll need to
> do some checking. I know that we're pretty aggressive on package,
> transaction, and file trigger usage compared to Fedora... Heck, we
> don't even need ldconfig runs in Mageia, since they're run
> automatically through file triggers.

TBH my opinion about this subject is a bit mixed.

On one side biggest triggers "deposit" are sitting in use ldconfig and
seems like no one is able to make decision about push this :/
Only this could save IMO about +30% of any upgrades time.
On systems with less memory when mass upgrade is done and it is not
possible to cache all libraries touched by ldconfig in memory this should
reduce upgrade time even by *few times*!!!
Discussion about these triggers stared *YEAR* and still there is no final
decision or any arguments why not to introduce those triggers.
[mode=sarcasm]
One year of deliberations on few lines modification must be here new
"aggressive" word synonym.
[/mode] :P

As I wrote in https://bugzilla.redhat.com/show_bug.cgi?id=1380878
implementing those triggers in form which is proposed at the and will not
harm anything but it will allow all maintainers one by one remove running
in %post/%postun.
Lack of progress seems has its cause in kind of cold inferno joke (no one
wants to put pieces of wood under the fire).

IMO even introduce ldconfig triggers and do mass remove will break
initially maybe few minor packages and it will be enormous possible to save
enormous amount of time and dependencies. Even if something will be broken
fixing it will be trivial.

On the other side week ago I've reached with Kalev agreement on
implementing info pages triggers (almost 300 packages can be simplified
after introduce this trigger)
https://bugzilla.redhat.com/show_bug.cgi?id=1482019
This will be shortly resolved as I only need to write announcement about
this here (as I promised :))

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: [Test-Announce] Fedora 27 Beta Freeze

[Vít Ondruch]

Dne 6.9.2017 v 12:39 Igor Gnatenko napsal(a):
> On Wed, 2017-09-06 at 12:17 +0200, Vít Ondruch wrote:
>
> > Dne 5.9.2017 v 16:28 Mohan Boddu napsal(a):
> >> Hi all,  
> >> Today is an important day on the Fedora 27 schedule[1], with two
> >>  significant cut-offs.  
> >> Today is the Beta freeze[2]. This means that only packages which
> >> fix
> >> accepted blocker or freeze exception bugs[3][4] will be marked as
> >> 'stable' and included in the 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.
>
> > May be it would be good to point out that Bodhi was enabled for F27?
> > I
> > just checking my yesterday build (done prior this announcement) and
> > it
> > is in f27-updates-candidate indeed ...
> It actually was!
>
> See "Fedora 27 Bodhi Activation Point" mail which was sent on "Tue, 29
> Aug 2017 11:05:17 -0400 (08/29/2017 05:05:17 PM)" 😉
>
>

Ah, sorry, my bad :/


V.





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

Re: GNOME 3.25.92 megaupdate

[Kalev Lember]

On 09/06/2017 01:22 PM, Tomasz Kłoczko wrote:
> [tkloczko@domek SPECS.fedora]$ grep filetrigger * | grep icons
> adwaita-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/Adwaita
> adwaita-icon-theme.spec:%transfiletriggerpostun -- %{_datadir}/icons/Adwaita
> gnome-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/gnome
> gnome-icon-theme.spec:%transfiletriggerpostun -- %{_datadir}/icons/gnome
> gnome-themes-standard.spec:%transfiletriggerin --
> %{_datadir}/icons/HighContrast
> gnome-themes-standard.spec:%transfiletriggerpostun --
> %{_datadir}/icons/HighContrast
> hicolor-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/hicolor
> hicolor-icon-theme.spec:%transfiletriggerpostun -- %{_datadir}/icons/hicolor
>  
> Seems like packages installing other themes *already* are doing exactly
> what I've been thinking that they should be doing so updating per icon
> theme strategy should be OK.

Right, I added file triggers to all gnome-related icon themes last cycle
with the plan to delete the scriptlets from individual packages soon. I
can add the triggers to KDE and other themes as well if their
maintainers are fine with it. rdieter?

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

Re: OCaml / aarch64 / binutils / coq mess

[Richard W.M. Jones]

I believe I have come up with a patch which works well enough that we
can push it to Fedora 27+ aarch64:

  
https://pagure.io/fedora-ocaml/c/e7fdaf008e047c445fd7a6acf9362d8b5940bf4b?branch=fedora-27-4.05.0

Note this patch is not upstream but I've brought it to the attention
of the upstream maintainers.

I will do the rebuilds of the affected packages, and unless those
rebuilds fail there is nothing required for the package maintainers to
do.

However it would be helpful if you could all keep an eye on your
package and after it has been rebuilt try to do some testing (ideally
on aarch64, but even x86_64 testing has some use).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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

[Richard W.M. Jones]

I only skimmed this thread and didn't see any reference to this.

Currently emacs is uninstallable in Rawhide, resulting in any Koji
build that depends on emacs failing:

  DEBUG util.py:439:- nothing provides 
libMagickCore-7.Q16HDRI.so.3()(64bit) needed by emacs-1:25.2-9.fc28.x86_64

Is there a fix for this?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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 6 September 2017 at 13:02, Kalev Lember  wrote:
[..]

> > Seems like packages installing other themes *already* are doing exactly
> > what I've been thinking that they should be doing so updating per icon
> > theme strategy should be OK.
>
> Right, I added file triggers to all gnome-related icon themes last cycle
> with the plan to delete the scriptlets from individual packages soon. I
> can add the triggers to KDE and other themes as well if their
> maintainers are fine with it. rdieter?
>

FYI: I'll be holding my gtk3 patch submission until it will be clear
decision here.
IMO it would be better to have triggers per themes as looks like number of
such triggers will be not huge and each one will be doing *exactly* what
needs to be done and no more (but it is only my personal +1 for such
option).

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: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

On 09/06/2017 10:23 AM, Richard W.M. Jones wrote:

Is there a fix for this?


ImageMagick was downgraded from v7 to v6 today. A emacs rebuild will fix it. I've 
submitted one.

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

what's the story with kerberos

[Nikos Mavrogiannopoulos]

-- 
Nikos Mavrogiannopoulos, PhD,
Crypto Tech. Lead,
Security Technologies,
Red Hat, Inc.



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

story of kerberos

[Nikos Mavrogiannopoulos]

Hi,
 What's the story between the recently introduced support of kerberos
in koji? My understanding was that eventually all services of fedora
would switch to kerberos authentication, though information on the
following bugs for bodhi seems to contradict that:

https://bugzilla.redhat.com/show_bug.cgi?id=1483538
https://github.com/fedora-infra/bodhi/issues/1179

In fact currently we have:
 * To change code: ssh public key authentication
 * To compile changed code: koji: kerberos ticket
 * To submit a changed package: bodhi: raw passwords
 * To subscribe to a mailing list: lists.fedoraproject.org: openid?

and probably few more options that I missed. Is there an integration
story behind all these, or is it intentional that various different
services will require different credentials?

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

Re: Confusing SCM package request

[Kevin Fenzi]

On 09/02/2017 07:09 AM, Pierre-Yves Chibon wrote:
> On Tue, Aug 29, 2017 at 07:48:47AM -0400, Neal Gompa wrote:
>> On Tue, Aug 29, 2017 at 5:36 AM, Björn 'besser82' Esser
>>  wrote:
>>> Am 29.08.2017 um 11:30 schrieb Richard W.M. Jones:

 I'm trying to import this package into Fedora:

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

 I went through the new process as far as I can tell and the tool just
 filed a bug and printed out the URL of the bug:

$ fedrepo-req -t 1174036 ocaml-re
https://pagure.io/releng/fedora-scm-requests/issue/596

 Do I have to wait for that request to be handled now?  The
 documentation seems to suggest that the branch should actually have
 been created, but it is not.

 Rich.
>>>
>>>
>>> fedrepo-req currently files issues against `fedora-scm-requests` on Pagure.
>>> You can see those issues as a kind of queue, which gets manually processed
>>> several times a day by limb (or other scm-admins).
>>>
>>> The process still is the same as it used to be, just the tooling and some
>>> technical implementations have changed.
>>>
>>
>> I don't get why this isn't automated yet... We seem to be stepping
>> closer to it without actually doing it...
> 
> We are but so far releng asked that this is not fully automated, so we would
> have to bring it to them if we want to change this.

We use this as a final check by a human.

When I was doing all these requests a few years ago, I definitely caught
packages that were not legally allowed or had a shoddy review at this step.

We can't catch everything of course, but having a trusted person check
on the two people adding a package (submittor/reviewer) is still well
worth the short delay IMHO.

kevin





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

Re: Confusing SCM package request

[Josh Boyer]

On Wed, Sep 6, 2017 at 12:15 PM, Kevin Fenzi  wrote:
> On 09/02/2017 07:09 AM, Pierre-Yves Chibon wrote:
>> On Tue, Aug 29, 2017 at 07:48:47AM -0400, Neal Gompa wrote:
>>> On Tue, Aug 29, 2017 at 5:36 AM, Björn 'besser82' Esser
>>>  wrote:
 Am 29.08.2017 um 11:30 schrieb Richard W.M. Jones:
>
> I'm trying to import this package into Fedora:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1174036
>
> I went through the new process as far as I can tell and the tool just
> filed a bug and printed out the URL of the bug:
>
>$ fedrepo-req -t 1174036 ocaml-re
>https://pagure.io/releng/fedora-scm-requests/issue/596
>
> Do I have to wait for that request to be handled now?  The
> documentation seems to suggest that the branch should actually have
> been created, but it is not.
>
> Rich.


 fedrepo-req currently files issues against `fedora-scm-requests` on Pagure.
 You can see those issues as a kind of queue, which gets manually processed
 several times a day by limb (or other scm-admins).

 The process still is the same as it used to be, just the tooling and some
 technical implementations have changed.

>>>
>>> I don't get why this isn't automated yet... We seem to be stepping
>>> closer to it without actually doing it...
>>
>> We are but so far releng asked that this is not fully automated, so we would
>> have to bring it to them if we want to change this.
>
> We use this as a final check by a human.
>
> When I was doing all these requests a few years ago, I definitely caught
> packages that were not legally allowed or had a shoddy review at this step.
>
> We can't catch everything of course, but having a trusted person check
> on the two people adding a package (submittor/reviewer) is still well
> worth the short delay IMHO.

I don't.  Your reasoning isn't wrong, but it falls down very quickly
when you take into account that there is 0 on-going review on
packages.  All it takes for someone to do a decent enough job on the
initial review to get a package in, and then they can muck about as
much as they want.  What you're catching by doing this forced delay is
rushed reviews or laziness on the part of two people.  That's not bad,
but I'm not convinced it's worth not automating.  You implicitly trust
the reviewer and sponsors already anyway.

josh
___
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 Wed, 2017-09-06 at 10:51 -0500, Michael Cronenworth wrote:
> On 09/06/2017 10:23 AM, Richard W.M. Jones wrote:
> > Is there a fix for this?
> 
> ImageMagick was downgraded from v7 to v6 today. A emacs rebuild will fix it. 
> I've 
> submitted one.

I am doing the rebuilds. Unfortunately, the f28-build repository took a
long time to regenerate after the ImageMagick build went through, so I
couldn't get them done in time to all go into the same compose
together.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: story of kerberos

[Kevin Fenzi]

On 09/06/2017 05:25 AM, Nikos Mavrogiannopoulos wrote:
> Hi,
>  What's the story between the recently introduced support of kerberos
> in koji? My understanding was that eventually all services of fedora
> would switch to kerberos authentication, though information on the
> following bugs for bodhi seems to contradict that:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1483538
> https://github.com/fedora-infra/bodhi/issues/1179

I'm not sure where you got the understanding that everything was moving
to kerberos. Did we say that somewhere?

> In fact currently we have:
>  * To change code: ssh public key authentication
>  * To compile changed code: koji: kerberos ticket
>  * To submit a changed package: bodhi: raw passwords
>  * To subscribe to a mailing list: lists.fedoraproject.org: openid?
> 
> and probably few more options that I missed. Is there an integration
> story behind all these, or is it intentional that various different
> services will require different credentials?
 For ssh keys, we are looking at various options. Possibly ssh
certificates. Patrick has been investigating this.

For all the web apps we have now (except wiki, but it should move soon),
we should have openid or openid-connect. In that case if you have a
valid kerberos ticket, your browser is configured right (default in all
recent ones), you automatically can authenticate via ipsilon.

ie, you click the login thing, it redirects to ipsilon, which sees you
have a valid kerberos ticket and just authenticates you. Do you not see
this happening there?

So, they are all tied together via ipsilon (except ssh keys, and wiki
login).

Once we have a concrete plan for ssh we will be happy to share it.

kevin






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

Re: Confusing SCM package request

[Adam Williamson]

On Wed, 2017-09-06 at 12:26 -0400, Josh Boyer wrote:
> What you're catching by doing this forced delay is
> rushed reviews or laziness on the part of two people.

Also *ignorance*, in the case of legally-not-allowed things. And it
also allows the folks doing the package reviews to look for patterns
emerging (like a single packager continually submitting non-suitable
things, or a reviewer continually doing shoddy reviews) which can be
then be dealt with appropriately.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Confusing SCM package request

[Adam Williamson]

On Wed, 2017-09-06 at 09:53 -0700, Adam Williamson wrote:
> On Wed, 2017-09-06 at 12:26 -0400, Josh Boyer wrote:
> > What you're catching by doing this forced delay is
> > rushed reviews or laziness on the part of two people.
> 
> Also *ignorance*, in the case of legally-not-allowed things. And it
> also allows the folks doing the package reviews

erf. I meant 'folks doing the SCM requests'.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: story of kerberos

[Simo Sorce]

On Wed, 2017-09-06 at 09:51 -0700, Kevin Fenzi wrote:

> So, they are all tied together via ipsilon (except ssh keys, and wiki
> login).
> 
> Once we have a concrete plan for ssh we will be happy to share it.

Would you consider allowing SSH+GSSAPI as well ?
This way I do not need to care for keys ...

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Confusing SCM package request

[Josh Boyer]

On Wed, Sep 6, 2017 at 12:53 PM, Adam Williamson
 wrote:
> On Wed, 2017-09-06 at 12:26 -0400, Josh Boyer wrote:
>> What you're catching by doing this forced delay is
>> rushed reviews or laziness on the part of two people.
>
> Also *ignorance*, in the case of legally-not-allowed things. And it

We have guidelines covering that.  I don't really find it acceptable
for a packager to be ignorant of it, and definitely not the reviewer.
Certainly not the sponsors of the packager and reviewers.

If our guidelines are sufficiently long or confusing enough that we
still have people ignorant of this, then it highlights a problem with
our guidelines.

> also allows the folks doing the package reviews to look for patterns
> emerging (like a single packager continually submitting non-suitable
> things, or a reviewer continually doing shoddy reviews) which can be
> then be dealt with appropriately.

Taking your follow up of "folks doing the SCM requests" into account,
I don't think that's what they signed up for?  That's the job of a
sponsor.

However, you're just making cases for the easy to catch things and
didn't address my point of 0 after-the-fact, on-going reviews taking
place.  If we are SO concerned with this up front, why are we
completely unconcerned with it once a package is in?  If we have
problems with our guidelines, sponsor process, and continuation of
both of those then lets fix those.  Don't make SCM admins accountable
for it.  That doesn't make sense and I simply don't agree that forcing
additional human delay here is worthwhile when it could be automated.

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

Fedora Rawhide-20170906.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Workstation live i386
Cloud_base raw-xz x86_64
Server boot i386
Kde live i386

Failed openQA tests: 47/137 (x86_64), 1/18 (i386), 1/2 (arm)

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

ID: 137942  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/137942
ID: 137967  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/137967
ID: 137979  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/137979
ID: 138000  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/138000

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

ID: 137928  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137928
ID: 137930  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137930
ID: 137932  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/137932
ID: 137939  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/137939
ID: 137951  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137951
ID: 137953  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137953
ID: 137956  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/137956
ID: 137968  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137968
ID: 137970  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137970
ID: 137973  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/137973
ID: 137981  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/137981
ID: 137982  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/137982
ID: 137985  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137985
ID: 137986  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/137986
ID: 137987  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/137987
ID: 137988  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/137988
ID: 137997  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/137997
ID: 137998  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/137998
ID: 137999  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/137999
ID: 138001  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/138001
ID: 138002  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/138002
ID: 138009  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/138009
ID: 138010  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/138010
ID: 138020  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/138020
ID: 138022  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/138022
ID: 138028  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/138028
ID: 138046  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/138046
ID: 138047  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/138047
ID: 138048  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/138048
ID: 138049  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/138049
ID: 138050  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/138050
ID: 138051  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/138051
ID: 138053  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/138053
ID: 138054  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/138054
ID: 138055  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/138055
ID: 138056  Test: x86_64 universal install_software_raid@uefi
URL: https://o

Re: Confusing SCM package request

[Adam Williamson]

On Wed, 2017-09-06 at 13:14 -0400, Josh Boyer wrote:
> Taking your follow up of "folks doing the SCM requests" into account,
> I don't think that's what they signed up for?  That's the job of a
> sponsor.
> 
> However, you're just making cases for the easy to catch things and
> didn't address my point of 0 after-the-fact, on-going reviews taking
> place.  If we are SO concerned with this up front, why are we
> completely unconcerned with it once a package is in?

I wouldn't say we are, I'd just say we haven't figured out a good
process for it yet. But it's not fair to say 'completely unconcerned';
for instance, a while ago someone ran a script checking for Flash
executables in packages and filed a bug on every package that contained
one which wasn't built from source. When major guideline changes
happen, there's sometimes a process to bring existing packages into
line (e.g. the ongoing effort to rename Python binary packages). It
*does* happen. We don't have a great, comprehensive process, but
'completely unconcerned' is an overreach.

I'd also suggest that the two situations aren't really equivalent.
There's a higher chance of something being legally unsuitable for
Fedora *at the time it goes in* than it suddenly *becoming* legally
unsuitable later, with no-one noticing. The chance of the latter isn't
zero, but I'd say it's lower.

I mean, if I slightly unfairly reduce it aggressively, your argument
seems to be "we're bad at doing stuff at point Y, so why not stop doing
it at point X too?" That seems an...odd way to 'solve' the problem.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Wed, 2017-09-06 at 09:28 -0700, Adam Williamson wrote:
> On Wed, 2017-09-06 at 10:51 -0500, Michael Cronenworth wrote:
> > On 09/06/2017 10:23 AM, Richard W.M. Jones wrote:
> > > Is there a fix for this?
> > 
> > ImageMagick was downgraded from v7 to v6 today. A emacs rebuild will fix 
> > it. I've 
> > submitted one.
> 
> I am doing the rebuilds. Unfortunately, the f28-build repository took a
> long time to regenerate after the ImageMagick build went through, so I
> couldn't get them done in time to all go into the same compose
> together.

Rebuilds are now done for Rawhide, and this is the update for F27:

https://bodhi.fedoraproject.org/updates/FEDORA-2017-f50d944ec7

I've filed a bug and nominated it for a freeze exception:

https://bugzilla.redhat.com/show_bug.cgi?id=1489124
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GNOME 3.25.92 megaupdate

[Matthias Clasen]

On Wed, 2017-09-06 at 14:02 +0200, Kalev Lember wrote:
> On 09/06/2017 01:22 PM, Tomasz Kłoczko wrote:
> > [tkloczko@domek SPECS.fedora]$ grep filetrigger * | grep icons
> > adwaita-icon-theme.spec:%transfiletriggerin --
> > %{_datadir}/icons/Adwaita
> > adwaita-icon-theme.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/Adwaita
> > gnome-icon-theme.spec:%transfiletriggerin --
> > %{_datadir}/icons/gnome
> > gnome-icon-theme.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/gnome
> > gnome-themes-standard.spec:%transfiletriggerin --
> > %{_datadir}/icons/HighContrast
> > gnome-themes-standard.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/HighContrast
> > hicolor-icon-theme.spec:%transfiletriggerin --
> > %{_datadir}/icons/hicolor
> > hicolor-icon-theme.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/hicolor
> >  
> > Seems like packages installing other themes *already* are doing
> > exactly
> > what I've been thinking that they should be doing so updating per
> > icon
> > theme strategy should be OK.
> 
> Right, I added file triggers to all gnome-related icon themes last
> cycle
> with the plan to delete the scriptlets from individual packages soon.
> I
> can add the triggers to KDE and other themes as well if their
> maintainers are fine with it. rdieter?

Lets try to bring some clarity into this. The only 'drop dir' icon
theme is hicolor - applications are expected to install their app icons
there, which is why we need a file trigger to update the icon cache for
this theme when an unrelated package places new content there.

Other themes should be entirely self-contained within their package.
Apps have no business dropping icons intio Adwaita or HighContrast, so
it really is not necessary to have file triggers for those themes,
afaics.
___
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 6 September 2017 at 03:16, Rex Dieter  wrote:
> [..]
>>> 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.
> 
> This is exactly what I wrote.
> Running those binaries per package is no longer needed as already
> implemented triggers are doing all what is needs to be done.

you claimed

"All this stuff only makes upgrades longer by executing at least two 
times per package."

and I'm disputing your claim.  In this case, they do not run per package and 
do not (significantly) contribute to making upgrades longer.

-- Rex

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

Kalev Lember wrote:

> I
> can add the triggers to KDE and other themes as well if their
> maintainers are fine with it. rdieter?

If you don't mind, please do, thanks.

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

Re: Confusing SCM package request

[Josh Boyer]

On Wed, Sep 6, 2017 at 1:49 PM, Adam Williamson
 wrote:
> On Wed, 2017-09-06 at 13:14 -0400, Josh Boyer wrote:
>> Taking your follow up of "folks doing the SCM requests" into account,
>> I don't think that's what they signed up for?  That's the job of a
>> sponsor.
>>
>> However, you're just making cases for the easy to catch things and
>> didn't address my point of 0 after-the-fact, on-going reviews taking
>> place.  If we are SO concerned with this up front, why are we
>> completely unconcerned with it once a package is in?
>
> I wouldn't say we are, I'd just say we haven't figured out a good
> process for it yet. But it's not fair to say 'completely unconcerned';
> for instance, a while ago someone ran a script checking for Flash
> executables in packages and filed a bug on every package that contained
> one which wasn't built from source. When major guideline changes
> happen, there's sometimes a process to bring existing packages into
> line (e.g. the ongoing effort to rename Python binary packages). It
> *does* happen. We don't have a great, comprehensive process, but
> 'completely unconcerned' is an overreach.

We've been doing Fedora packaging in the current setup, with reviews
and such, for many many years.  We haven't even tried to address these
problems systematically.  At best we have someone doing a one-off
script.  If the Fedora project hasn't prioritized it and come up with
a plan to solve it in all of these years, I do not think it is
overreach to say the project is unconcerned.  If you don't like that
word, you could say it's low priority which is just a manager-y way of
saying it is not a concern (speaking as a manager).

> I'd also suggest that the two situations aren't really equivalent.
> There's a higher chance of something being legally unsuitable for
> Fedora *at the time it goes in* than it suddenly *becoming* legally
> unsuitable later, with no-one noticing. The chance of the latter isn't
> zero, but I'd say it's lower.

I agree the chance lower, but I think it is much worse in severity.
Much much worse.

> I mean, if I slightly unfairly reduce it aggressively, your argument
> seems to be "we're bad at doing stuff at point Y, so why not stop doing
> it at point X too?" That seems an...odd way to 'solve' the problem.

No, my point is "we're creating artificial bottlenecks and using up
valuable human contributor time because our other processes are
lacking, and that's preventing automating something that should
already be accounted for by our review process".  It's not exactly
technical debt, but it's similar to it.  It's process debt or
something, and requiring SCM admins (of which there are few) to do
that work is silly.

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

Re: GNOME 3.25.92 megaupdate

[Yaakov Selkowitz]

On 2017-09-06 13:16, Matthias Clasen wrote:
> On Wed, 2017-09-06 at 14:02 +0200, Kalev Lember wrote:
>> On 09/06/2017 01:22 PM, Tomasz Kłoczko wrote:
>>> [tkloczko@domek SPECS.fedora]$ grep filetrigger * | grep icons
>>> adwaita-icon-theme.spec:%transfiletriggerin --
>>> %{_datadir}/icons/Adwaita
>>> adwaita-icon-theme.spec:%transfiletriggerpostun --
>>> %{_datadir}/icons/Adwaita
>>> gnome-icon-theme.spec:%transfiletriggerin --
>>> %{_datadir}/icons/gnome
>>> gnome-icon-theme.spec:%transfiletriggerpostun --
>>> %{_datadir}/icons/gnome
>>> gnome-themes-standard.spec:%transfiletriggerin --
>>> %{_datadir}/icons/HighContrast
>>> gnome-themes-standard.spec:%transfiletriggerpostun --
>>> %{_datadir}/icons/HighContrast
>>> hicolor-icon-theme.spec:%transfiletriggerin --
>>> %{_datadir}/icons/hicolor
>>> hicolor-icon-theme.spec:%transfiletriggerpostun --
>>> %{_datadir}/icons/hicolor
>>>  
>>> Seems like packages installing other themes *already* are doing
>>> exactly
>>> what I've been thinking that they should be doing so updating per
>>> icon
>>> theme strategy should be OK.
>>
>> Right, I added file triggers to all gnome-related icon themes last
>> cycle
>> with the plan to delete the scriptlets from individual packages soon.
>> I
>> can add the triggers to KDE and other themes as well if their
>> maintainers are fine with it. rdieter?
> 
> Lets try to bring some clarity into this. The only 'drop dir' icon
> theme is hicolor - applications are expected to install their app icons
> there, which is why we need a file trigger to update the icon cache for
> this theme when an unrelated package places new content there.
> 
> Other themes should be entirely self-contained within their package.
> Apps have no business dropping icons intio Adwaita or HighContrast, so
> it really is not necessary to have file triggers for those themes,
> afaics.

Unfortunately not 100% accurate:

* A number of KDE applications drop icons into oxygen or locolor (in
addition to hicolor).

* d-feet, meld, and terminator drop icons into HighContrast (in addition
to hicolor).  gobby and gobby05 do the same in
HighContrastLargePrint{,Inverse}.

* geocode-glib still drops icons into the 'gnome' theme (the deprecated
one, not Adwaita).

* libmateweather adds to the 'mate' theme.

And there are probably more.

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.



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

Re: OCaml / aarch64 / binutils / coq mess

[Richard W.M. Jones]

Nearly done it.  Unfortunately I updated ‘why’ to the latest upstream
version (the previous one didn't know about OCaml 4.05), however that
will require updating ‘frama-c’:

  configure: WARNING: bad Frama-c version "Silicon-20161101", you need version 
Phosphorus

At that point I stopped.  Would you mind updating and rebuilding
‘frama-c’ and ‘why’ in both Rawhide and F27?

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

Re: Urgent attention required; ImageMagick update breakage

[Richard W.M. Jones]

On Wed, Sep 06, 2017 at 11:12:14AM -0700, Adam Williamson wrote:
> On Wed, 2017-09-06 at 09:28 -0700, Adam Williamson wrote:
> > On Wed, 2017-09-06 at 10:51 -0500, Michael Cronenworth wrote:
> > > On 09/06/2017 10:23 AM, Richard W.M. Jones wrote:
> > > > Is there a fix for this?
> > > 
> > > ImageMagick was downgraded from v7 to v6 today. A emacs rebuild will fix 
> > > it. I've 
> > > submitted one.
> > 
> > I am doing the rebuilds. Unfortunately, the f28-build repository took a
> > long time to regenerate after the ImageMagick build went through, so I
> > couldn't get them done in time to all go into the same compose
> > together.
> 
> Rebuilds are now done for Rawhide, and this is the update for F27:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-f50d944ec7
> 
> I've filed a bug and nominated it for a freeze exception:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1489124

Thanks (both), emacs installs in Rawhide now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Need review for f27-backgrounds

[Luya Tshimbalanga]

Design team recently completed the beta wallpapers and the package is
ready for review.
The spec is very straightforward and needs for the beta release. See

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

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: story of kerberos

[Ben Rosser]

On Wed, Sep 6, 2017 at 12:51 PM, Kevin Fenzi  wrote:
> On 09/06/2017 05:25 AM, Nikos Mavrogiannopoulos wrote:
>> Hi,
>>  What's the story between the recently introduced support of kerberos
>> in koji? My understanding was that eventually all services of fedora
>> would switch to kerberos authentication, though information on the
>> following bugs for bodhi seems to contradict that:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1483538
>> https://github.com/fedora-infra/bodhi/issues/1179
>
> I'm not sure where you got the understanding that everything was moving
> to kerberos. Did we say that somewhere?

No, but it seems to me like one of the advantages of using a system
like Kerberos is that, theoretically, we *could* standardize all
authentication on it

For example, I complained recently that I need Kerberos tickets to
submit builds but "pagure auth tokens" to actually request branches
using fedrepo-req: https://pagure.io/pagure/issue/2549. The same is
true to interact with copr via copr-cli. It's not clear to me why, as
a packager, I should need N different types of authentication token on
my system in order to interact with the different parts of the
packaging plumbing. It seems to me that in an ideal world it would
only require one mechanism to interact with all these services.

That mechanism doesn't need to be Kerberos, but... if it's not going
to be Kerberos, why *did* Koji switch over to Kerberos?

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

Should a binary allowed to self-update ?

[DAVID Clément]

Dear packagers,

On my road to package http://exercism.io CLI, I need to provide a
self-update feature [1] for Golang-coded binaries. After a look at the
packaging guidelines, I am not sure if it is allowed to package binaries
with such a feature. To me, it should be discarded as the rpm provided
binary files should not be altered out of the packaging system.

Should I package [1] or patch the exercism CLI to remove that feature ?

[1]: https://github.com/inconshreveable/go-update

Thanks,

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

Re: Should a binary allowed to self-update ?

[Neal Gompa]

On Wed, Sep 6, 2017 at 5:01 PM, DAVID Clément  wrote:
> Dear packagers,
>
> On my road to package http://exercism.io CLI, I need to provide a
> self-update feature [1] for Golang-coded binaries. After a look at the
> packaging guidelines, I am not sure if it is allowed to package binaries
> with such a feature. To me, it should be discarded as the rpm provided
> binary files should not be altered out of the packaging system.
>
> Should I package [1] or patch the exercism CLI to remove that feature ?
>
> [1]: https://github.com/inconshreveable/go-update
>

Patch out the functionality. RPM is supposed to manage binaries.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: story of kerberos

[Kevin Fenzi]

On 09/06/2017 10:05 AM, Simo Sorce wrote:
> On Wed, 2017-09-06 at 09:51 -0700, Kevin Fenzi wrote:
> 
>> So, they are all tied together via ipsilon (except ssh keys, and wiki
>> login).
>>
>> Once we have a concrete plan for ssh we will be happy to share it.
> 
> Would you consider allowing SSH+GSSAPI as well ?
> This way I do not need to care for keys ...

Thats a possiblity. I think there was some reason we didn't like that
path, but Patrick would be the one to ask.

kevin




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

Re: story of kerberos

[Kevin Fenzi]

On 09/06/2017 01:37 PM, Ben Rosser wrote:
> On Wed, Sep 6, 2017 at 12:51 PM, Kevin Fenzi  wrote:
>> On 09/06/2017 05:25 AM, Nikos Mavrogiannopoulos wrote:
>>> Hi,
>>>  What's the story between the recently introduced support of kerberos
>>> in koji? My understanding was that eventually all services of fedora
>>> would switch to kerberos authentication, though information on the
>>> following bugs for bodhi seems to contradict that:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1483538
>>> https://github.com/fedora-infra/bodhi/issues/1179
>>
>> I'm not sure where you got the understanding that everything was moving
>> to kerberos. Did we say that somewhere?
> 
> No, but it seems to me like one of the advantages of using a system
> like Kerberos is that, theoretically, we *could* standardize all
> authentication on it

We could, but there's tradeoffs. In some cases other things are better
and could be transparently done via ipsilon.
> 
> For example, I complained recently that I need Kerberos tickets to
> submit builds but "pagure auth tokens" to actually request branches
> using fedrepo-req: https://pagure.io/pagure/issue/2549. The same is
> true to interact with copr via copr-cli. It's not clear to me why, as
> a packager, I should need N different types of authentication token on
> my system in order to interact with the different parts of the
> packaging plumbing. It seems to me that in an ideal world it would
> only require one mechanism to interact with all these services.

I agree reducing the number of things is a good goal.
However, support for something doesn't magically appear because we would
like it. For example, pagure has no code at all for kerberos auth (that
I know of).
> 
> That mechanism doesn't need to be Kerberos, but... if it's not going
> to be Kerberos, why *did* Koji switch over to Kerberos?

Because koji has implemented 2 types of auth: certs (which we used to
use) and kerberos (which we switched to). Kerberos is much better than
certs for our needs.

kevin




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

Re: story of kerberos

[Alexander Bokovoy]

On Wed, 06 Sep 2017, Kevin Fenzi wrote:

On 09/06/2017 10:05 AM, Simo Sorce wrote:

On Wed, 2017-09-06 at 09:51 -0700, Kevin Fenzi wrote:


So, they are all tied together via ipsilon (except ssh keys, and wiki
login).

Once we have a concrete plan for ssh we will be happy to share it.


Would you consider allowing SSH+GSSAPI as well ?
This way I do not need to care for keys ...


Thats a possiblity. I think there was some reason we didn't like that
path, but Patrick would be the one to ask.

I'm not on a receiving end of Fedora Infra team but as someone who was
involved in Kerberos deployment discussions, including development of
FreeIPA features that Fedora Infra uses, I can add few details.

One concern we had in discussions is that we are still allowing plain
Kerberos authentication (port 88). This means, in the absence of working
SPAKE exchange, there is still a potential for hijacking the initial
ticket issuance. We closed this down with the introduction of MS-KKDCP
compatible Kerberos proxy that is effectively an HTTPS-enforced
tunnelling on newer Fedora and RHEL 7.x versions. However, to enable
Kerberos for SSH logins it would be good to make sure we always use
secure method. SPAKE exchange in Kerberos would give that to us even for
plain Kerberos.

Another part of a story is that with FreeIPA 4.5 we have now PKINIT
support as well. E.g. one can associate a certificate with a user and
obtain Kerberos tickets based on the use of a smartcard. This is not
something Fedora Infra people are keen to use right now, primarily due
to management issues that certificate handling involved in past, but
this option is here.

Doing PKINIT in Kerberos enables another possibility: authentication
indicators can be associated with particular Fedora hosts to enforce
login with Kerberos to them only if your Kerberos ticket was obtained
using a stronger authentication method, like smartcards or one time
tokens (2FA). For 2FA-based setup we needed so-called Anonymous PKINIT
feature to enable a smooth way to get 2FA-based Kerberos tickets for
users on non-enrolled machines (all Fedora contributors because our
laptops/home machines aren't enrolled into FreeIPA realm of
FEDORAPROJECT.ORG).

These options are available now but we haven't discussed their use in
Fedora Infra context since deploying Kerberos. They also involve a
change at user's side, at least workflow-wise, to obtain a stronger
authenticate Kerberos tickets (although, with Anonymous PKINIT, it is
just one more kinit before the actual one). The latter can be seen as an
obstacle to more users than one could expect.


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

Re: OCaml / aarch64 / binutils / coq mess

[Jerry James]

On Wed, Sep 6, 2017 at 2:20 PM, Richard W.M. Jones  wrote:
> Nearly done it.  Unfortunately I updated ‘why’ to the latest upstream
> version (the previous one didn't know about OCaml 4.05), however that
> will require updating ‘frama-c’:
>
>   configure: WARNING: bad Frama-c version "Silicon-20161101", you need 
> version Phosphorus
>
> At that point I stopped.  Would you mind updating and rebuilding
> ‘frama-c’ and ‘why’ in both Rawhide and F27?

Yep.  That's why, earlier in this thread, I said:

BTW, most of the packages that sit on top of coq have new versions
available, so when this is fixed, I will want to update the other
packages anyway.  If you could let me know when a fix for this issue
is available, I will take care of building everything else.


I guess what I should have said was, "Don't rebuild anything that sits
on top of coq.  I'll take care of all of the builds since I have to do
some updates anyway."  Sorry for not being clearer.  I'll get those
updates done in the next day or two.  Thanks a lot for the aarch64 bug
fix.  I appreciate the work you put in on this.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org