[Test-Announce] 2018-04-02 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2018-04-02
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet for the last few weeks due to Beta work, so let's get
together and check in on where we're at.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 28 status
3. Test Day status
4. Criteria proposals
5. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] 2018-04-02 @ 16:00 UTC - Fedora 28 Blocker Review Meeting

[Adam Williamson]

# F28 Blocker Review meeting
# Date: 2018-04-02
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 3 proposed blockers and 4 proposed freeze exception
issues for Final to review, so let's have a review meeting on Monday.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F28 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Chris Murphy]

On Thu, Mar 29, 2018 at 6:16 PM, Adam Williamson
 wrote:
> On Thu, 2018-03-29 at 17:29 -0600, Chris Murphy wrote:
>> Short version:
>> I suggest setting the Live ISO size limit to 4GB (3.7GiB), and
>> including whatever fonts the g11n folks think a global operating
>> system should have. Alternatively, have Latin and Global Live media
>> but I think the download savings having two separate media is probably
>> outweighed by producing dual media.
>>
>>
>> Longer version:
>>
>> -rw-r-. 1 chris chris 4.1G Jul  2  2017  Win10_1703_English_x64.iso
>> -rw-r-. 1 chris chris 4.9G Nov 28 14:22 'macOS High Sierra.dmg'
>> -rw-rw-r--. 1 chris chris 1.8G Mar 28 15:21
>> Fedora-Workstation-Live-x86_64-28_Beta-1.1.iso
>> -rw-rw-r--. 1 chris chris 571M Mar 28 15:16
>> Fedora-Server-netinst-x86_64-28_Beta-1.1.iso
>> -rw-rw-r--. 1 chris chris 2.2G Mar 28 22:14
>> Fedora-AtomicWorkstation-ostree-x86_64-28_Beta-1.3.iso
>>
>> We're way lower than anyone else.
>
> ubuntu-17.10.1-desktop-amd64.iso  1.4G
> ubuntu-17.10.1-server-amd64.iso  754M

Yes the linux distros are all over the map, and it's not always
obvious how complete these ISOs really are. openSUSE has a 1.6G image
the isn't complete and downloads a bunch of additional stuff, where
their 4.3G image is a complete ISO. And the Endless ISO is 13G and is
very complete. But the point is that a 4GB installer size is not out
of the ordinary.



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

[Bug 1562274] New: perl-Unicode-LineBreak-2018.003 is available

[bugzilla]

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

Bug ID: 1562274
   Summary: perl-Unicode-LineBreak-2018.003 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Unicode-LineBreak
  Keywords: FutureFeature, Triaged
  Assignee: xav...@bachelot.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
xav...@bachelot.org



Latest upstream release: 2018.003
Current version/release in rawhide: 2017.004-8.fc29
URL: http://search.cpan.org/dist/Unicode-LineBreak/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6033/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Adam Williamson]

On Thu, 2018-03-29 at 17:29 -0600, Chris Murphy wrote:
> Short version:
> I suggest setting the Live ISO size limit to 4GB (3.7GiB), and
> including whatever fonts the g11n folks think a global operating
> system should have. Alternatively, have Latin and Global Live media
> but I think the download savings having two separate media is probably
> outweighed by producing dual media.
> 
> 
> Longer version:
> 
> -rw-r-. 1 chris chris 4.1G Jul  2  2017  Win10_1703_English_x64.iso
> -rw-r-. 1 chris chris 4.9G Nov 28 14:22 'macOS High Sierra.dmg'
> -rw-rw-r--. 1 chris chris 1.8G Mar 28 15:21
> Fedora-Workstation-Live-x86_64-28_Beta-1.1.iso
> -rw-rw-r--. 1 chris chris 571M Mar 28 15:16
> Fedora-Server-netinst-x86_64-28_Beta-1.1.iso
> -rw-rw-r--. 1 chris chris 2.2G Mar 28 22:14
> Fedora-AtomicWorkstation-ostree-x86_64-28_Beta-1.3.iso
> 
> We're way lower than anyone else.

ubuntu-17.10.1-desktop-amd64.iso  1.4G
ubuntu-17.10.1-server-amd64.iso  754M
-- 
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

[Bug 1562268] New: perl-IPC-Run-0.98 is available

[bugzilla]

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

Bug ID: 1562268
   Summary: perl-IPC-Run-0.98 is available
   Product: Fedora
   Version: rawhide
 Component: perl-IPC-Run
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org,
st...@silug.org



Latest upstream release: 0.98
Current version/release in rawhide: 0.97-1.fc29
URL: http://search.cpan.org/dist/IPC-Run

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/7128/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1562267] New: perl-Git-Wrapper-0.048 is available

[bugzilla]

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

Bug ID: 1562267
   Summary: perl-Git-Wrapper-0.048 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Git-Wrapper
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
ser...@serjux.com



Latest upstream release: 0.048
Current version/release in rawhide: 0.047-5.fc28
URL: http://search.cpan.org/dist/Git-Wrapper/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/12908/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Chris Murphy]

On Thu, Mar 29, 2018 at 5:29 PM, Chris Murphy  wrote:
> Short version:
> I suggest setting the Live ISO size limit to 4GB (3.7GiB), and
> including whatever fonts the g11n folks think a global operating
> system should have. Alternatively, have Latin and Global Live media
> but I think the download savings having two separate media is probably
> outweighed by producing dual media.

 ^effort of producing dual media


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

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Chris Murphy]

Short version:
I suggest setting the Live ISO size limit to 4GB (3.7GiB), and
including whatever fonts the g11n folks think a global operating
system should have. Alternatively, have Latin and Global Live media
but I think the download savings having two separate media is probably
outweighed by producing dual media.


Longer version:

-rw-r-. 1 chris chris 4.1G Jul  2  2017  Win10_1703_English_x64.iso
-rw-r-. 1 chris chris 4.9G Nov 28 14:22 'macOS High Sierra.dmg'
-rw-rw-r--. 1 chris chris 1.8G Mar 28 15:21
Fedora-Workstation-Live-x86_64-28_Beta-1.1.iso
-rw-rw-r--. 1 chris chris 571M Mar 28 15:16
Fedora-Server-netinst-x86_64-28_Beta-1.1.iso
-rw-rw-r--. 1 chris chris 2.2G Mar 28 22:14
Fedora-AtomicWorkstation-ostree-x86_64-28_Beta-1.3.iso

We're way lower than anyone else.

The only limitation I'm aware of is a 4GiB file size (single extent)
limit on ISO 9660 [1], which would apply to LiveOS/squashfs.img. That
file is 100MB smaller than the ISO file size, ergo 99+% of the ISO
size is this one file.

And the next USB stick size above 2GB is 4GB. Realistically they're
hard to find. I can find 8GB sticks easily, but they're far less
common than 16, 32 and even 64GB sticks and they don't cost much less
than a 16GB stick. So it's reasonable to make the Live ISO size set to
4G (or 3.7GiB) for now.

[1]
ISO 9660 Level 3 supports multi-extent files, which I think Linux
mkisofs and the kernel support, in which case the actual limit is
8TiB. There's also UDF. And since Fedora has dropped the release
blocking criterion for successful optical media creation, we're not
limited to these two choices.

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

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Adam Williamson]

On Thu, 2018-03-29 at 22:37 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > AIUI, this means it really only works for simplified Chinese users
> > (which means, approximately, mainland China; other Chinese-speaking
> > territories tend to use traditional Chinese).
> 
> AIUI, WQY MicroHei actually tries to cover the traditional-only,
> Japanese-only or Korean-only glyphs, too. According to 
> http://wenq.org/wqy2/index.cgi?action=browse=Home=en they cover the 
> whole GBK set and 80% of CJK Extension A. According to
> http://wenq.org/wqy2/index.cgi?MicroHei_BigBang_README the 2009 release 
> claimed support for 99% of Japanese, 100% of Korean, and 99% of Traditional 
> Chinese.
> 
> The main issue, as I was told, is those CJK Unified codepoints that are 
> normally rendered/drawn differently in the different countries, but were 
> unified into a single Unicode codepoint. I was told by the experts that WQY 
> MicorHei (like all WQY fonts) only contains one rendering (the Simplified 
> Chinese one) for those, and Wikipedia confirms it: 
> https://en.wikipedia.org/wiki/WenQuanYi#Glyph
> 
> So in short, if you point it to Traditional Chinese, Japanese or Korean 
> text, you should see SOME glyph for each character in the text. (I tested it 
> on the KDE Live image some time ago and I did not get the feared black 
> boxes.) But that glyph is not necessarily what a speaker of those languages 
> expects to see and might in some cases be hard or impossible for them to 
> read.

Thanks for the clarification. That does make the case more debatable.
-- 
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: F28 Self Contained Change: Stop building 389-ds-base on i686

[Mark Reynolds]

On 03/29/2018 04:45 PM, Florian Weimer wrote:
> On 03/29/2018 10:25 PM, Mark Reynolds wrote:
>> We can not back out the atomic work
>> because it's needed to address several issues in our server.

First of all, I updated the request wiki page to answer some of John's
questions.
>
> One thing that's still not clear to me: What happens on 32-bit
> architectures which do not have 64-bit atomics?  Are they buggy in a
> different way, and you used 64-bit atomics to address this because
> i686 is still the most important 32-bit architecture?
It's supposed to fallback to mutexes, but apparently it does not happen
on i686.  This is what the original engineer said.  For more background
the entire conversation is in
https://bugzilla.redhat.com/show_bug.cgi?id=1544386
>
> Looking at slapi_atomic_load_64 and slapi_atomic_incr_64, on the pure
> 32-bit architectures, you just use 32-bit counters instead of 64-bit
> counters.  So whatever problems you were trying to fix exist on armhfp
> as well, and if the 32-bit atomics aren't good enough, you have to
> exclude armhfp as well.
>
> Do you have a reproducer for the issues you are trying to fix?  
I believe it's our cmocka tests that occur at rpm package time that
brought this to our attention.  So it is easy to reproduce.
> I can try to put something together which uses a different type for
> 64-bit atomics which has the proper 8-byte alignment, which will
> eliminate the known cause of incorrect CAS results on i686.
I would love to test whatever you have!

Thanks,
Mark
>
> Thanks,
> Florian
> ___
> 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: F28 Self Contained Change: Stop building 389-ds-base on i686

[Florian Weimer]

On 03/29/2018 10:25 PM, Mark Reynolds wrote:

We can not back out the atomic work
because it's needed to address several issues in our server.


One thing that's still not clear to me: What happens on 32-bit 
architectures which do not have 64-bit atomics?  Are they buggy in a 
different way, and you used 64-bit atomics to address this because i686 
is still the most important 32-bit architecture?


Looking at slapi_atomic_load_64 and slapi_atomic_incr_64, on the pure 
32-bit architectures, you just use 32-bit counters instead of 64-bit 
counters.  So whatever problems you were trying to fix exist on armhfp 
as well, and if the 32-bit atomics aren't good enough, you have to 
exclude armhfp as well.


Do you have a reproducer for the issues you are trying to fix?  I can 
try to put something together which uses a different type for 64-bit 
atomics which has the proper 8-byte alignment, which will eliminate the 
known cause of incorrect CAS results on i686.


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

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Kevin Kofler]

Adam Williamson wrote:
> AIUI, this means it really only works for simplified Chinese users
> (which means, approximately, mainland China; other Chinese-speaking
> territories tend to use traditional Chinese).

AIUI, WQY MicroHei actually tries to cover the traditional-only,
Japanese-only or Korean-only glyphs, too. According to 
http://wenq.org/wqy2/index.cgi?action=browse=Home=en they cover the 
whole GBK set and 80% of CJK Extension A. According to
http://wenq.org/wqy2/index.cgi?MicroHei_BigBang_README the 2009 release 
claimed support for 99% of Japanese, 100% of Korean, and 99% of Traditional 
Chinese.

The main issue, as I was told, is those CJK Unified codepoints that are 
normally rendered/drawn differently in the different countries, but were 
unified into a single Unicode codepoint. I was told by the experts that WQY 
MicorHei (like all WQY fonts) only contains one rendering (the Simplified 
Chinese one) for those, and Wikipedia confirms it: 
https://en.wikipedia.org/wiki/WenQuanYi#Glyph

So in short, if you point it to Traditional Chinese, Japanese or Korean 
text, you should see SOME glyph for each character in the text. (I tested it 
on the KDE Live image some time ago and I did not get the feared black 
boxes.) But that glyph is not necessarily what a speaker of those languages 
expects to see and might in some cases be hard or impossible for them to 
read.

What also speaks against WQY MicroHei is that there has been no release 
since 2009.

The one thing that speaks for it is size: it is only ~4 MiB xz-compressed, 
whereas a typical font for any single CJK language (which may or may not 
have the same limited support as described above for the other 3 languages; 
often, there are no characters at all for the unsupported languages) is
20+ MiB xz-compressed. At the time where the decision to ship it on the KDE 
Spin was made, the choice was between WQY MicroHei or no CJK support at all.

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

[Bug 1553479] SElinux denials on stock install

[bugzilla]

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



--- Comment #9 from Emmanuel Seyman  ---
(In reply to Itamar Reis Peixoto from comment #8)
> 
> I think the correct thing todo is to retire bugzilla for el6 and el7 what do
> you think about ?

Bugzilla was never in el7 but, yes, it should be retired in el6.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Stop building 389-ds-base on i686

[Mark Reynolds]

On 03/28/2018 12:29 AM, John Reiser wrote:
> On 03/27/2018 14:17 UTC, Jan Kurik wrote:
>> = Proposed Self Contained Change: Stop building 389-ds-base on i686 =
>> https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
>>
>>
>> Owner(s):
>>    * Mark Reynolds 
>>
>>
>> 389-ds-base does not work properly on i686 hardware in regards to
>> atomic types.
>
> Please cite a technical description of the problem,
> such as a bugzilla report, blog post, etc.
> I'll believe it does not work, but I want to try to understand _why_.
The engineer who did "all" the work on this has just left Red Hat
unexpectedly, and with him goes all the details on this issue.  This is
very unfortunate timing, and it is quite frustrating.

All I know is that this a real problem for us that only occurs on i686. 
The previous DS engineer who worked on this insisted it's a bug in i686
arch, while the glibc team insisted it's a bug in our code.  Anyway here
we are.  We know that i686 fails in our tests consistently while on
other architectures it does not.  We can not back out the atomic work
because it's needed to address several issues in our server.  It also
does not make sense to back it out for a one-off architecture that is
not used downstream or by our customers.  So... I understand that there
is a major lack of detail in this case, and if it's insufficient to
officially exclude i686 then so be it.  But in that case is there way to
flag those i686 builds as "use at your risk/unstable"?


>
>> == Detailed description ==
>> 389-ds project have found an issue which causes system instability on
>> all versions of 1.4.x of the server on i686 platform. This is a
>> hardware limitation of the platform related to how we consume atomic
>> types. This may lead to thread unsafety and other issues.
>
> I would appreciate more details about "an issue which causes system
> instability".
>
>> * Release engineering:
>> #6894: https://pagure.io/releng/issues/6894
>
> That URL gets HTTP error 404 (page not found) as of just now
> (2018-03-28T0426).
> ___
> 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

[Bug 1553479] SElinux denials on stock install

[bugzilla]

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



--- Comment #8 from Itamar Reis Peixoto  ---
(In reply to Emmanuel Seyman from comment #7)
> A while back, the RPMFusion guys asked me to build a package for current
> Bugzilla for EPEL7. I couldn't do it without upgrading packages in base so
> went for the copr route.

I think the correct thing todo is to retire bugzilla for el6 and el7 what do
you think about ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

[Stephen John Smoogen]

On 29 March 2018 at 14:43, Rex Dieter  wrote:
> Sérgio Basto wrote:
>
>> On Tue, 2018-03-27 at 13:46 -0500, Rex Dieter wrote:
>>> Sérgio Basto wrote:
>>>
>>> > On Tue, 2018-03-27 at 11:53 -0500, Rex Dieter wrote:
>>> > > Sérgio Basto wrote:
>>> > >
>>> > > > On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
>>> > > > > Sérgio Basto wrote:
>>> > > > >
>>> > > > > > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
>>> > > > > > > I'd be ok with an epel7-only python3-sip
>>> > > > > > >
>>> > > > > > > Since it is a new package (not a branch of an existing
>>> > > > > > > one),
>>> > > > > > > then
>>> > > > > > > it
>>> > > > > > > would require a new package review.
>>> > > > > > >
>>> > > > > > > It would be a bit of shame though, having to fork things
>>> > > > > > > like
>>> > > > > > > that.
>>> > > > > >
>>> > > > > > I tried this solution (epel7-only python3-sip) but
>>> > > > > > BUILDSTDERR: Error: This version of PyQt5 requires sip
>>> > > > > > 4.19.4
>>> > > > > > or
>>> > > > > > later.
>>> > > > > > when el7 have  sip-devel  x86_64 4.14.6-
>>> > > > > > 4.el7 base
>>> > > > > >
>>> > > > > > if we do package sip-qt5 we must override
>>> > > > > > /usr/lib64/python2.7/site-
>>> > > > > > packages/sip.so
>>> > > > > > it is possible sip-qt5 provides and obsolete sip (4.14.6-
>>> > > > > > 4.el7)
>>> > > > > > ?
>>> > > > >
>>> > > > > Not possible (by policy).  It should be able to work without
>>> > > > > doing
>>> > > > > that, but
>>> > > > > it may require patching.
>>> > > >
>>> > > > I don't see how. In python2, how "import sip" will work ?
>>> > > > "import
>>> > > > sip-qt5
>>> > > > as sip" ?
>>> > >
>>> > > I thought the context here was your desire to add *only python3*
>>> > > sip/python-
>>> > > qt5 to epel ?
>>> >
>>> > That was if pyhton2-sip was enough , but sip 4.14.6 is not enough
>>> > for
>>> > python2-qt5-devel ...
>>> >
>>> > But thinking, we might only build python3-qt5 ?  ok,  let me review
>>> > this again , seems enough for my openshot and subdownloader 
>>>
>>> Yes, that's really the only viable option here, to do *only* python3-
>>> sip and
>>> python3-qt5
>>
>> Done, sip :
>>
> https://src.fedoraproject.org/fork/sergiomb/rpms/sip/c/84b5266e6d36d6e20c23bafe4da429fa0b98e0de?branch=master
>>
>> and python3-qt5:
>> https://src.fedoraproject.org/fork/sergiomb/rpms/python-qt5/commits/master
>>
>>
>> As a note python34-sip-devel and sip-devel (pyhton2 version) can't be
>> installed at same time [1] but it is correct, we can only have one
>> macros.sip in the system , is it a problem ? So can we do branches of sip
>> and python-qt5 for epel-7 using the same packages but just build python3
>> part ?
>
> Someone correct me if I'm wrong, but I think that's not allowed by policy.
> The base package names (the src.rpm used to produce these) would conflict
> with that of core rhel packages.  If that's true, then we'll need new
> packages with non-conflicting names, using something like:
> python3-sip
> python3-qt5
>
>

Yes. I believe this will cause problems with how koji builds packages
and decides what will be used in buildchains for any related packages.


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



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

[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

[Rex Dieter]

Sérgio Basto wrote:

> On Tue, 2018-03-27 at 13:46 -0500, Rex Dieter wrote:
>> Sérgio Basto wrote:
>> 
>> > On Tue, 2018-03-27 at 11:53 -0500, Rex Dieter wrote:
>> > > Sérgio Basto wrote:
>> > > 
>> > > > On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
>> > > > > Sérgio Basto wrote:
>> > > > > 
>> > > > > > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
>> > > > > > > I'd be ok with an epel7-only python3-sip
>> > > > > > > 
>> > > > > > > Since it is a new package (not a branch of an existing
>> > > > > > > one),
>> > > > > > > then
>> > > > > > > it
>> > > > > > > would require a new package review.
>> > > > > > > 
>> > > > > > > It would be a bit of shame though, having to fork things
>> > > > > > > like
>> > > > > > > that.
>> > > > > > 
>> > > > > > I tried this solution (epel7-only python3-sip) but
>> > > > > > BUILDSTDERR: Error: This version of PyQt5 requires sip
>> > > > > > 4.19.4
>> > > > > > or
>> > > > > > later.
>> > > > > > when el7 have  sip-devel  x86_64 4.14.6-
>> > > > > > 4.el7 base
>> > > > > > 
>> > > > > > if we do package sip-qt5 we must override
>> > > > > > /usr/lib64/python2.7/site-
>> > > > > > packages/sip.so
>> > > > > > it is possible sip-qt5 provides and obsolete sip (4.14.6-
>> > > > > > 4.el7)
>> > > > > > ?
>> > > > > 
>> > > > > Not possible (by policy).  It should be able to work without
>> > > > > doing
>> > > > > that, but
>> > > > > it may require patching.
>> > > > 
>> > > > I don't see how. In python2, how "import sip" will work ?
>> > > > "import
>> > > > sip-qt5
>> > > > as sip" ?
>> > > 
>> > > I thought the context here was your desire to add *only python3*
>> > > sip/python-
>> > > qt5 to epel ?
>> > 
>> > That was if pyhton2-sip was enough , but sip 4.14.6 is not enough
>> > for
>> > python2-qt5-devel ...
>> > 
>> > But thinking, we might only build python3-qt5 ?  ok,  let me review
>> > this again , seems enough for my openshot and subdownloader 
>> 
>> Yes, that's really the only viable option here, to do *only* python3-
>> sip and
>> python3-qt5
> 
> Done, sip :
> 
https://src.fedoraproject.org/fork/sergiomb/rpms/sip/c/84b5266e6d36d6e20c23bafe4da429fa0b98e0de?branch=master
> 
> and python3-qt5:
> https://src.fedoraproject.org/fork/sergiomb/rpms/python-qt5/commits/master
> 
> 
> As a note python34-sip-devel and sip-devel (pyhton2 version) can't be
> installed at same time [1] but it is correct, we can only have one
> macros.sip in the system , is it a problem ? So can we do branches of sip
> and python-qt5 for epel-7 using the same packages but just build python3
> part ?

Someone correct me if I'm wrong, but I think that's not allowed by policy.  
The base package names (the src.rpm used to produce these) would conflict 
with that of core rhel packages.  If that's true, then we'll need new 
packages with non-conflicting names, using something like:
python3-sip
python3-qt5


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

Re: Fedora 28 Beta status is GO, release on April 03, 2018

[Adam Williamson]

On Thu, 2018-03-29 at 17:35 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Mar 29, 2018 at 07:18:32PM +0200, Jan Kurik wrote:
> > The Fedora 28 Beta RC3 compose [1] is considered as GOLD and is going to be
> > shipped live on Tuesday, April 3rd, 2018.
> > 
> > For more information please check the Go/No-Go meeting minutes [2] or logs
> > [3].
> > 
> > I would like to thank all the people who were and are still working on this
> > release.
> > 
> > [1] http://dl.fedoraproject.org/pub/alt/stage/28_Beta-1.3/
> 
> FWIW, I tested installation/deinstallation/upgrade of packages to
> exercise systemd transfiletriggers in 28_Beta-1.3/, and they seems to
> work fine. The decision to use 1.3 instead of 1.1 is right imho.

Thanks a lot for doing that, Zbigniew.
-- 
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

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Perl-Tidy-Sweetened-1.14-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9a9149f55f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561806] perl-HTTP-Message-6.16 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-HTTP-Message-6.16-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2f3b35e7cb

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561800] perl-Config-Model-Tester-3.004 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Config-Model-Tester-3.004-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b39d981933

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora 28 Beta status is GO, release on April 03, 2018

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 29, 2018 at 07:18:32PM +0200, Jan Kurik wrote:
> The Fedora 28 Beta RC3 compose [1] is considered as GOLD and is going to be
> shipped live on Tuesday, April 3rd, 2018.
> 
> For more information please check the Go/No-Go meeting minutes [2] or logs
> [3].
> 
> I would like to thank all the people who were and are still working on this
> release.
> 
> [1] http://dl.fedoraproject.org/pub/alt/stage/28_Beta-1.3/
FWIW, I tested installation/deinstallation/upgrade of packages to
exercise systemd transfiletriggers in 28_Beta-1.3/, and they seems to
work fine. The decision to use 1.3 instead of 1.1 is right imho.

Zbyszek

> [2]
> https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.html
> 
> [3]
> https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.log.html
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Beta status is GO, release on April 03, 2018

[Jan Kurik]

The Fedora 28 Beta RC3 compose [1] is considered as GOLD and is going to be
shipped live on Tuesday, April 3rd, 2018.

For more information please check the Go/No-Go meeting minutes [2] or logs
[3].

I would like to thank all the people who were and are still working on this
release.

[1] http://dl.fedoraproject.org/pub/alt/stage/28_Beta-1.3/
[2]
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.html

[3]
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.log.html


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

Re: [games-sig] Re: Can we revise the games packaging guidelines wiki page?

[Justin W. Flory]

On 03/28/2018 02:21 PM, Michael Thomas wrote:
> On 3/28/18 1:17 PM, Artur Iwicki wrote:
>> I took a look at "SIG/Games/Packaging" page [1] on the Fedora wiki, and it 
>> seems to be quite old - the revision history says the last edit was made in 
>> May 2008, which places it at close to 10 years old.
>> Could we possibly revise the packaging guidelines to make sure they don't 
>> contradict the general guidelines - and if they do, have a clear "yes, this 
>> contradicts the main guidelines, do it either way" message?
> 
> I'd be happy to make any changes needed if folks point them out.
> 

I am +1 to making modern revisions to this SIG's guidelines, but I am
unable to offer much technical insight for these changes.

In May 2008, Windows XP / Vista were in wide use, Steam was not yet in
the eye of the mainstream gaming world, and Fedora was approaching five
years old. A lot of things in technology, gaming, and Fedora have
changed since May 2008. :-)

The best way to move forward, as I see it, is to draft proposed /
revised changes. If you have a draft with proposed changes, it is easier
to collect feedback on those changes. I am not much of a packager, so I
cannot contribute much technical insight. However, I am happy to help
gather feedback and formally adopt any new guidelines, once a draft is
ready.

-- 
Cheers,
Justin W. Flory
jflo...@gmail.com



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

Fedora 28 Beta status is GO, release on April 03, 2018

[Jan Kurik]

The Fedora 28 Beta RC3 compose [1] is considered as GOLD and is going to be
shipped live on Tuesday, April 3rd, 2018.

For more information please check the Go/No-Go meeting minutes [2] or logs
[3].

I would like to thank all the people who were and are still working on this
release.

[1] http://dl.fedoraproject.org/pub/alt/stage/28_Beta-1.3/
[2]
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.html

[3]
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.log.html


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

Re: F28 Self Contained Change: Stop building 389-ds-base on i686

[Stephen John Smoogen]

On 29 March 2018 at 07:00, Tomasz Torcz  wrote:
> March 29, 2018 12:06 PM, "Peter Robinson"  wrote:
>
>> On Thu, 29 Mar 2018, 16:24 Florian Weimer,  wrote:
>>
>>> On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
>>>
> Note that while GCC produces broken code, this is actually an ABI bug, and
> we cannot change struct layout rules for long long retroactively. Maybe we
> could for _Atomic long long, but that would need a lengthy investigation,
> and I strongly believe that everyone is better off if the time is spent on
> improving 64-bit architectures.

 Does it mean that the bug was here for the last 23 years? And now this
 became a problem?
>>>
>>> I'm not sure how you came up with the duration. The bug is most
>>> certainly much younger than that, probably introduced along with the new
>>> atomic intrinsics in a late GCC 4.8.x release. Arguably, it is a real
>>> bug only for _Atomic long long members.
>>
>> Probably referring to the age of the 389-ds code base which dates all the 
>> way back to Netscape
>> Directory Server
>
>  i686 become available in 1995. The bug in 389ds is serious enough to condemn 
> the whole
> architecture, so what exactly happened?
> 1) 389ds was always broken on i686 (and no-one noticed that before?)
> 2) there was some code added to 389ds later, code which triggered the bug? 
> (could it be reverted then?)
> 3) there was code added to toolchain (GCC) which started producing broken 
> code in 389? (could the change in GCC be reverted/ repaired?)
> 4) … ?
>
>   Don't get me wrong, I'm not defending i686, it should have been relegated 
> to the museum long ago. But I feel uneasy when there is some bug marking the 
> whole architecture as broken. We were running GCC-compiled 389ds on i686 for 
> years, does it mean we trusted broken code to manage our identity?

My understanding is that the code was rearchitected to use atomic 64
features to avoid deadlocks, corruptions and other things that atomics
are meant to avoid. To undo it would be to revert N months of work and
probably reintroduce whatever 'flaws' that the atomic functions
remove.

On the other hand, it may be that the atomics aren't implemented
correctly on anything but 64 bit architectures (aka they work by luck
on arm32 versus design) so it isn't just i386 which is problematic...
it is just the one it shows up on loudly. [This seems to be what the
gcc maintainers have said.. that unless you force alignment on
specific boundaries you are in undefined behavior]

So to me this isn't as much about i686 being problematic. It is that
32 bit needs to be looked at and most code which is using 64 bit
atomics in 32 bit may need to excludearch to 64 bit only.


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



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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1116  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 879  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 461  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 358  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 190  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 127  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f41541339   
monitorix-3.10.1-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ae3a1eae7e   
glpi-0.90.5-2.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-add4fc19d8   
mosquitto-1.4.15-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1fbdf7f103   
chromium-65.0.3325.181-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-86171fce03   
python-paramiko-2.1.1-0.4.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

drupal7-7.58-1.el7
firefox-pkcs11-loader-3.13.0-7.el7
rho-0.0.33-1.el7
webextension-token-signing-1.0.6-5.el7

Details about builds:



 drupal7-7.58-1.el7 (FEDORA-EPEL-2018-2074629ed3)
 An open-source content-management platform

Update Information:

- https://www.drupal.org/SA-CORE-2018-002 - https://www.drupal.org/SA-
CORE-2018-001

References:

  [ 1 ] Bug #1548323 - CVE-2017-6926 CVE-2017-6927 CVE-2017-6928 CVE-2017-6929 
CVE-2017-6930 CVE-2017-6931 CVE-2017-6932 drupal: Multiple vulnerabilities 
fixed in 7.57 and 8.4.5 (SA-CORE-2018-001)
https://bugzilla.redhat.com/show_bug.cgi?id=1548323




 firefox-pkcs11-loader-3.13.0-7.el7 (FEDORA-EPEL-2018-bf99c257e1)
 Helper script for Firefox that sets up the browser for authentication with 
Estonian ID-card

Update Information:

removed Requires: esteidcerts    3.13.0 release




 rho-0.0.33-1.el7 (FEDORA-EPEL-2018-191a89bd01)
 An SSH system profiler

Update Information:

# Testing Rho  To set up Rho, you create profiles that control how to run each
scan. - Authentication profiles contain user credentials for a user with
sufficient authority to complete the scan (for example, a root user or one with
root-level access obtained through -sudo privilege escalation). - Network
profiles contain network identifiers (for example, a hostname, IP address, or
range of IP addresses) and the authentication profiles to be used for a scan.
Complete the following steps, repeating them as necessary to access all parts of
your environment that you want to scan: 1. Create at least one authentication
profile with root-level access to Rho: ``` rho auth add --name auth_name
--username root_name(--sshkeyfile key_file | --password) ```  a. At the Rho
vault password prompt, create a new Rho vault password. This password is
required to access the encrypted Rho data, such as authentication and network
profiles, scan data, and other information.  b. If you did not use the
sshkeyfile option to provide an SSH key for the username value, enter the
password of the user with root-level access at the connection password prompt.
For example, for an authentication profile where the authentication profile name
is roothost1, the user with root-level access is root, and the SSH key for the
user is in the path ~/.ssh/id_rsa, you would enter the following command: ```
rho auth add --name roothost1 --username root --sshkeyfile ~/.ssh/id_rsa ``` You
can also use the sudo-password option to create an authentication profile for a
user with root-level access who requires a password to obtain this privilege.
You can use the sudo-password option with either the sshkeyfile or the password
option. For example, for an authentication profile where the authentication
profile name is sudouser1, the user with root-level access is sysadmin, and the
access is obtained through the password option, you would enter the following
command: ``` rho auth add --name sudouser1 --username sysadmin --password
--sudo-password ```  After you enter this command, 

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 989  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 879  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 850  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 461  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 190  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
 109  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  81  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-10ff026fa8   
monitorix-3.10.1-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f5cd94db4e   
tomcat-7.0.85-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a67ea8c563   
golang-1.9.4-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

drupal7-7.58-1.el6
rho-0.0.33-1.el6

Details about builds:



 drupal7-7.58-1.el6 (FEDORA-EPEL-2018-e4e96fbf3f)
 An open-source content-management platform

Update Information:

- https://www.drupal.org/SA-CORE-2018-002 - https://www.drupal.org/SA-
CORE-2018-001

References:

  [ 1 ] Bug #1548190 - drupal7: drupal: JavaScript cross-site scripting in 
checkPlain function [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548190
  [ 2 ] Bug #1547793 - drupal7-7.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1547793
  [ 3 ] Bug #1548324 - CVE-2017-6926 CVE-2017-6927 CVE-2017-6928 CVE-2017-6929 
CVE-2017-6930 CVE-2017-6931 CVE-2017-6932 drupal7: drupal: Multiple 
vulnerabilities fixed in 7.57 and 8.4.5 (SA-CORE-2018-001) [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548324
  [ 4 ] Bug #1548201 - drupal7: drupal: External link injection on 404 pages 
when linking to the current page [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548201
  [ 5 ] Bug #1548197 - drupal7: drupal: jQuery vulnerability with untrusted 
domains requests via Ajax [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548197
  [ 6 ] Bug #1548195 - drupal7: drupal: Private file access bypass in Drupal 
private file system [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548195
  [ 7 ] Bug #1561801 - drupal7-7.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1561801
  [ 8 ] Bug #1548191 - drupal7: drupal: JavaScript cross-site scripting in 
checkPlain function [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548191
  [ 9 ] Bug #1548326 - CVE-2017-6926 CVE-2017-6927 CVE-2017-6928 CVE-2017-6929 
CVE-2017-6930 CVE-2017-6931 CVE-2017-6932 drupal7: drupal: Multiple 
vulnerabilities fixed in 7.57 and 8.4.5 (SA-CORE-2018-001) [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548326
  [ 10 ] Bug #1548202 - drupal7: drupal: External link injection on 404 pages 
when linking to the current page [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548202
  [ 11 ] Bug #1548198 - drupal7: drupal: jQuery vulnerability with untrusted 
domains requests via Ajax [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548198
  [ 12 ] Bug #1548194 - drupal7: drupal: Private file access bypass in Drupal 
private file system [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1548194




 rho-0.0.33-1.el6 (FEDORA-EPEL-2018-6b3e536911)
 An SSH system profiler

Update Information:

# Testing Rho  To set up Rho, you create profiles that control how to run each
scan. - Authentication profiles contain user credentials for a user with
sufficient authority to complete the scan (for example, a root user or one with
root-level access obtained through -sudo privilege escalation). - Network
profiles contain network identifiers (for example, a hostname, IP address, or
range of IP addresses) and the authentication profiles to be used for a scan.
Complete the following steps, repeating them as necessary to access all parts of
your environment that you want to scan: 1. Create at least one authentication
profile with root-level access to Rho: ``` rho auth add --name auth_name
--username root_name(--sshkeyfile key_file | --password) ```  a. At the Rho
vault password prompt, create a new Rho vault password. This 

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Owen Taylor]

It sounds like what we are doing is shipping the "regional subset" fonts
for all 4 CJK scripts. I wonder if we would do better to ship one unified
font - I believe that at least with the GNOME stack, the rendered results
will be equivalent, since Pango+Harfbuzz should set appropriate 'locl' tags
(https://www.google.com/get/noto/help/cjk/).

Investigation would be required:
 * Am I right about GNOME?
 * Do you also get the right behavior under Qt, LibreOffice, Web browsers -
they use harfbuzz, but do they set locl tags based on $LANG?
 * How much smaller is this
 * What if the user wants to get Korean fonts in LibreOffice with
$LANG=ja_JP, or whatever?

But there would be an issue that in a font list the font would probably
show up with a name that sounds language specific, which is bad.

Could also investigate whether installing the fonts in TTC form is broadly
enough supported in the different rendering stacks and whether it gives
space saving.

I do think we need to ship enough fonts to get the user through GDM and
gnome-initial-setup to render correctly for major languages, but if we want
to start installing additional weights/style variants after installation,
there's a related issue at:

 https://pagure.io/fedora-workstation/issue/27

Owen


On Thu, Mar 29, 2018 at 12:06 PM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Thu, 2018-03-29 at 15:57 +, Stephen Gallagher wrote:
> > On Thu, Mar 29, 2018 at 10:12 AM Kevin Kofler 
> > wrote:
> >
> > > Hi,
> > >
> > > we did more debugging on #fedora-kde (thanks in particular to lupinix)
> and
> > > we found what seems to be the primary source of the bloat: CJK fonts!
> > >
> > > CJK fonts are by far the largest of all fonts due to the huge number of
> > > characters used in those languages.
> > >
> > > Up to Fedora 26, Fedora shipped 4 CJK fonts:
> > >> > type="default">adobe-source-han-sans-cn-fonts
> > >> > type="default">adobe-source-han-sans-tw-fonts
> > >   naver-nanum-gothic-fonts
> > >   vlgothic-fonts
> > > The KDE and LXQt Spins actually opted to blacklist these fonts in their
> > > kickstart, and ship one compact CJK font instead: wqy-microhei-fonts.
> > >
> > > In Fedora 27, this Change:
> > > https://fedoraproject.org/wiki/Changes/ChineseSerifFonts
> > > added 2 additional fonts (for a total of 6):
> > >> > type="default">adobe-source-han-serif-cn-fonts
> > >> > type="default">adobe-source-han-serif-tw-fonts
> > > which were unfortunately missing from the blacklist:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> > > already increasing the size of the image.
> > >
> > > But now in Fedora 28, after:
> > > https://fedoraproject.org/wiki/Changes/JPDefaultFontsToNoto
> > > https://fedoraproject.org/wiki/Changes/KRDefaultFontsToNoto
> > > https://fedoraproject.org/wiki/Changes/ChineseDefaultFontsToNoto
> > > we actually ship a whopping 12 CJK fonts:
> > >   google-noto-
> sans-jp-fonts
> > >   google-noto-
> sans-kr-fonts
> > >> > type="default">google-noto-sans-mono-cjk-jp-fonts
> > >> > type="default">google-noto-sans-mono-cjk-kr-fonts
> > >> > type="default">google-noto-sans-mono-cjk-sc-fonts
> > >> > type="default">google-noto-sans-mono-cjk-tc-fonts
> > >   google-noto-
> sans-sc-fonts
> > >   google-noto-
> sans-tc-fonts
> > >   google-noto-
> serif-jp-fonts
> > >   google-noto-
> serif-kr-fonts
> > >   google-noto-
> serif-sc-fonts
> > >   google-noto-
> serif-tc-fonts
> > > none of which are blacklisted in the Spins! According to lupinix, these
> > > amount to a download size (and thus an xz-compressed size, which is
> also
> > > the
> > > compression algorithm used for the live images) of 364 MiB!
> > >
> > > The fix is to update the blacklists in the KDE and LXQt spin
> kickstarts, as
> > > per the discussion under:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> > > IMHO, this needs to be implemented, urgently.
> > >
> > > But I think we also need to generally consider whether it makes sense
> to
> > > force 3 font variants for each CJK language on all users worldwide, and
> > > whether there are smaller fonts that could be used. (E.g.,
> > > wqy-microhei-fonts is very effective, but unfortunately it only covers
> > > Simplified Chinese and the syllabic parts of Japanese and Korean, not
> the
> > > Traditional Chinese, Japanese or Korean renderings of the CJK Unified
> > > Ideographs.)
> > >
> > >
> >
> > Kevin, thanks for the investigation and the detailed analysis. Great work
> > tracking this down!
> >
> > I think our font strategy is a bit complicated, because we do strive to
> be
> > an international distribution, but I feel like there must be better ways
> to
> > accomplish this goal than to simply install all possible fonts by
> default.
>
> Well, I don't think this really is "all possible fonts". Just looking
> at the list, one obvious improvement is that there now 

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Perl-Tidy-Sweetened-1.14-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-bb6f917f6c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Stop building 389-ds-base on i686

[Tomasz Torcz]

March 29, 2018 12:06 PM, "Peter Robinson"  wrote:

> On Thu, 29 Mar 2018, 16:24 Florian Weimer,  wrote:
> 
>> On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
>> 
 Note that while GCC produces broken code, this is actually an ABI bug, and
 we cannot change struct layout rules for long long retroactively. Maybe we
 could for _Atomic long long, but that would need a lengthy investigation,
 and I strongly believe that everyone is better off if the time is spent on
 improving 64-bit architectures.
>>> 
>>> Does it mean that the bug was here for the last 23 years? And now this
>>> became a problem?
>> 
>> I'm not sure how you came up with the duration. The bug is most
>> certainly much younger than that, probably introduced along with the new
>> atomic intrinsics in a late GCC 4.8.x release. Arguably, it is a real
>> bug only for _Atomic long long members.
> 
> Probably referring to the age of the 389-ds code base which dates all the way 
> back to Netscape
> Directory Server

 i686 become available in 1995. The bug in 389ds is serious enough to condemn 
the whole
architecture, so what exactly happened?
1) 389ds was always broken on i686 (and no-one noticed that before?)
2) there was some code added to 389ds later, code which triggered the bug? 
(could it be reverted then?)
3) there was code added to toolchain (GCC) which started producing broken code 
in 389? (could the change in GCC be reverted/ repaired?)
4) … ?

  Don't get me wrong, I'm not defending i686, it should have been relegated to 
the museum long ago. But I feel uneasy when there is some bug marking the whole 
architecture as broken. We were running GCC-compiled 389ds on i686 for years, 
does it mean we trusted broken code to manage our identity?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Adam Williamson]

On Thu, 2018-03-29 at 16:12 +0200, Kevin Kofler wrote:
> wqy-microhei-fonts is very effective, but unfortunately it only covers
> Simplified Chinese and the syllabic parts of Japanese and Korean, not the
> Traditional Chinese, Japanese or Korean renderings of the CJK Unified
> Ideographs.)

AIUI, this means it really only works for simplified Chinese users
(which means, approximately, mainland China; other Chinese-speaking
territories tend to use traditional Chinese).

Simplified Chinese is a subset of traditional Chinese, so many
characters needed to render TC properly will be missing entirely from
it. Korean is technically related but in practice is really an entirely
different character set; AIUI being able to read Korean does not mean
you'd be able to read the 'equivalent' Chinese characters at all. You
couldn't just render a Korean text with Chinese ideographs in place of
the Korean ones and expect it to be at all OK for Korean readers.

Japanese ideographs are a subset of traditional Chinese too, but a
*different* subset. AIUI it's a smaller subset but includes some
characters that simplified Chinese doesn't include, so a simplified
Chinese font would again be missing some needed characters for full
Japanese rendering.

(Note on 'syllabic' vs. 'ideographic': Japanese and Korean have both
alphabet(s) for phonetic/syllabic rendering of words, like Latin, and
much larger alphabets of ideographic characters. We don't need to go
into the reasons for this or when one is used vs. the others; all
that's important is that any practical use of written Japanese and
Korean is going to involve the ideographic characters, so a font which
doesn't cover the ideographic characters is entirely insufficient).

So calling it a 'CJK' font is, well, stretching the point quite a lot.
;) It's really a mainland Chinese font, nothing more. Again, AIUI; it
would really be best to speak to the experts.
-- 
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

[Bug 1558293] perl-Test-Harness-3.42 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Test-Harness-3.42-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1558274] perl-App-find2perl-1.004 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-App-find2perl-1.004-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Adam Williamson]

On Thu, 2018-03-29 at 15:57 +, Stephen Gallagher wrote:
> On Thu, Mar 29, 2018 at 10:12 AM Kevin Kofler 
> wrote:
> 
> > Hi,
> > 
> > we did more debugging on #fedora-kde (thanks in particular to lupinix) and
> > we found what seems to be the primary source of the bloat: CJK fonts!
> > 
> > CJK fonts are by far the largest of all fonts due to the huge number of
> > characters used in those languages.
> > 
> > Up to Fedora 26, Fedora shipped 4 CJK fonts:
> >> type="default">adobe-source-han-sans-cn-fonts
> >> type="default">adobe-source-han-sans-tw-fonts
> >   naver-nanum-gothic-fonts
> >   vlgothic-fonts
> > The KDE and LXQt Spins actually opted to blacklist these fonts in their
> > kickstart, and ship one compact CJK font instead: wqy-microhei-fonts.
> > 
> > In Fedora 27, this Change:
> > https://fedoraproject.org/wiki/Changes/ChineseSerifFonts
> > added 2 additional fonts (for a total of 6):
> >> type="default">adobe-source-han-serif-cn-fonts
> >> type="default">adobe-source-han-serif-tw-fonts
> > which were unfortunately missing from the blacklist:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> > already increasing the size of the image.
> > 
> > But now in Fedora 28, after:
> > https://fedoraproject.org/wiki/Changes/JPDefaultFontsToNoto
> > https://fedoraproject.org/wiki/Changes/KRDefaultFontsToNoto
> > https://fedoraproject.org/wiki/Changes/ChineseDefaultFontsToNoto
> > we actually ship a whopping 12 CJK fonts:
> >   google-noto-sans-jp-fonts
> >   google-noto-sans-kr-fonts
> >> type="default">google-noto-sans-mono-cjk-jp-fonts
> >> type="default">google-noto-sans-mono-cjk-kr-fonts
> >> type="default">google-noto-sans-mono-cjk-sc-fonts
> >> type="default">google-noto-sans-mono-cjk-tc-fonts
> >   google-noto-sans-sc-fonts
> >   google-noto-sans-tc-fonts
> >   google-noto-serif-jp-fonts
> >   google-noto-serif-kr-fonts
> >   google-noto-serif-sc-fonts
> >   google-noto-serif-tc-fonts
> > none of which are blacklisted in the Spins! According to lupinix, these
> > amount to a download size (and thus an xz-compressed size, which is also
> > the
> > compression algorithm used for the live images) of 364 MiB!
> > 
> > The fix is to update the blacklists in the KDE and LXQt spin kickstarts, as
> > per the discussion under:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> > IMHO, this needs to be implemented, urgently.
> > 
> > But I think we also need to generally consider whether it makes sense to
> > force 3 font variants for each CJK language on all users worldwide, and
> > whether there are smaller fonts that could be used. (E.g.,
> > wqy-microhei-fonts is very effective, but unfortunately it only covers
> > Simplified Chinese and the syllabic parts of Japanese and Korean, not the
> > Traditional Chinese, Japanese or Korean renderings of the CJK Unified
> > Ideographs.)
> > 
> > 
> 
> Kevin, thanks for the investigation and the detailed analysis. Great work
> tracking this down!
> 
> I think our font strategy is a bit complicated, because we do strive to be
> an international distribution, but I feel like there must be better ways to
> accomplish this goal than to simply install all possible fonts by default.

Well, I don't think this really is "all possible fonts". Just looking
at the list, one obvious improvement is that there now appear to be
sans, serif, and monospace fonts, whereas before there was only sans.
Would we ship images without serif and monospace fonts for Latin?

For those wondering what the other factors here are: 'jp' is Japanese,
'kr' is Korean, 'sc' is Simplified Chinese and 'tc' is Traditional
Chinese. We could go more into the details on the relationships between
them and why we might need different fonts for them all, but I think
what we really ought to do is go to the actual experts here - the g11n
teams, and specifically CJK specialists on those teams - explain the
problem, and see what they recommend as the best way forward to provide
an acceptable experience for CJK users of our images while keeping
sizes reasonable.

> I know that for GNOME at least, there's some PackageKit integration that
> allows users to be prompted to install fonts as-needed (though it also
> seems to trigger whenever I accidentally `cat` a binary file in the
> terminal :-) ). Perhaps we can look into finding a desktop-agnostic way of
> doing this and then limit our installed fonts to only a few minimal ones
> based on the language selected in Anaconda?

The obvious problem here is *live* images, though. I'd say we want the
live environment to be practical for CJK users without them having to
do large downloads and installs that, in the live environment, will eat
up RAM...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Stephen Gallagher]

On Thu, Mar 29, 2018 at 10:12 AM Kevin Kofler 
wrote:

> Hi,
>
> we did more debugging on #fedora-kde (thanks in particular to lupinix) and
> we found what seems to be the primary source of the bloat: CJK fonts!
>
> CJK fonts are by far the largest of all fonts due to the huge number of
> characters used in those languages.
>
> Up to Fedora 26, Fedora shipped 4 CJK fonts:
>type="default">adobe-source-han-sans-cn-fonts
>type="default">adobe-source-han-sans-tw-fonts
>   naver-nanum-gothic-fonts
>   vlgothic-fonts
> The KDE and LXQt Spins actually opted to blacklist these fonts in their
> kickstart, and ship one compact CJK font instead: wqy-microhei-fonts.
>
> In Fedora 27, this Change:
> https://fedoraproject.org/wiki/Changes/ChineseSerifFonts
> added 2 additional fonts (for a total of 6):
>type="default">adobe-source-han-serif-cn-fonts
>type="default">adobe-source-han-serif-tw-fonts
> which were unfortunately missing from the blacklist:
> https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> already increasing the size of the image.
>
> But now in Fedora 28, after:
> https://fedoraproject.org/wiki/Changes/JPDefaultFontsToNoto
> https://fedoraproject.org/wiki/Changes/KRDefaultFontsToNoto
> https://fedoraproject.org/wiki/Changes/ChineseDefaultFontsToNoto
> we actually ship a whopping 12 CJK fonts:
>   google-noto-sans-jp-fonts
>   google-noto-sans-kr-fonts
>type="default">google-noto-sans-mono-cjk-jp-fonts
>type="default">google-noto-sans-mono-cjk-kr-fonts
>type="default">google-noto-sans-mono-cjk-sc-fonts
>type="default">google-noto-sans-mono-cjk-tc-fonts
>   google-noto-sans-sc-fonts
>   google-noto-sans-tc-fonts
>   google-noto-serif-jp-fonts
>   google-noto-serif-kr-fonts
>   google-noto-serif-sc-fonts
>   google-noto-serif-tc-fonts
> none of which are blacklisted in the Spins! According to lupinix, these
> amount to a download size (and thus an xz-compressed size, which is also
> the
> compression algorithm used for the live images) of 364 MiB!
>
> The fix is to update the blacklists in the KDE and LXQt spin kickstarts, as
> per the discussion under:
> https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> IMHO, this needs to be implemented, urgently.
>
> But I think we also need to generally consider whether it makes sense to
> force 3 font variants for each CJK language on all users worldwide, and
> whether there are smaller fonts that could be used. (E.g.,
> wqy-microhei-fonts is very effective, but unfortunately it only covers
> Simplified Chinese and the syllabic parts of Japanese and Korean, not the
> Traditional Chinese, Japanese or Korean renderings of the CJK Unified
> Ideographs.)
>
>
Kevin, thanks for the investigation and the detailed analysis. Great work
tracking this down!

I think our font strategy is a bit complicated, because we do strive to be
an international distribution, but I feel like there must be better ways to
accomplish this goal than to simply install all possible fonts by default.
I know that for GNOME at least, there's some PackageKit integration that
allows users to be prompted to install fonts as-needed (though it also
seems to trigger whenever I accidentally `cat` a binary file in the
terminal :-) ). Perhaps we can look into finding a desktop-agnostic way of
doing this and then limit our installed fonts to only a few minimal ones
based on the language selected in Anaconda?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1558274] perl-App-find2perl-1.004 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-App-find2perl-1.004-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1558293] perl-Test-Harness-3.42 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Test-Harness-3.42-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1551203] amavisd-release and amavisd-submit use wrong default socket path

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
amavisd-new-2.11.0-3.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1553479] SElinux denials on stock install

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 CC||emman...@seyman.fr,
   ||xav...@bachelot.org



--- Comment #7 from Emmanuel Seyman  ---
Bugzilla on EPEL6 was maintained by xavierb (cc-ing), not itamar.

A while back, the RPMFusion guys asked me to build a package for current
Bugzilla for EPEL7. I couldn't do it without upgrading packages in base so went
for the copr route.

https://copr.fedorainfracloud.org/coprs/eseyman/bugzilla-5.0/

(yes, I'm aware 5.0.4 came out recently. I'll push out an update soon.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1553479] SElinux denials on stock install

[bugzilla]

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



--- Comment #6 from R P Herrold  ---
To  : ita...@ispbrasil.com.br
Cc  : 
Attchmnt: 
Subject : bugzilla in EPEL , ticket: 1553479
- Message Text -

Hi

I filed
https://bugzilla.redhat.com/show_bug.cgi?id=1553479

because the bugzilla version in EPEL 6 is throsing SELinux
errors.  Looking further, it is also very old, and has known
CSS and related avenues for exploits

I am willing to co-maintain, but need for you to add me as
such, for EPEL 6 and 7

Alternatively if you are no longer active with Fedoraproject,
it may make sense to simply orphan it to me

I send this, starting (continuing really) the process under:
   
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintain$


I would prefer not to do this more 'publicly' on the
fedora-devel mailing list, but that appears to be the next 
step

-- Russ herrold

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Kevin Kofler]

Hi,

we did more debugging on #fedora-kde (thanks in particular to lupinix) and
we found what seems to be the primary source of the bloat: CJK fonts!

CJK fonts are by far the largest of all fonts due to the huge number of
characters used in those languages.

Up to Fedora 26, Fedora shipped 4 CJK fonts:
  adobe-source-han-sans-cn-fonts
  adobe-source-han-sans-tw-fonts
  naver-nanum-gothic-fonts
  vlgothic-fonts
The KDE and LXQt Spins actually opted to blacklist these fonts in their
kickstart, and ship one compact CJK font instead: wqy-microhei-fonts.

In Fedora 27, this Change:
https://fedoraproject.org/wiki/Changes/ChineseSerifFonts
added 2 additional fonts (for a total of 6):
  adobe-source-han-serif-cn-fonts
  adobe-source-han-serif-tw-fonts
which were unfortunately missing from the blacklist:
https://bugzilla.redhat.com/show_bug.cgi?id=1530006
already increasing the size of the image.

But now in Fedora 28, after:
https://fedoraproject.org/wiki/Changes/JPDefaultFontsToNoto
https://fedoraproject.org/wiki/Changes/KRDefaultFontsToNoto
https://fedoraproject.org/wiki/Changes/ChineseDefaultFontsToNoto
we actually ship a whopping 12 CJK fonts:
  google-noto-sans-jp-fonts
  google-noto-sans-kr-fonts
  google-noto-sans-mono-cjk-jp-fonts
  google-noto-sans-mono-cjk-kr-fonts
  google-noto-sans-mono-cjk-sc-fonts
  google-noto-sans-mono-cjk-tc-fonts
  google-noto-sans-sc-fonts
  google-noto-sans-tc-fonts
  google-noto-serif-jp-fonts
  google-noto-serif-kr-fonts
  google-noto-serif-sc-fonts
  google-noto-serif-tc-fonts
none of which are blacklisted in the Spins! According to lupinix, these
amount to a download size (and thus an xz-compressed size, which is also the
compression algorithm used for the live images) of 364 MiB!

The fix is to update the blacklists in the KDE and LXQt spin kickstarts, as
per the discussion under:
https://bugzilla.redhat.com/show_bug.cgi?id=1530006
IMHO, this needs to be implemented, urgently.

But I think we also need to generally consider whether it makes sense to
force 3 font variants for each CJK language on all users worldwide, and
whether there are smaller fonts that could be used. (E.g.,
wqy-microhei-fonts is very effective, but unfortunately it only covers
Simplified Chinese and the syllabic parts of Japanese and Korean, not the
Traditional Chinese, Japanese or Korean renderings of the CJK Unified
Ideographs.)

Any additional bloat is likely caused by:
* the updated glibc Unicode collation tables,
* Annobin,
but those seem to have much smaller impact than the above.

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

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Perl-Tidy-Sweetened-1.14-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-056341c5e0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561806] perl-HTTP-Message-6.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-HTTP-Message-6.16-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7252728b49

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561803] perl-DBD-SQLite-1.58 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-DBD-SQLite-1.58-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-0ab6e790c2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561800] perl-Config-Model-Tester-3.004 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Config-Model-Tester-3.004-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-5499e9d17a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28 (caused by Annobin?)

[Martin Bříza]

On Thu, 29 Mar 2018 15:32:06 +0200, Stephen Gallagher  
 wrote:





On Thu, Mar 29, 2018 at 9:16 AM Stephen Gallagher   
wrote:
On Thu, Mar 29, 2018 at 8:43 AM Kevin Kofler   
wrote:

Hi,

on #fedora-kde, we discussed a huge increase to the size of the KDE  
live

image:
F27 KDE GA: 1656752111 bytes
F27 KDE Respin: 1744830464 bytes
F28 KDE Beta: 2069889024 bytes

It turns out the LXQt live image is also hit:
F27 LXQt GA: < 1 GiB
F28 LXQt Beta: 1.4 GiB
and I am pretty sure that this is a global issue affecting ALL the live
images.

While there is certainly more than one cause (e.g., the difference  
between
F27 KDE GA and the F27 KDE Respin must be caused by package updates  
and/or
added dependencies), it is striking that between a recent F27 KDE  
Respin
(which has several of the KDE package updates that are also in the F28  
Beta)

and the F28 Beta, there is a size increase of more than 300 MB!

Therefore, my question:
Is this size increase caused by Annobin?

If not, then WHAT causes this size increase? And can the offending  
change(s)

be reverted in time for F28 Final?

If yes, then IMHO it is time to enact the contingency plan, i.e.:
1. drop the annobin requirement from redhat-rpm-config, AND
2. perform an emergency mass rebuild to actually get rid of the bloat.

A global live image size increase of 19%-40% is just not acceptable.

   Kevin Kofler



Have you done a comparison between individual package sizes and count?  
I wonder if the problem is that some subset of >>critical packages  
gained a whole lot of dependencies (intentionally or not) or if we're  
actually seeing that built >>binaries are suddenly carrying a huge  
additional amount of content. Or even if for some reason the binaries  
aren't being >>stripped properly.


I just checked several packages that compiled the same sources on F26  
and F28:

* sscg: 4.31% increase in size
* nodejs 8:  22% *decrease* in size
* libmodulemd: 12% *decrease* in size
* sssd-common: 2.58% increase in size
* boost-system: 1.00% increase in size

Granted, this is just a spot-check, but it seems to me like (on the  
whole) improvements in the compiler are at least >balancing out the  
increase caused by annobin. It definitely doesn't indicate a 19-40%  
increase across the board. So I'd >guess it's more likely to be  
dependency bloat or one or two core packages growing significantly.


Just for fun, I wrote a patch comparing only _unrebased_ (probably just  
rebuilt) packages between F27 and F28.
For compiled packages, the size difference is just a bunch of percent.  
Some packages grew considerably, but these are mostly fonts  
(google-noto-sans-fonts by 1012%).


The diff is attached. Order of data is: percentage, package name, f27 RPM  
size, f28 RPM size.


Martin

pkgsizediff
Description: Binary data
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28 (caused by Annobin?)

[Neal Gompa]

On Thu, Mar 29, 2018 at 9:32 AM, Stephen Gallagher  wrote:
>
> I just checked several packages that compiled the same sources on F26 and
> F28:
> * sscg: 4.31% increase in size
> * nodejs 8:  22% *decrease* in size
> * libmodulemd: 12% *decrease* in size
> * sssd-common: 2.58% increase in size
> * boost-system: 1.00% increase in size
>
> Granted, this is just a spot-check, but it seems to me like (on the whole)
> improvements in the compiler are at least balancing out the increase caused
> by annobin. It definitely doesn't indicate a 19-40% increase across the
> board. So I'd guess it's more likely to be dependency bloat or one or two
> core packages growing significantly.
>

I don't yet have proof of this, but I suspect that we might have more
packages that either:

1. Don't respect our compilation flags and thus simply are larger
because of that

or

2. Are built in static or static-like manner which promotes binary
bloat (Go, Rust, etc.)


Last I checked, we don't have anything significant on the ISOs that
fall into the latter category, so I would not be shocked if the former
is the reason why...

-- 
真実はいつも一つ！/ 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: Unacceptable size increase to ALL live images in F28 (caused by Annobin?)

[Florian Weimer]

On 03/29/2018 02:42 PM, Kevin Kofler wrote:

Is this size increase caused by Annobin?


Very unlikely.  We only have 356 MB of annobin data in the entire x86-64 
buildroot.  That's 1.7% of the total ELF binary size.


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

Re: Unacceptable size increase to ALL live images in F28 (caused by Annobin?)

[Stephen Gallagher]

On Thu, Mar 29, 2018 at 9:16 AM Stephen Gallagher 
wrote:

> On Thu, Mar 29, 2018 at 8:43 AM Kevin Kofler 
> wrote:
>
>> Hi,
>>
>> on #fedora-kde, we discussed a huge increase to the size of the KDE live
>> image:
>> F27 KDE GA: 1656752111 bytes
>> F27 KDE Respin: 1744830464 bytes
>> F28 KDE Beta: 2069889024 <(206)%20988-9024> bytes
>>
>> It turns out the LXQt live image is also hit:
>> F27 LXQt GA: < 1 GiB
>> F28 LXQt Beta: 1.4 GiB
>> and I am pretty sure that this is a global issue affecting ALL the live
>> images.
>>
>> While there is certainly more than one cause (e.g., the difference between
>> F27 KDE GA and the F27 KDE Respin must be caused by package updates and/or
>> added dependencies), it is striking that between a recent F27 KDE Respin
>> (which has several of the KDE package updates that are also in the F28
>> Beta)
>> and the F28 Beta, there is a size increase of more than 300 MB!
>>
>> Therefore, my question:
>> Is this size increase caused by Annobin?
>>
>> If not, then WHAT causes this size increase? And can the offending
>> change(s)
>> be reverted in time for F28 Final?
>>
>> If yes, then IMHO it is time to enact the contingency plan, i.e.:
>> 1. drop the annobin requirement from redhat-rpm-config, AND
>> 2. perform an emergency mass rebuild to actually get rid of the bloat.
>>
>> A global live image size increase of 19%-40% is just not acceptable.
>>
>> Kevin Kofler
>>
>
>
> Have you done a comparison between individual package sizes and count? I
> wonder if the problem is that some subset of critical packages gained a
> whole lot of dependencies (intentionally or not) or if we're actually
> seeing that built binaries are suddenly carrying a huge additional amount
> of content. Or even if for some reason the binaries aren't being stripped
> properly.
>

I just checked several packages that compiled the same sources on F26 and
F28:
* sscg: 4.31% increase in size
* nodejs 8:  22% *decrease* in size
* libmodulemd: 12% *decrease* in size
* sssd-common: 2.58% increase in size
* boost-system: 1.00% increase in size

Granted, this is just a spot-check, but it seems to me like (on the whole)
improvements in the compiler are at least balancing out the increase caused
by annobin. It definitely doesn't indicate a 19-40% increase across the
board. So I'd guess it's more likely to be dependency bloat or one or two
core packages growing significantly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28 (caused by Annobin?)

[Stephen Gallagher]

On Thu, Mar 29, 2018 at 8:43 AM Kevin Kofler  wrote:

> Hi,
>
> on #fedora-kde, we discussed a huge increase to the size of the KDE live
> image:
> F27 KDE GA: 1656752111 bytes
> F27 KDE Respin: 1744830464 bytes
> F28 KDE Beta: 2069889024 <(206)%20988-9024> bytes
>
> It turns out the LXQt live image is also hit:
> F27 LXQt GA: < 1 GiB
> F28 LXQt Beta: 1.4 GiB
> and I am pretty sure that this is a global issue affecting ALL the live
> images.
>
> While there is certainly more than one cause (e.g., the difference between
> F27 KDE GA and the F27 KDE Respin must be caused by package updates and/or
> added dependencies), it is striking that between a recent F27 KDE Respin
> (which has several of the KDE package updates that are also in the F28
> Beta)
> and the F28 Beta, there is a size increase of more than 300 MB!
>
> Therefore, my question:
> Is this size increase caused by Annobin?
>
> If not, then WHAT causes this size increase? And can the offending
> change(s)
> be reverted in time for F28 Final?
>
> If yes, then IMHO it is time to enact the contingency plan, i.e.:
> 1. drop the annobin requirement from redhat-rpm-config, AND
> 2. perform an emergency mass rebuild to actually get rid of the bloat.
>
> A global live image size increase of 19%-40% is just not acceptable.
>
> Kevin Kofler
>


Have you done a comparison between individual package sizes and count? I
wonder if the problem is that some subset of critical packages gained a
whole lot of dependencies (intentionally or not) or if we're actually
seeing that built binaries are suddenly carrying a huge additional amount
of content. Or even if for some reason the binaries aren't being stripped
properly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Randy Barlow]

Hello again!

There's been a lot of discussion on this thread, and some useful
feedback. Thanks!

I would like to make a clearer proposal about how gating in Rawhide
would work:


Multi-package update workflow
=

When a packager wants to update multiple interdependent packages (such
as a Gnome or KDE update), they will request a new side tag from Bodhi
(we can make a fedpkg feature for ease), and then they will use fedpkg
build --target=my_side_tag for each package they want to include in the
same update. The packager could also use chain building to do this if
preferred.

When the packager has finished the builds they intend to group together,
they will request the side tag to be merged via Bodhi/fedpkg. This will
create a Bodhi update and will trigger tests to run on the set of
packages included in the side tag. If the tests pass, Bodhi will merge
the side tag into Rawhide, and the packager's work is done. If they
fail, the packager will need to take action to get them to pass, or
submit a waiver to waiverdb to ignore them.

Once the side tag is merged, the update will be marked stable
automatically by Bodhi (no need for karma or time in
testing) and will be tagged into the rawhide tag.


Single package update workflow
==

If a packager wants to update a single package, they will use fedpkg
build, without specifying a side tag. fedpkg can see that the user did
not specify a side tag, so it will go ahead and prompt the user for
update details and create an update (or we could make this opt-in,
either way).

Once the Bodhi update exists, tests will run. If the tests pass, Bodhi
will automatically mark the update for stable and the packager's work is
done. If the tests fail, the packager will need to either fix the
problem or waive the update.


Benefits


* We increase the quality of packages in Rawhide through automated
  testing.
* By giving Bodhi the ability to manage side tags, we can also give side
  tags to packagers for stable releases. This will allow packagers to
  chain build for stable releases in addition to rawhide, which is not
  possible today.
* The workflow isn't so different from what we have today. Single
  package updates are nearly the same, and multi-package updates often
  manually request side tags from releng.


Buildroot overrides
===

If Bodhi can provide side tags to packagers, the use case for buildroot
overrides becomes diminished. I am not able to immediately think of a
purpose for them that would remain, but it would be bold to say they
would have no purpose with this design. If we go with the above design,
we should monitor buildroot override usage and remove it if it is
unused. We may even make it an admin-only feature (you would request it
from releng).


Thanks to pingou for creating the nice flowcharts for us.



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: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Thu, Mar 29, 2018 at 10:47:50AM +0200, Nicolas Mailhot wrote:
> Le 2018-03-28 12:52, Pierre-Yves Chibon a écrit :
> 
> Hi
> 
> > With bodhi:
> > - Single package update
> > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png
> > - Multi-packages update
> 
> Not terribly fond of anything that offloads multi-build intellignece
> coordination on packagers, forcing everyone that needs multi-build to either
> do lots of manual operations, to reinvent its own local tooling, or just
> give up on some updates.

I am not sure where you're seeing:
- lots of manual operations
- reinventing its own tooling
- giving up on some updates

There would be 2 new operation: ask for a new side-tag, ask for it to be merged.
These already exists for large rebuilds and need to go via rel-eng while the new
tooling would allow self-service.

I think we made it clear that we want to get chain-build to work/keep working

For the last point, I'm very unclear on where you got this impression.

> The correct packager-friendly way to do it is
> 
> eat-this  → ok/nok

How is this different from chain-build?
 
> With the tooling chain-building , automatically applying
> boostrap sections when present, automatically rebuilding everything in the
> set against the final state of other parts of the set, and applying
> integration tests to the end result and not to the intermediary steps.
> 
> And it should not matter if  has a count of one or many.

Agreed in theory, in practice having a list of one item allows to simplify
things.

> Anything that posits list of srpms is a special case 

I think it's the other way around: single srpm are a special case, they are a
sub-case of the multi-srpm which allow taking shortcut.

> (that's also a huge defect our the review workflow, unbundle and produce a
> clean and maintenable set of packages → lots of review and tooling misery,
> keep it all in a single srpm → no problems)

One could argue than 1 is always simpler than > 1 so this is intrinsically a
state of things.

That being said, I think it is a fair critic one we may want to address but I
think that's broader than the discussion at hand.



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

Re: Gating packages in Rawhide

[Pierre-Yves Chibon]

On Wed, Mar 28, 2018 at 09:09:09PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Mar 09, 2018 at 10:20:12AM +0100, Pierre-Yves Chibon wrote:
> > On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote:
> > > I would like to kick off a general discussion about how we might gate
> > > packages in Rawhide. I think it would be nice to get something in place
> > > for the Fedora 29 timeframe.
> > 
> > I was waiting to have some more time to work on it to kick off that 
> > discussion.
> > This is cool as it means there are more people interested in having this :)
> > 
> > > As one of the Bodhi contributors, I am inclined to suggest that we could
> > > use Bodhi on Rawhide, similar to how we use it for our stable/branched
> > > releases, with more relaxed rules (perhaps 1 day in testing or something
> > > simple).
> > > 
> > > It may be possible to automate the process a bit to make it less heavy
> > > for developers, though there is some complication for multi-package
> > > updates (more on that in a bit). For simple package updates, we may be
> > > able to detect new commits on dist-git, and react to those by
> > > automatically starting a Koji build, and automatically filing a Bodhi
> > > update when that build is complete. I think that would be pretty nice,
> > > and pingou created a PoC[0] to do this about a year ago.
> > > 
> > > Multi-package updates won't be so easy though. It's not uncommon for us
> > > to need to update packages together, and the above workflow would be
> > > problematic since it would result in updates with single packages in
> > > them rather than updates with multiple packages. Of course, buildroot
> > > overrides would be a problem too, since multi-package updates often
> > > depend on each other at build time too.
> > > 
> > > We could create some way for packagers to indicate that a commit (or
> > > possibly even a whole repo) is not intended to be "autobuilt/updated".
> > > If the packager indicates this then their builds would go into a
> > > rawhide-pending (similar to what we do for f27 today). Once they have
> > > all their builds (and buildroot overrides) the way they want them, they
> > > can create the update.
> > > 
> > > Another idea that was tossed around in some chats I had with people
> > > about this involved a system for packagers to use to create Koji side
> > > tags. Bodhi manages BuildRoot Overrides today (with expirations), so
> > > perhaps Bodhi could be expanded to also manage Koji side tags (also with
> > > expirations). I can't remember all the details about this approach or
> > > why it was suggested over the former approach, but I wanted to list it
> > > to invite others to chew on it and see if it could work.
> > > 
> > > If you have other suggestions on how we might gate packages in Rawhide
> > > that are wildly different than the above, please feel free to share!
> > 
> > I had a different idea in mind, basically try to keep the experience as 
> > close as
> > what it is now.
> > for single package:
> >   - packager commit
> >   - packager build
> >   - build is tagged into a specfic koji tag
> >   - test are run on this tag
> > -> results go to src.fp.o
> >   - if tests pass
> > - package is moved to another koji tag
> > - package is signed
> > - package is pushed to rawhide
> >   - if tests do not pass
> > - do nothing
> > - if the user submits a waiver
> >   - move the package to the next koji tag for signing it
> > If a packager does not want to run the tests, we could have a fedpkg build
> > --noci that would directly build the package in the koji tag used for 
> > signing
> > the package (useful for mass-rebuild for example)
> In the graphs, the red arrows are always full, i.e. signify manual steps.
> Is this an oversight, or are so many manual steps actually needed in that
> workflow?

The one between fedpkg build --noci and koji build should be dashed indeed, the
others are plain as they should I believe.

> > for multi-package:
> >   - packager requests a new side-tag (I'd propose via bodhi)
> >   - packager build all the different packages in that side-tag
> >   - packager asks for the side tag to be merged
> >   - tests are run on all these packages
> Are those tests run will all the packages in the side-tag, or with
> each package separately installed onto current rawhide? I assume the
> first, but please clarify that.

They should run with all the packages in the side-tag I think.

> > -> results go to src.fp.o
> > --> We probably want to also report them on the bodhi request to merge 
> > the
> > tag as otherwise the packager will have to go through all the 
> > package to
> > find the one(s) that failed
> >   - if tests pass
> > -> cf above
> 
> I see two advantages of the workflow with bodhi:
> - we can reuse existing reporting interfaces, for tests results, but also
>   for user comments. In particular I expect that the integration of bodhi
>   with greenwave and 

Unacceptable size increase to ALL live images in F28 (caused by Annobin?)

[Kevin Kofler]

Hi,

on #fedora-kde, we discussed a huge increase to the size of the KDE live 
image:
F27 KDE GA: 1656752111 bytes
F27 KDE Respin: 1744830464 bytes
F28 KDE Beta: 2069889024 bytes

It turns out the LXQt live image is also hit:
F27 LXQt GA: < 1 GiB
F28 LXQt Beta: 1.4 GiB
and I am pretty sure that this is a global issue affecting ALL the live 
images.

While there is certainly more than one cause (e.g., the difference between 
F27 KDE GA and the F27 KDE Respin must be caused by package updates and/or 
added dependencies), it is striking that between a recent F27 KDE Respin 
(which has several of the KDE package updates that are also in the F28 Beta) 
and the F28 Beta, there is a size increase of more than 300 MB!

Therefore, my question:
Is this size increase caused by Annobin?

If not, then WHAT causes this size increase? And can the offending change(s) 
be reverted in time for F28 Final?

If yes, then IMHO it is time to enact the contingency plan, i.e.:
1. drop the annobin requirement from redhat-rpm-config, AND
2. perform an emergency mass rebuild to actually get rid of the bloat.

A global live image size increase of 19%-40% is just not acceptable.

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

Re: Announcing DNF 3 development

[Kevin Kofler]

Matěj Cepl wrote:
> When switching the programming langauge than I would think there
> are some better C-successors than C++, namely Rust? Mad rush of
> giving up on 46 years old language and switching to one which is
> just 33 years old seems a bit bizarre to me.

But the "33 years old" language WORKS. :-) As for why switching from C to 
C++, that's because C++ has some features that C does not have and that are 
useful for the DNF developers, in particular, native support for object 
orientation (without the GObject hack).

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

Re: Package Anki has a Non-responsive Maintainer, Christian Krause

[Timotheus Pokorra]

Hello Thomas,


I am posted to ask if anybody knows how to contact Christian Krause
who is currently the maintainer of Anki in Fedora.


I have sent him an e-mail to his personal address, and I hope he will 
respond to this thread soon.


Timotheus



Diese Nachricht wurde versandt mit Webmail von www.tbits.net.
This message was sent using webmail of www.tbits.net.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Package Anki has a Non-responsive Maintainer, Christian Krause

[Thomas Drake-Brockman]

As per the Non-responsive Maintainer Policy
(https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers)
I am posted to ask if anybody knows how to contact Christian Krause who
is currently the maintainer of Anki in Fedora.
They are yet to respond to my bug requesting that they respond
(https://bugzilla.redhat.com/show_bug.cgi?id=1553215) since 2018-03-08,
nor have they responded to numerous other bugs against the Anki package.
Thanks,
Thomas

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

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Perl-Tidy-Sweetened-1.14-1.fc26 has been submitted as an update to Fedora
26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-bb6f917f6c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Perl-Tidy-Sweetened-1.14-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9a9149f55f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Perl-Tidy-Sweetened-1.14-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-056341c5e0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Perl-Tidy-Sweetened-1.
   ||14-1.fc29



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Stop building 389-ds-base on i686

[Peter Robinson]

On Thu, 29 Mar 2018, 16:24 Florian Weimer,  wrote:

> On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
>
> >> Note that while GCC produces broken code, this is actually an ABI bug,
> and
> >> we cannot change struct layout rules for long long retroactively. Maybe
> we
> >> could for _Atomic long long, but that would need a lengthy
> investigation,
> >> and I strongly believe that everyone is better off if the time is spent
> on
> >> improving 64-bit architectures.
> >
> >Does it mean that the bug was here for the last 23 years? And now this
> > became a problem?
>
> I'm not sure how you came up with the duration.  The bug is most
> certainly much younger than that, probably introduced along with the new
> atomic intrinsics in a late GCC 4.8.x release.  Arguably, it is a real
> bug only for _Atomic long long members.
>

Probably referring to the age of the 389-ds code base which dates all the
way back to Netscape Directory Server

Thanks,
> Florian
> ___
> 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

[Bug 1561806] perl-HTTP-Message-6.16 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-HTTP-Message-6.16-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2f3b35e7cb

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561806] perl-HTTP-Message-6.16 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-HTTP-Message-6.16-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7252728b49

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Stop building 389-ds-base on i686

[Florian Weimer]

On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:


Note that while GCC produces broken code, this is actually an ABI bug, and
we cannot change struct layout rules for long long retroactively. Maybe we
could for _Atomic long long, but that would need a lengthy investigation,
and I strongly believe that everyone is better off if the time is spent on
improving 64-bit architectures.


   Does it mean that the bug was here for the last 23 years? And now this
became a problem?


I'm not sure how you came up with the duration.  The bug is most 
certainly much younger than that, probably introduced along with the new 
atomic intrinsics in a late GCC 4.8.x release.  Arguably, it is a real 
bug only for _Atomic long long members.


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

[Bug 1561814] perl-Perl-Tidy-Sweetened-1.14 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |ppi...@redhat.com
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561806] perl-HTTP-Message-6.16 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-HTTP-Message-6.16-1.fc
   ||29



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 27.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561803] perl-DBD-SQLite-1.58 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-DBD-SQLite-1.58-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-0ab6e790c2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561803] perl-DBD-SQLite-1.58 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-DBD-SQLite-1.58-1.fc29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 28.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Nicolas Mailhot]

Le 2018-03-28 12:52, Pierre-Yves Chibon a écrit :

Hi


With bodhi:
- Single package update
  
https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png

- Multi-packages update


Not terribly fond of anything that offloads multi-build intellignece 
coordination on packagers, forcing everyone that needs multi-build to 
either do lots of manual operations, to reinvent its own local tooling, 
or just give up on some updates.


The correct packager-friendly way to do it is

eat-this  → ok/nok

With the tooling chain-building , automatically applying 
boostrap sections when present, automatically rebuilding everything in 
the set against the final state of other parts of the set, and applying 
integration tests to the end result and not to the intermediary steps.


And it should not matter if  has a count of one or many.

Anything that posits list of srpms is a special case that can be bolted 
on the single srpm is broken by design and produces broken packaging, 
because people will try to workaround tooling defects by stashing 
everything in a single srpm to make tools happy.


(that's also a huge defect our the review workflow, unbundle and produce 
a clean and maintenable set of packages → lots of review and tooling 
misery, keep it all in a single srpm → no problems)


Regards,

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

[Bug 1561800] perl-Config-Model-Tester-3.004 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Config-Model-Tester-3.004-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b39d981933

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561803] perl-DBD-SQLite-1.58 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |ppi...@redhat.com
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Fedora-Atomic 27-20180329.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1561800] perl-Config-Model-Tester-3.004 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Config-Model-Tester-3.004-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5499e9d17a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Kernel updates breaking grub configuration with tuned

[Ondřej Lysoněk]

On 28.3.2018 20:58, Christopher wrote:
> So, I've been seeing this problem recently where every time I update the
> Fedora kernel (currently F27), my grub configuration gets mangled.
> 
> I have tuned installed, so it has installed /etc/grub.d/00_tuned, which
> executes /etc/tuned/bootcmdline, which in turn spits out when
> grub2-mkconfig is run.
> 
> ### BEGIN /etc/grub.d/00_tuned ###
> set tuned_initrd=""
> set tuned_params="skew_tick=1"
> ### END /etc/grub.d/00_tuned ###
> 
> However, every time I update the F27 kernel, it mangles the params line,
> to something like:
> 
> set tuned_params="skew_tick=1"=1"=1"=1"=1"

Thanks for bringing this up. The issue has already been reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1509515

Best regards
Ondřej Lysoněk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1561800] perl-Config-Model-Tester-3.004 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Config-Model-Tester-3.
   ||004-1.fc29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 27.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1561800] perl-Config-Model-Tester-3.004 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |ppi...@redhat.com
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org