Fwd: Broken dependencies: redhat-rpm-config

[Panu Matilainen]

Started getting these bogus broken deps emails after merging a request 
to depend on gcc conditionally. Is the broken dependencies check done 
with yum era repoclosure still, or...?


- Panu -

 Forwarded Message 
Subject: Broken dependencies: redhat-rpm-config
Date: Tue,  9 Jan 2018 01:30:25 + (UTC)
From: build...@fedoraproject.org
To: redhat-rpm-config-ow...@fedoraproject.org



redhat-rpm-config has broken dependencies in the rawhide tree:
On x86_64:
redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc)
On armhfp:
redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc)
On ppc64le:
redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc)
On aarch64:
redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc)
On ppc64:
redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc)
On s390x:
redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc)
On i386:
redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc)
Please resolve this as soon as possible.

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

Fedora Rawhide-20180108.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 184999  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/184999
ID: 185004  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/185004
ID: 185059  Test: i386 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/185059
ID: 185070  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/185070

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

ID: 184923  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/184923
ID: 184958  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/184958
ID: 184959  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/184959
ID: 184960  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/184960
ID: 184969  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/184969
ID: 184971  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/184971
ID: 184972  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/184972
ID: 185013  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/185013
ID: 185030  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/185030
ID: 185031  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/185031
ID: 185034  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/185034
ID: 185035  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/185035
ID: 185036  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/185036
ID: 185053  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/185053
ID: 185064  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/185064
ID: 185069  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/185069

Soft failed openQA tests: 74/128 (x86_64), 19/24 (i386)
(Tests completed, but using a workaround for a known bug)

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

ID: 184940  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/184940
ID: 184955  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/184955
ID: 185000  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/185000
ID: 185021  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/185021

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

ID: 184911  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/184911
ID: 184912  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/184912
ID: 184913  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/184913
ID: 184914  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/184914
ID: 184921  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/184921
ID: 184922  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/184922
ID: 184931  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/184931
ID: 184933  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/184933
ID: 184934  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/184934
ID: 184935  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/184935
ID: 184936  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/184936
ID: 184937  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/184937
ID: 184938  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/184938
ID: 184939  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/184939
ID: 184951  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/184951
ID: 184954 

Re: F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Tue, 2018-01-09 at 04:09 +, Peter Robinson wrote:
> On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson
>  wrote:
> > On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote:
> > > 
> > > > A significant miss here is 'testing'. Making an arch primary means we
> > > > need to ensure we have the necessary resources to run all the relevant
> > > > validation testing.
> > > > 
> > > > I note pwhalen is a co-owner of the proposal so he's likely signed up
> > > > to ensure testing gets done, but still, it should be properly covered
> > > > in the Change document itself.
> > > 
> > > Yes, we've got a bunch of stuff here but the change document template
> > > doesn't really have a good spot to outline all of that.
> > 
> > It does have an entire section called "How To Test".
> 
> Fair enough, I was assuming more that was a end user individual as
> opposed to CI/CD/infra details

I mean, it's a template. Adjust as appropriate. Including the relevant
material seems clearly preferable to leaving it out. Anyhoo.
-- 
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 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson
 wrote:
> On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote:
>>
>> > A significant miss here is 'testing'. Making an arch primary means we
>> > need to ensure we have the necessary resources to run all the relevant
>> > validation testing.
>> >
>> > I note pwhalen is a co-owner of the proposal so he's likely signed up
>> > to ensure testing gets done, but still, it should be properly covered
>> > in the Change document itself.
>>
>> Yes, we've got a bunch of stuff here but the change document template
>> doesn't really have a good spot to outline all of that.
>
> It does have an entire section called "How To Test".

Fair enough, I was assuming more that was a end user individual as
opposed to CI/CD/infra details
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

[mcatanzaro]

On Mon, Jan 8, 2018 at 8:17 PM, Peter Robinson  
wrote:
I thought for some reason that all updates marked as security were 
automatically urgent, maybe I'm misremembering, but if not it might 
be good to do that as a RFE that way all security updates go out non 
batched.


Most security updates are simply not urgent, and we really don't want 
to pester users with these on a daily basis. So it would be nice if 
security updates went through batched by default.


Still, this update was marked as a high-severity security update. It 
probably makes sense that those should skip batched, in addition to 
updates marked as urgent.


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

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

>> > == Scope ==
>> > * Proposal owners:
>> > The general AArch64 support is already in place and is widely and
>> > actively supported by the Fedora ARM SIG and numerous ARM vendors
>> > and
>> > third parties in Fedora. There will be further and wider support,
>> > hardware enablement, polish and general improvements.
>> >
>> > * Other developers:
>> > N/A: There's no work required for other developers, the aarch64
>> > architecture is already widely supported as an Alternate
>> > Architecture.
>> >
>> > * Release engineering:
>> > Needs approval from release engineering as a primary architecture
>> > as
>> > well as pungi configuration changes to output artifacts to new
>> > location on the primary mirror.
>> > rel-eng ticket #7243: https://pagure.io/releng/issue/7243
>> >
>> > * Policies and guidelines:
>> > Updates to the primary architectures and release blocking details
>> > will
>> > need to be updated to reflect that the AArch64 Server/Cloud/Docker
>> > components are now considered primary.
>> >
>> > * Trademark approval:
>> > N/A (not needed for this Change)
>>
>> A significant miss here is 'testing'. Making an arch primary means we
>> need to ensure we have the necessary resources to run all the
>> relevant
>> validation testing.
>>
>> I note pwhalen is a co-owner of the proposal so he's likely signed up
>> to ensure testing gets done, but still, it should be properly covered
>> in the Change document itself.
>>
>> As a further note, almost all the Server validation for x86_64 is
>> done
>> by openQA; doing it manually can be a considerable pain, as you have
>> to
>> set up a mini FreeIPA deployment. It would probably be best if we add
>> aarch64 workers to the Fedora openQA deployment to run these tests on
>> aarch64; we've already extended openQA (staging) to ppc64, so all the
>> bits should be in place for us to add another arch, pretty much. I'm
>> going to follow up on this with pwhalen.
>>
>> Another consideration would be whether we ought to also have aarch64
>> support in Taskotron, if it's going to become a primary arch. I'm not
>> actually sure if Taskotron currently covers 32-bit ARM, though, even.
>
> currently taskotron is x86 only.  I am not sure what it would take to
> extend it beyond x86, it would be a worthwhile investigation. It would
> be useful to have all arches in openQA regardless of primary or
> secondary status. I would like to see openQA working for aarch64 in
> Fedora's instance a hard requirement of this change.

I'm fine with that, we already have OpenQA working fine on aarch64 and
the only reason it's not yet in the Fedora infra was that we were
awaiting on the DC move and the EOL of Fedora 25 to be able to move
hardware around.

In fact it basically was a hard requirement for myself (and I suspect
Paul as well) as basically I'm lazy and would prefer a machine do as
much as the testing as humanly possible so I don't have to :-D

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

Re: F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote:
> 
> > A significant miss here is 'testing'. Making an arch primary means we
> > need to ensure we have the necessary resources to run all the relevant
> > validation testing.
> > 
> > I note pwhalen is a co-owner of the proposal so he's likely signed up
> > to ensure testing gets done, but still, it should be properly covered
> > in the Change document itself.
> 
> Yes, we've got a bunch of stuff here but the change document template
> doesn't really have a good spot to outline all of that.

It does have an entire section called "How To Test".
-- 
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: Anaconda modularization

[Adam Williamson]

On Tue, 2018-01-09 at 02:31 +, Peter Robinson wrote:
> On Mon, Jan 8, 2018 at 2:01 PM, Matthew Miller  
> wrote:
> > On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote:
> > > Yep - basically, there will be no "old" and "new, DBUS/modular"
> > > Anaconda, the plan is to turn the current Anaconda to the new one one
> > > step at a time.
> > > 
> > > This should allow us to fix bugs as usual and handle any unforeseen
> > > modularization issues early on one-by-one as they show up.
> > 
> > It sounds like there actually isn't a contingency plan as such. Do you
> > think that this could all be reverted on Final Freeze day if we would
> > decide it's not working out? If not, let's not call that a contingency.
> 
> I would argue this isn't a "Self Contained Change" but a system wide
> one. If anaconda is broken we can't even compose so this should all be
> landed and complete by the time the system wide features need to be.

Yeah, good point. I'd agree this should be considered system-wide, not
self-contained.
-- 
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 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 6:06 PM, Andreas Tunek  wrote:
> 2018-01-08 19:03 GMT+01:00 Jonathan Dieter :
>> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>>> On 8 January 2018 at 12:28, Matthew Miller 
>>> wrote:
>>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>>> > > A significant miss here is 'testing'. Making an arch primary
>>> > > means we
>>> > > need to ensure we have the necessary resources to run all the
>>> > > relevant
>>> > > validation testing.
>>> >
>>> > Are there hardware needs here? (Like, not in the server room but in
>>> > QA
>>> > team member's hands?)
>>> >
>>>
>>> I would say in both. We would need to make sure we have enough
>>> systems
>>> which openqa can reliably run on and we need to have some sort of
>>> system that testers can get a hand on. That would require a bit of a
>>> 'we expect this hardware to work and this is how you buy/get it' from
>>> the aarch64 team.. otherwise most everyone is going to come and ask
>>> why the raspberry pi 3 isn't supported (just like they did with the
>>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
>>> more that is what most testers can get their hands on easily.. and it
>>> is not a aarch64 platform we support).
>>
>> I may be going off in the weeds here, but is https://fedoraproject.org/
>> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
>> accurate when it says it *is* supported?
>>
>
> That link does not work for me and I get some strange redirect to the
> Fedora download page.

https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 6:03 PM, Jonathan Dieter  wrote:
> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>> On 8 January 2018 at 12:28, Matthew Miller 
>> wrote:
>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>> > > A significant miss here is 'testing'. Making an arch primary
>> > > means we
>> > > need to ensure we have the necessary resources to run all the
>> > > relevant
>> > > validation testing.
>> >
>> > Are there hardware needs here? (Like, not in the server room but in
>> > QA
>> > team member's hands?)
>> >
>>
>> I would say in both. We would need to make sure we have enough
>> systems
>> which openqa can reliably run on and we need to have some sort of
>> system that testers can get a hand on. That would require a bit of a
>> 'we expect this hardware to work and this is how you buy/get it' from
>> the aarch64 team.. otherwise most everyone is going to come and ask
>> why the raspberry pi 3 isn't supported (just like they did with the
>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
>> more that is what most testers can get their hands on easily.. and it
>> is not a aarch64 platform we support).
>
> I may be going off in the weeds here, but is https://fedoraproject.org/
> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
> accurate when it says it *is* supported?

Nope, it's completely accurate and it's supported
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:53 PM, Stephen John Smoogen  wrote:
> On 8 January 2018 at 12:28, Matthew Miller  wrote:
>> On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>>> A significant miss here is 'testing'. Making an arch primary means we
>>> need to ensure we have the necessary resources to run all the relevant
>>> validation testing.
>>
>> Are there hardware needs here? (Like, not in the server room but in QA
>> team member's hands?)
>>
>
> I would say in both. We would need to make sure we have enough systems
> which openqa can reliably run on and we need to have some sort of
> system that testers can get a hand on. That would require a bit of a

There will be more than enough HW for openQA, we have two large
systems we'll put into the cloud (awaiting commissioning now the DC
migration is done) which will enable us to use AutoCloud (or what ever
it's replacement is) for VM/Docker testing, and a number of physical
systems for OpenQA.

> 'we expect this hardware to work and this is how you buy/get it' from
> the aarch64 team.. otherwise most everyone is going to come and ask
> why the raspberry pi 3 isn't supported (just like they did with the

The Raspberry Pi 3 *IS* supported on aarch64 [1]! As is the Pine64,
currently headless needs a serial console but by F-28 it will be
supported with basic console out for HDMI too, We support around 20
aarch64 SBCs in F-27 [1] and I expect that to likely double, or even
more than that, with F-28. Along with all the SBSA compliant hardware
etc.

I have the ability to get HW provided to people that are actually
going to use it for testing the problem I have here is that I
regularly give people hardware for testing and I get zero testing back
and Paul, myself and others still end up doing all the testing.

> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
> more that is what most testers can get their hands on easily.. and it
> is not a aarch64 platform we support).

Err, RPi 0-2 are 32 bit only devices in the case of < 2 they're
ARMv6, and we support the RPi2 with 32 bit I don't see how any of
that is relevant to this conversation?

[1] https://nullr0ute.com/2017/11/overview-of-aarch64-sbc-support-in-fedora-27/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:16 PM, Adam Williamson
 wrote:
> On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote:
>>
>> == Scope ==
>> * Proposal owners:
>> The general AArch64 support is already in place and is widely and
>> actively supported by the Fedora ARM SIG and numerous ARM vendors and
>> third parties in Fedora. There will be further and wider support,
>> hardware enablement, polish and general improvements.
>>
>> * Other developers:
>> N/A: There's no work required for other developers, the aarch64
>> architecture is already widely supported as an Alternate Architecture.
>>
>> * Release engineering:
>> Needs approval from release engineering as a primary architecture as
>> well as pungi configuration changes to output artifacts to new
>> location on the primary mirror.
>> rel-eng ticket #7243: https://pagure.io/releng/issue/7243
>>
>> * Policies and guidelines:
>> Updates to the primary architectures and release blocking details will
>> need to be updated to reflect that the AArch64 Server/Cloud/Docker
>> components are now considered primary.
>>
>> * Trademark approval:
>> N/A (not needed for this Change)
>
> A significant miss here is 'testing'. Making an arch primary means we
> need to ensure we have the necessary resources to run all the relevant
> validation testing.
>
> I note pwhalen is a co-owner of the proposal so he's likely signed up
> to ensure testing gets done, but still, it should be properly covered
> in the Change document itself.

Yes, we've got a bunch of stuff here but the change document template
doesn't really have a good spot to outline all of that.

> As a further note, almost all the Server validation for x86_64 is done
> by openQA; doing it manually can be a considerable pain, as you have to
> set up a mini FreeIPA deployment. It would probably be best if we add
> aarch64 workers to the Fedora openQA deployment to run these tests on
> aarch64; we've already extended openQA (staging) to ppc64, so all the
> bits should be in place for us to add another arch, pretty much. I'm
> going to follow up on this with pwhalen.

Yes, that is the plan, we have the HW to do it and Paul Whalen has it
running locally, the reason it's not in place already basically comes
down to two things:
1) we needed to wait for the DC migration before we could set some of it up
2) with all the various changes around CI/testing/modularity etc
awaiting to see what the final outcome would be

> Another consideration would be whether we ought to also have aarch64
> support in Taskotron, if it's going to become a primary arch. I'm not
> actually sure if Taskotron currently covers 32-bit ARM, though, even.

That's also on my list, basically we have some hardware, with the
option of more, I had on my list of options:
* openQA
* auto cloud
* task-o-tron
* other CI/CD pipelines
* any other options.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Anaconda modularization

[Peter Robinson]

On Mon, Jan 8, 2018 at 2:01 PM, Matthew Miller  wrote:
> On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote:
>> Yep - basically, there will be no "old" and "new, DBUS/modular"
>> Anaconda, the plan is to turn the current Anaconda to the new one one
>> step at a time.
>>
>> This should allow us to fix bugs as usual and handle any unforeseen
>> modularization issues early on one-by-one as they show up.
>
> It sounds like there actually isn't a contingency plan as such. Do you
> think that this could all be reverted on Final Freeze day if we would
> decide it's not working out? If not, let's not call that a contingency.

I would argue this isn't a "Self Contained Change" but a system wide
one. If anaconda is broken we can't even compose so this should all be
landed and complete by the time the system wide features need to be.

> I'm not saying we shouldn't do this, but let's be honest with
> ourselves. If the contingency plan is "None: we'll have to hold up the
> release for fixes if it's not ready", the Change plan should say that.

And we should be honest that the "Final Freeze day" is _WAY_ too late
to be working out whether we should revert this or not!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1377996] perl-XML-LibXML: Expanding external entities by default

[bugzilla]

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

Doran Moppert  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WONTFIX
 Whiteboard|impact=moderate,public=2016 |impact=moderate,public=2016
   |0917,reported=20160920,sour |0917,reported=20160920,sour
   |ce=debian,cvss2=6.8/AV:N/AC |ce=debian,cvss2=3.3/AV:L/AC
   |:M/Au:N/C:P/I:P/A:P,cvss3=7 |:M/Au:N/C:P/I:N/A:P,cvss3=5
   |.0/CVSS:3.0/AV:N/AC:H/PR:N/ |.7/CVSS:3.0/AV:L/AC:H/PR:N/
   |UI:N/S:U/C:H/I:L/A:L,cwe=CW |UI:N/S:U/C:H/I:N/A:L,cwe=CW
   |E-611,rhel-5/perl-XML-LibXM |E-611,rhel-5/perl-XML-LibXM
   |L=affected,rhel-6/perl-XML- |L=wontfix,rhel-6/perl-XML-L
   |LibXML=affected,rhel-7/perl |ibXML=wontfix,rhel-7/perl-X
   |-XML-LibXML=affected,fedora |ML-LibXML=wontfix,fedora-al
   |-all/perl-XML-LibXML=affect |l/perl-XML-LibXML=affected
   |ed  |
Last Closed||2018-01-08 21:26:32



-- 
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: Security updates and batched pushes

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:39 PM, Kevin Fenzi  wrote:
> On 01/07/2018 08:01 PM, Kevin Kofler wrote:
>> Kevin Fenzi wrote:
>>> The critera for bypassing batched is if the update is marked "urgent".
>>
>> The problem is, this appears to be insufficient.
> Well, if this firefox update was urgent, shouldn't it have been marked
> urgent?

I thought for some reason that all updates marked as security were
automatically urgent, maybe I'm misremembering, but if not it might be
good to do that as a RFE that way all security updates go out non
batched.

>> I really don't understand why we do this "batched" thing to begin with.
>
> To reduce the constant flow of updates that are very minor or affect
> very few mixed in with the major updates that affect lots of people and
> are urgent. To save users downloads of repodata.
>
>> Users who want to batch updates have always been able to do it, GNOME
>> Software will even do it for theNow, those users who want to batch their
>> updates are forced to follow Fedora rel-eng's schedule for the batches
>> rather than being able to pick their own weekday, so how does the server-
>> side batching help them? And those users (like me) who want to get their
>> updates, including security fixes (!) as we see here, as soon as they passed
>> testing are now screwed.
>
> rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch
> appears on wed's pushes).
>
> There was some discussion about changing the gnome batching based on the
> Fedora batching, but I don't know whats happened there.
>
> I haven't seen a bunch of urgent updates get blocked by this process.
> Do you have more data for updates that hit this?
>
>> If people insist on that "batched" misfeature, can we please at least get a
>> fast track repository that contains all the batched updates (but no updates
>> that are still in testing and have not been batched yet!)?
>
> I would be very much against additional repos like this.
>
>
> kevin
>
>
> ___
> 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: Security updates and batched pushes

[Andrew Clayton]

On Mon, 08 Jan 2018 19:53:01 +0100
Kevin Kofler  wrote:

> Batching really needs to be left to the client side!

Right.

I did wonder what was going on with the updates...

dnf-cron, gnome-software etc could all *default* to weekly.

But if I'm doing a dnf update, I want the updates *now*.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Matthew Miller]

On Mon, Jan 08, 2018 at 04:37:34PM -0800, Adam Williamson wrote:
> > Are there hardware needs here? (Like, not in the server room but in QA
> > team member's hands?)
> pwhalen has hardware. Not sure who else does. I'm not going to ask for
> any, because it'd just join all my ARM hardware in the Pile Of Boxes I
> Never Get Time To Open.

If anyone else on the QA team (or Server SIG) has time but *not* the
pile of boxes, this is a good time to say something. :)

-- 
Matthew Miller

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

Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

[Matthew Miller]

On Mon, Jan 08, 2018 at 08:27:22PM -0500, Matthew Miller wrote:
> > combination of the 2.  Unfortunately both have external requirements.
> > Retpoline requires GCC patches, and microcode updates for some CPUs.
> > IBRS requires microcode updates. While RHEL has done quite a bit of
> 
> Does this mean we should do a mass rebuild once those patches have
> landed? We have a mass rebuild scheduled for Jan 31st (basically three
> weeks from now). Is that too soon?

Or are the GCC changes just needed for the kernel itself?

-- 
Matthew Miller

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

Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

[Matthew Miller]

On Mon, Jan 08, 2018 at 04:49:44PM -0600, Justin Forbes wrote:
> combination of the 2.  Unfortunately both have external requirements.
> Retpoline requires GCC patches, and microcode updates for some CPUs.
> IBRS requires microcode updates. While RHEL has done quite a bit of

Does this mean we should do a mass rebuild once those patches have
landed? We have a mass rebuild scheduled for Jan 31st (basically three
weeks from now). Is that too soon?

-- 
Matthew Miller

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

Re: F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Mon, 2018-01-08 at 20:03 +0200, Jonathan Dieter wrote:
> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
> > On 8 January 2018 at 12:28, Matthew Miller 
> > wrote:
> > > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
> > > > A significant miss here is 'testing'. Making an arch primary
> > > > means we
> > > > need to ensure we have the necessary resources to run all the
> > > > relevant
> > > > validation testing.
> > > 
> > > Are there hardware needs here? (Like, not in the server room but in
> > > QA
> > > team member's hands?)
> > > 
> > 
> > I would say in both. We would need to make sure we have enough
> > systems
> > which openqa can reliably run on and we need to have some sort of
> > system that testers can get a hand on. That would require a bit of a
> > 'we expect this hardware to work and this is how you buy/get it' from
> > the aarch64 team.. otherwise most everyone is going to come and ask
> > why the raspberry pi 3 isn't supported (just like they did with the
> > raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
> > more that is what most testers can get their hands on easily.. and it
> > is not a aarch64 platform we support).
> 
> I may be going off in the weeds here, but is https://fedoraproject.org/
> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
> accurate when it says it *is* supported?

I'd say it's slightly unclear. So far as *the ARM team* is concerned,
they 'support' that hardware, but so far as *anyone else* is concerned,
aarch64 has been a secondary arch all this time. No aarch64 image has
been considered 'release-blocking', the aarch64 trees / images are
published in the fedora-secondary tree (not the fedora tree), etc.
-- 
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 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
> On 8 January 2018 at 12:28, Matthew Miller  wrote:
> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
> > > A significant miss here is 'testing'. Making an arch primary means we
> > > need to ensure we have the necessary resources to run all the relevant
> > > validation testing.
> > 
> > Are there hardware needs here? (Like, not in the server room but in QA
> > team member's hands?)
> > 
> 
> I would say in both. We would need to make sure we have enough systems
> which openqa can reliably run on and we need to have some sort of
> system that testers can get a hand on. That would require a bit of a
> 'we expect this hardware to work and this is how you buy/get it' from
> the aarch64 team..

pwhalen says we already have hardware available in phx, but I haven't
asked him for more details yet.

We wouldn't need much to run the necessary tests, really. Enough boxes
to run ~8 VMs simultaneously would probably suffice.
-- 
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 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Mon, 2018-01-08 at 12:28 -0500, Matthew Miller wrote:
> On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
> > A significant miss here is 'testing'. Making an arch primary means we
> > need to ensure we have the necessary resources to run all the relevant
> > validation testing.
> 
> Are there hardware needs here? (Like, not in the server room but in QA
> team member's hands?)

pwhalen has hardware. Not sure who else does. I'm not going to ask for
any, because it'd just join all my ARM hardware in the Pile Of Boxes I
Never Get Time To Open.
-- 
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: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

[Justin Forbes]

tl;dr:
We are fixing things as quickly as we can safely do so. The fixes will
be ongoing, keep testing and installing new kernels as they appear!

On Sat, Jan 6, 2018 at 1:32 PM, Chris Adams  wrote:
> Once upon a time, Adam Williamson  said:
>> * If the fix does cause problems on your hardware, you can disable it
>> by booting with the kernel parameter 'nopti'.
>
> So, on RHEL/CentOS kernels, there are three new entries in
> /sys/kernel/debug/x86; ibpb_enabled, ibrs_enabled, and pti_enabled.  I
> don't see these on the Fedora kernel.
>
> Are these variables something added by Red Hat to their kernel,
> something that will be added to Fedora, etc.?  They are useful to see
> exactly what fix(es) are being applied, as well as to have a runtime way
> to enable/disable them.

These do not exist in Fedora yet. For KPTI, the feature is
implemented, but there isn't a debugfs entry.  Variant 2 Spectre
mitigation has a couple of proposed solutions. IBRS and retpoline are
both being discussed upstream, and the end result will likely be a
combination of the 2.  Unfortunately both have external requirements.
Retpoline requires GCC patches, and microcode updates for some CPUs.
IBRS requires microcode updates. While RHEL has done quite a bit of
testing with IBRS in their kernels, Fedora moves a lot quicker and
current Fedora kernels are substantially different from the current
RHEL kernels. Additionally, while RHEL was given microcode to ship
with these updates, Intel has not released them upstream  (soon I am
told). It is entirely possible that the patches floating around
upstream have not been tested with the microcode that RHEL shipped.
Given that variant 2 is difficult (not impossible) to attack, we have
been waiting to see what we can ship, when microcode is available and
GCC updates are available.  I can assure you that I have spending
pretty much all of my time tracking upstream, testing patch sets, and
doing what I can to make sure we have mitigations for all 3 variants
in place as quickly as possible.
Today's build of rawhide contains mitigation for variant 1 of spectre
and variant 3 (meltdown) for x86_64. Current stable Fedora kernels
contain mitigation for meltdown on x86_64 as well. Wednesday should
see a new kernel pushed to updates-testing with some bug fixes for the
meltdown mitigation (KPTI), and some mitigation for variant 1. I am
hoping to also get some meltdown coverage for other architectures in
that update. While I would love to see some variant 2 coverage as
well, it is unlikely in the Wednesday time frame.  If it is possible,
I will include those as well, but even then, it will not be the final
solution.  As soon as a solution is deemed ready, it will be pushed to
Fedora.

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

[Fedocal] Reminder meeting : Modularity WG (once every two weeks)

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Modularity WG (once every two weeks) on 2018-01-09 from 10:00:00 to 11:00:00 
US/Eastern
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Working Group.

More information available at: [Modularity Working Group wiki 
page](https://fedoraproject.org/wiki/Modularity_Working_Group)

The agenda for the meeting is available at [modularity-wg-agendas 
pad](https://board.net/p/modularity-wg-agendas).



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

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

Re: Ruby 2.5 - Mass rebuild

[Dominik 'Rathann' Mierzejewski]

Hi, Vít.

On Monday, 08 January 2018 at 15:19, Vít Ondruch wrote:
> Hi everybody,
> 
> The sidetag with Ruby 2.5 and all the rebuilt packages were merged into
> F25 [1]. Since the update of Ruby involved soname
> bump, we managed to rebuild most of the depending packages. But there
> are still some packages which are broken for various reasons (you can
> see the analysis of them here [2]. But luckily, some of the issues from
> the list were already resolved). We will try to fix them, but of course,
> any help is welcome.
> 
> Also, please check your pure Ruby packages for compatibility with Ruby
> 2.5 (Koschei will help you to catch those issues), but there were no
> major issues during rebuild, so I am quite positive there wont be many.
> 
> Let us know if you need some help ...

I could use some help debugging mkvtoolnix build failure. It doesn't
depend on Ruby directly, but it uses drake to build:
https://apps.fedoraproject.org/koschei/package/mkvtoolnix?collection=f28
and fails with:
[...]
rake aborted!
File exists @ dir_s_mkdir - ./rake.d/dependency.d

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changelog between OS states (ie: VMs)

[Jonathan Lebon]

- Original Message -
> On Mon, Jan 8, 2018 at 2:52 PM, Jonathan Lebon  wrote:
> > Interestingly, these are both things that Atomic Host make
> > easier to query.
> >
> > E.g. if both VMs are on AH but sitting on different commits,
> > you can pull the commit on one of the two and do:
> >
> > $ rpm-ostree db diff COMMIT1 COMMIT2
> 
> oh, that's so very nice. Can it be extracted, split out to a script?
> (ie: point it to two rpmdb dirs...)

It's not pretty, though here's a Gist that does this:

https://gist.github.com/jlebon/790fcd04646e10bb09ae7993b20ca307

You'll need `ostree` and `rpm-ostree` (which can be
installed equally well in yum/dnf-managed systems).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

[Nico Kadel-Garcia]

On Mon, Jan 8, 2018 at 3:38 PM, Fernando Nasser  wrote:
> On 2018-01-08 3:07 PM, Nico Kadel-Garcia wrote:
>>
>> On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser 
>> wrote:
>>>
>>> On 2018-01-08 12:21 PM, Steve Dickson wrote:

 Hello,

 Is it a problem for a package to pull from two different
 upstream tar balls? Basically have

 Source0: http://server.com/package1/package1.tar
 Source1: http://server.com/package2/package2.tar
>>
>> It happens all the time. Subversion used to do this a lot, when the
>> requirement for the "swig" library was more recent than what was in
>> Fedora. It also happens quite a lot for RHEL and EPEL packages, where
>> the necessary versions of various libraries may conflict with the
>> stable, standard library used by other tools.
>
>
> Hum... not sure if this was good form.  An important security fix may fail
> to be applied to this "hidden" library for one thing.

This is absolutely true. It's especially been necessary for various
EPEL packages, which may have requirements of more recent libraries.

> This is supposed to be handled by having a versioned package for the
> alternative library version that could then be used by this package (as
> opposed as the default Fedora version of it).

Yeah. It can be awkward to maintain, and the potential requirement is
precisely why the "%setup" macro in RPM is designed to support the
extraction of multiple tarballs in an arbitrary build layout: because
some packages are published as a set of multiple tarballs. "git", for
example, has often been built from the distinct git, git-html, and
git-manpages tarballs from upstream in order to avoid having to build
those other components and require all the build tools for
documentation on the local RPM build environment. Been there, done
that, publish tools for CentOS 6 and 7 for git-2.15 at
https://github.com/nkadel/git215-srpm/blob/master/git215.spec

"texlive" is a better example, since it has so many source tarballs
for different fonts from upstreamy. I count roughly 7000 distinct
Source tarballs listed in texlive.spec, Those *are* the Fedora system
component for those fonts, so it's a better example of where the usage
or multiple tarballs makes great sense sense.

Building distinct, internal libraries has been unusual to need
directly for Fedora, since Fedora tends to be near the bleeding edge
of software releases. But it's certainly happened on occasion,
especially if software needs to be backported to EPEL for RHEL and
CentOS use, or for for older versions of Fedora.

> This has similar problems as using the Maven shadow plugin in Fedora Java
> builds (which is AFAIK also discouraged).
>
> --Fernando
>
>
>
>> ___
>> 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: Changelog between OS states (ie: VMs)

[Martin Langhoff]

On Mon, Jan 8, 2018 at 2:52 PM, Jonathan Lebon  wrote:
> Interestingly, these are both things that Atomic Host make
> easier to query.
>
> E.g. if both VMs are on AH but sitting on different commits,
> you can pull the commit on one of the two and do:
>
> $ rpm-ostree db diff COMMIT1 COMMIT2

oh, that's so very nice. Can it be extracted, split out to a script?
(ie: point it to two rpmdb dirs...)

thanks,




m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

[Fernando Nasser]

On 2018-01-08 3:07 PM, Nico Kadel-Garcia wrote:

On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser  wrote:

On 2018-01-08 12:21 PM, Steve Dickson wrote:

Hello,

Is it a problem for a package to pull from two different
upstream tar balls? Basically have

Source0: http://server.com/package1/package1.tar
Source1: http://server.com/package2/package2.tar

It happens all the time. Subversion used to do this a lot, when the
requirement for the "swig" library was more recent than what was in
Fedora. It also happens quite a lot for RHEL and EPEL packages, where
the necessary versions of various libraries may conflict with the
stable, standard library used by other tools.


Hum... not sure if this was good form.  An important security fix may 
fail to be applied to this "hidden" library for one thing.


This is supposed to be handled by having a versioned package for the 
alternative library version that could then be used by this package (as 
opposed as the default Fedora version of it).


This has similar problems as using the Maven shadow plugin in Fedora 
Java builds (which is AFAIK also discouraged).


--Fernando



___
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 1532230] perl-RPM2-1.4 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-RPM2-1.4-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-0bfed89ef0

-- 
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: Package Question

[Nico Kadel-Garcia]

On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser  wrote:
> On 2018-01-08 12:21 PM, Steve Dickson wrote:
>>
>> Hello,
>>
>> Is it a problem for a package to pull from two different
>> upstream tar balls? Basically have
>>
>> Source0: http://server.com/package1/package1.tar
>> Source1: http://server.com/package2/package2.tar

It happens all the time. Subversion used to do this a lot, when the
requirement for the "swig" library was more recent than what was in
Fedora. It also happens quite a lot for RHEL and EPEL packages, where
the necessary versions of various libraries may conflict with the
stable, standard library used by other tools.
___
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
 1036  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 799  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 381  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 278  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 110  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  48  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  36  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d704442ae7   
qpid-cpp-1.37.0-1.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-957aa05f33   
heketi-5.0.1-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-753e392fc4   
xrdp-0.9.5-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2e2d08b1ff   
awstats-7.6-4.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-49ca8440a1   
gifsicle-1.90-1.el7


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

composer-1.6.2-1.el7
debootstrap-1.0.93-1.el7
dh-make-2.201701-1.el7
ocserv-0.11.10-1.el7
php-composer-spdx-licenses-1.2.0-1.el7
python-www-authenticate-0.9.2-3.el7
shorewall-5.1.10.2-1.el7

Details about builds:



 composer-1.6.2-1.el7 (FEDORA-EPEL-2018-a6e741d0c1)
 Dependency Manager for PHP

Update Information:

**composer 1.6.2** - 2018-01-05* Fixed more autoloader regressions   * Fixed
support for updating dist refs in gitlab URLs  ---  **composer 1.6.1** -
2018-01-04* Fixed upgrade regression due to some autoloader cleanups   *
Fixed some overly loose version constraints    **composer 1.6.0** -
2018-01-04* Added support for SPDX license identifiers v3.0, deprecates
GPL/LGPL/AGPL identifiers, which should now have a `-only` or `-or-later` suffix
added.   * Added support for COMPOSER_MEMORY_LIMIT env var to make Composer set
the PHP memory limit explicitly   * Added support for simple strings for the
`bin`   * Fixed `check-platform-reqs` bug in version checking  ---  **composer
1.6.0RC** -  2017-12-19* Improved performance of installs and updates from
git clones when checking out known commits   * Added `check-platform-reqs`
command that checks that your PHP and extensions versions match the platform
requirements of the installed packages   * Added `--with-all-dependencies` to
the `update` and `require` commands which updates all dependencies of the listed
packages, including those that are direct root requirements   * Added `scripts-
descriptions` key to composer.json to customize the description and document
your custom commands   * Added support for the uppercase NO_PROXY env var   *
Added support for COMPOSER_DEFAULT_{AUTHOR,LICENSE,EMAIL,VENDOR} env vars to
pre-populate init command values   * Added support for local fossil repositories
* Added suggestions for alternative spellings when entering packages in `init`
and `require` commands and nothing can be found   * Fixed installed.json data to
be sorted alphabetically by package name   * Fixed compatibility with Symfony
4.x components that Composer uses  ---  **spdx-licenses 1.2.0** - 2018-01-03
* Added: deprecation status for all licenses and a
`SpdxLicenses::isDeprecatedByIdentifier` method.   * Changed: updated licenses
list to SPDX 3.0.




 debootstrap-1.0.93-1.el7 (FEDORA-EPEL-2018-082cb9794e)
 Debian GNU/Linux bootstrapper

Update Information:

Update to 1.0.93 (#1523424)

References:

  [ 1 ] Bug #1523424 - debootstrap-1.0.93 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1523424




 dh-make-2.201701-1.el7 (FEDORA-EPEL-2018-f7eb7c1747)
 Tool that converts source archives into Debian package source

Update Information:

Update to 2.201701 (#1527706)

References:

  [ 1 ] Bug #1527706 - dh-make-2.201701 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1527706

Re: Changelog between OS states (ie: VMs)

[Jonathan Lebon]

- Original Message -
> On Mon, Jan 8, 2018 at 1:19 PM, Nico Kadel-Garcia  wrote:
> I fully agree wrt configuration changes. I am scoping my interest
> exclusively to rpms.
> 
> A bit like saying "I run yum/dnf update on an OS, what bugfixes are
> landing/have landed?"

Interestingly, these are both things that Atomic Host make
easier to query.

E.g. if both VMs are on AH but sitting on different commits,
you can pull the commit on one of the two and do:

$ rpm-ostree db diff COMMIT1 COMMIT2

to get a diff of the rpmdb between the two, and with the
`--changelogs` flag, it will also output new changelog
entries.

Re. configuration changes, not exactly what you were looking
for, though `ostree admin config-diff` allows you to see
which `/etc` files were changed/added/removed from the base
shipped configuration.

Anyway, I realize this doesn't help if your VMs are not
currently on AH, though just thought I'd bring it up for
general interest!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 909  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 799  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 770  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 381  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 110  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-37c8dbd6f1   
gifsicle-1.90-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6


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

GeoIP-GeoLite-data-2018.01-1.el6
debootstrap-1.0.93-1.el6

Details about builds:



 GeoIP-GeoLite-data-2018.01-1.el6 (FEDORA-EPEL-2018-330c1e51f5)
 Free GeoLite IP geolocation country database

Update Information:

Update to current databases.




 debootstrap-1.0.93-1.el6 (FEDORA-EPEL-2018-ffc9433d89)
 Debian GNU/Linux bootstrapper

Update Information:

Update to 1.0.93 (#1523424)    new upstream release

References:

  [ 1 ] Bug #1523424 - debootstrap-1.0.93 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1523424

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

Re: Package Question

[Fernando Nasser]

On 2018-01-08 12:21 PM, Steve Dickson wrote:

Hello,

Is it a problem for a package to pull from two different
upstream tar balls? Basically have

Source0: http://server.com/package1/package1.tar
Source1: http://server.com/package2/package2.tar


Important questions:

1) Are the lifecycles the same?

2) Can one be built independently of the other?

3) Are the licenses the same?  Is the IP owner the same?


I am just wondering if these cannot be split into two packages, built 
one after the other.



Maybe it is necessary to look into the specifics of the case, instead of 
trying to reason over a generic case.


What are you trying to package exactly?


Regards,
Fernando




Then I would, by hand, untar Source1 into Source0 directory.

Before do the work I want to make sure I'm not
breaking violating any package rules. I did look
around and didn't see anything addressing this.

If this is kosher, are there any examples of other
packages doing this...

tia,

steved.
___
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: Security updates and batched pushes

[Kevin Kofler]

Kevin Fenzi wrote:
> Well, if this firefox update was urgent, shouldn't it have been marked
> urgent?

Urgency is always in the eye of the beholder. I as a user consider all 
security updates "urgent", and in addition, I want ALL updates as soon as 
they passed testing no matter whether they actually are urgent.

>> I really don't understand why we do this "batched" thing to begin with.
> 
> To reduce the constant flow of updates that are very minor or affect
> very few mixed in with the major updates that affect lots of people and
> are urgent.

But the users were already able to opt to update only weekly. So why force a 
fixed schedule on them?

> To save users downloads of repodata.

This does not work in practice because there is almost always at least one 
urgent update that requires downloading the whole repodata. (And also 
because maintainers are free to skip batched without giving a reason. I 
always do this because I consider batching a disservice to my users.)

> rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch
> appears on wed's pushes).
> 
> There was some discussion about changing the gnome batching based on the
> Fedora batching, but I don't know whats happened there.

But what if this is a company that wants to do weekly updates on Monday 
morning in order to be free from disruptions for the working week? Then they 
will get the updates up to almost 2 weeks late rather than up to 1 week as 
both you and they intend.

Batching really needs to be left to the client side!

> I haven't seen a bunch of urgent updates get blocked by this process.
> Do you have more data for updates that hit this?

I have empirically seen security updates end up in the batches, but I have 
not checked each of them to see whether it actually went through "batched" 
or just happened to go out on that day.

But again, I think it is essential for users to be able to opt to getting 
updates without arbitrary delays.

>> If people insist on that "batched" misfeature, can we please at least get
>> a fast track repository that contains all the batched updates (but no
>> updates that are still in testing and have not been batched yet!)?
> 
> I would be very much against additional repos like this.

Why? It would allow you to keep the server-side batching while still 
allowing those users like me to opt out of it. And the repodata download 
size for fast track would be minimal if updates that went out to stable get 
removed from fast track.

Even RHEL has a fast track repository.

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

Re: F28 System Wide Change: AArch64 Server Promotion

[Stephen John Smoogen]

On 8 January 2018 at 13:03, Jonathan Dieter  wrote:
> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>> On 8 January 2018 at 12:28, Matthew Miller 
>> wrote:
>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>> > > A significant miss here is 'testing'. Making an arch primary
>> > > means we
>> > > need to ensure we have the necessary resources to run all the
>> > > relevant
>> > > validation testing.
>> >
>> > Are there hardware needs here? (Like, not in the server room but in
>> > QA
>> > team member's hands?)
>> >
>>
>> I would say in both. We would need to make sure we have enough
>> systems
>> which openqa can reliably run on and we need to have some sort of
>> system that testers can get a hand on. That would require a bit of a
>> 'we expect this hardware to work and this is how you buy/get it' from
>> the aarch64 team.. otherwise most everyone is going to come and ask
>> why the raspberry pi 3 isn't supported (just like they did with the
>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
>> more that is what most testers can get their hands on easily.. and it
>> is not a aarch64 platform we support).
>
> I may be going off in the weeds here, but is https://fedoraproject.org/
> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
> accurate when it says it *is* supported?
>

Well I am off by a year or more on supported hardware and was passing
along DUD (Dodgy Unusable Data). That said it would be good to know
what hardware that they want testing on.. in case there is something
about XYZ hardware which makes it bootable/runnable but more out of
luck than anything people want to put effort to fix on.

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

Re: F28 System Wide Change: AArch64 Server Promotion

[Dennis Gilmore]

El lun, 08-01-2018 a las 09:16 -0800, Adam Williamson escribió:
> On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote:
> > 
> > == Scope ==
> > * Proposal owners:
> > The general AArch64 support is already in place and is widely and
> > actively supported by the Fedora ARM SIG and numerous ARM vendors
> > and
> > third parties in Fedora. There will be further and wider support,
> > hardware enablement, polish and general improvements.
> > 
> > * Other developers:
> > N/A: There's no work required for other developers, the aarch64
> > architecture is already widely supported as an Alternate
> > Architecture.
> > 
> > * Release engineering:
> > Needs approval from release engineering as a primary architecture
> > as
> > well as pungi configuration changes to output artifacts to new
> > location on the primary mirror.
> > rel-eng ticket #7243: https://pagure.io/releng/issue/7243
> > 
> > * Policies and guidelines:
> > Updates to the primary architectures and release blocking details
> > will
> > need to be updated to reflect that the AArch64 Server/Cloud/Docker
> > components are now considered primary.
> > 
> > * Trademark approval:
> > N/A (not needed for this Change)
> 
> A significant miss here is 'testing'. Making an arch primary means we
> need to ensure we have the necessary resources to run all the
> relevant
> validation testing.
> 
> I note pwhalen is a co-owner of the proposal so he's likely signed up
> to ensure testing gets done, but still, it should be properly covered
> in the Change document itself.
> 
> As a further note, almost all the Server validation for x86_64 is
> done
> by openQA; doing it manually can be a considerable pain, as you have
> to
> set up a mini FreeIPA deployment. It would probably be best if we add
> aarch64 workers to the Fedora openQA deployment to run these tests on
> aarch64; we've already extended openQA (staging) to ppc64, so all the
> bits should be in place for us to add another arch, pretty much. I'm
> going to follow up on this with pwhalen.
> 
> Another consideration would be whether we ought to also have aarch64
> support in Taskotron, if it's going to become a primary arch. I'm not
> actually sure if Taskotron currently covers 32-bit ARM, though, even.

currently taskotron is x86 only.  I am not sure what it would take to
extend it beyond x86, it would be a worthwhile investigation. It would
be useful to have all arches in openQA regardless of primary or
secondary status. I would like to see openQA working for aarch64 in
Fedora's instance a hard requirement of this change.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

[nicolas . mailhot]

Hi,

It can be done but it's a PITA to maintain and it's a very bad idea to do if 
the two packages are actually two different projects with different lifecycle 
expectations, legalities, etc

See the convolutions of the %setup macro

Regards,

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

Re: Changelog between OS states (ie: VMs)

[Martin Langhoff]

On Mon, Jan 8, 2018 at 1:19 PM, Nico Kadel-Garcia  wrote:
> On Mon, Jan 8, 2018 at 12:59 PM, Martin Langhoff
>  wrote:
>> I have two VMs, or OS states I can `rpm -qa` on. Is there a script to
>> diff the output of the two listings, and then query the package
>> changelogs to generate an overall OS-wide changelog?
>
> This is so sensitive to individual environment requirements it has
> never been standardized well that I've seen. It *always* gets done by
> the local admin, to fit their requirments.

I fully agree wrt configuration changes. I am scoping my interest
exclusively to rpms.

A bit like saying "I run yum/dnf update on an OS, what bugfixes are
landing/have landed?"

cheers,


m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changelog between OS states (ie: VMs)

[Nico Kadel-Garcia]

On Mon, Jan 8, 2018 at 12:59 PM, Martin Langhoff
 wrote:
> I have two VMs, or OS states I can `rpm -qa` on. Is there a script to
> diff the output of the two listings, and then query the package
> changelogs to generate an overall OS-wide changelog?

This is so sensitive to individual environment requirements it has
never been standardized well that I've seen. It *always* gets done by
the local admin, to fit their requirments.

If you really want to store system configs to be able to do diffs, I
personally pull backups to a secured central server with tools like
"rsnapshot" to get daily backups of all of "/etc/" and "/root/" and a
few critical logs It's very stable, very robust, and very flexible.

> Use case: I generated an F26 OVA image using imagefactory 30 days ago,
> then I generated a new F26 image today. I'd export rpm -qa listings
> from both, and then get a changelog showing all the package updates,
> expecting to see the kernel package with the recent CVEs fixed.
>
> Does such a tool exist?
>
>
>
>
> m
> --
>  martin.langh...@gmail.com
>  - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
>  - don't be distracted~  http://github.com/martin-langhoff
>by shiny stuff
> ___
> 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 System Wide Change: AArch64 Server Promotion

[Przemek Klosowski]

On 01/08/2018 01:06 PM, Andreas Tunek wrote:

That link does not work for me and I get some strange redirect to the
Fedora download page.

There was something odd in the link---this works for me:

https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi

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

Re: Package Question

[Rob Crittenden]

Ben Rosser wrote:
> On Mon, Jan 8, 2018 at 12:58 PM, Rob Crittenden  wrote:
>> Florian Weimer wrote:
>>> On 01/08/2018 06:21 PM, Steve Dickson wrote:
 Is it a problem for a package to pull from two different
 upstream tar balls? Basically have

 Source0:http://server.com/package1/package1.tar
 Source1:http://server.com/package2/package2.tar

 Then I would, by hand, untar Source1 into Source0 directory.
>>>
>>> That's fairly common.  I don't particularly like it, but if it's the way
>>> upstream ships things, there isn't much choice.
>>
>> wine is an example of this. wine-staging is provided as a separate
>> tarball of patches that are applied before build.
> 
> This is also the recommended way to handle git submodules, according
> to the packaging guidelines.
> 
> https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Submodules

It isn't a sub-module. It is a quasi-related project AIUI.

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

Re: Disable a package for Fedora 26

[Kevin Fenzi]

On 01/08/2018 06:20 AM, Jonny Heggheim wrote:
> Hi!
> 
> We just pused a urgent security update for Electrum for Fedora 27 and
> rawhide, Fedora 26 is still affected.
> 
> All versions of Electrum is affected by this bug, Fedora 26 still runs
> an older version because of big changes in Electrum 3.0 and an updated
> version of a dependency.
> 
> So I see 3 options:
> 
>  * Upgrade to latest version for Fedora 26. Will take time to update and
> might brake something else.

I think this might be the best option here. It would leave things close
to upstream so you could upgrade from there or report bugs and get help.
> 
>  * Create a patch for the version running on Fedora 26. Will take time
> to make the patch and test on Fedora 26.

This seems less good because you are diverging from upstream and will
have to maintain the backport yourself.

>  * Make an update that disables Electrum, include only a README or
> someting like that. Will make users confused.

This is not a good option, IMHO.

> Any better options?
> 
> See https://bodhi.fedoraproject.org/updates/FEDORA-2018-4978426286 for
> details

I'd advise the first path...

kevin




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

Re: Package Question

[Ben Rosser]

On Mon, Jan 8, 2018 at 12:58 PM, Rob Crittenden  wrote:
> Florian Weimer wrote:
>> On 01/08/2018 06:21 PM, Steve Dickson wrote:
>>> Is it a problem for a package to pull from two different
>>> upstream tar balls? Basically have
>>>
>>> Source0:http://server.com/package1/package1.tar
>>> Source1:http://server.com/package2/package2.tar
>>>
>>> Then I would, by hand, untar Source1 into Source0 directory.
>>
>> That's fairly common.  I don't particularly like it, but if it's the way
>> upstream ships things, there isn't much choice.
>
> wine is an example of this. wine-staging is provided as a separate
> tarball of patches that are applied before build.

This is also the recommended way to handle git submodules, according
to the packaging guidelines.

https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Submodules

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

Re: F28 System Wide Change: AArch64 Server Promotion

[Andreas Tunek]

2018-01-08 19:03 GMT+01:00 Jonathan Dieter :
> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>> On 8 January 2018 at 12:28, Matthew Miller 
>> wrote:
>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>> > > A significant miss here is 'testing'. Making an arch primary
>> > > means we
>> > > need to ensure we have the necessary resources to run all the
>> > > relevant
>> > > validation testing.
>> >
>> > Are there hardware needs here? (Like, not in the server room but in
>> > QA
>> > team member's hands?)
>> >
>>
>> I would say in both. We would need to make sure we have enough
>> systems
>> which openqa can reliably run on and we need to have some sort of
>> system that testers can get a hand on. That would require a bit of a
>> 'we expect this hardware to work and this is how you buy/get it' from
>> the aarch64 team.. otherwise most everyone is going to come and ask
>> why the raspberry pi 3 isn't supported (just like they did with the
>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
>> more that is what most testers can get their hands on easily.. and it
>> is not a aarch64 platform we support).
>
> I may be going off in the weeds here, but is https://fedoraproject.org/
> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
> accurate when it says it *is* supported?
>

That link does not work for me and I get some strange redirect to the
Fedora download page.

/Andreas Tunek
> Jonathan
> ___
> 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 System Wide Change: AArch64 Server Promotion

[Jonathan Dieter]

On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
> On 8 January 2018 at 12:28, Matthew Miller 
> wrote:
> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
> > > A significant miss here is 'testing'. Making an arch primary
> > > means we
> > > need to ensure we have the necessary resources to run all the
> > > relevant
> > > validation testing.
> > 
> > Are there hardware needs here? (Like, not in the server room but in
> > QA
> > team member's hands?)
> > 
> 
> I would say in both. We would need to make sure we have enough
> systems
> which openqa can reliably run on and we need to have some sort of
> system that testers can get a hand on. That would require a bit of a
> 'we expect this hardware to work and this is how you buy/get it' from
> the aarch64 team.. otherwise most everyone is going to come and ask
> why the raspberry pi 3 isn't supported (just like they did with the
> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
> more that is what most testers can get their hands on easily.. and it
> is not a aarch64 platform we support).

I may be going off in the weeds here, but is https://fedoraproject.org/
wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
accurate when it says it *is* supported?

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

Changelog between OS states (ie: VMs)

[Martin Langhoff]

I have two VMs, or OS states I can `rpm -qa` on. Is there a script to
diff the output of the two listings, and then query the package
changelogs to generate an overall OS-wide changelog?

Use case: I generated an F26 OVA image using imagefactory 30 days ago,
then I generated a new F26 image today. I'd export rpm -qa listings
from both, and then get a changelog showing all the package updates,
expecting to see the kernel package with the recent CVEs fixed.

Does such a tool exist?




m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

[Rob Crittenden]

Florian Weimer wrote:
> On 01/08/2018 06:21 PM, Steve Dickson wrote:
>> Is it a problem for a package to pull from two different
>> upstream tar balls? Basically have
>>
>> Source0:http://server.com/package1/package1.tar
>> Source1:http://server.com/package2/package2.tar
>>
>> Then I would, by hand, untar Source1 into Source0 directory.
> 
> That's fairly common.  I don't particularly like it, but if it's the way
> upstream ships things, there isn't much choice.

wine is an example of this. wine-staging is provided as a separate
tarball of patches that are applied before build.

rob

> 
>> If this is kosher, are there any examples of other
>> packages doing this...
> 
> glibc did that until Fedora 20.  We eventually split out the files in
> the tarball into individual source files, which was easy enough in our
> case (and the files were Fedora-specific anyway).
> 
> 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 System Wide Change: AArch64 Server Promotion

[Stephen John Smoogen]

On 8 January 2018 at 12:28, Matthew Miller  wrote:
> On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>> A significant miss here is 'testing'. Making an arch primary means we
>> need to ensure we have the necessary resources to run all the relevant
>> validation testing.
>
> Are there hardware needs here? (Like, not in the server room but in QA
> team member's hands?)
>

I would say in both. We would need to make sure we have enough systems
which openqa can reliably run on and we need to have some sort of
system that testers can get a hand on. That would require a bit of a
'we expect this hardware to work and this is how you buy/get it' from
the aarch64 team.. otherwise most everyone is going to come and ask
why the raspberry pi 3 isn't supported (just like they did with the
raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
more that is what most testers can get their hands on easily.. and it
is not a aarch64 platform we support).

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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

Re: Package Question

[Florian Weimer]

On 01/08/2018 06:21 PM, Steve Dickson wrote:

Is it a problem for a package to pull from two different
upstream tar balls? Basically have

Source0:http://server.com/package1/package1.tar
Source1:http://server.com/package2/package2.tar

Then I would, by hand, untar Source1 into Source0 directory.


That's fairly common.  I don't particularly like it, but if it's the way 
upstream ships things, there isn't much choice.



If this is kosher, are there any examples of other
packages doing this...


glibc did that until Fedora 20.  We eventually split out the files in 
the tarball into individual source files, which was easy enough in our 
case (and the files were Fedora-specific anyway).


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

Re: Security updates and batched pushes

[Kevin Fenzi]

On 01/07/2018 08:01 PM, Kevin Kofler wrote:
> Kevin Fenzi wrote:
>> The critera for bypassing batched is if the update is marked "urgent".
> 
> The problem is, this appears to be insufficient.
Well, if this firefox update was urgent, shouldn't it have been marked
urgent?

> I really don't understand why we do this "batched" thing to begin with. 

To reduce the constant flow of updates that are very minor or affect
very few mixed in with the major updates that affect lots of people and
are urgent. To save users downloads of repodata.

> Users who want to batch updates have always been able to do it, GNOME 
> Software will even do it for theNow, those users who want to batch their
> updates are forced to follow Fedora rel-eng's schedule for the batches 
> rather than being able to pick their own weekday, so how does the server-
> side batching help them? And those users (like me) who want to get their 
> updates, including security fixes (!) as we see here, as soon as they passed 
> testing are now screwed.

rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch
appears on wed's pushes).

There was some discussion about changing the gnome batching based on the
Fedora batching, but I don't know whats happened there.

I haven't seen a bunch of urgent updates get blocked by this process.
Do you have more data for updates that hit this?

> If people insist on that "batched" misfeature, can we please at least get a 
> fast track repository that contains all the batched updates (but no updates 
> that are still in testing and have not been batched yet!)?

I would be very much against additional repos like this.


kevin



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

Re: Package Question

[William Moreno]

2018-01-08 11:21 GMT-06:00 Steve Dickson :

> Hello,
>
> Is it a problem for a package to pull from two different
> upstream tar balls? Basically have
>
> Source0: http://server.com/package1/package1.tar
> Source1: http://server.com/package2/package2.tar
>
> Then I would, by hand, untar Source1 into Source0 directory.
>
> Before do the work I want to make sure I'm not
> breaking violating any package rules. I did look
> around and didn't see anything addressing this.
>
>
>
Patch the content of the package2 inside the package1 do not work the same?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Matthew Miller]

On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
> A significant miss here is 'testing'. Making an arch primary means we
> need to ensure we have the necessary resources to run all the relevant
> validation testing.

Are there hardware needs here? (Like, not in the server room but in QA
team member's hands?)

-- 
Matthew Miller

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

[389-devel] Please review: Ticket 49523 - Refactor CI test

[Simon Pichugin]

https://pagure.io/389-ds-base/issue/49523

https://pagure.io/389-ds-base/issue/raw/files/da1e9819a28050aed3d00828a1b8212f19420411d6fd8e11aabe7a6776f851c3-0001-Ticket-49523-Refactor-CI-test.patch


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

Package Question

[Steve Dickson]

Hello,

Is it a problem for a package to pull from two different 
upstream tar balls? Basically have 

Source0: http://server.com/package1/package1.tar
Source1: http://server.com/package2/package2.tar

Then I would, by hand, untar Source1 into Source0 directory.

Before do the work I want to make sure I'm not
breaking violating any package rules. I did look
around and didn't see anything addressing this.

If this is kosher, are there any examples of other
packages doing this... 

tia,

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

Re: F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote:
> 
> == Scope ==
> * Proposal owners:
> The general AArch64 support is already in place and is widely and
> actively supported by the Fedora ARM SIG and numerous ARM vendors and
> third parties in Fedora. There will be further and wider support,
> hardware enablement, polish and general improvements.
> 
> * Other developers:
> N/A: There's no work required for other developers, the aarch64
> architecture is already widely supported as an Alternate Architecture.
> 
> * Release engineering:
> Needs approval from release engineering as a primary architecture as
> well as pungi configuration changes to output artifacts to new
> location on the primary mirror.
> rel-eng ticket #7243: https://pagure.io/releng/issue/7243
> 
> * Policies and guidelines:
> Updates to the primary architectures and release blocking details will
> need to be updated to reflect that the AArch64 Server/Cloud/Docker
> components are now considered primary.
> 
> * Trademark approval:
> N/A (not needed for this Change)

A significant miss here is 'testing'. Making an arch primary means we
need to ensure we have the necessary resources to run all the relevant
validation testing.

I note pwhalen is a co-owner of the proposal so he's likely signed up
to ensure testing gets done, but still, it should be properly covered
in the Change document itself.

As a further note, almost all the Server validation for x86_64 is done
by openQA; doing it manually can be a considerable pain, as you have to
set up a mini FreeIPA deployment. It would probably be best if we add
aarch64 workers to the Fedora openQA deployment to run these tests on
aarch64; we've already extended openQA (staging) to ppc64, so all the
bits should be in place for us to add another arch, pretty much. I'm
going to follow up on this with pwhalen.

Another consideration would be whether we ought to also have aarch64
support in Taskotron, if it's going to become a primary arch. I'm not
actually sure if Taskotron currently covers 32-bit ARM, though, even.
-- 
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 1532250] perl-Net-SSLeay fails to connect to some SSL servers

[bugzilla]

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



--- Comment #3 from Paul Howarth  ---
Requests for enhancements to Net::SSLeay's error messages would be best off
directed to the upstream maintainer. The documentation suggests
https://alioth.debian.org/projects/net-ssleay but
https://rt.cpan.org/Public/Dist/Display.html?Name=net-ssleay would probably
work too.

-- 
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 1532250] perl-Net-SSLeay fails to connect to some SSL servers

[bugzilla]

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



--- Comment #2 from Need Real Name  ---
Thank you, Paul. I will fix the script with the 
 SSL_cipher_list => 'DES-CBC3-SHA'
that you recommended, I have no control over the site www.halstead.com

My bug report was mostly about perl-Net-SSLeay cryptic error message:

DEBUG: .../IO/Socket/SSL.pm:749: local error: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:752: fatal SSL error: SSL connect attempt failed

I think that perl-Net-SSLeay can be much improved by making better SSL error
messages.

-- 
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 1532250] perl-Net-SSLeay fails to connect to some SSL servers

[bugzilla]

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



--- Comment #1 from Paul Howarth  ---
The problem here is that the target server doesn't support newer SSL
protocols/ciphers, and the ones it does support are below the standard required
by the system-wide crypto policy (see
https://fedoraproject.org/wiki/Changes/CryptoPolicy), which is implemented in
Fedora's perl-IO-Socket-SSL package (this is why your use of raw Net::SSLeay
works, and IO::Socket::SSL doesn't).

I can make it work by changing the IO::Socket::SSL->new() invocation to this:

my $cl = IO::Socket::SSL->new(
PeerHost => $ARGV[0],
PeerPort => 'https',
SSL_cipher_list => 'DES-CBC3-SHA'
);

A useful debugging tool for this is analyze-ssl.pl, which you can get from
https://github.com/noxxi/p5-ssl-tools (this is from the upstream maintainer of
IO::Socket::SSL).

Example output:
$ perl analyze-ssl.pl www.halstead.com:443
-- www.halstead.com port 443
 ! server sent unused chain certificate '/C=US/ST=New Jersey/L=Jersey
City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority'
 ! server sent unused chain certificate '/C=US/ST=New Jersey/L=Jersey
City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority'
 * maximum SSL version  : TLSv1 (SSLv23)
 * supported SSL versions with handshake used and preferred cipher(s):
   * handshake protocols ciphers
   * SSLv23TLSv1 DES-CBC3-SHA
   * TLSv1_2   FAILED: SSL connect attempt failed error:1417110A:SSL
routines:tls_process_server_hello:wrong ssl version SSL connect attempt failed
   * TLSv1_1   FAILED: SSL connect attempt failed error:1417110A:SSL
routines:tls_process_server_hello:wrong ssl version
   * TLSv1 TLSv1 DES-CBC3-SHA
   * SSLv3 SSLv3 DES-CBC3-SHA
 * cipher order by  : unknown
 * SNI supported: ok
 * certificate verified : ok
 * chain on 209.173.134.149
   * [0/0] bits=2048, ocsp_uri=http://ocsp.netsolssl.com,
/C=US/postalCode=10065/ST=NY/L=New York/street=770 Lexington Ave/O=Halstead
Property/OU=Web/OU=Secure Link SSL Wildcard/CN=*.halstead.com
SAN=DNS:*.halstead.com,DNS:halstead.com
   * [1/1] bits=2048, ocsp_uri=http://ocsp.usertrust.com,
/C=US/ST=VA/L=Herndon/O=Network Solutions L.L.C./CN=Network Solutions OV Server
CA 2
   * [2/-] bits=4096, ocsp_uri=http://ocsp.usertrust.com, /C=US/ST=New
Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification 
Authority
   * [-/2] bits=4096, ocsp_uri=, /C=US/ST=New Jersey/L=Jersey City/O=The
USERTRUST Network/CN=USERTrust RSA Certification Authority
 * OCSP stapling: no stapled response
 * OCSP status  : good (soft error: http://ocsp.usertrust.com: OCSP
response failed: internalerror; subject: /C=US/ST=VA/L=Herndon/O=Network
Solutions L.L.C./CN=Network Solutions OV Server CA 2; /C=US/ST=New
Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Au
thority)

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

nfs-utils: does not compile in rawhide

[Steve Dickson]

Just an FYI... 

nfs-utils currently does not compile in rawhide do
to this change: 
   https://bugzilla.redhat.com/show_bug.cgi?id=1531540

We know about and should be resolved by the EOD...

Personally I think this is step in the right direction
but apologize for the inconvenience
 
steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Ruby 2.5 - Mass rebuild

[Vít Ondruch]

Dne 8.1.2018 v 16:10 Pavel Valena napsal(a):
> - Original Message -
>> From: "Vít Ondruch" 
>> To: ruby-...@lists.fedoraproject.org, "Development discussions related to 
>> Fedora" 
>> Sent: Monday, January 8, 2018 3:19:11 PM
>> Subject: Re: Ruby 2.5 - Mass rebuild
>>
>> Hi everybody,
>>
>> The sidetag with Ruby 2.5 and all the rebuilt packages were merged into
>> F25 [1]. Since the update of Ruby involved soname
> You probable meant F28, right? (ruby-2.5.0-86.fc28)

Right.

5 is dangerously close to 8 on my numerical keyboard. Sorry for the
confusion.


V.

>
>> bump, we managed to rebuild most of the depending packages. But there
>> are still some packages which are broken for various reasons (you can
>> see the analysis of them here [2]. But luckily, some of the issues from
>> the list were already resolved). We will try to fix them, but of course,
>> any help is welcome.
>>
>> Also, please check your pure Ruby packages for compatibility with Ruby
>> 2.5 (Koschei will help you to catch those issues), but there were no
>> major issues during rebuild, so I am quite positive there wont be many.
>>
>> Let us know if you need some help ...
>>
>> And special thanks goes to Mamoru, who handled the major part of the
>> rebuild.
> Good job, both of you!
>
> Pavel
>
>> Regards,
>>
>>
>> Vít
>>
>>
>> [1] https://pagure.io/releng/issue/7228
>> [2]
>> https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/XGQNGECLGHMCCA2CLEYWLGRJFR2AR3VV/
>>
>> ___
>> 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

[389-devel] revised: Ticket 49524 - password token checking breaks if password has the same length as the entry attribute

[Mark Reynolds]

https://pagure.io/389-ds-base/issue/raw/files/1e329597283ab242ecfe42394e817e7b408e215b73a8fc3dd715e0ed303d6a2b-0001-Ticket-49524-Password-policy-minimum-token-length-fa.patch

On 01/05/2018 12:47 PM, Mark Reynolds wrote:
> https://pagure.io/389-ds-base/issue/49524
>
> https://pagure.io/389-ds-base/issue/raw/files/fb4a688293da923749d296ea9e9750645194928c258fd1d2c1264ad1759c5c45-0001-Ticket-49524-Password-policy-minimum-token-length-fa.patch
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Ruby 2.5 - Mass rebuild

[Pavel Valena]

- Original Message -
> From: "Vít Ondruch" 
> To: ruby-...@lists.fedoraproject.org, "Development discussions related to 
> Fedora" 
> Sent: Monday, January 8, 2018 3:19:11 PM
> Subject: Re: Ruby 2.5 - Mass rebuild
> 
> Hi everybody,
> 
> The sidetag with Ruby 2.5 and all the rebuilt packages were merged into
> F25 [1]. Since the update of Ruby involved soname

You probable meant F28, right? (ruby-2.5.0-86.fc28)

> bump, we managed to rebuild most of the depending packages. But there
> are still some packages which are broken for various reasons (you can
> see the analysis of them here [2]. But luckily, some of the issues from
> the list were already resolved). We will try to fix them, but of course,
> any help is welcome.
> 
> Also, please check your pure Ruby packages for compatibility with Ruby
> 2.5 (Koschei will help you to catch those issues), but there were no
> major issues during rebuild, so I am quite positive there wont be many.
> 
> Let us know if you need some help ...
> 
> And special thanks goes to Mamoru, who handled the major part of the
> rebuild.

Good job, both of you!

Pavel

> 
> Regards,
> 
> 
> Vít
> 
> 
> [1] https://pagure.io/releng/issue/7228
> [2]
> https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/XGQNGECLGHMCCA2CLEYWLGRJFR2AR3VV/
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 System Wide Change: mpfr-4.0.0

[Jan Kurik]

= System Wide Change: mpfr-4.0.0 =
https://fedoraproject.org/wiki/Changes/mpfr-4.0.0

Change owner(s):
* James Paul Turner 

Update the MPFR package to version 4.0.0.


== Detailed Description ==
The purpose of this change is to update the Fedora MPFR package to the
latest version (4.0.0), released on the 25th December 2017. Due to a
soname bump, this change will rebuild all packages that depend on
MPFR.


== Scope ==
* Proposal owners:
- Rebuild of packages that depend on MPFR
- Minor specfile corrections and testing

* Other developers:
Testing and/or minor fixes of dependant packages

* Release engineering:
Separate Koji tag for package rebuild will be needed.
#7247: https://pagure.io/releng/issue/7247

* List of deliverables:
N/A (not needed for this Change)

* Policies and guidelines:
N/A (not needed for this Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
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

Flexible Metadata Format

[Petr Splichal]

Hi!

In order to keep test execution efficient when number of test
cases grows, it is crucial to maintain corresponding metadata,
which define some aspects of how the test coverage is executed.
For example limiting environment combinations where the test is
relevant or selecting a subset of important test cases for quick
verification of essential features when testing a security update.

Within the BaseOS QE team we were thinking (for a long time) about
an efficient metadata solution which would cover our use cases and
would be open source. Recently we've been involved in the Upstream
First initiative which increased the need for an open metadata
solution which would enable us to more easily share test code
between Red Hat Enterprise Linux and Fedora.

We've put together a draft solution which covers some of the most
important stories we've gathered so far. It does not cover all use
cases and it is not complete. In this early stage we would like to
invite others who might have similar use cases to gather your
feedback, share your experience or even join the project:

https://fedoraproject.org/wiki/Flexible_Metadata_Format

The page lists some of our core user stories as well as a couple of
real-life examples to demonstrate proposed features of the format.
Can you see similar user stories in your team? Is this something
that could be useful for you as well? Do you know of a different
solution for these use cases? Any other relevant ideas?

To illustrate where we could be heading: In the ideal future there
could be just a single test case for a particular feature stored
in public with a single set of metadata attached close to the test
code and together used for testing in both upstream and downstream
without need to duplicate the test code (maintain both copies).

This proposal does not suggest in any way to replace tests.yml [1]
files defined by the Standard Test Interface. The new format could
serve as an extension for selecting the right tests to be executed
(e.g. filtering tests by tag instead of listing them manually).

Looking forward to your feedback!

psss...

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

[Bug 1532095] perl-Mouse-2.5.1 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mouse-2.5.1-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|emman...@seyman.fr  |p...@city-fan.org
Last Closed||2018-01-08 09:28:46



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24075037

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

Disable a package for Fedora 26

[Jonny Heggheim]

Hi!

We just pused a urgent security update for Electrum for Fedora 27 and
rawhide, Fedora 26 is still affected.

All versions of Electrum is affected by this bug, Fedora 26 still runs
an older version because of big changes in Electrum 3.0 and an updated
version of a dependency.

So I see 3 options:

 * Upgrade to latest version for Fedora 26. Will take time to update and
might brake something else.

 * Create a patch for the version running on Fedora 26. Will take time
to make the patch and test on Fedora 26.

 * Make an update that disables Electrum, include only a README or
someting like that. Will make users confused.

Any better options?

See https://bodhi.fedoraproject.org/updates/FEDORA-2018-4978426286 for
details


Sincerely Jonny Heggheim




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: Ruby 2.5 - Mass rebuild

[Vít Ondruch]

Hi everybody,

The sidetag with Ruby 2.5 and all the rebuilt packages were merged into
F25 [1]. Since the update of Ruby involved soname
bump, we managed to rebuild most of the depending packages. But there
are still some packages which are broken for various reasons (you can
see the analysis of them here [2]. But luckily, some of the issues from
the list were already resolved). We will try to fix them, but of course,
any help is welcome.

Also, please check your pure Ruby packages for compatibility with Ruby
2.5 (Koschei will help you to catch those issues), but there were no
major issues during rebuild, so I am quite positive there wont be many.

Let us know if you need some help ...

And special thanks goes to Mamoru, who handled the major part of the
rebuild.

Regards,


Vít


[1] https://pagure.io/releng/issue/7228
[2]
https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/XGQNGECLGHMCCA2CLEYWLGRJFR2AR3VV/

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

[389-devel] Please Review: Issue 48118 - Add CI test case

[Amita Sharma]

Hello,

Please review my patch for - Add CI test for Replication test suit

https://pagure.io/389-ds-base/issue/48118

https://pagure.io/389-ds-base/issue/raw/files/67774c3468e49bb0457d1b36b7de325d2e1fb0b008e66e076e6a8031ec6c8074-0001-Ticket-48118-Add-CI-test-case.patch

Thanks & Regards,
Amita
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Anaconda modularization

[Matthew Miller]

On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote:
> Yep - basically, there will be no "old" and "new, DBUS/modular"
> Anaconda, the plan is to turn the current Anaconda to the new one one
> step at a time.
> 
> This should allow us to fix bugs as usual and handle any unforeseen
> modularization issues early on one-by-one as they show up.

It sounds like there actually isn't a contingency plan as such. Do you
think that this could all be reverted on Final Freeze day if we would
decide it's not working out? If not, let's not call that a contingency.

I'm not saying we shouldn't do this, but let's be honest with
ourselves. If the contingency plan is "None: we'll have to hold up the
release for fixes if it's not ready", the Change plan should say that.

-- 
Matthew Miller

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

F28 System Wide Change: AArch64 Server Promotion

[Jan Kurik]

= System Wide Change: AArch64 Server Promotion =
https://fedoraproject.org/wiki/Changes/AArch64_Server_Promotion

Change owner(s):
* Peter Robinson 
* Paul Whalen 

Promote Aarch64 server technologies to Primary Architecture status.
This would include the Server installer, the DVD installer ISOs, the
Cloud (qcow2 images) and Docker base images to the same status as
other primary Server architectures. This would NOT currently include
other components such as Workstation images/installs, any of the
various spins, or Fedora Atomic components.


== Detailed Description ==
The AArch64 Architecture in the server space is a mature product with
numerous platforms widely available for testing. We support both SBSA
Enterprise Haware as well as a number of Single Board Computers,
initially officially supported in Fedora 27 with the aarch64 SBC
Feature, with new device support being added all the time and more
widely available and affordable hardware.

The changes is actually a minor one as we already produce all the
deliverables as an Alternate Architecture, this primarily be a change
of where the output of the artifacts are delivered on the mirrors and
making the architecture a release blocking architecture.

This would NOT currently include other components such as Workstation
images/installs, any of the various spins, or Fedora Atomic
components.


== Scope ==
* Proposal owners:
The general AArch64 support is already in place and is widely and
actively supported by the Fedora ARM SIG and numerous ARM vendors and
third parties in Fedora. There will be further and wider support,
hardware enablement, polish and general improvements.

* Other developers:
N/A: There's no work required for other developers, the aarch64
architecture is already widely supported as an Alternate Architecture.

* Release engineering:
Needs approval from release engineering as a primary architecture as
well as pungi configuration changes to output artifacts to new
location on the primary mirror.
rel-eng ticket #7243: https://pagure.io/releng/issue/7243

* Policies and guidelines:
Updates to the primary architectures and release blocking details will
need to be updated to reflect that the AArch64 Server/Cloud/Docker
components are now considered primary.

* Trademark approval:
N/A (not needed for this Change)
-- 
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: Anaconda modularization

[Martin Kolman]

- Original Message -
> From: "Colin Walters" 
> To: "development discussions related to Fedora" 
> 
> Sent: Saturday, January 6, 2018 5:29:28 PM
> Subject: Re: F28 Self Contained Change: Anaconda modularization
> 
> 
> 
> On Fri, Jan 5, 2018, at 7:28 AM, Jan Kurik wrote:
> 
> > Anaconda installer will be split into several modules that will
> > communicate over DBus using stable API.
> 
> For the curious this blog entry is useful:
> http://blog-jkonecny.rhcloud.com/2017/06/16/shining-new-anaconda-modularisation/
> 
> I also would still like
> http://blog-jkonecny.rhcloud.com/2017/06/16/shining-new-anaconda-modularisation/#comment-3366641149
> 
> However my main concern here is: Anaconda is a baseline requirement
> for really doing much at all in releasing anything "Fedora" - for example
> we use Anaconda to generate both cloud images and the base container images.
> And obviously it's required to do bare metal installs.
> 
> There are a few ways I could imagine doing this; ideally Fedora releng
> would have a real branching concept.  I think it can sort of be set up
> manually.
> Do you have any plans to request that?
> 
> At least let's be ready with a fallback plan of using the existing codebase?
> Are there going to be git branches upstream so fixes can still land
> in the current installer?
As the changes will be done incrementally, we don't plan to use any special 
branches
and all usual bug fixes, feature development and modularization work will happen
on the master branch. 

> 
> For example I had plans to work on
> https://github.com/rhinstaller/anaconda/issues/1259
> sometime soon, and *hopefully* it shouldn't conflict with modularization
> but it seems likely the change would need to go in both branches or so?
As mentioned above, targeting the master branch should be fine.

> ___
> 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 1532250] New: perl-Net-SSLeay fails to connect to some SSL servers

[bugzilla]

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

Bug ID: 1532250
   Summary: perl-Net-SSLeay fails to connect to some SSL servers
   Product: Fedora
   Version: 27
 Component: perl-Net-SSLeay
  Assignee: p...@city-fan.org
  Reporter: m...@gromco.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, ka...@ucw.cz,
p...@city-fan.org, perl-devel@lists.fedoraproject.org



In F26 F27 compiled
perl-Net-SSLeay-1.82-1.fc26.x86_64
fails to connect to some SSL servers, , but to the other can connect OK
Below is a test case and two examples.
www.google.com perl-Net-SSLeay connects OK
www.halstead.com perl-Net-SSLeay fails.
Code example xu.pl is below.

This works OK
perl -w  xu.pl  'www.google.com'
And this one fails, and without any meaningful diag
perl -w  xu.pl  www.halstead.com

P.S. strange thing that this works OK
my($page) = Net::SSLeay::get_https('www.halstead.com', 443, '/');

--- sample code xu.pl 
use strict;
require Net::SSLeay;
require IO::Socket::SSL;
#require IO::Socket::SSL qw(debug9);

 $Net::SSLeay::trace = 3;
$Net::SSLeay::linux_debug =3 ;
# simple client
my $cl = IO::Socket::SSL->new($ARGV[0].":443");

print{*STDERR} "CL=",$cl,"\n";
print $cl "GET / HTTP/1.0\r\n\r\n";
print <$cl>;
- end sample code -

This works OK
perl -w  xu.pl  'www.google.com'
And this one fails, and without any Net::SSLeay diag, only SSL.pm
perl -w  xu.pl  www.halstead.com
Name "Net::SSLeay::trace" used only once: possible typo at xu.pl line 6.
Name "Net::SSLeay::linux_debug" used only once: possible typo at xu.pl line 7.
DEBUG: .../IO/Socket/SSL.pm:2764: new ctx 24108480
DEBUG: .../IO/Socket/SSL.pm:616: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:618: socket connected
DEBUG: .../IO/Socket/SSL.pm:641: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:674: using SNI with hostname www.halstead.com
DEBUG: .../IO/Socket/SSL.pm:709: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:743: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:746: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:749: local error: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:752: fatal SSL error: SSL connect attempt failed
DEBUG: ...erl5/IO/Socket.pm:49: ignoring less severe local error
'IO::Socket::IP configuration failed', keep 'SSL connect attempt failed'
DEBUG: .../IO/Socket/SSL.pm:2786: free ctx 24108480 open=24108480
DEBUG: .../IO/Socket/SSL.pm:2790: free ctx 24108480 callback
DEBUG: .../IO/Socket/SSL.pm:2797: OK free ctx 24108480
CL=Use of uninitialized value $cl in print at xu.pl line 11.

Can't use an undefined value as a symbol reference at xu.pl line 12.

-- 
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 1532232] perl-Text-Xslate-v3.5.6 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Text-Xslate-3.5.6-1.fc
   ||28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-08 08:26:54



-- 
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: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement

[Christian Kellner]

On Mon, 8 Jan, 2018 at 11:44 AM, Tom Hughes  wrote:
The only real concern then is that the implicit permanent 
authorisation of the device - that if you can once get an 
administrator to plug it in you can in future do so when they aren't 
present.
So if I am J Evil Hacker and I can get you to connect to my projector 
at a conference then I can in future plug my Evil Memory Stealer 
device in that presents the same ID and hence gets accepted.


Yep, that is indeed tricky. The problem is, that J Evil Hacker build 
the Evil Memory Stealer in such a way that you have to authorize it to 
get a picture at all and the already super nervous Speaker (who was 
already a bit late and his talk is of course too long) just wants to 
get that ** projector working NOW and so clicks YES YES YES on any 
dialog warning him. But you are of course right that this problem. For 
people who really care, the solution is to put the daemon in paranoid 
mode before going to untrusted environments. A better solution would be 
if we had a global status somewhere if we are in a safe or unsafe 
environment and honour that for thunderbolt and also usb etc. pp.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1532230] perl-RPM2-1.4 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-RPM2-1.4-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-0bfed89ef0

-- 
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 1532230] perl-RPM2-1.4 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-RPM2-1.4-1.fc28
   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 1532232] New: perl-Text-Xslate-v3.5.6 is available

[bugzilla]

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

Bug ID: 1532232
   Summary: perl-Text-Xslate-v3.5.6 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Text-Xslate
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: v3.5.6
Current version/release in rawhide: 3.5.4-1.fc28
URL: http://search.cpan.org/dist/Text-Xslate/

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/3455/

-- 
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 1532230] New: perl-RPM2-1.4 is available

[bugzilla]

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

Bug ID: 1532230
   Summary: perl-RPM2-1.4 is available
   Product: Fedora
   Version: rawhide
 Component: perl-RPM2
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.4
Current version/release in rawhide: 1.3-9.fc27
URL: http://search.cpan.org/dist/RPM2/

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/3306/

-- 
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: Anaconda modularization

[Martin Kolman]

- Original Message -
> From: jkone...@redhat.com
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, January 8, 2018 12:56:17 PM
> Subject: Re: F28 Self Contained Change: Anaconda modularization
> 
> On Sat, 2018-01-06 at 09:09 +, Zbigniew Jędrzejewski-Szmek wrote:
> > Wow, that sounds like a hefty change. Has the work already begun?
> > Is there a repo/branch where one can look at the WIP, test stuff,
> > etc?
> > 
> 
> We are already working on that and everything goes directly to master -
> "Rawhide" branch. The code is just not enabled right now on Rawhide but
> will be soon.
> 
> Our plan is to move incrementally on Rawhide - migrate one thing after
> another without changing functionality and without user noticeable impact.
> So everything should be incrementally tested on Rawhide, no big potentially
> disruptive flag days.
Yep - basically, there will be no "old" and "new, DBUS/modular" Anaconda,
the plan is to turn the current Anaconda to the new one one step at a time.

This should allow us to fix bugs as usual and handle any unforeseen 
modularization issues
early on one-by-one as they show up.
> 
> Jirka
> ___
> 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: Anaconda modularization

[jkonecny]

On Sat, 2018-01-06 at 09:09 +, Zbigniew Jędrzejewski-Szmek wrote:
> Wow, that sounds like a hefty change. Has the work already begun?
> Is there a repo/branch where one can look at the WIP, test stuff,
> etc?
> 

We are already working on that and everything goes directly to master -
"Rawhide" branch. The code is just not enabled right now on Rawhide but
will be soon.

Our plan is to move incrementally on Rawhide - migrate one thing after another 
without changing functionality and without user noticeable impact. So 
everything should be incrementally tested on Rawhide, no big potentially 
disruptive flag days.

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

[Bug 1470030] perl-Test-LeakTrace-0.16-1.fc27 FTBFS: Failed test ' UninitCondition' on ppc64

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1532205



-- 
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 System Wide Change: Make authselect default tool instead of authconfig

[nicolas . mailhot]

- Mail original -
De: "Tom Hughes" 
>> Well /usr/share/authselect/custom is not really the correct location
>> for local administrator configuration...
> 
> What location do you suggest?

> Well somewhere in /etc in short.

Like other such packages it needs a hierarchy with default templates in 
/usr/share and local updates in /etc

Regards,

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

Re: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement

[Tom Hughes]

On 08/01/18 10:23, Christian Kellner wrote:

Hi Tom,

On Mon, 8 Jan, 2018 at 11:07 AM, Tom Hughes  wrote:

On 08/01/18 09:59, Christian Kellner wrote:

The current design how gnome-shell and boltd work together will
avoid showing any prompts at all as long as a) the current user
is an admin, b) she is logged in and c) the session is unlocked.
We hope that this will take care of most situations where people
plug in thunderbolt devices. 

I obviously misunderstood... I thought the whole point of the desktop 
bit was so it could prompt you when it saw a new device? Ideally I 
would have though with the option to allow it once or permanently. If 
this is so potentially dangerous what's the logic behind going to all 
this trouble and then not actually asking the user? 


Can I point you to the design document for answers to that question: 
https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess


Although I did not come up with the design myself, I do indeed agree 
that for most people "do you want to allow XXX to work" is not a 
meaningful question and the most likely thing happening is that people 
click yes not matter what. The main attack vector that is prevented but 
"all this trouble" is that someone plugs in a malicious tb3 device into 
your computer to read all your main memory while you are away from the 
computer.


I guess that does make reasonable sense if the model is that for an 
unlocked machine with an administrator logged in that user is physically 
present to observe anything being plugged in.


The only real concern then is that the implicit permanent authorisation 
of the device - that if you can once get an administrator to plug it in 
you can in future do so when they aren't present.


So if I am J Evil Hacker and I can get you to connect to my projector at 
a conference then I can in future plug my Evil Memory Stealer device in 
that presents the same ID and hence gets accepted.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: VirtualBox Guest Integration

[Hans de Goede]

Hi,

On 05-01-18 15:03, Sérgio Basto wrote:

Hi,

On Thu, 2018-01-04 at 14:16 +0100, Jan Kurik wrote:

- Add VirtualBox Guest Additions package to the default package list
for the Workstation product


I don't understand this one, VirtualBox Guest should *only* be
installed in an virtual machine .


But it is impossible to determine ahead of time if e.g. a
Fedora Workstation Live image is going to get booted as a
VirtualBox guest or in some other way. As others have reported,
we do the same thing for the guest tools for all other hypervisors.


Today VirtualBox-server conflicts with VirtualBox-guest-additions and
vice versa .


I don't know why this used to be done, but this simply will no longer
be necessary going forward. There are going to be 2 kernel modules
named vboxguest.ko and vboxsf.ko as part of the main kernel-modules
package, which will have no symbols which in any way will conflict with
the out of tree vbox host kernel modules and the VirtualBox-guest-additions
package itself (which will not contain any kernel modules) will contain
this:

[hans@shalem master]$ rpm -qlp 
x86_64/VirtualBox-guest-additions-5.2.2-1.fc27.x86_64.rpm
VirtualBox-guest-additions-5.2.2-1.fc27.x86_64
/etc/X11/xinit/xinitrc.d/98vboxadd-xclient.sh
/etc/xdg/autostart/vboxclient.desktop
/usr/bin/VBoxClient
/usr/bin/VBoxClient-all
/usr/bin/VBoxControl

/usr/lib/systemd/system/vboxservice.service
/usr/lib/udev/rules.d/60-vboxguest.rules
/usr/lib64/security/pam_vbox.so
/usr/sbin/VBoxService
/usr/sbin/mount.vboxsf
/usr/share/licenses/VirtualBox-guest-additions
/usr/share/licenses/VirtualBox-guest-additions/COPYING
/usr/share/licenses/VirtualBox-guest-additions/COPYING.CDDL

ConditionVirtualization=|oracle

So the service will only run under vbox. As for the file size,
the installed size is all of 3308559 bytes.


I also propose the patch attach, to don't let install VirtualBox-guest-
additions in host systems, at the time could break the Xorg graphics
and all windows managers .
Furthermore at least is just a waste of disk space, for non virtual
machines and for who don't use VirtualBox.


As others have already explained this is a bad idea.

Regards,

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

Re: Self Introduction: Abhiram Kuchibhotla

[Charalampos Stratakis]

Hello and welcome!

- Original Message -
> From: "Abhiram Kuchibhotla" 
> To: devel@lists.fedoraproject.org
> Sent: Sunday, January 7, 2018 10:28:57 PM
> Subject: Self Introduction: Abhiram Kuchibhotla
> 
> Good day, everyone!
> 
> My name is Abhiram, and I go by "Axel" online.
> I recently graduated college with a bachelor's degree in technology with a
> focus on software engineering and IT.
> 
> I've been a full time Linux user for about 11-ish years having started my
> journey on good ol' Fedora core 9.
> 
> Recently, I've started to teach myself how to package applications for Fedora
> and I submitted my first package review request earlier
> today(https://bugzilla.redhat.com/show_bug.cgi?id=1532042) for Compton which
> is a compositor for X11 that I use regularly.
> 
> Besides that, I've also made a copr repository for a small program called
> nvidia-xrun which allows people with Nvidia Optimus devices to launch
> separate Xsessions using their nvidia cards.
> 
> I have a few more packages that I'm making, and I'm looking for a sponsorship
> into the packager group so that I can contribute further.
> 
> I really look forward to working with all of you!
> 
> Best Regard,
> Abhiram K.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement

[Christian Kellner]

Hi Tom,

On Mon, 8 Jan, 2018 at 11:07 AM, Tom Hughes  wrote:

On 08/01/18 09:59, Christian Kellner wrote:

The current design how gnome-shell and boltd work together will 
avoid showing any prompts at all as long as a) the current user is 
an admin, b) she is logged in and c) the session is unlocked. We 
hope that this will take care of most situations where people plug 
in thunderbolt devices.


I obviously misunderstood... I thought the whole point of the desktop
bit was so it could prompt you when it saw a new device? Ideally I 
would

have though with the option to allow it once or permanently.

If this is so potentially dangerous what's the logic behind going to 
all this trouble and then not actually asking the user?


Can I point you to the design document for answers to that question: 
https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess


Although I did not come up with the design myself, I do indeed agree 
that for most people "do you want to allow XXX to work" is not a 
meaningful question and the most likely thing happening is that people 
click yes not matter what. The main attack vector that is prevented but 
"all this trouble" is that someone plugs in a malicious tb3 device into 
your computer to read all your main memory while you are away from the 
computer.


FWIW: I do intend to add a "paranoid" mode for people that know what 
they are doing and are maybe exposed to more security relevant 
contexts; in such a mode we would indeed show a polkit-dialog for all 
devices (https://github.com/gicmo/bolt/issues/14). But that will not be 
the default.


Cheers,
CK


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

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Tom Hughes]

On 08/01/18 10:02, Pavel Březina wrote:

On 01/05/2018 04:54 PM, Tom Hughes wrote:

On 05/01/18 15:02, Pavel Březina wrote:


Yes, there is a data dir: /usr/share/authselect/
Description of these directories may be seen in the man page,
currently at this upstream link:
https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profiles.5.txt.in.in 




Well /usr/share/authselect/custom is not really the correct location
for local administrator configuration...


What location do you suggest?


Well somewhere in /etc in short.

I mean /usr/share/authselect/custom is fine for local customisation via 
building your own rpms but not for on the fly changes.


Really nobody should ever be changing anything in /usr (excluding 
/usr/local) except via package installation/update/removal.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement

[Tom Hughes]

On 08/01/18 09:59, Christian Kellner wrote:

The current design how gnome-shell and boltd work together will avoid 
showing any prompts at all as long as a) the current user is an admin, 
b) she is logged in and c) the session is unlocked. We hope that this 
will take care of most situations where people plug in thunderbolt devices.


I obviously misunderstood... I thought the whole point of the desktop
bit was so it could prompt you when it saw a new device? Ideally I would
have though with the option to allow it once or permanently.

If this is so potentially dangerous what's the logic behind going to all 
this trouble and then not actually asking the user?


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1480480] perl-RPM2-1.3-8.fc27 FTBFS: lib/RPM2.xs:157:20: error: ' RPMVSF_NOSHA1' undeclared

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-RPM2-1.3-9.fc27
 Resolution|--- |CURRENTRELEASE
   Assignee|jples...@redhat.com |ignate...@redhat.com
Last Closed||2018-01-08 05:04:08



-- 
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 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 04:54 PM, Tom Hughes wrote:

On 05/01/18 15:02, Pavel Březina wrote:


Yes, there is a data dir: /usr/share/authselect/
Description of these directories may be seen in the man page,
currently at this upstream link:
https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profiles.5.txt.in.in



Well /usr/share/authselect/custom is not really the correct location
for local administrator configuration...


What location do you suggest?



Tom


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

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 04:43 PM, John Florian wrote:

On Fri, 2018-01-05 at 16:02 +0100, Pavel Březina wrote:

On 01/05/2018 03:14 PM, John Florian wrote:

On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:

The tool is packaged with a default
profile set that is fully supported. If an administrator has
different
needs they can create a custom profile and make it accessible in
authselect by dropping it in the tool specific directory.


How?  The authselect(8) man page tells me that `authselect show
profile_id` will print info about the profile, but I see nothing of
any
detail.  (Perhaps more could be gleaned with `--trace`, but without
any
apparent dry-run option I'd want a VM to experiment.)


There is also authselect-profiles(5) that explains how profiles
works.
But it is not yet present in current Fedora packages. I will do new
release on Monday.


Ah, that explains a lot.  I did fail to mention this was all from the
perspective of a F27 system.



Looking at the package contents doesn't help much either:

$ rpm -ql authselect
/usr/bin/authselect
/usr/lib/.build-id
/usr/lib/.build-id/b6
/usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e
/usr/share/man/man8/authselect.8.gz

So the built-in profiles are hard-coded into the binary?  I might
have
expected a data dir providing these to serve as examples for making
new
ones.


Yes, there is a data dir: /usr/share/authselect/


Doh!  I see now that's part of authselect-libs, a package I failed to
notice getting installed alongside of authselect itself.


We have put the authselect functionality into a separate library so it 
is better usable by realmd (that can call it directly instead of 
executing cli) and other programs that may be interested. We also plan 
to provide ansible module and probably also python and maybe even dbus 
bindings. But this is out of scope of F28.





Description of these directories may be seen in the man page,
currently
at this upstream link:
https://github.com/pbrezina/authselect/blob/master/src/man/authselect
-profiles.5.txt.in.in


Oh, very nice!


I also didn't see (nor did I even try searching for) any mention of
the
upstream project.

Otherwise, this is a very nice write up.  I'm mostly curious as our
setup uses an openldap directory server for identity and WinAD for
authentication.  realmd doesn't seem to cover (from a very cursory
glance) that arrangement.  So I have an eye out for how to best
leverage these things, if at all.


We had many discussions on this topic while designing and developing
authselect. The resolution was to include only sssd and winbind
profiles
and avoid other use cases and avoid plain ldap and kerberos since
they
can be implemented with sssd. So the use case that you have
mentioned
above (different id and auth providers) can be achieved.


That makes sense and seems like a wise choice.


One last thought, how friendly is this going to be with tools like
puppet and ansible?  For example, would something like this be doable?


It is idempotent so it can be used here as well.



exec { 'authselect select sssd':
  unless => "authselect current | grep -q '^sssd$' && authselect check
| grep -q unmodified"
}

The idea being to only run to make a change if needed to keep change
reports tidy.  I can't quite tell at this point because:

$ sudo authselect current
No existing configuration detected.

In this sense, it would be helpful if authselect(8) had some details
about exit codes.  Also, the "check" command could be more explicit
about what happens with exit codes/output messages when:
  * the config was created by authselect and remains unmodified
  * the config was created by authselect but has since been modified
  * the config hasn't apparently ever been touched by authselect

Maybe another command like "test" command could be ideal for the job if
it did much the same but gave diff output and suitable exit code
indicating spot-on vs. needs-change.


Thank you for your input, we will try to include it soon:
https://github.com/pbrezina/authselect/issues/26


I ask because I'd far prefer to have a well maintained tool like
authselect managing PAM versus self-hacked file replacements based on
old configurations that once may have been correct(ish).  PAM syntax is
a wee bit too arcane and yet immensely critical to go mucking around
haphazardly.


Yes, this is exactly what we aim for.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement

[Christian Kellner]

Hi Florian,

On Fri, 5 Jan, 2018 at 10:45 AM, Florian Weimer  
wrote:

> Devices connected via Thunderbolt can be DMA masters and thus read

system memory without interference of the operating system (or even
the CPU). Version 3 of the interface provides 4 different security
levels, in order to mitigate the aforementioned security risk that
connected devices pose to the system. The security level is set by 
the

system firmware.

The four security levels are:
* none: Security disabled, all devices will fully functional on 
connect.
* dponly: Only pass the display-port stream through to the connected 
device.

* user: Connected devices need to be manually authorized by the user.
* secure: As 'user', but also challenge the device with a secret key
to verify its identity.


Can the IOMMU help here?  If it can, would it make sense to disable 
all security prompts?
In theory yes, in practice it is hard to make sure it is always 
properly set up (for all drivers in the mix). Also apparently "various 
[other] reasons" according to the Linux kernel documentation: "There 
are ways to prevent this by setting up an IOMMU but it is not always 
available for various reasons."


The current design how gnome-shell and boltd work together will avoid 
showing any prompts at all as long as a) the current user is an admin, 
b) she is logged in and c) the session is unlocked. We hope that this 
will take care of most situations where people plug in thunderbolt 
devices.


Are there plans to prevent enabling devices when the shield is 
active? (That's something we should do for most USB decices, too, 
FWIW.)
I am not sure what you refer to with "shield" but if you mean the lock 
screen, then yes indeed we wont enable devices when the session is 
locked.


Cheers,
CK

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/admin-guide/thunderbolt.rst


--
Dr. Christian J. Kellner
Desktop Hardware Enablement
Red Hat



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