[Bug 1815371] perl-Business-ISSN-1.004 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Business-ISSN-1.004-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=42628666

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1815371] perl-Business-ISSN-1.004 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1671690
  --> https://bugzilla.redhat.com/attachment.cgi?id=1671690=edit
[patch] Update to 1.004 (#1815371)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1815371] New: perl-Business-ISSN-1.004 is available

[bugzilla]

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

Bug ID: 1815371
   Summary: perl-Business-ISSN-1.004 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Business-ISSN
  Keywords: FutureFeature, Triaged
  Assignee: c...@m.fsf.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: c...@m.fsf.org, mefos...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.004
Current version/release in rawhide: 1.003-7.fc32
URL: http://search.cpan.org/dist/Business-ISSN

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-03-20 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/20/report-389-ds-base-1.4.3.4-20200320git6fba9a8.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Adding new syntaxes

[William Brown]

Hi there,

I'm looking to add the syntaxes to handle entryUUID properly, because they have 
a different format to nsUniqueId. Thinking that I need to look at the plugins 
under ldap/servers/plugins/syntaxes/, but it would be good to have some extra 
insight about the plugin hooks. Should I look at the old plugin guide? Or is 
there some extra info I can get from somewhere? 

Thanks! 

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: CoC

[John M. Harris Jr]

On Thursday, March 19, 2020 8:03:18 PM MST Martin Langhoff wrote:
> Oh my - Daniel and his sock puppets come to bring mayhem to Fedora-devel?
> 
> some background at https://lwn.net/Articles/814508/
> 
> cut off the trolling...
> 
> 
> m
> 
> On Thu, Mar 19, 2020 at 3:37 PM Ty Young  wrote:
> > On 3/19/20 2:18 PM, Daniel Pocock wrote:
> > > On 12/03/2020 22:34, Matthew Miller wrote:
> > >> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
> > >>> It is very, very wrong and I don't feel I should have to make a public
> > >>> request like this.  Nonetheless, there is a certain type of person who
> > >> 
> > >> Daniel, to request re-instatement, please follow the process outlined
> > >> in the original code-of-conduct suspension notice you received. A
> > >> public post is not necessary.
> > > 
> > > Personally, I feel offended by your choice of words
> > > 
> > > A suspension of a blog may itself be a violation of the Code of Conduct
> > > if the blog was written in good faith
> > > 
> > > I never received one complaint about my blog from anybody in the Fedora
> > > world.  Several people noticed when it disappeared though.
> > > 
> > > The blog post in question discussed a conflict of interest between the
> > > leaders of two free software organizations, the Debian Project Leader
> > > and the OSI board president.  As I interacted with both of them
> > > personally, I felt that I was qualified to share my observations.
> > > 
> > > That topic itself was forced into the public because one of the people
> > > party to the conflict of interest had spread gossip about me and the
> > > other used her speech at an event for humiliating volunteers.
> > > 
> > > It feels like Codes of Conduct apply to some people and not others.  As
> > > George Orwell puts it, /All animals are equal but some animals are more
> > > equal than others/.
> > 
> > Have you seen Gnome's CoC? It literally allows racism. There was a bit
> > of an uproar about it, and Gnome foundation/developers members refused
> > to change it.
> > 
> > 
> > (Gnome and Fedora are very incestous projects, so yes, it is relevant)
> > 
> > 
> > Now that communism is the cool, hip ideology in town, Gnome/Fedora are
> > embracing it. Book burning is the next step, but one might argue the
> > deletion of discussion threads and blogs already *is* that step.
> > 
> > > Fedora's Code of Conduct[1] asks people to be excellent to each other.
> > > When talking about governance issues, being excellent to other
> > > volunteers means telling them the truth about leadership problems in the
> > > free software world.
> > > 
> > > Being excellent to leaders who behave badly means keeping a focus on the
> > > issues.  For example, when blogging about two people with a romantic
> > > conflict of interest, I would never speculate about their first date and
> > > other personal details, I would only focus on the way their decision
> > > making was impaired.
> > > 
> > > Even this week there are people writing public comments alleging I had a
> > > conflict of interest, but that is false.  I named Chris Lamb and Molly
> > > de Blanc because their conflict of interest was at the root of certain
> > > problems.  At least one member of Debian's mentoring team also had a
> > > conflict of interest with an intern.  I didn't identify them out of
> > > concerns for student privacy.  Nonetheless, when people spread gossip,
> > > leadership figures have a responsibility to stop it, but they didn't,
> > > they added fuel to the fire and they continue to do so even now.
> > > 
> > > If the leaders of organizations can behave like that, why should the
> > > Code of Conduct deny a volunteer a right of reply?
> > 
> > Silly Daniel, you aren't supposed to question the supreme leaders. You
> > have to fall in line and never question anything.
> > 
> > 
> > If you need help understanding, I recommend reading up on what's going
> > on in China right now. Concentration camps, book burning, police
> > brutality, people vanishing, etc...
> > 
> > > Regards,
> > > 
> > > Daniel


Hi Martin,

Please see the Fedora Code of Conduct[1]. Referring to other members of the 
community as "sock puppets" falls a bit shy of "be excellent to each other", 
in my opinion.

1: https://docs.fedoraproject.org/en-US/project/code-of-conduct/

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CoC

[Ty Young]

On 3/19/20 10:03 PM, Martin Langhoff wrote:

Oh my - Daniel and his sock puppets come to bring mayhem to Fedora-devel?

some background at https://lwn.net/Articles/814508/

cut off the trolling...



I do believe calling people "sock puppets" is a violation of the CoC. 
Specifically, the "be respectful" section at the top.



Anyway, not the same person. I'd jump off a cliff before having anything 
to do with or use Debian. Anyone who knows me from Reddit could probably 
tell you that.






m

On Thu, Mar 19, 2020 at 3:37 PM Ty Young > wrote:



On 3/19/20 2:18 PM, Daniel Pocock wrote:
>
> On 12/03/2020 22:34, Matthew Miller wrote:
>> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
>>> It is very, very wrong and I don't feel I should have to make
a public
>>> request like this.  Nonetheless, there is a certain type of
person who
>> Daniel, to request re-instatement, please follow the process
outlined
>> in the original code-of-conduct suspension notice you received. A
>> public post is not necessary.
>
> Personally, I feel offended by your choice of words
>
> A suspension of a blog may itself be a violation of the Code of
Conduct
> if the blog was written in good faith
>
> I never received one complaint about my blog from anybody in the
Fedora
> world.  Several people noticed when it disappeared though.
>
> The blog post in question discussed a conflict of interest
between the
> leaders of two free software organizations, the Debian Project
Leader
> and the OSI board president.  As I interacted with both of them
> personally, I felt that I was qualified to share my observations.
>
> That topic itself was forced into the public because one of the
people
> party to the conflict of interest had spread gossip about me and the
> other used her speech at an event for humiliating volunteers.
>
> It feels like Codes of Conduct apply to some people and not
others.  As
> George Orwell puts it, /All animals are equal but some animals
are more
> equal than others/.


Have you seen Gnome's CoC? It literally allows racism. There was a
bit
of an uproar about it, and Gnome foundation/developers members
refused
to change it.


(Gnome and Fedora are very incestous projects, so yes, it is relevant)


Now that communism is the cool, hip ideology in town, Gnome/Fedora
are
embracing it. Book burning is the next step, but one might argue the
deletion of discussion threads and blogs already *is* that step.


>
> Fedora's Code of Conduct[1] asks people to be excellent to each
other.
> When talking about governance issues, being excellent to other
> volunteers means telling them the truth about leadership
problems in the
> free software world.
>
> Being excellent to leaders who behave badly means keeping a
focus on the
> issues.  For example, when blogging about two people with a romantic
> conflict of interest, I would never speculate about their first
date and
> other personal details, I would only focus on the way their decision
> making was impaired.
>
> Even this week there are people writing public comments alleging
I had a
> conflict of interest, but that is false.  I named Chris Lamb and
Molly
> de Blanc because their conflict of interest was at the root of
certain
> problems.  At least one member of Debian's mentoring team also had a
> conflict of interest with an intern.  I didn't identify them out of
> concerns for student privacy.  Nonetheless, when people spread
gossip,
> leadership figures have a responsibility to stop it, but they
didn't,
> they added fuel to the fire and they continue to do so even now.
>
> If the leaders of organizations can behave like that, why should the
> Code of Conduct deny a volunteer a right of reply?


Silly Daniel, you aren't supposed to question the supreme leaders.
You
have to fall in line and never question anything.


If you need help understanding, I recommend reading up on what's
going
on in China right now. Concentration camps, book burning, police
brutality, people vanishing, etc...


>
> Regards,
>
> Daniel
>
> 1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> ___
> devel mailing list -- devel@lists.fedoraproject.org

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

> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:

Re: Donate 1 minute of your time to test upgrades from F31 to F32

[Samuel Sieb]

On 3/19/20 6:59 PM, Solomon Peachy wrote:

I nuked python2-matplotlib and python2-matplotlib-tk, and it was able to
proceed.  One thing that looked odd is that it's downgrading a bunch of
packages, including the kernel:

  kernel-toolsx86_64 5.5.0-0.rc6.git0.1.fc32  fedora   190 k
  kernel-tools-libs   x86_64 5.5.0-0.rc6.git0.1.fc32  fedora21 k
  kernel-tools-libs-devel x86_64 5.5.0-0.rc6.git0.1.fc32  fedora14 k

I wonder if I'm hitting an out-of-date mirror?  The other system I just
updated had a 5.6.0-0.rc kernel out of the gate..


Downgrading is pretty common as the new release is frozen so new updates 
only go to the old releases.  Although, if the other system you're 
referring to was an update to F32 beta and not an F31 update, then it 
probably was an out of date mirror.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-658581cb5f   
php-horde-Horde-Form-2.0.20-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-81c37f8ff5   
tomcat-7.0.100-2.el6


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

php-behat-gherkin-4.6.2-1.el6

Details about builds:



 php-behat-gherkin-4.6.2-1.el6 (FEDORA-EPEL-2020-6d41882ce2)
 Gherkin DSL parser for PHP

Update Information:

## 4.6.2 / 2020-03-17  * Fixed issues due to incorrect cache key  ## 4.6.1 /
2020-02-27  * Fix AZ translations * Correctly filter features, now that the base
path is correctly set   ## 4.6.0 / 2019-01-16  * Updated translations (including
'Example' as synonym for 'Scenario' in `en`)  ## 4.5.1 / 2017-08-30  * Fix
regression in `PathsFilter`  ## 4.5.0 / 2017-08-30  * Sync i18n with Cucumber
Gherkin * Drop support for HHVM tests on Travis * Add `TableNode::fromList()`
method (thanks @TravisCarden) * Add `ExampleNode::getOutlineTitle()` method
(thanks @duxet) * Use realpath, so the feature receives the cwd prefixed (thanks
@glennunipro) * Explicitly handle non-two-dimensional arrays in TableNode
(thanks @TravisCarden) * Fix to line/linefilter scenario runs which take
relative paths to files (thanks @generalconsensus)

ChangeLog:

* Wed Mar 18 2020 Shawn Iwinski  - 4.6.2-1
- Update to 4.6.2 (RHBZ #1808131)
* Tue Mar 17 2020 Shawn Iwinski  - 4.6.1-2
- Conditional Symfony 2 or not
* Tue Mar 17 2020 Shawn Iwinski  - 4.6.1-1
- Update to 4.6.1 (RHBZ #1808131)
- Conditionally use range dependencies
- Drop Symfony 2 interoperability
* Thu Jan 30 2020 Fedora Release Engineering  - 
4.4.5-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Fri Jul 26 2019 Fedora Release Engineering  - 
4.4.5-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Sat Feb  2 2019 Fedora Release Engineering  - 
4.4.5-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Fri Jul 13 2018 Fedora Release Engineering  - 
4.4.5-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Fri Feb  9 2018 Fedora Release Engineering  - 
4.4.5-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

References:

  [ 1 ] Bug #1808131 - php-behat-gherkin-4.6.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808131


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1814445] perl-Crypt-OpenSSL-EC-1.32 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Crypt-OpenSSL-EC-1.32-1.fc31 has been pushed to the Fedora 31 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-2020-6f4441494a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1814445] perl-Crypt-OpenSSL-EC-1.32 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Crypt-OpenSSL-EC-1.32-1.fc30 has been pushed to the Fedora 30 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-2020-93df3e0e37

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: CoC

[Martin Langhoff]

Oh my - Daniel and his sock puppets come to bring mayhem to Fedora-devel?

some background at https://lwn.net/Articles/814508/

cut off the trolling...


m

On Thu, Mar 19, 2020 at 3:37 PM Ty Young  wrote:

>
> On 3/19/20 2:18 PM, Daniel Pocock wrote:
> >
> > On 12/03/2020 22:34, Matthew Miller wrote:
> >> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
> >>> It is very, very wrong and I don't feel I should have to make a public
> >>> request like this.  Nonetheless, there is a certain type of person who
> >> Daniel, to request re-instatement, please follow the process outlined
> >> in the original code-of-conduct suspension notice you received. A
> >> public post is not necessary.
> >
> > Personally, I feel offended by your choice of words
> >
> > A suspension of a blog may itself be a violation of the Code of Conduct
> > if the blog was written in good faith
> >
> > I never received one complaint about my blog from anybody in the Fedora
> > world.  Several people noticed when it disappeared though.
> >
> > The blog post in question discussed a conflict of interest between the
> > leaders of two free software organizations, the Debian Project Leader
> > and the OSI board president.  As I interacted with both of them
> > personally, I felt that I was qualified to share my observations.
> >
> > That topic itself was forced into the public because one of the people
> > party to the conflict of interest had spread gossip about me and the
> > other used her speech at an event for humiliating volunteers.
> >
> > It feels like Codes of Conduct apply to some people and not others.  As
> > George Orwell puts it, /All animals are equal but some animals are more
> > equal than others/.
>
>
> Have you seen Gnome's CoC? It literally allows racism. There was a bit
> of an uproar about it, and Gnome foundation/developers members refused
> to change it.
>
>
> (Gnome and Fedora are very incestous projects, so yes, it is relevant)
>
>
> Now that communism is the cool, hip ideology in town, Gnome/Fedora are
> embracing it. Book burning is the next step, but one might argue the
> deletion of discussion threads and blogs already *is* that step.
>
>
> >
> > Fedora's Code of Conduct[1] asks people to be excellent to each other.
> > When talking about governance issues, being excellent to other
> > volunteers means telling them the truth about leadership problems in the
> > free software world.
> >
> > Being excellent to leaders who behave badly means keeping a focus on the
> > issues.  For example, when blogging about two people with a romantic
> > conflict of interest, I would never speculate about their first date and
> > other personal details, I would only focus on the way their decision
> > making was impaired.
> >
> > Even this week there are people writing public comments alleging I had a
> > conflict of interest, but that is false.  I named Chris Lamb and Molly
> > de Blanc because their conflict of interest was at the root of certain
> > problems.  At least one member of Debian's mentoring team also had a
> > conflict of interest with an intern.  I didn't identify them out of
> > concerns for student privacy.  Nonetheless, when people spread gossip,
> > leadership figures have a responsibility to stop it, but they didn't,
> > they added fuel to the fire and they continue to do so even now.
> >
> > If the leaders of organizations can behave like that, why should the
> > Code of Conduct deny a volunteer a right of reply?
>
>
> Silly Daniel, you aren't supposed to question the supreme leaders. You
> have to fall in line and never question anything.
>
>
> If you need help understanding, I recommend reading up on what's going
> on in China right now. Concentration camps, book burning, police
> brutality, people vanishing, etc...
>
>
> >
> > Regards,
> >
> > Daniel
> >
> > 1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff

Review swap

[Jerry James]

I have one more review I would like to swap with somebody.  This is
one of the last 2 packages I need to be able to update the coq stack.
The other is already under review.  Who needs a review?

ocaml-ppx-deriving-yojson: https://bugzilla.redhat.com/show_bug.cgi?id=1801421

-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F31 to F32

[Solomon Peachy]

On Wed, Mar 04, 2020 at 02:33:02PM -0500, Solomon Peachy wrote:
> > * Workstation 3 (a frankenstein beast and a lot of modular errors)
> 
> With 'dnf module reset' this is a lot cleaner.  dispcalGUI was snagged 
> from OBS, so not a fedora problem.

Tried to upgrade this workstation from F31 to F32 beta.  The old errors did 
not show up, but now I'm getting these new ones:

Error: 
 Problem 1: package python2-matplotlib-2.2.5-1.fc31.x86_64 requires 
python2-backports-functools_lru_cache, but none of the providers can be 
installed
  - package python2-matplotlib-2.2.5-1.fc31.x86_64 requires 
python2.7dist(backports.functools-lru-cache), but none of the providers can be 
installed
  - python2-backports-functools_lru_cache-1.5-6.fc31.noarch does not belong to 
a distupgrade repository
  - problem with installed package python2-matplotlib-2.2.5-1.fc31.x86_64
 Problem 2: package python2-matplotlib-2.2.5-1.fc31.x86_64 requires 
python2-cycler >= 0.10.0, but none of the providers can be installed
  - package python2-matplotlib-2.2.5-1.fc31.x86_64 requires 
python2.7dist(cycler) >= 0.10, but none of the providers can be installed
  - package python2-matplotlib-tk-2.2.5-1.fc31.x86_64 requires 
python2-matplotlib(x86-64) = 2.2.5-1.fc31, but none of the providers can be 
installed
  - python2-cycler-0.10.0-10.fc31.noarch does not belong to a distupgrade 
repository
  - problem with installed package python2-matplotlib-tk-2.2.5-1.fc31.x86_64

I nuked python2-matplotlib and python2-matplotlib-tk, and it was able to 
proceed.  One thing that looked odd is that it's downgrading a bunch of 
packages, including the kernel:

 kernel-toolsx86_64 5.5.0-0.rc6.git0.1.fc32  fedora   190 k 
  
 kernel-tools-libs   x86_64 5.5.0-0.rc6.git0.1.fc32  fedora21 k 
  
 kernel-tools-libs-devel x86_64 5.5.0-0.rc6.git0.1.fc32  fedora14 k 
 

I wonder if I'm hitting an out-of-date mirror?  The other system I just 
updated had a 5.6.0-0.rc kernel out of the gate..

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1814445] perl-Crypt-OpenSSL-EC-1.32 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Crypt-OpenSSL-EC-1.32-1.fc32 has been pushed to the Fedora 32 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-2020-c745bc2d38

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[389-devel] please review: PR 50965 - wildcards in rootdn-allow-ip attribute are not accepted

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50965

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

FedoraRespin-31-updates-20200319.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/35 (x86_64)

ID: 551441  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/551441
ID: 551458  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/551458

Soft failed openQA tests: 2/35 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 551451  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/551451
ID: 551453  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/551453

Passed openQA tests: 31/35 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned containers (D lang library)

[Neal Gompa]

Hey all,

I have orphaned containers[1], a D language library for extended
"containers" concept in D based on std.experimental.allocator.

I have no use for it anymore. If you're interested in D language
stuff, feel free to take it.

There is a newer version available from upstream[2], which would
likely fix the FTBFS bug[3].

[1]: https://src.fedoraproject.org/rpms/containers
[2]: https://github.com/dlang-community/containers
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1799253

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-32-20200319.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 2/8 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-32-20200314.0):

ID: 551429  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/551429
ID: 551430  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/551430

Passed openQA tests: 6/8 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Broken OCaml dependencies in fedora 32

[Fabio Valentini]

On Fri, Mar 20, 2020 at 12:14 AM Richard W.M. Jones  wrote:
>
> On Thu, Mar 19, 2020 at 11:25:19PM +0100, Fabio Valentini wrote:
> > Hi everybody,
> >
> > I can't seem to figure out why this happened, but there are now a lot
> > of OCaml packages in fedora 32 that have broken dependencies. I've CCd
> > two of the maintainers that are impacted most by this (rjones and
> > jjames).
> >
> > Right now, the following packages have broken dependencies and are not
> > installable (you can verify this with "mock -r fedora-32-x86_64
> > (--enablerepo updates-testing, if necessary) install foo"):
> >
> > - coccinelle
>
> We're waiting on an upstream fix for OCaml 4.10.
>
> > - nbdkit-ocaml-plugin-devel
> > - ocaml-libnbd
> > - ocaml-libguestfs
>
> Probably waiting on updates to go through.  These ought to work after
> updates-testing have been applied afaik.
>
> > - ocaml-json-wheel{,-devel}
>
> Orphaned I think.  Long dead upstream anyhow.

Ok, so it seems those new broken dependencies only come from things
getting pushed from updates-testing into stable after the beta freeze
was lifted?
Thanks for looking into this, and sorry for the "false alarm" :)

Fabio

> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Kevin Fenzi]

On Tue, Mar 17, 2020 at 04:19:21PM +, Peter Robinson wrote:
> 
> You're still listed [1], I've found from recent cleanups of packages I
> maintained myself, you have to:
> 1) give to the orphan user. This makes them main admin, but moves you
> to a standard admin
> 2) remove yourself from the "users & groups" list as you'll still be admin
> 3) then "reset watch status" from the watch drop down on the package main 
> status
> 
> Once you've done those 3 steps you're no longer on the list, won't get
> BZ etc, it takes a day or two to get that synced over to bugzilla.

Odd, I could have sworn I did exactly that... but I guess not. ;) 

Done now.

Thanks Peter. 

kevin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[Dominik 'Rathann' Mierzejewski]

On Thursday, 19 March 2020 at 19:59, Chris Murphy wrote:
[...]
> I think what you'd want for the stolen laptop use case is an encrypted
> $BOOT, which GRUB does support:
> 
> The first grub.cfg is unencrypted, and provides strictly for unlocking
> a LUKS1 (no LUKS2 support yet) $BOOT volume, and then using
> 'configfile' command to read a second "real" grub.cfg on the encrypted
> $BOOT, which also contains BLS snippets, and kernel+initramfs. Since a
> passphrase is required to even read these files, in order to boot the
> installed system, I'm not sure it's necessary to also lock down the
> command line. (Also, the setup details differ considerably between
> UEFI and BIOS.)

Could you share the steps to configure the above for UEFI case? I'm
interested in such setup, but never had time to try configuring it.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone seen build hangs (esp armv7, s390x) in Fedora?

[Richard W.M. Jones]

On Thu, Mar 19, 2020 at 01:01:05PM +0100, Sumit Bose wrote:
> On Thu, Mar 19, 2020 at 08:37:31AM +, Richard W.M. Jones wrote:
> > On Wed, Mar 18, 2020 at 11:39:37AM +0100, Dan Horák wrote:
> > > On Wed, 18 Mar 2020 09:50:24 +
> > > "Richard W.M. Jones"  wrote:
> > > 
> > > > On Wed, Mar 18, 2020 at 10:46:19AM +0100, Dan Horák wrote:
> > > > > On Wed, 18 Mar 2020 09:34:45 +
> > > > > "Richard W.M. Jones"  wrote:
> > > > > 
> > > > > > 
> > > > > > This might be a bug in the package itself, but has anyone seen
> > > > > > builds hanging in weird places, in Rawhide, especially on armv7
> > > > > > and s390x?
> > > > > > 
> > > > > > This packge build has hung 3 times in the same place, once on
> > > > > > armv7 and twice on s390x:
> > > > > > 
> > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42570766
> > > > > > 
> > > > > > It's hard to explain how it could hang at that place in the build
> > > > > > unless something fundamental is broken like make.
> > > > > 
> > > > > let me try the rebuild locally on s390x ...
> > > > 
> > > > Note that the build did succeed once on s390x (that was when it hung
> > > > on armv7 instead).  So it's not 100% reproducible.  Also if our theory
> > > > about tooling is correct then you would need all Rawhide packages.
> > > 
> > > it's a deadlock in the tests, not in make. Reproduced with
> > > "fedpkg local" in a cycle.
> > > 
> > > sharkcz  1649225  0.0  0.0 88  3904 pts/5S+   06:24   0:00 
> > > /bin/sh -e /var/tmp/rpm-tmp.RXcMRr
> > > sharkcz  1649230  0.0  0.0  10372  3248 pts/5S+   06:24   0:00 make 
> > > -j4 check
> > > sharkcz  1658088  0.0  0.0 251236  3400 pts/5Sl+  06:25   0:00 
> > > /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P 
> > > test-nbd-tls-psk.pid1 -U /tmp/tmp.7e7Gv5MPmZ --tls=require 
> > > --tls-psk=keys.psk -- 
> > > /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/example1/.libs/nbdkit-example1-plugin.so
> > > sharkcz  1658091  0.0  0.1 192944  4464 pts/5Sl+  06:25   0:00 
> > > /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P 
> > > test-nbd-tls-psk.pid2 -U /tmp/tmp.yp61yXx09y --tls=off -- 
> > > /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/nbd/.libs/nbdkit-nbd-plugin.so 
> > > tls=require tls-psk=keys.psk tls-username=qemu socket=/tmp/tmp.7e7Gv5MPmZ
> > > 
> > > the 2 nbdkit processes are stuck in the futex() syscall
> > > 
> > > Some years ago there was a kernel bug with the same symptoms. All
> > > arches were affected, but mostly visible on s390x and armv7.
> > 
> > In fact this happens on x86-64.  I was able to reproduce it
> > locally.  Investigating now.
> 
> Hi,
> 
> jfiy, I have two builds with similar behavior as well:
> 
>  - https://koji.fedoraproject.org/koji/taskinfo?taskID=42581593 f33 i686
>  - https://koji.fedoraproject.org/koji/taskinfo?taskID=42600523 f32 aarch64
> 
> both are stuck in tests. Trying to reproduce locally.

It seems like if your test leaves any subprocesses around after the
test it will now hang, whereas before it would have continued (albeit
leaving orphaned processes which is bad behaviour).  Not sure exactly
what changed here, maybe make or rpmbuild?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Broken OCaml dependencies in fedora 32

[Richard W.M. Jones]

On Thu, Mar 19, 2020 at 11:25:19PM +0100, Fabio Valentini wrote:
> Hi everybody,
> 
> I can't seem to figure out why this happened, but there are now a lot
> of OCaml packages in fedora 32 that have broken dependencies. I've CCd
> two of the maintainers that are impacted most by this (rjones and
> jjames).
> 
> Right now, the following packages have broken dependencies and are not
> installable (you can verify this with "mock -r fedora-32-x86_64
> (--enablerepo updates-testing, if necessary) install foo"):
> 
> - coccinelle

We're waiting on an upstream fix for OCaml 4.10.

> - nbdkit-ocaml-plugin-devel
> - ocaml-libnbd
> - ocaml-libguestfs

Probably waiting on updates to go through.  These ought to work after
updates-testing have been applied afaik.

> - ocaml-json-wheel{,-devel}

Orphaned I think.  Long dead upstream anyhow.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer: pocock

[Neal Gompa]

On Thu, Mar 19, 2020 at 6:42 PM Daniel Pocock  wrote:
>
>
>
> On 15/03/2020 13:32, Neal Gompa wrote:
> > On Fri, Mar 6, 2020 at 2:06 PM Dakota Williams
> >  wrote:
> >>
> >> On 3/6/20 1:21 PM, Daniel Pocock wrote:
> >>>
> >>>
> >>> On 05/03/2020 21:26, Julian Sikorski wrote:
> >>>
>  I would like to take this opportunity to remind about the PR that I have
>  prepared - let us not duplicate the work:
>  https://src.fedoraproject.org/rpms/asio/pull-request/1
>  I have rebuilt all asio's dependencies and only encountered issues with
>  abiword and OpenSceneGraph - both were complaining about error not being
>  a member of asio::placeholders. Same issues were found by gentoo, I have
>  linked the relevant bug reports in the PR. Is this something you would
>  be able to advise about? I am happy to share full build logs if needed.
> >>>
> >>> I haven't personally looked at asio 1.14.0 yet so I don't have the
> >>> solution off the top of my head.  These are the type of issues I
> >>> normally deal with in upstream development.
> >>>
> >>>  From a strategic perspective, I feel it is most efficient to try and
> >>> coordinate with the upstreams and other distributions so that everybody
> >>> is supporting the same asio in each of the major distributions.
> >>>
> >>> In any C++ library, there are small API changes from time to time
> >>> leading to the type of problem you describe.
> >>>
> >>> If upstreams are using travis-ci, we are testing against version 1.12.2
> >>> from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
> >>> if you patch for the issue, it may be completely untested upstream.
> >>> That is why it is so vital to resolve the Debian/Ubuntu lag.
> >>>
> >>> Is there a convenient way for upstreams to make CI builds on the latest
> >>> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
> >>>
>  Please also note that I have checked both fale and uwog's recent
>  activity with fedora-active-user and neither seem to have been active
>  lately.
> >>>
> >>> Thanks for this feedback.  Dakota, do you want to be promoted to admin
> >>> on asio?
> >>>
> >>> Is either of you happy to be co-maintainer of resiprocate with me?  I
> >>> opened an issue to unretire it.  I do upstream releases and I run the
> >>> latest version for fedrtc.org (using CentOS/EPEL) so it is important for
> >>> me that it supports Fedora and any Fedora issues are given the attention
> >>> they deserve during the release process.
> >>
> >>
> >> Sure, admin is ok with me. Co-maintainer of resiprocate would also be
> >> something I'd be willing to take on.
> >
> > It's been a couple of weeks now, and I don't see "raineforest" listed
> > as admin for asio[1]. Can you please add him as requested?
>
> I had added Dakota as developer (commit?) and when I looked tonight, I
> notice he had vanished.  I've added him now as admin.  Is there any way
> to see how he vanished?  Does he need to explicitly click something to
> accept the permissions?
>
>

It seems to have stuck this time. Thanks for that.

> > Also, resiprocate[2] was retired three months ago after being orphaned
> > for 6 weeks for failing to build for Fedora 31[3]. It will need to go
> > through a whole new review process *after* asio is updated.
>
> Is it possible to make Covid-19 exception for this and just put it back
> again?  Lots of people want to use the WebRTC conferencing features.
> Yesterday I updated[4] JSCommunicator and today I tweaked[5] resiprocate
> for asio 1.14.0 so it is ready to go in Fedora, EPEL and fedrtc.org.  I
> have a backlog of upstream issues in all these projects and would prefer
> not to lose time in another review process.
>

If this had been only just retired, maybe. But it's been months.
Unfortunately, a re-review is required. Fortunately, I think a review
of it should be pretty easy to do, and I'm sure we can get it back in
quickly.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Broken OCaml dependencies in fedora 32

[Jerry James]

On Thu, Mar 19, 2020 at 4:25 PM Fabio Valentini  wrote:
> - coq{,-coqide}

This one needs a version update.  For that, it needs several new
packages.  I've been working through the reviews, and we're almost
there!  Two more reviews to get through, and the new coq version can
be built.

> - frama-c
> - gappalib-coq
> - ocaml-why3

These are blocked waiting for the coq build.

> - ocaml-ppx-tools
> - ocaml-stdint

There are updates for these two.  They should be pushed stable
tomorrow, I think.

> - why-jessie

I am going to retire the why package when I update the coq stack.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer: pocock

[Daniel Pocock]

On 15/03/2020 13:32, Neal Gompa wrote:
> On Fri, Mar 6, 2020 at 2:06 PM Dakota Williams
>  wrote:
>>
>> On 3/6/20 1:21 PM, Daniel Pocock wrote:
>>>
>>>
>>> On 05/03/2020 21:26, Julian Sikorski wrote:
>>>
 I would like to take this opportunity to remind about the PR that I have
 prepared - let us not duplicate the work:
 https://src.fedoraproject.org/rpms/asio/pull-request/1
 I have rebuilt all asio's dependencies and only encountered issues with
 abiword and OpenSceneGraph - both were complaining about error not being
 a member of asio::placeholders. Same issues were found by gentoo, I have
 linked the relevant bug reports in the PR. Is this something you would
 be able to advise about? I am happy to share full build logs if needed.
>>>
>>> I haven't personally looked at asio 1.14.0 yet so I don't have the
>>> solution off the top of my head.  These are the type of issues I
>>> normally deal with in upstream development.
>>>
>>>  From a strategic perspective, I feel it is most efficient to try and
>>> coordinate with the upstreams and other distributions so that everybody
>>> is supporting the same asio in each of the major distributions.
>>>
>>> In any C++ library, there are small API changes from time to time
>>> leading to the type of problem you describe.
>>>
>>> If upstreams are using travis-ci, we are testing against version 1.12.2
>>> from Debian/Ubuntu and may not be aware of issues in asio 1.14.0.  Even
>>> if you patch for the issue, it may be completely untested upstream.
>>> That is why it is so vital to resolve the Debian/Ubuntu lag.
>>>
>>> Is there a convenient way for upstreams to make CI builds on the latest
>>> Fedora rawhide in parallel with our travis-ci Ubuntu builds?
>>>
 Please also note that I have checked both fale and uwog's recent
 activity with fedora-active-user and neither seem to have been active
 lately.
>>>
>>> Thanks for this feedback.  Dakota, do you want to be promoted to admin
>>> on asio?
>>>
>>> Is either of you happy to be co-maintainer of resiprocate with me?  I
>>> opened an issue to unretire it.  I do upstream releases and I run the
>>> latest version for fedrtc.org (using CentOS/EPEL) so it is important for
>>> me that it supports Fedora and any Fedora issues are given the attention
>>> they deserve during the release process.
>>
>>
>> Sure, admin is ok with me. Co-maintainer of resiprocate would also be
>> something I'd be willing to take on.
> 
> It's been a couple of weeks now, and I don't see "raineforest" listed
> as admin for asio[1]. Can you please add him as requested?

I had added Dakota as developer (commit?) and when I looked tonight, I
notice he had vanished.  I've added him now as admin.  Is there any way
to see how he vanished?  Does he need to explicitly click something to
accept the permissions?


> Also, resiprocate[2] was retired three months ago after being orphaned
> for 6 weeks for failing to build for Fedora 31[3]. It will need to go
> through a whole new review process *after* asio is updated.

Is it possible to make Covid-19 exception for this and just put it back
again?  Lots of people want to use the WebRTC conferencing features.
Yesterday I updated[4] JSCommunicator and today I tweaked[5] resiprocate
for asio 1.14.0 so it is ready to go in Fedora, EPEL and fedrtc.org.  I
have a backlog of upstream issues in all these projects and would prefer
not to lose time in another review process.

> 
> [1]: https://src.fedoraproject.org/rpms/asio
> [2]: https://src.fedoraproject.org/rpms/resiprocate
> [3]: https://pagure.io/releng/issue/8917#comment-610267
> 

[4]: https://groups.google.com/forum/#!forum/jssip
[5]: https://github.com/resiprocate/resiprocate/commits/master
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Broken OCaml dependencies in fedora 32

[Fabio Valentini]

Hi everybody,

I can't seem to figure out why this happened, but there are now a lot
of OCaml packages in fedora 32 that have broken dependencies. I've CCd
two of the maintainers that are impacted most by this (rjones and
jjames).

Right now, the following packages have broken dependencies and are not
installable (you can verify this with "mock -r fedora-32-x86_64
(--enablerepo updates-testing, if necessary) install foo"):

- coccinelle
- coq{,-coqide}
- frama-c
- gappalib-coq
- graphviz-opaml
- nbdkit-ocaml-plugin-devel
- ocaml-brlapi
- ocaml-json-wheel{,-devel}
- ocaml-libguestfs
- ocaml-libnbd
- ocaml-ppx-tools
- ocaml-stdint
- ocaml-why3
- why-jessie

Most now broken dependencies seem to be caused by "Requires:
ocaml(Stdlib) = aa33af4684579b41817bc194be0a7a26", which makes we
wonder if those packages were built against the wrong version of ocaml
somehow (maybe due to the side tag usage).

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating wcslib in Rawhide to 7.1

[Fabio Valentini]

On Thu, Mar 5, 2020 at 1:19 PM Sergio Pascual  wrote:
>
> Hello, I'm going to update (one week from now) wcslib to from 6.4 to 7.1. 
> There is an API break, the changes are here; 
> https://www.atnf.csiro.au/people/mcalabre/WCS/CHANGES
>
> I'm CCing affected package owners (astrometry, cpl, kstars and 
> python-astropy).

wcslib 7 has landed in rawhide but most of the dependent packages have
been rebuilt yet.

- astrometry
- cpl
- kstars
- python-astropy

Please coordinate the necessary rebuilds.

Fabio

> Regards, Sergio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Committee

[Troy Dawson]

Biggest thing on the agenda is the vote/discussion about the official
change to EPEL guidelines.
https://pagure.io/epel/issue/100

Please look over the latest/final proposal.  If you want, you can vote
on the issue itself, or just be prepared to vote at the meeting.


On Thu, Mar 19, 2020 at 2:00 PM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2020-03-20 from 21:00:00 to 22:00:00 UTC
>At freenode@fedora-meeting
>
> The meeting will be about:
> This is the weekly EPEL Steering Committee Meeting.
>
> A general agenda is the following:
>
> #meetingname EPEL
> #topic Intros
> #topic Old Business
> #topic EPEL-6
> #topic EPEL-7
> #topic EPEL-8
> #topic Openfloor
> #endmeeting
>
>
>
>
> Source: https://apps.fedoraproject.org/calendar/meeting/9722/
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: CoC

[Michael Watters]

This is one reason I vastly prefer decentralized platforms such as
mailing lists and Usenet.  You can't unsend an email.

On 3/19/2020 4:20 PM, Ty Young wrote:
> Oh, and when called out about the censorship on places like Medium &
> Reddit, people who apparently have the ability to uncensor threads(AKA
> higher ups) here attempted to weaponize it by threats as if it was
> somehow damning and later only uncensored parts of the whole thread. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2020-03-20 from 21:00:00 to 22:00:00 UTC
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




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

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: CoC

[Ty Young]

On 3/19/20 2:43 PM, Neal Gompa wrote:

On Thu, Mar 19, 2020 at 3:37 PM Ty Young  wrote:


On 3/19/20 2:18 PM, Daniel Pocock wrote:

On 12/03/2020 22:34, Matthew Miller wrote:

On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:

It is very, very wrong and I don't feel I should have to make a public
request like this.  Nonetheless, there is a certain type of person who

Daniel, to request re-instatement, please follow the process outlined
in the original code-of-conduct suspension notice you received. A
public post is not necessary.

Personally, I feel offended by your choice of words

A suspension of a blog may itself be a violation of the Code of Conduct
if the blog was written in good faith

I never received one complaint about my blog from anybody in the Fedora
world.  Several people noticed when it disappeared though.

The blog post in question discussed a conflict of interest between the
leaders of two free software organizations, the Debian Project Leader
and the OSI board president.  As I interacted with both of them
personally, I felt that I was qualified to share my observations.

That topic itself was forced into the public because one of the people
party to the conflict of interest had spread gossip about me and the
other used her speech at an event for humiliating volunteers.

It feels like Codes of Conduct apply to some people and not others.  As
George Orwell puts it, /All animals are equal but some animals are more
equal than others/.


Have you seen Gnome's CoC? It literally allows racism. There was a bit
of an uproar about it, and Gnome foundation/developers members refused
to change it.


(Gnome and Fedora are very incestous projects, so yes, it is relevant)


Now that communism is the cool, hip ideology in town, Gnome/Fedora are
embracing it. Book burning is the next step, but one might argue the
deletion of discussion threads and blogs already *is* that step.



Please stop insinuating things that are not true. Fedora and GNOME are
no more "incestuous" than any other combination of upstream projects
with Fedora. Many developers of many projects choose to use Fedora and
maintain packages in the distribution.



How many of those projects are sponsored by the same large corporation? 
How many distros are flagships for DEs?




  It doesn't mean that those
projects are tightly woven in such a way that they behave identically
or have the same governance model.

I will note that Fedora and GNOME *do* have very different models of governance.


Fedora's Code of Conduct[1] asks people to be excellent to each other.
When talking about governance issues, being excellent to other
volunteers means telling them the truth about leadership problems in the
free software world.

Being excellent to leaders who behave badly means keeping a focus on the
issues.  For example, when blogging about two people with a romantic
conflict of interest, I would never speculate about their first date and
other personal details, I would only focus on the way their decision
making was impaired.

Even this week there are people writing public comments alleging I had a
conflict of interest, but that is false.  I named Chris Lamb and Molly
de Blanc because their conflict of interest was at the root of certain
problems.  At least one member of Debian's mentoring team also had a
conflict of interest with an intern.  I didn't identify them out of
concerns for student privacy.  Nonetheless, when people spread gossip,
leadership figures have a responsibility to stop it, but they didn't,
they added fuel to the fire and they continue to do so even now.

If the leaders of organizations can behave like that, why should the
Code of Conduct deny a volunteer a right of reply?


Silly Daniel, you aren't supposed to question the supreme leaders. You
have to fall in line and never question anything.


If you need help understanding, I recommend reading up on what's going
on in China right now. Concentration camps, book burning, police
brutality, people vanishing, etc...


This is not how Fedora works *at all*. If anything, I'm proof of that,
as are many other Fedora contributors. It doesn't mean you have to be
a terrible human while disagreeing with people.



"terrible human" is completely subjective. People can be and often are 
biased, especially in a community so "passionate".



I seem to remember a certain thread about X. Org server running as 
root(breaking applications as a result) that went south in large part 
because of people having beef with Nvidia not releasing their driver 
under an open source license. Instead of dealing with the people causing 
issues, it continued to go south, until it was nuked and censored by the 
supreme leaders.



But that's OK... because ideology.


Oh, and when called out about the censorship on places like Medium & 
Reddit, people who apparently have the ability to uncensor threads(AKA 
higher ups) here attempted to weaponize it by threats as if it was 
somehow damning and later 

Re: CoC

[John M. Harris Jr]

On Thursday, March 19, 2020 12:46:01 PM MST Silvia Sánchez wrote:
> Hello,
> 
> I just read Gnome Code of Conduct, which can be found here:
> https://wiki.gnome.org/Foundation/CodeOfConduct
> Can anyone explain in which line racism is allowed?
> Also, what communism has to do with anything?  Aren't you getting a bit too
> paranoid? Why communist and not fascism?  And how the decisions made in a
> software-related community can escalate to concentration camps and police
> brutality?  How on Earth do you connect these activities?
> *Can we please get back to common sense?*
> 
> Kind regards,
> Lailah
> 
> On Thu, 19 Mar 2020 at 20:37, Ty Young  wrote:
> > On 3/19/20 2:18 PM, Daniel Pocock wrote:
> > > On 12/03/2020 22:34, Matthew Miller wrote:
> > >> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
> > >>> It is very, very wrong and I don't feel I should have to make a public
> > >>> request like this.  Nonetheless, there is a certain type of person who
> > >> 
> > >> Daniel, to request re-instatement, please follow the process outlined
> > >> in the original code-of-conduct suspension notice you received. A
> > >> public post is not necessary.
> > > 
> > > Personally, I feel offended by your choice of words
> > > 
> > > A suspension of a blog may itself be a violation of the Code of Conduct
> > > if the blog was written in good faith
> > > 
> > > I never received one complaint about my blog from anybody in the Fedora
> > > world.  Several people noticed when it disappeared though.
> > > 
> > > The blog post in question discussed a conflict of interest between the
> > > leaders of two free software organizations, the Debian Project Leader
> > > and the OSI board president.  As I interacted with both of them
> > > personally, I felt that I was qualified to share my observations.
> > > 
> > > That topic itself was forced into the public because one of the people
> > > party to the conflict of interest had spread gossip about me and the
> > > other used her speech at an event for humiliating volunteers.
> > > 
> > > It feels like Codes of Conduct apply to some people and not others.  As
> > > George Orwell puts it, /All animals are equal but some animals are more
> > > equal than others/.
> > 
> > Have you seen Gnome's CoC? It literally allows racism. There was a bit
> > of an uproar about it, and Gnome foundation/developers members refused
> > to change it.
> > 
> > 
> > (Gnome and Fedora are very incestous projects, so yes, it is relevant)
> > 
> > 
> > Now that communism is the cool, hip ideology in town, Gnome/Fedora are
> > embracing it. Book burning is the next step, but one might argue the
> > deletion of discussion threads and blogs already *is* that step.
> > 
> > > Fedora's Code of Conduct[1] asks people to be excellent to each other.
> > > When talking about governance issues, being excellent to other
> > > volunteers means telling them the truth about leadership problems in the
> > > free software world.
> > > 
> > > Being excellent to leaders who behave badly means keeping a focus on the
> > > issues.  For example, when blogging about two people with a romantic
> > > conflict of interest, I would never speculate about their first date and
> > > other personal details, I would only focus on the way their decision
> > > making was impaired.
> > > 
> > > Even this week there are people writing public comments alleging I had a
> > > conflict of interest, but that is false.  I named Chris Lamb and Molly
> > > de Blanc because their conflict of interest was at the root of certain
> > > problems.  At least one member of Debian's mentoring team also had a
> > > conflict of interest with an intern.  I didn't identify them out of
> > > concerns for student privacy.  Nonetheless, when people spread gossip,
> > > leadership figures have a responsibility to stop it, but they didn't,
> > > they added fuel to the fire and they continue to do so even now.
> > > 
> > > If the leaders of organizations can behave like that, why should the
> > > Code of Conduct deny a volunteer a right of reply?
> > 
> > Silly Daniel, you aren't supposed to question the supreme leaders. You
> > have to fall in line and never question anything.
> > 
> > 
> > If you need help understanding, I recommend reading up on what's going
> > on in China right now. Concentration camps, book burning, police
> > brutality, people vanishing, etc...
> > 
> > > Regards,
> > > 
> > > Daniel
> > > 
> > > 1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/

What does this CoC nonsense have to do with Fedora? Unless I'm missing some of 
this thread, it looks like this sort of thing is better discussed on some 
Debian, OSI or GNOME mailing list, where these folks can take their CoC fight. 
In the future, I believe removing the CoC link from the footer of messages on 
this mailing list would prevent these sorts of threads from cropping up.

Silvia,
There is not as much of a difference between communism and fascism from the 

Re: CoC

[Michael Catanzaro]

On Thu, Mar 19, 2020 at 2:36 pm, Ty Young  wrote:

Have you seen Gnome's CoC? It literally allows racism. There was a bit
of an uproar about it, and Gnome foundation/developers members refused
to change it.


https://wiki.gnome.org/Foundation/CodeOfConduct

Clearly prohibits:

"Sexist, racist, homophobic, transphobic, ableist language or otherwise 
exclusionary language."


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CoC

[Kevin Fenzi]

Hey folks. 

Just a reminder that this is the Fedora Devel list.

Fedora devel related things are ontopic and this thread is drifting way
away from those. :) 

If you want to discuss the Fedora code of conduct, I guess the council
discuss list would be ok for that? Other topics might be better for
private emails or the like. 

Thanks, 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CoC

[Daniel Pocock]

On 19/03/2020 20:46, Silvia Sánchez wrote:
> 
> Hello,
> 
> I just read Gnome Code of Conduct, which can be found
> here:  https://wiki.gnome.org/Foundation/CodeOfConduct 
> Can anyone explain in which line racism is allowed?
> Also, what communism has to do with anything?  Aren't you getting a bit


I think some people confuse communism and totalitarianism

You can actually have the latter without the former.  Some people feel
the former was just a disguise to sugar-coat the latter.

The Sam Hartman "Debian ban" blog looks suspiciously like an enforced
holiday in Siberia.  His evidence looks comprehensive enough to satisfy
any gulag or kangaroo court but nobody else.

Coincidentally, I was born on 9 November.  It is the day the Berlin wall
came down.  They tried to rebuild the wall in 2018 as an art project,
Dau Freedom, and it was censored[1], just like my blogs.

For those who are curious, there is also a DAU movie and people already
complain[2] that it is not code-of-conduct compliant.  But if you are
locked in coronavirus lockdown right now, maybe it will help pass the
time better than debating codes of conduct.

> too paranoid? Why communist and not fascism?  And how the decisions made
> in a software-related community can escalate to concentration camps and
> police brutality?  How on Earth do you connect these activities?
> /Can we please get back to common sense?/
> 


I sincerely hope we can discuss the code of conduct ambiguities and
contradictions without violating the code of conduct.

But if we can't discuss it at all, then the code of conduct is having
the wrong impact, at least from the perspective of the grass roots
volunteers.

Regards,

Daniel


1.
https://www.theguardian.com/world/2018/sep/24/art-installation-of-replica-berlin-wall-rejected-by-city-authorities
2.
https://www.theguardian.com/world/2020/mar/03/russian-film-dau-natasha-violence-soviet
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[John M. Harris Jr]

On Saturday, March 14, 2020 5:05:11 AM MST Marius Schwarz wrote:
> Hi all,
> 
> bevor we start, it is a VERY VERY SPECIAL situation i will talk about
> now. It could get fixed by a UNUSUAL approach.
> 
> The device we talk about as an example is the SURFACE PRO Tablet Series
> from Microsoft WITH a LUKS encrypted installation on the drive.
> 
> Situation:
> 
> If you encrypt  the fedora ( or any ) installation with luks, as
> security of a mobile device indicates, you end up without the
> possibility to enter the password, when you do not have an in/external
> keyboard at hand.
> 
> As tablets do not come with a keypad ( called TypoCover by MS ) by
> default, it's not possible to enter the password when Plymouth asks for it.
> 
> There is simply no keyboard available, AND additionally since surface
> pro 4+,  touch does not work with upstream kernel, so adding an OSK
> isn't helping.
> 
> Solution until now: TypeCover or external Keyboard OR no encryption for
> the device.
> 
> 
> ## My Suggestion ##
> 
> MS blends in a very basic keyboard when grub is displayed. I guess it's
> for low level repairs when windows fails. The clou is, it gets displayed
> and handled by the Surface Bios itself as it seems.
> 
> With the help of this OSK on grublevel, it is possible to use an
> (nonexisting yet)  envvar or a kernel parameter to pass the password
> down to the luks unlock part. (not to forget, to choose a kernel there ;) )
> 
> ## BENEFITS ##
> 
> This would secure the mobile device and  makes it usable as a real
> tablet computers should be used.
> 
> It's also a way for other future mobile devices with touchscreens-only,
> how they  could solve the issue i.e. linux smartphones.
> 
> it gets really interesting as a standard way of how things should work,
> when you keep in mind that any mobile bios  has already solved touch
> support for the device in question, because they have the urge need to
> enter the phones bios and do things like "wipe cache" "boot from .."
> "test graphics" etc. etc. which is then obviously touchbased.  Opening
> the already present touchhandling to an OSK on startup as MS did, could
> be the way to go for all future touch devices.
> 
> 
> Your comments on this, please.
> 
> Best regards,
> Marius Schwarz

If you're drawing a direct comparison to the Fedora boot process from the 
Windows process, the point at which Windows is presenting an OSK is about at 
the point after which initrd is loaded in the Fedora boot process. It's not 
happening at the bootloader itself.

Further, there is no threading support in GRUB to begin with, nor a GUI 
toolkit which could be used for an OSK.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[John M. Harris Jr]

On Monday, March 16, 2020 2:15:34 AM MST Marius Schwarz wrote:
> Am 16.03.20 um 09:15 schrieb Tomasz Torcz:
> 
> >> I  knew someone would bring this up:  TMP does not protect your drive,
> >> as you could boot with "init=/bin/bash 1" . 
> >> 
> >How do you do that WITHOUT KEYBOARD?  This thread is about very
> >  
> >  specific situation, please do not forget that when generalising.
> >
> >
> 
> 
> The Surface Bios is inserting an OSK (only) on the level where grub
> operates, so you can choose your kernel and edit your cmd line.
> No external keyboard needed at that point.
> 
> Best regards,
> Marius Schwarz

If you're drawing a direct comparison to the Fedora boot process from the 
Windows process, the point at which Windows is presenting an OSK is about at 
the point after which initrd is loaded in the Fedora boot process. It's not 
happening at the bootloader itself.

-- 
John M. Harris, Jr.

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CoC

[Silvia Sánchez]

Hello,

I just read Gnome Code of Conduct, which can be found here:
https://wiki.gnome.org/Foundation/CodeOfConduct
Can anyone explain in which line racism is allowed?
Also, what communism has to do with anything?  Aren't you getting a bit too
paranoid? Why communist and not fascism?  And how the decisions made in a
software-related community can escalate to concentration camps and police
brutality?  How on Earth do you connect these activities?
*Can we please get back to common sense?*

Kind regards,
Lailah



On Thu, 19 Mar 2020 at 20:37, Ty Young  wrote:

>
> On 3/19/20 2:18 PM, Daniel Pocock wrote:
> >
> > On 12/03/2020 22:34, Matthew Miller wrote:
> >> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
> >>> It is very, very wrong and I don't feel I should have to make a public
> >>> request like this.  Nonetheless, there is a certain type of person who
> >> Daniel, to request re-instatement, please follow the process outlined
> >> in the original code-of-conduct suspension notice you received. A
> >> public post is not necessary.
> >
> > Personally, I feel offended by your choice of words
> >
> > A suspension of a blog may itself be a violation of the Code of Conduct
> > if the blog was written in good faith
> >
> > I never received one complaint about my blog from anybody in the Fedora
> > world.  Several people noticed when it disappeared though.
> >
> > The blog post in question discussed a conflict of interest between the
> > leaders of two free software organizations, the Debian Project Leader
> > and the OSI board president.  As I interacted with both of them
> > personally, I felt that I was qualified to share my observations.
> >
> > That topic itself was forced into the public because one of the people
> > party to the conflict of interest had spread gossip about me and the
> > other used her speech at an event for humiliating volunteers.
> >
> > It feels like Codes of Conduct apply to some people and not others.  As
> > George Orwell puts it, /All animals are equal but some animals are more
> > equal than others/.
>
>
> Have you seen Gnome's CoC? It literally allows racism. There was a bit
> of an uproar about it, and Gnome foundation/developers members refused
> to change it.
>
>
> (Gnome and Fedora are very incestous projects, so yes, it is relevant)
>
>
> Now that communism is the cool, hip ideology in town, Gnome/Fedora are
> embracing it. Book burning is the next step, but one might argue the
> deletion of discussion threads and blogs already *is* that step.
>
>
> >
> > Fedora's Code of Conduct[1] asks people to be excellent to each other.
> > When talking about governance issues, being excellent to other
> > volunteers means telling them the truth about leadership problems in the
> > free software world.
> >
> > Being excellent to leaders who behave badly means keeping a focus on the
> > issues.  For example, when blogging about two people with a romantic
> > conflict of interest, I would never speculate about their first date and
> > other personal details, I would only focus on the way their decision
> > making was impaired.
> >
> > Even this week there are people writing public comments alleging I had a
> > conflict of interest, but that is false.  I named Chris Lamb and Molly
> > de Blanc because their conflict of interest was at the root of certain
> > problems.  At least one member of Debian's mentoring team also had a
> > conflict of interest with an intern.  I didn't identify them out of
> > concerns for student privacy.  Nonetheless, when people spread gossip,
> > leadership figures have a responsibility to stop it, but they didn't,
> > they added fuel to the fire and they continue to do so even now.
> >
> > If the leaders of organizations can behave like that, why should the
> > Code of Conduct deny a volunteer a right of reply?
>
>
> Silly Daniel, you aren't supposed to question the supreme leaders. You
> have to fall in line and never question anything.
>
>
> If you need help understanding, I recommend reading up on what's going
> on in China right now. Concentration camps, book burning, police
> brutality, people vanishing, etc...
>
>
> >
> > Regards,
> >
> > Daniel
> >
> > 1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 

Re: CoC

[Neal Gompa]

On Thu, Mar 19, 2020 at 3:37 PM Ty Young  wrote:
>
>
> On 3/19/20 2:18 PM, Daniel Pocock wrote:
> >
> > On 12/03/2020 22:34, Matthew Miller wrote:
> >> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
> >>> It is very, very wrong and I don't feel I should have to make a public
> >>> request like this.  Nonetheless, there is a certain type of person who
> >> Daniel, to request re-instatement, please follow the process outlined
> >> in the original code-of-conduct suspension notice you received. A
> >> public post is not necessary.
> >
> > Personally, I feel offended by your choice of words
> >
> > A suspension of a blog may itself be a violation of the Code of Conduct
> > if the blog was written in good faith
> >
> > I never received one complaint about my blog from anybody in the Fedora
> > world.  Several people noticed when it disappeared though.
> >
> > The blog post in question discussed a conflict of interest between the
> > leaders of two free software organizations, the Debian Project Leader
> > and the OSI board president.  As I interacted with both of them
> > personally, I felt that I was qualified to share my observations.
> >
> > That topic itself was forced into the public because one of the people
> > party to the conflict of interest had spread gossip about me and the
> > other used her speech at an event for humiliating volunteers.
> >
> > It feels like Codes of Conduct apply to some people and not others.  As
> > George Orwell puts it, /All animals are equal but some animals are more
> > equal than others/.
>
>
> Have you seen Gnome's CoC? It literally allows racism. There was a bit
> of an uproar about it, and Gnome foundation/developers members refused
> to change it.
>
>
> (Gnome and Fedora are very incestous projects, so yes, it is relevant)
>
>
> Now that communism is the cool, hip ideology in town, Gnome/Fedora are
> embracing it. Book burning is the next step, but one might argue the
> deletion of discussion threads and blogs already *is* that step.
>
>

Please stop insinuating things that are not true. Fedora and GNOME are
no more "incestuous" than any other combination of upstream projects
with Fedora. Many developers of many projects choose to use Fedora and
maintain packages in the distribution. It doesn't mean that those
projects are tightly woven in such a way that they behave identically
or have the same governance model.

I will note that Fedora and GNOME *do* have very different models of governance.

> >
> > Fedora's Code of Conduct[1] asks people to be excellent to each other.
> > When talking about governance issues, being excellent to other
> > volunteers means telling them the truth about leadership problems in the
> > free software world.
> >
> > Being excellent to leaders who behave badly means keeping a focus on the
> > issues.  For example, when blogging about two people with a romantic
> > conflict of interest, I would never speculate about their first date and
> > other personal details, I would only focus on the way their decision
> > making was impaired.
> >
> > Even this week there are people writing public comments alleging I had a
> > conflict of interest, but that is false.  I named Chris Lamb and Molly
> > de Blanc because their conflict of interest was at the root of certain
> > problems.  At least one member of Debian's mentoring team also had a
> > conflict of interest with an intern.  I didn't identify them out of
> > concerns for student privacy.  Nonetheless, when people spread gossip,
> > leadership figures have a responsibility to stop it, but they didn't,
> > they added fuel to the fire and they continue to do so even now.
> >
> > If the leaders of organizations can behave like that, why should the
> > Code of Conduct deny a volunteer a right of reply?
>
>
> Silly Daniel, you aren't supposed to question the supreme leaders. You
> have to fall in line and never question anything.
>
>
> If you need help understanding, I recommend reading up on what's going
> on in China right now. Concentration camps, book burning, police
> brutality, people vanishing, etc...
>

This is not how Fedora works *at all*. If anything, I'm proof of that,
as are many other Fedora contributors. It doesn't mean you have to be
a terrible human while disagreeing with people.

Please stop making untrue and unkind comparisons.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CoC

[Ty Young]

On 3/19/20 2:18 PM, Daniel Pocock wrote:


On 12/03/2020 22:34, Matthew Miller wrote:

On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:

It is very, very wrong and I don't feel I should have to make a public
request like this.  Nonetheless, there is a certain type of person who

Daniel, to request re-instatement, please follow the process outlined
in the original code-of-conduct suspension notice you received. A
public post is not necessary.


Personally, I feel offended by your choice of words

A suspension of a blog may itself be a violation of the Code of Conduct
if the blog was written in good faith

I never received one complaint about my blog from anybody in the Fedora
world.  Several people noticed when it disappeared though.

The blog post in question discussed a conflict of interest between the
leaders of two free software organizations, the Debian Project Leader
and the OSI board president.  As I interacted with both of them
personally, I felt that I was qualified to share my observations.

That topic itself was forced into the public because one of the people
party to the conflict of interest had spread gossip about me and the
other used her speech at an event for humiliating volunteers.

It feels like Codes of Conduct apply to some people and not others.  As
George Orwell puts it, /All animals are equal but some animals are more
equal than others/.



Have you seen Gnome's CoC? It literally allows racism. There was a bit 
of an uproar about it, and Gnome foundation/developers members refused 
to change it.



(Gnome and Fedora are very incestous projects, so yes, it is relevant)


Now that communism is the cool, hip ideology in town, Gnome/Fedora are 
embracing it. Book burning is the next step, but one might argue the 
deletion of discussion threads and blogs already *is* that step.





Fedora's Code of Conduct[1] asks people to be excellent to each other.
When talking about governance issues, being excellent to other
volunteers means telling them the truth about leadership problems in the
free software world.

Being excellent to leaders who behave badly means keeping a focus on the
issues.  For example, when blogging about two people with a romantic
conflict of interest, I would never speculate about their first date and
other personal details, I would only focus on the way their decision
making was impaired.

Even this week there are people writing public comments alleging I had a
conflict of interest, but that is false.  I named Chris Lamb and Molly
de Blanc because their conflict of interest was at the root of certain
problems.  At least one member of Debian's mentoring team also had a
conflict of interest with an intern.  I didn't identify them out of
concerns for student privacy.  Nonetheless, when people spread gossip,
leadership figures have a responsibility to stop it, but they didn't,
they added fuel to the fire and they continue to do so even now.

If the leaders of organizations can behave like that, why should the
Code of Conduct deny a volunteer a right of reply?



Silly Daniel, you aren't supposed to question the supreme leaders. You 
have to fall in line and never question anything.



If you need help understanding, I recommend reading up on what's going 
on in China right now. Concentration camps, book burning, police 
brutality, people vanishing, etc...





Regards,

Daniel

1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CoC (was: putting my blog back on Planet Fedora)

[Daniel Pocock]

On 12/03/2020 22:34, Matthew Miller wrote:
> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
>> It is very, very wrong and I don't feel I should have to make a public
>> request like this.  Nonetheless, there is a certain type of person who
> 
> Daniel, to request re-instatement, please follow the process outlined
> in the original code-of-conduct suspension notice you received. A
> public post is not necessary.


Personally, I feel offended by your choice of words

A suspension of a blog may itself be a violation of the Code of Conduct
if the blog was written in good faith

I never received one complaint about my blog from anybody in the Fedora
world.  Several people noticed when it disappeared though.

The blog post in question discussed a conflict of interest between the
leaders of two free software organizations, the Debian Project Leader
and the OSI board president.  As I interacted with both of them
personally, I felt that I was qualified to share my observations.

That topic itself was forced into the public because one of the people
party to the conflict of interest had spread gossip about me and the
other used her speech at an event for humiliating volunteers.

It feels like Codes of Conduct apply to some people and not others.  As
George Orwell puts it, /All animals are equal but some animals are more
equal than others/.

Fedora's Code of Conduct[1] asks people to be excellent to each other.
When talking about governance issues, being excellent to other
volunteers means telling them the truth about leadership problems in the
free software world.

Being excellent to leaders who behave badly means keeping a focus on the
issues.  For example, when blogging about two people with a romantic
conflict of interest, I would never speculate about their first date and
other personal details, I would only focus on the way their decision
making was impaired.

Even this week there are people writing public comments alleging I had a
conflict of interest, but that is false.  I named Chris Lamb and Molly
de Blanc because their conflict of interest was at the root of certain
problems.  At least one member of Debian's mentoring team also had a
conflict of interest with an intern.  I didn't identify them out of
concerns for student privacy.  Nonetheless, when people spread gossip,
leadership figures have a responsibility to stop it, but they didn't,
they added fuel to the fire and they continue to do so even now.

If the leaders of organizations can behave like that, why should the
Code of Conduct deny a volunteer a right of reply?

Regards,

Daniel

1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[Chris Murphy]

On Thu, Mar 19, 2020 at 11:53 AM Marius Schwarz  wrote:
>
> Am 19.03.20 um 17:11 schrieb Michael Cronenworth:
> > On 3/19/20 11:04 AM, Marius Schwarz wrote:
> >> correct and thats the main issue, as long you have grub where you can
> >> edit the kernel line to start in runlevel 1.
> >> This makes the encryption null and void.
> >
> > Adding a grub password will prevent those without it from editing your
> > boot parameters. By default you can still boot without the grub
> > password. Does that help?
>
> It would solve a problem.
>
> - does it prevent updates ( after booting into rl 5 ) of grub?
> - where is the passcode stored?

grub.cfg or user.cfg contains the hashed password

https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Password_protection_of_GRUB_menu
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sec-protecting_grub_2_with_a_password

But if the attacker has physical access to the computer, they can
mount /boot/efi or /boot where this file is stored; and remove the
password requirement. The GRUB password protection workflow protects
the kiosk use case, where there is no physical access. Not a stolen
laptop.

I think what you'd want for the stolen laptop use case is an encrypted
$BOOT, which GRUB does support:

The first grub.cfg is unencrypted, and provides strictly for unlocking
a LUKS1 (no LUKS2 support yet) $BOOT volume, and then using
'configfile' command to read a second "real" grub.cfg on the encrypted
$BOOT, which also contains BLS snippets, and kernel+initramfs. Since a
passphrase is required to even read these files, in order to boot the
installed system, I'm not sure it's necessary to also lock down the
command line. (Also, the setup details differ considerably between
UEFI and BIOS.)

The out of the box UX, whether GRUB edit lockdown or encrypted $BOOT,
would be terrible. It requires a sophisticated user to understand,
maintain, and troubleshoot such a setup.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[Marius Schwarz]

Am 19.03.20 um 17:11 schrieb Michael Cronenworth:
> On 3/19/20 11:04 AM, Marius Schwarz wrote:
>> correct and thats the main issue, as long you have grub where you can
>> edit the kernel line to start in runlevel 1.
>> This makes the encryption null and void.
>
> Adding a grub password will prevent those without it from editing your
> boot parameters. By default you can still boot without the grub
> password. Does that help?

It would solve a problem.

- does it prevent updates ( after booting into rl 5 ) of grub?
- where is the passcode stored?

best regards,
Marius

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Miro Hrončok]

On 19. 03. 20 18:47, Richard Shaw wrote:
I do in fact have that setup, but I tried commenting it out and now mock fails 
almost immediately not able to find /usr/bin/yum.


After i removed that config, i needed to do:

$ mock -r epel-7-x86_64 --scrub all

To get rid of the broken bootstrap mock.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Richard Shaw]

On Thu, Mar 19, 2020 at 9:58 AM Miro Hrončok  wrote:

> I've seen this before. It was my ~/.config/mock.cfg:
>
>  config_opts['package_manager'] = 'dnf'
>

I do in fact have that setup, but I tried commenting it out and now mock
fails almost immediately not able to find /usr/bin/yum.

$ cat ~/.config/mock.cfg
config_opts['cleanup_on_failure'] = 0
config_opts['nosync'] = True
config_opts['macros']['%_smp_mflags'] = "-j12"
#config_opts['package_manager'] = 'dnf'



> See what config options you have in ~/.config/mock.cfg and /etc/mock/ or
> /etc/mock/default.cfg.
>

$ cat /etc/mock/default.cfg
config_opts['releasever'] = '31'
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Artem Egorenkov

[Peter Lemenkov]

Hello Artem,
Speaking of Java - Java SIG also wants help. Just fyi :)

чт, 19 мар. 2020 г. в 17:35, Artem Egorenkov :
>
> Hi,
>
> My name is Artem Egorenkov. I recently joined Red Hat in Brno, Czech Republic.
> I worked as a Software Developer for around 7 years and most of my experience 
> relates to Java stack, and now I have decided to start in a system 
> development field.
>
> I don't have much experience in open source development, but I'm willing to 
> get it.
>
> I recently became a maintainer of "stabby" package, which was separated from 
> "getdns".
>
> Thanks,
> Artem
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Self Introduction: Artem Egorenkov

[Artem Egorenkov]

Hi,

My name is Artem Egorenkov. I recently joined Red Hat in Brno, Czech
Republic.
I worked as a Software Developer for around 7 years and most of my
experience relates to Java stack, and now I have decided to start in a
system development field.

I don't have much experience in open source development, but I'm willing to
get it.

I recently became a maintainer of "stabby" package, which was separated
from "getdns".

Thanks,
Artem
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Heads up: OpenSSL-1.1.1e coming to Rawhide

[Tomas Mraz]

The new openssl-1.1.1e is coming to Rawhide.

It reports premature EOF/improper shutdown on TLS connections more
properly. However this might make some dependencies broken in build
tests (such as Ruby).

As I would like to eventually update the openssl also on stable
branches because it brings many bugfixes please consider bringing
eventual fixes/workarounds in depending packages also there.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[Michael Cronenworth]

On 3/19/20 11:04 AM, Marius Schwarz wrote:

correct and thats the main issue, as long you have grub where you can
edit the kernel line to start in runlevel 1.
This makes the encryption null and void.


Adding a grub password will prevent those without it from editing your boot 
parameters. By default you can still boot without the grub password. Does that help?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[Petr Pisar]

On Thu, Mar 19, 2020 at 05:04:36PM +0100, Marius Schwarz wrote:
> Am 19.03.20 um 15:52 schrieb Momčilo Medić:
> >
> > I'm not familiar with TPM chips, but from what I read here it sounds
> > like there would be no password prompt and anyone would be able to boot
> > the device, no?
> >
> >
> 
> correct and thats the main issue, as long you have grub where you can
> edit the kernel line to start in runlevel 1.
> This makes the encryption null and void.
> 
You can protect the Grub editting with a password.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[Marius Schwarz]

Am 19.03.20 um 15:52 schrieb Momčilo Medić:
>
> I'm not familiar with TPM chips, but from what I read here it sounds
> like there would be no password prompt and anyone would be able to boot
> the device, no?
>
>

correct and thats the main issue, as long you have grub where you can
edit the kernel line to start in runlevel 1.
This makes the encryption null and void.

best regards,
Marius

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 compose report: 20200319.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200318.n.0
NEW: Fedora-32-20200319.n.0

= SUMMARY =
Added images:3
Dropped images:  0
Added packages:  1
Dropped packages:1
Upgraded packages:   6
Downgraded packages: 0

Size of added packages:  7.17 MiB
Size of dropped packages:621.27 KiB
Size of upgraded packages:   229.74 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -686.06 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-32-20200319.n.0.ppc64le.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-32-20200319.n.0.ppc64le.qcow2
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-32-20200319.n.0.ppc64le.vmdk

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: rust-ripgrep-12.0.0-1.fc32
Summary: Line oriented search tool using Rust's regex library
RPMs:ripgrep
Size:7.17 MiB


= DROPPED PACKAGES =
Package: postgresql-plruby-0.5.7-6.fc32
Summary: PostgreSQL Ruby Procedural Language
RPMs:postgresql-plruby postgresql-plruby-doc
Size:621.27 KiB


= UPGRADED PACKAGES =
Package:  curl-7.69.1-1.fc32
Old package:  curl-7.68.0-2.fc32
Summary:  A utility for getting files from remote servers (FTP, HTTP, and 
others)
RPMs: curl curl-minimal libcurl libcurl-devel libcurl-minimal
Size: 10.01 MiB
Size change:  39.61 KiB
Changelog:
  * Wed Mar 04 2020 Kamil Dudka  - 7.69.0-1
  - new upstream release

  * Mon Mar 09 2020 Kamil Dudka  - 7.69.0-2
  - make Flatpak work again (#1810989)

  * Wed Mar 11 2020 Kamil Dudka  - 7.69.1-1
  - new upstream release


Package:  mangohud-0.3.1-1.fc32
Old package:  mangohud-0.2.0-11.fc32
Summary:  Vulkan overlay layer for monitoring FPS, temperatures, CPU/GPU 
load and more
RPMs: mangohud
Size: 419.27 KiB
Size change:  -1.43 MiB
Changelog:
  * Sun Mar 15 2020 Artem Polishchuk  - 0.3.0-1
  - Update to 0.3.0

  * Wed Mar 18 2020 Artem Polishchuk  - 0.3.1-1
  - Update to 0.3.1


Package:  mock-2.1-1.fc32
Old package:  mock-2.0-2.fc32
Summary:  Builds packages inside chroots
RPMs: mock mock-lvm mock-scm
Size: 225.49 KiB
Size change:  -8.67 KiB
Changelog:
  * Wed Mar 11 2020 Pavel Raiskup  2.1-1
  - depend on mock-core-configs >= 32.4
  - new build-time testsuite
  - accept return code 0 from rpmbuild -br (thrnc...@redhat.com)
  - bootstrap: bind-mount the inner root mount with rprivate
  - new ssl_ca_bundle_path option
  - chain: don't run buildroot.finalize() for each package
  - don't fail when /etc/pki certs are not found (fros...@email.cz)
  - lvm_root: fix --scrub=all
  - exclude plugin compiled stuff packaged in sub-packages
  - keep trailing newlines in jinja expand
  - sign-plugin: use %(rpms) variable expansion again
  - bootstrap: bind-mount also baseurl=/absolute/dir repos
  - 'dnf.conf' config is now equivalent to 'yum.conf'
  - don't emit unneeded warning for missing yum (r...@remirepo.net)
  - allow --install /usr/bin/time [GH#474] (miros...@suchy.cz)


Package:  mock-core-configs-32.4-1.fc32
Old package:  mock-core-configs-32.3-2.fc32
Summary:  Mock core config files basic chroots
RPMs: mock-core-configs
Size: 51.50 KiB
Size change:  136 B
Changelog:
  * Wed Mar 11 2020 Pavel Raiskup  32.4-1
  - disable package_state plugin for openmandriva 4.0/Cooker
  - Mageia 6 is EOL
  - opensuse: copy ssl ca bundle to correct path


Package:  nethack-3.6.6-1.fc32
Old package:  nethack-3.6.5-1.fc32
Summary:  A rogue-like single player dungeon exploration game
RPMs: nethack nethack-bitmap-fonts nethack-bitmap-fonts-core
Size: 8.16 MiB
Size change:  -1.17 KiB
Changelog:
  * Tue Mar 10 2020 Ron Olson  - 3.6.6-1
  - Update to NetHack 3.6.6


Package:  wine-5.4-1.fc32
Old package:  wine-5.3-1.fc32
Summary:  A compatibility layer for windows applications
RPMs: wine wine-alsa wine-arial-fonts wine-capi wine-cms wine-common 
wine-core wine-courier-fonts wine-desktop wine-devel wine-filesystem 
wine-fixedsys-fonts wine-fonts wine-ldap wine-marlett-fonts 
wine-ms-sans-serif-fonts wine-openal wine-opencl wine-pulseaudio 
wine-small-fonts wine-symbol-fonts wine-system-fonts wine-systemd 
wine-tahoma-fonts wine-tahoma-fonts-system wine-times-new-roman-fonts 
wine-times-new-roman-fonts-system wine-twain wine-wingdings-fonts 
wine-wingdings-fonts-system
Size: 210.90 MiB
Size change:  745.15 KiB
Changelog:
  * Mon Mar 16 2020 Michael Cronenworth  5.4-1
  - version update



= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
L

Fedora-32-20200319.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200318.n.0):

ID: 551053  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/551053
ID: 551153  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/551153

Old failures (same test failed in Fedora-32-20200318.n.0):

ID: 551085  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/551085
ID: 551091  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/551091

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

Old soft failures (same test soft failed in Fedora-32-20200318.n.0):

ID: 551012  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/551012
ID: 551013  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/551013
ID: 551017  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/551017
ID: 551021  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/551021
ID: 551024  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/551024
ID: 551025  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/551025
ID: 551047  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/551047
ID: 551070  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/551070
ID: 551072  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/551072
ID: 551104  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/551104
ID: 551126  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/551126
ID: 551136  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/551136
ID: 551145  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/551145
ID: 551154  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/551154
ID: 551170  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/551170
ID: 551178  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/551178
ID: 551179  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/551179
ID: 551182  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/551182
ID: 551184  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/551184

Passed openQA tests: 149/171 (x86_64)

New passes (same test not passed in Fedora-32-20200318.n.0):

ID: 551078  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/551078
ID: 551087  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/551087
ID: 551130  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/551130

Skipped non-gating openQA tests: 1 of 173

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 7 MiB to 1 MiB
System load changed from 0.60 to 0.81
Average CPU usage changed from 5.42380952 to 17.35714286
Previous test data: https://openqa.fedoraproject.org/tests/54#downloads
Current test data: https://openqa.fedoraproject.org/tests/551057#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 0.93 to 1.18
Previous test data: https://openqa.fedoraproject.org/tests/55#downloads
Current test data: https://openqa.fedoraproject.org/tests/551058#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 1.00 to 1.83
Average CPU usage changed from 33.39523810 to 46.33809524
Previous test data: https://openqa.fedoraproject.org/tests/550016#downloads
Current test data: https://openqa.fedoraproject.org/tests/551074#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Mount /run/user/0 disappeared since previous compose
Used mem changed from 734 MiB to 893 MiB
System load changed from 1.02 to 1.88
Average CPU usage changed from 2.00952381 to 41.67619048
Previous test data: https://openqa.fedoraproject.org/tests/550017#downloads
Current test data: https://openqa.fedoraproject.org/tests/551075#downloads

Installed system 

Fedora-IoT-33-20200319.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 1/8 (x86_64)

New failures (same test not failed in Fedora-IoT-33-20200318.0):

ID: 551187  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/551187

Passed openQA tests: 7/8 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.28 to 0.07
Previous test data: https://openqa.fedoraproject.org/tests/549947#downloads
Current test data: https://openqa.fedoraproject.org/tests/551186#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Pavel Raiskup]

On Thursday, March 19, 2020 3:47:55 PM CET Richard Shaw wrote:
> > That sounds like the correct (the default in mock-core-conifgs) config.
> > At the same time, you seem to be using --resultdir option - which for some
> > reason triggers the problem.  Try to run mock without the option for now.
> 
> Using fedpkg I don't think you can not use --resultdir but I also tried a
> direct mock build.

Ah, makes sense.

> $ mock -r epel-7-x86_64 fail2ban-0.11.1-5.fc33.src.rpm
> 
> Mock Version: 2.1
> INFO: Mock Version: 2.1
> Finish(bootstrap): chroot init

This means that ^^^ bootstrap chroot was successfully initialized (before?).  So
you should have 'yum' inside.  That looks fine, but..

> Start: chroot init
> ...

... when initializing normal chroot ...

> ...
> Start: dnf install

... mock seems to do 'dnf install', instead of 'yum install'.  This looks like
you have `package_manager = dnf`.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Miro Hrončok]

On 19. 03. 20 15:47, Richard Shaw wrote:

$ mock -r epel-7-x86_64 fail2ban-0.11.1-5.fc33.src.rpm
INFO: mock.py version 2.1 starting (python version = 3.7.6)...
Start(bootstrap): init plugins
INFO: selinux enabled
Finish(bootstrap): init plugins
Start: init plugins
INFO: selinux enabled
Finish: init plugins
INFO: Signal handler active
Start: run
INFO: Start(fail2ban-0.11.1-5.fc33.src.rpm)  Config(epel-7-x86_64)
Start: clean chroot
Finish: clean chroot
Start(bootstrap): chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 2.1
INFO: Mock Version: 2.1
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 2.1
INFO: Mock Version: 2.1
Start: dnf install
Traceback (most recent call last):
   File "/usr/bin/dnf", line 57, in 
     from dnf.cli import main
   File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in 
     import dnf.base
   File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in 
     import libdnf.transaction
   File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in 

     from . import conf
   File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in 

     _conf = swig_import_helper()
   File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in 
swig_import_helper

     return importlib.import_module('_conf')
   File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
     __import__(name)
ImportError: No module named _conf
ERROR: Exception(fail2ban-0.11.1-5.fc33.src.rpm) Config(epel-7-x86_64) 0 minutes 
1 seconds


I've seen this before. It was my ~/.config/mock.cfg:

config_opts['package_manager'] = 'dnf'

See what config options you have in ~/.config/mock.cfg and /etc/mock/ or 
/etc/mock/default.cfg.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: entering luks password on grub level for devices without keyboards

[Momčilo Medić]

On Mon, 2020-03-16 at 14:13 -0400, Stephen John Smoogen wrote:
> 
> 
> On Mon, 16 Mar 2020 at 13:56, Robbie Harwood 
> wrote:
> > Tomasz Torcz  writes:
> > 
> > > On Sun, Mar 15, 2020 at 11:12:43PM +0100, Marius Schwarz wrote:
> > >> Am 15.03.20 um 13:32 schrieb Vitaly Zaitsev via devel:
> > >> > On 14.03.2020 13:05, Marius Schwarz wrote:
> > >> >> If you encrypt  the fedora ( or any ) installation with luks,
> > as
> > >> >> security of a mobile device indicates, you end up without the
> > >> >> possibility to enter the password, when you do not have an
> > in/external
> > >> >> keyboard at hand.
> > >> > You should use TPM 2.0 LUKS unlock instead of using passwords.
> > >> >
> > >> I  knew someone would bring this up:  TMP does not protect your
> > drive,
> > >> as you could boot with "init=/bin/bash 1" . 
> > >
> > >How do you do that WITHOUT KEYBOARD?  This thread is about
> > very
> > >  specific situation, please do not forget that when generalising.
> > 
> > I believe nothing stops someone from simply plugging one in.
> > 
> 
> And the counter point is that if you can't plug one in, it is not
> something that is supported. This is not general purpose hardware but
> a set of hardware that is primarily built to run Microsoft Windows by
> the vendor. There are going to be limits to what is going to be
> possible to get done with it. 
> 
> 

I am a owner of HP Pavilion X2 Detachable[1] which does have a
detachable keyboard.
Gnome is really a blast to work with on touchscreen devices and I like
it more and more.
The only thing not functioning in Fedora 32 with latest kernel iswebcam. 

It is very annoying to have to have keyboard attached for every
boot/reboot.
I'm only using keyboard when I need to do some serios terminal work or
so.

I understand that it would require significant effort but, I think that
having Plymouth OSK would be perfect. Even if it would be numbers only.

I'm not familiar with TPM chips, but from what I read here it sounds
like there would be no password prompt and anyone would be able to boot
the device, no?

[1] https://www8.hp.com/us/en/campaigns/pavilion-x2/overview.html

Kind regards,
Momo.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Richard Shaw]

On Thu, Mar 19, 2020 at 7:37 AM Pavel Raiskup  wrote:

> On Thursday, March 19, 2020 1:27:11 PM CET Richard Shaw wrote:
>
> We need to fix the bug I'm afraid.  If anyone can submit PR, it is
> welcome..  otherwise I hope I'll get to it this or the next week.
>
> > I tried adding the following to one of the EPEL 7 cfg files to no avail:
> >
> > config_opts['use_bootstrap'] = True
> > config_opts['package_manager'] = 'yum'
>
> That sounds like the correct (the default in mock-core-conifgs) config.
> At the same time, you seem to be using --resultdir option - which for some
> reason triggers the problem.  Try to run mock without the option for now.
>

Using fedpkg I don't think you can not use --resultdir but I also tried a
direct mock build.

Nope...

$ mock -r epel-7-x86_64 fail2ban-0.11.1-5.fc33.src.rpm
INFO: mock.py version 2.1 starting (python version = 3.7.6)...
Start(bootstrap): init plugins
INFO: selinux enabled
Finish(bootstrap): init plugins
Start: init plugins
INFO: selinux enabled
Finish: init plugins
INFO: Signal handler active
Start: run
INFO: Start(fail2ban-0.11.1-5.fc33.src.rpm)  Config(epel-7-x86_64)
Start: clean chroot
Finish: clean chroot
Start(bootstrap): chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 2.1
INFO: Mock Version: 2.1
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 2.1
INFO: Mock Version: 2.1
Start: dnf install
Traceback (most recent call last):
  File "/usr/bin/dnf", line 57, in 
from dnf.cli import main
  File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in

import dnf.base
  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in 
import libdnf.transaction
  File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in

from . import conf
  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in

_conf = swig_import_helper()
  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in
swig_import_helper
return importlib.import_module('_conf')
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
ImportError: No module named _conf
ERROR: Exception(fail2ban-0.11.1-5.fc33.src.rpm) Config(epel-7-x86_64) 0
minutes 1 seconds


Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20200319.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
4 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 13/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20200318.n.0):

ID: 550870  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/550870
ID: 550872  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/550872
ID: 550875  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/550875
ID: 550878  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/550878
ID: 550883  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/550883
ID: 550946  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/550946
ID: 550967  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/550967

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

ID: 550865  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/550865
ID: 550867  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/550867
ID: 550873  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/550873
ID: 550874  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/550874
ID: 550876  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/550876
ID: 550916  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/550916
ID: 550927  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/550927

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

New soft failures (same test not soft failed in Fedora-Rawhide-20200318.n.0):

ID: 550913  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/550913
ID: 550915  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/550915
ID: 550970  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/550970
ID: 551004  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/551004
ID: 551007  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/551007
ID: 551009  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/551009

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

ID: 550837  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/550837
ID: 550838  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/550838
ID: 550842  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/550842
ID: 550846  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/550846
ID: 550849  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/550849
ID: 550850  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/550850
ID: 550929  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/550929
ID: 550951  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/550951
ID: 550961  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/550961
ID: 550979  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/550979
ID: 550995  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/550995
ID: 551003  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/551003

Passed openQA tests: 126/171 (x86_64)

Skipped gating openQA tests: 4/171 (x86_64)

New skipped gating tests (same test not skipped in Fedora-Rawhide-20200318.n.0):

ID: 550890  Test: x86_64 Workstation-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/550890
ID: 550891  Test: x86_64 Workstation-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/550891
ID: 550893  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: 

Fedora rawhide compose report: 20200319.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200318.n.0
NEW: Fedora-Rawhide-20200319.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  11
Dropped packages:0
Upgraded packages:   111
Downgraded packages: 0

Size of added packages:  2.59 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.04 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -65.29 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20200318.n.0.iso

= ADDED PACKAGES =
Package: gap-pkg-qpa-1.30-1.fc33
Summary: GAP package for quivers and path algebras
RPMs:gap-pkg-qpa gap-pkg-qpa-doc
Size:1.83 MiB

Package: rust-base64-0.11-0.11.0-1.fc33
Summary: Encodes and decodes base64 as bytes or utf8
RPMs:rust-base64-0.11+alloc-devel rust-base64-0.11+default-devel 
rust-base64-0.11+std-devel rust-base64-0.11-devel
Size:68.30 KiB

Package: rust-listenfd-0.3.3-1.fc33
Summary: Simple library to work with listenfds passed from the outside
RPMs:rust-listenfd+default-devel rust-listenfd-devel
Size:20.70 KiB

Package: rust-platform-dirs-0.2.0-1.fc33
Summary: Library for obtaining platform dependant directory paths for 
application
RPMs:rust-platform-dirs+default-devel rust-platform-dirs-devel
Size:21.04 KiB

Package: rust-platforms-0.2.1-1.fc33
Summary: Rust platform registry with information about valid Rust platforms
RPMs:rust-platforms+default-devel rust-platforms+serde-devel 
rust-platforms+std-devel rust-platforms-devel
Size:49.54 KiB

Package: rust-psutil-3.0.1-2.fc33
Summary: Process and system monitoring library
RPMs:rust-psutil+cpu-devel rust-psutil+default-devel 
rust-psutil+derive_more-devel rust-psutil+disk-devel rust-psutil+glob-devel 
rust-psutil+host-devel rust-psutil+memory-devel rust-psutil+network-devel 
rust-psutil+num_cpus-devel rust-psutil+platforms-devel 
rust-psutil+process-devel rust-psutil+sensors-devel rust-psutil+signal-devel 
rust-psutil+unescape-devel rust-psutil-devel
Size:165.52 KiB

Package: rust-size-0.1.2-1.fc33
Summary: Units and formatting for file sizes in base2 and base10
RPMs:rust-size+default-devel rust-size-devel
Size:20.79 KiB

Package: rust-snafu-0.6.2-1.fc33
Summary: Ergonomic error handling library
RPMs:rust-snafu+backtrace-devel rust-snafu+backtraces-devel 
rust-snafu+backtraces-impl-backtrace-crate-devel rust-snafu+default-devel 
rust-snafu+futures-01-crate-devel rust-snafu+futures-01-devel 
rust-snafu+futures-core-crate-devel rust-snafu+futures-crate-devel 
rust-snafu+futures-devel rust-snafu+internal-dev-dependencies-devel 
rust-snafu+pin-project-devel rust-snafu+std-devel 
rust-snafu+unstable-backtraces-impl-std-devel rust-snafu-devel
Size:136.39 KiB

Package: rust-snafu-derive-0.6.2-1.fc33
Summary: Ergonomic error handling library
RPMs:rust-snafu-derive+default-devel 
rust-snafu-derive+unstable-backtraces-impl-std-devel rust-snafu-derive-devel
Size:33.47 KiB

Package: rust-tokio-tungstenite-0.10.1-1.fc33
Summary: Tokio binding for Tungstenite
RPMs:rust-tokio-tungstenite+connect-devel 
rust-tokio-tungstenite+default-devel rust-tokio-tungstenite+native-tls-devel 
rust-tokio-tungstenite+stream-devel rust-tokio-tungstenite+tls-devel 
rust-tokio-tungstenite+tokio-tls-devel rust-tokio-tungstenite-devel
Size:73.31 KiB

Package: stubby-0.3.1-0.2.20200318git7939e965.fc33
Summary: Application that act as a local DNS Privacy stub resolver
RPMs:stubby
Size:194.53 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  R-zoo-1.8.7-1.fc33
Old package:  R-zoo-1.8.6-5.fc32
Summary:  Z's ordered observations for irregular time series
RPMs: R-zoo R-zoo-devel
Size: 6.44 MiB
Size change:  23.61 KiB
Changelog:
  * Wed Mar 18 2020 Jos?? Matos  - 1.8.7-1
  - update to 1.8-7


Package:  adcli-0.9.0-1.fc33
Old package:  adcli-0.8.2-9.fc32
Summary:  Active Directory enrollment
RPMs: adcli adcli-doc
Size: 482.59 KiB
Size change:  -92.15 KiB
Changelog:
  * Wed Mar 18 2020 Sumit Bose  - 0.9.0-1
  - Update to upstream release 0.9.0 and latest patches


Package:  awscli-1.18.23-1.fc33
Old package:  awscli-1.18.22-1.fc33
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.70 MiB
Size change:  231 B
Changelog:
  * Wed Mar 18 2020 Gwyn Ciesla  - 1.18.23-1
  - 1.8.23


Package:  azove-2.0-19.fc33
Old package:  azove-2.0-18.fc32
Summary:  Another Zero-One Vertex Enumeration tool
RPMs: azove
Size: 233.15 KiB
Size change:  -10.15 KiB
Changelog:
  * Wed Mar 18 2020 Jerry James  - 2.0-19
  - Add -memory and -map patches
  - Build with RPM_LD_FLAGS


Package:  beaker-27.3-1.fc33
Old package:  beaker-27.2-1.fc33
Summary:  Full-stack software and hardware integration testing system
RPMs: beaker

[Bug 1794749] perl-EV-4.33 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1794749
Bug 1794749 depends on bug 1814655, which changed state.

Bug 1814655 Summary: libev-4.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814655

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Should logrotate timer be enabled by default on all installations?

[Kamil Dudka]

On Wednesday, March 18, 2020 3:50:34 PM CET Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 18, 2020 at 01:04:58PM +0100, Kamil Dudka wrote:
> 
> > logrotate is a utility designed to simplify the administration of log
> > files on 
 a system which generates a lot of log files.  It used to be
> > triggered by cron. The cron hook was unconditionally installed with
> > logrotate but it took effect only if a cron daemon was installed.
> > 
> > Starting with Fedora 30, logrotate is triggered by a systemd timer
> > instead.  
 In order to make updates smoother, the timer was enabled on
> > updates in case a cron daemon was configured on the system.
> > 
> > The timer is currently not enabled on fresh installs to avoid surprises
> > (such 
 as data lost) on systems where logrotate is installed but not
> > actually used. logrotate can also be triggered independently of
> > systemd/cron and can be even run by non-privileged users to rotate logs
> > they have access to.
> > 
> > Some people think that the logrotate timer should be enabled by default on
> > all 
 systems where the logrotate package is installed:
> > 
> > 
> > https://bugzilla.redhat.com/1655153#c4
> > 
> > 
> > Do you think it would be a good idea?
> 
> 
> Yes, I think it's reasonable to enable it by default. People should just
> not
 install logrotate package if it's not necessary. We should also make
> sure that the package is not Required from those packages that use the
> journal. 
> (I think that for most cases text logs are not necessary, and journald
> is a better approach, but for the cases where text logs are created,
> logrotate is something that people want 99% of the time, so we should
> make it easy to have the right thing happen if the package is installed.)
> 
> Note: we have a documented process for enabling services:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/.
> logrotate.timer satisfies the requirements to be enabled without a fesco
> exception. So it should be enough to file a PR for fedora-release. 
> Zbyszek

Thank you all for sharing your opinion on this!

I have opened a pull request to enable logrotate.timer by default:

https://src.fedoraproject.org/rpms/fedora-release/pull-request/111

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Pavel Raiskup]

On Thursday, March 19, 2020 1:27:11 PM CET Richard Shaw wrote:
> > You bild for epel-7-x86_64, but on Fedora?
> 
> Yes, as a Fedora packager supporting both Fedora and EPEL I need the ability
> to do test builds on my system without needlessly abusing koji.

Ok, I just wanted confirmation it is not el7 -> el7 build.

> Thank you very much for the explanation, but what's the solution?

We need to fix the bug I'm afraid.  If anyone can submit PR, it is
welcome..  otherwise I hope I'll get to it this or the next week.

> I tried adding the following to one of the EPEL 7 cfg files to no avail:
> 
> config_opts['use_bootstrap'] = True
> config_opts['package_manager'] = 'yum'

That sounds like the correct (the default in mock-core-conifgs) config.
At the same time, you seem to be using --resultdir option - which for some
reason triggers the problem.  Try to run mock without the option for now.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Richard Shaw]

On Thu, Mar 19, 2020 at 3:07 AM Pavel Raiskup  wrote:

> On Thursday, March 19, 2020 2:16:46 AM CET Richard Shaw wrote:
> > On Wed, Mar 18, 2020 at 8:04 PM Sérgio Basto  wrote:
> >
> > > On Thu, 2020-03-19 at 00:55 +, Sérgio Basto wrote:
> > >
> > > On Wed, 2020-03-18 at 19:45 -0500, Richard Shaw wrote:
> > >
> > > Things have been somewhat rough with building packages lately between
> > > configs that don't work and such..
> > >
> > > Now all the logs I see using "fedpkg mockbuild" have all the log lines
> > > doubled. I searched the mailing list and didn't find anything.
> > >
> > > Am I the only one seeing this?
> > >
> > >
> > > https://github.com/rpm-software-management/mock/issues/73 ?
> > >
> > >
> > > Correct, uncheck "Enable mock's use_bootstrap_container experimental
> > > feature" and no more double lines in build.log.gz .
>
> >  That sounds like the COPR option... I'm just using plain "mock" or
> "fedpkg
> > mockbuild".
>
> Yes, originally the bug is about Copr, but it is also 'use_bootstrap' mock
> config option, which has --bootstrap-chroot/--no-bootstrap-chroot
> commandline
> option atlernative.  The --bootstrap-chroot is the default now in mock:
> https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.0
>
> > Meanwhile trying to do a test build of fail2ban for EPEL 7 via fedpkg
> > mockbuild...
>
> You bild for epel-7-x86_64, but on Fedora?
>

Yes, as a Fedora packager supporting both Fedora and EPEL I need the
ability to do test builds on my system without needlessly abusing koji.

Thank you very much for the explanation, but what's the solution?

I tried adding the following to one of the EPEL 7 cfg files to no avail:

config_opts['use_bootstrap'] = True
config_opts['package_manager'] = 'yum'

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: bodhi web interface (not associating bugzilla entries)

[José Abílio Matos]

On Thursday, 19 March 2020 11.05.18 WET Tom Hughes wrote:
> Are you using a browser extension like uMatrix that may be blocking
> the cross domain query from bodhi to bugzilla?
> 
> Tom

The only extension that I am using, and could potentially do that, is EFF's 
Privacy Badger.

I will try a new update to see if the badger complains.
OK I have disable the Privacy Badger for bodhi and now it works.  :-)

Thank you for heading me in the right direction.
-- 
José Abílio

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone seen build hangs (esp armv7, s390x) in Fedora?

[Sumit Bose]

On Thu, Mar 19, 2020 at 08:37:31AM +, Richard W.M. Jones wrote:
> On Wed, Mar 18, 2020 at 11:39:37AM +0100, Dan Horák wrote:
> > On Wed, 18 Mar 2020 09:50:24 +
> > "Richard W.M. Jones"  wrote:
> > 
> > > On Wed, Mar 18, 2020 at 10:46:19AM +0100, Dan Horák wrote:
> > > > On Wed, 18 Mar 2020 09:34:45 +
> > > > "Richard W.M. Jones"  wrote:
> > > > 
> > > > > 
> > > > > This might be a bug in the package itself, but has anyone seen
> > > > > builds hanging in weird places, in Rawhide, especially on armv7
> > > > > and s390x?
> > > > > 
> > > > > This packge build has hung 3 times in the same place, once on
> > > > > armv7 and twice on s390x:
> > > > > 
> > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42570766
> > > > > 
> > > > > It's hard to explain how it could hang at that place in the build
> > > > > unless something fundamental is broken like make.
> > > > 
> > > > let me try the rebuild locally on s390x ...
> > > 
> > > Note that the build did succeed once on s390x (that was when it hung
> > > on armv7 instead).  So it's not 100% reproducible.  Also if our theory
> > > about tooling is correct then you would need all Rawhide packages.
> > 
> > it's a deadlock in the tests, not in make. Reproduced with
> > "fedpkg local" in a cycle.
> > 
> > sharkcz  1649225  0.0  0.0 88  3904 pts/5S+   06:24   0:00 /bin/sh 
> > -e /var/tmp/rpm-tmp.RXcMRr
> > sharkcz  1649230  0.0  0.0  10372  3248 pts/5S+   06:24   0:00 make -j4 
> > check
> > sharkcz  1658088  0.0  0.0 251236  3400 pts/5Sl+  06:25   0:00 
> > /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P 
> > test-nbd-tls-psk.pid1 -U /tmp/tmp.7e7Gv5MPmZ --tls=require 
> > --tls-psk=keys.psk -- 
> > /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/example1/.libs/nbdkit-example1-plugin.so
> > sharkcz  1658091  0.0  0.1 192944  4464 pts/5Sl+  06:25   0:00 
> > /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P 
> > test-nbd-tls-psk.pid2 -U /tmp/tmp.yp61yXx09y --tls=off -- 
> > /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/nbd/.libs/nbdkit-nbd-plugin.so 
> > tls=require tls-psk=keys.psk tls-username=qemu socket=/tmp/tmp.7e7Gv5MPmZ
> > 
> > the 2 nbdkit processes are stuck in the futex() syscall
> > 
> > Some years ago there was a kernel bug with the same symptoms. All
> > arches were affected, but mostly visible on s390x and armv7.
> 
> In fact this happens on x86-64.  I was able to reproduce it
> locally.  Investigating now.

Hi,

jfiy, I have two builds with similar behavior as well:

 - https://koji.fedoraproject.org/koji/taskinfo?taskID=42581593 f33 i686
 - https://koji.fedoraproject.org/koji/taskinfo?taskID=42600523 f32 aarch64

both are stuck in tests. Trying to reproduce locally.

bye,
Sumit

> 
> Thanks,
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Beware: java-1.8.0-openjdk SIGSEGVs / SIGABRTs in rawhide

[Guido Aulisi]

Il giorno gio, 19/03/2020 alle 12.07 +0100, Iñaki Ucar ha scritto:
> Yet another gcc10-related headache... I'm experiencing issues
> building rstudio in rawhide for i686: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42614405. But I
> believe this is not the best package to chase the bug. No issues so
> far in F32, but you said this fails randomly?
> 
> Iñaki
> 

snip

I had problems with package sord and gcc 10, but not building, runtime,
when building other packages that use sord.
Doing test sord segfaulted in a for loop with iterators, where the end
conditions calls a function, which IMO is optimized out (?).
I had to compile with -O1 to get it working [0].
This only happened on ppc64le, arm, aarch64.

Guido
FAS: tartina

[0]: 
https://src.fedoraproject.org/rpms/sord/c/0a9adfc498d2e3cfcb3c8e67e53463beefdb10ff?branch=master


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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Beware: java-1.8.0-openjdk SIGSEGVs / SIGABRTs in rawhide

[Iñaki Ucar]

Yet another gcc10-related headache... I'm experiencing issues building
rstudio in rawhide for i686:
https://koji.fedoraproject.org/koji/taskinfo?taskID=42614405. But I believe
this is not the best package to chase the bug. No issues so far in F32, but
you said this fails randomly?

Iñaki

On Sun, 15 Mar 2020 at 15:10, Fabio Valentini  wrote:

> Hi everybody,
>
> The latest java-1.8.0-openjdk update for rawhide (the first build with
> GCC 10) seems to have introduced some serious problems - including
> crashes and segmentation faults during package builds for Java
> packages.
>
> The broken update landed in rawhide with the
> Fedora-Rawhide-20200313.n.0 compose:
> java-1.8.0-openjdk-1:1.8.0.242.b06-0.0.ea.fc32 ->
> java-1.8.0-openjdk-1:1.8.0.242.b08-0.fc33
>
> I haven't been able to reproduce the crashes reliably, so I assume
> it's something that's either randomly triggered, or dependent on the
> specific hardware / architecture (but this seems to affect at least
> x86_64, i686, and aarch64, so I'm not so sure it's architecture
> related).
>
> koschei started complaining about a whole lot of Java packages since
> the update landed:
>
>
> https://koschei.fedoraproject.org/affected-by/java-1.8.0-openjdk-headless?epoch1=1=1.8.0.242.b06=0.0.ea.fc32=1=1.8.0.242.b08=0.fc33=f33
>
> The same java-1.8.0-openjdk update has also landed in f32
> updates-testing, but I haven't been able to reproduce any crashes with
> that version (so far), so I'm not sure if this is also affecting the
> f32 update, or if it's isolated to rawhide.
>
> Here's the - seemingly unaffected - f32 update for the same version:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-af190951f6
>
> I've reported this issue here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1813550
>
> Does somebody have experience with debugging the JVM? Please help :D
>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1794749] perl-EV-4.33 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Depends On||1814655




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1814655
[Bug 1814655] libev-4.33 is available
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: bodhi web interface (not associating bugzilla entries)

[Tom Hughes via devel]

On 19/03/2020 10:19, José Abílio Matos wrote:


when entering a new update through the web interface of bodhi I do
not get the list of open bugs in bugzilla, no mater the wait. There is a
rotating symbol as it happens to select the build(s) but I continues without
any output.


Are you using a browser extension like uMatrix that may be blocking
the cross domain query from bodhi to bugzilla?

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-31-20200319.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

bodhi web interface (not associating bugzilla entries)

[José Abílio Matos]

Hi,
when entering a new update through the web interface of bodhi I do 
not get the list of open bugs in bugzilla, no mater the wait. There is a 
rotating symbol as it happens to select the build(s) but I continues without 
any output.

If I try to insert the bug number by hand the number shows below but it can 
not be selected either by mouse or by key cursor. After that first attempt it 
does not work anymore.

I am seing this on Fedora 32, but the same happened on Fedora 31 and I am 
using Firefox.

Is this known or should I fill an issue in github?

Regards,
-- 
José Abílio

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1814445] perl-Crypt-OpenSSL-EC-1.32 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-93df3e0e37 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-93df3e0e37

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1814445] perl-Crypt-OpenSSL-EC-1.32 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Crypt-OpenSSL-EC-1.32-
   ||1.fc33



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1814445] perl-Crypt-OpenSSL-EC-1.32 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Pavel Raiskup]

On Thursday, March 19, 2020 3:09:14 AM CET Sérgio Basto wrote:
> Now we can't use `config_opts['package_manager'] = 'dnf'` to build on epel 7 ,
> it is working for me , maybe just after add
> config_opts['use_bootstrap_image'] = True on ~/.config/mock.cfg 

Shortly, the `package_manager` option says what is the package manager of the
system you build for;  ie. YUM for epel-7 (el7 isn't DNF system, and you don't
want to set package_manager = dnf).

Longer story.
As package managers evolve, they are not back/forward compatible (YUM is not
compatible with new features in DNF, but even very old DNF may be incompatible
with future versions of itself).  From the other side, modern DNF may calculate
the install transactions for old YUM systems significantly differently
than YUM would.

So, since packages (and inter-dependencies) in buildroots are _customized_ for
proper version of the package manager included _in_ the buildroot - mock tries
to way around the compatibility problems by first installing _proper_ package
manager into bootstrap chroot, and using that package manager eventually install
the requested buildroot.  E.g.

  DNF(on Fedora) ---installs--> YUM(bootstrap el7) ---installs--> epel-7 chroot

When you say `package_manager = dnf` for el7, this happens:

  DNF(on Fedora) ---installs--> DNF(bootstrap el7) ---installs--> epel-7 chroot

.. but it fails, because there's no DNF in el7 by default.  You could set
`package_manager=dnf`, and `use_bootstrap=False`, that would:

  DNF(on Fedora) ---installs--> epel-7 chroot

But that would have the problem that the "installroot" order of
transaction isn't calculated as package maintainers in EL7 expected.

Slightly off topic;  the `use_bootsrap` isn't even enough for EL7 to build
Fedora nowadays.  Because e.g. fedora-33-x86_64 has
`package_manager = dnf`, mock would attempt to

  YUM(on host) ---installs--> DNF(bootstrap F33) --installs--> fedora-33 chroot

but YUM on el7 host can not install packages compressed by ZSTD in
bootstrap F33 chroot.  That's why `use_bootstrap_image` was invented - so
the bootstrap chroot doesn't have to be _installed_, but it is rather
_downloaded_ as podman image.  So this happens:

  podman (on host) --downloads--> DNF chroot ---installs---> F33 chroot

Hope that helps,
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Anyone seen build hangs (esp armv7, s390x) in Fedora?

[Richard W.M. Jones]

On Wed, Mar 18, 2020 at 11:39:37AM +0100, Dan Horák wrote:
> On Wed, 18 Mar 2020 09:50:24 +
> "Richard W.M. Jones"  wrote:
> 
> > On Wed, Mar 18, 2020 at 10:46:19AM +0100, Dan Horák wrote:
> > > On Wed, 18 Mar 2020 09:34:45 +
> > > "Richard W.M. Jones"  wrote:
> > > 
> > > > 
> > > > This might be a bug in the package itself, but has anyone seen
> > > > builds hanging in weird places, in Rawhide, especially on armv7
> > > > and s390x?
> > > > 
> > > > This packge build has hung 3 times in the same place, once on
> > > > armv7 and twice on s390x:
> > > > 
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42570766
> > > > 
> > > > It's hard to explain how it could hang at that place in the build
> > > > unless something fundamental is broken like make.
> > > 
> > > let me try the rebuild locally on s390x ...
> > 
> > Note that the build did succeed once on s390x (that was when it hung
> > on armv7 instead).  So it's not 100% reproducible.  Also if our theory
> > about tooling is correct then you would need all Rawhide packages.
> 
> it's a deadlock in the tests, not in make. Reproduced with
> "fedpkg local" in a cycle.
> 
> sharkcz  1649225  0.0  0.0 88  3904 pts/5S+   06:24   0:00 /bin/sh -e 
> /var/tmp/rpm-tmp.RXcMRr
> sharkcz  1649230  0.0  0.0  10372  3248 pts/5S+   06:24   0:00 make -j4 
> check
> sharkcz  1658088  0.0  0.0 251236  3400 pts/5Sl+  06:25   0:00 
> /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P test-nbd-tls-psk.pid1 
> -U /tmp/tmp.7e7Gv5MPmZ --tls=require --tls-psk=keys.psk -- 
> /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/example1/.libs/nbdkit-example1-plugin.so
> sharkcz  1658091  0.0  0.1 192944  4464 pts/5Sl+  06:25   0:00 
> /home/sharkcz/nbdkit/nbdkit-1.19.3/server/nbdkit -v -P test-nbd-tls-psk.pid2 
> -U /tmp/tmp.yp61yXx09y --tls=off -- 
> /home/sharkcz/nbdkit/nbdkit-1.19.3/plugins/nbd/.libs/nbdkit-nbd-plugin.so 
> tls=require tls-psk=keys.psk tls-username=qemu socket=/tmp/tmp.7e7Gv5MPmZ
> 
> the 2 nbdkit processes are stuck in the futex() syscall
> 
> Some years ago there was a kernel bug with the same symptoms. All
> arches were affected, but mostly visible on s390x and armv7.

In fact this happens on x86-64.  I was able to reproduce it
locally.  Investigating now.

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-30-20200319.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Pavel Raiskup]

On Thursday, March 19, 2020 2:16:46 AM CET Richard Shaw wrote:
> On Wed, Mar 18, 2020 at 8:04 PM Sérgio Basto  wrote:
> 
> > On Thu, 2020-03-19 at 00:55 +, Sérgio Basto wrote:
> >
> > On Wed, 2020-03-18 at 19:45 -0500, Richard Shaw wrote:
> >
> > Things have been somewhat rough with building packages lately between
> > configs that don't work and such..
> >
> > Now all the logs I see using "fedpkg mockbuild" have all the log lines
> > doubled. I searched the mailing list and didn't find anything.
> >
> > Am I the only one seeing this?
> >
> >
> > https://github.com/rpm-software-management/mock/issues/73 ?
> >
> >
> > Correct, uncheck "Enable mock's use_bootstrap_container experimental
> > feature" and no more double lines in build.log.gz .

>  That sounds like the COPR option... I'm just using plain "mock" or "fedpkg
> mockbuild".

Yes, originally the bug is about Copr, but it is also 'use_bootstrap' mock
config option, which has --bootstrap-chroot/--no-bootstrap-chroot commandline
option atlernative.  The --bootstrap-chroot is the default now in mock:
https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.0

> Meanwhile trying to do a test build of fail2ban for EPEL 7 via fedpkg
> mockbuild...

You bild for epel-7-x86_64, but on Fedora?

> Traceback (most recent call last):
>   File "/usr/bin/dnf", line 57, in 
> from dnf.cli import main
>   File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in
> 
> import dnf.base
>   File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in 
> import libdnf.transaction
>   File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in
> 
> from . import conf
>   File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in
> 
> _conf = swig_import_helper()
>   File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in
> swig_import_helper
> return importlib.import_module('_conf')
>   File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
> import_module
> __import__(name)
> ImportError: No module named _conf

I can not reproduce this on my F31.  I probably need more info.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1814532] perl-Encode-3.05 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Encode-3.05-444.fc33



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras. Pushing into older Fedoras is
postponed after stabilizing the previous release.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Pavel Raiskup]

On Thursday, March 19, 2020 1:55:39 AM CET Sérgio Basto wrote:
> On Wed, 2020-03-18 at 19:45 -0500, Richard Shaw wrote:
> > Things have been somewhat rough with building packages lately between
> > configs that don't work and such..
> > Now all the logs I see using "fedpkg mockbuild" have all the log
> > lines doubled. I searched the mailing list and didn't find anything.
> > 
> > Am I the only one seeing this? 
> 
> https://github.com/rpm-software-management/mock/issues/73 ?

Yes, this got re-reported here:
https://github.com/rpm-software-management/mock/issues/539
https://bugzilla.redhat.com/show_bug.cgi?id=1805631

Pavel

> > There's no way I would send this kind of crap to upstreams to figure
> > out problems with packages. 
> > 
> > I"m not trying to be an a-hole here, I'm sure everyone is working
> > very hard, but being a Fedora packager has been pretty rough for the
> > last several months. 
> > 
> > Thanks,
> > Richard
> > 
> > ___devel mailing list -- 
> > devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1814532] perl-Encode-3.05 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: mock: all log lines doubled?

[Fabio Valentini]

On Thu, Mar 19, 2020 at 1:46 AM Richard Shaw  wrote:
>
> Things have been somewhat rough with building packages lately between configs 
> that don't work and such..
>
> Now all the logs I see using "fedpkg mockbuild" have all the log lines 
> doubled. I searched the mailing list and didn't find anything.
>
> Am I the only one seeing this?
>
> There's no way I would send this kind of crap to upstreams to figure out 
> problems with packages.
>
> I"m not trying to be an a-hole here, I'm sure everyone is working very hard, 
> but being a Fedora packager has been pretty rough for the last several months.

I think this problem has been introduced with this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8c3f06d776

I submitted negative karma as soon as I noticed it (which is when
xmvn-builddep failed to parse the build.log), but it was too late

It indeed looks like this is an old issue hitting us again, as pointed
out in another response:
https://github.com/rpm-software-management/mock/issues/73

Fabio

> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F31 to F32

[Fabio Valentini]

On Thu, Mar 19, 2020 at 5:48 AM Samuel Sieb  wrote:
>
> On 3/18/20 5:14 PM, Solomon Peachy wrote:
> > Error: Transaction test error:
>
> There appears to be a packaging change causing this problem.
>
> >file /usr/share/widelands/i18n/fonts/DejaVu from install of 
> > widelands-0-0.76.build20.fc32.x86_64 conflicts with file from package 
> > widelands-0-0.72.build20.fc31.x86_64
>
> In the F31 version, /usr/share/widelands/i18n/fonts/DejaVu is a link to
> the system fonts directory.  In the F32 version, somehow it has become a
> real directory with font files in it.

This looks like a bug in the dejavu-fonts package. Please either chime
in in the bug about the incompatible packaging changes [0] or open a
new one.

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1806272

Fabio

> >file /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf conflicts between 
> > attempted installs of compat-f32-dejavu-sans-fonts-2.37-7.fc32.noarch and 
> > widelands-0-0.76.build20.fc32.x86_64
> >file /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf conflicts 
> > between attempted installs of 
> > compat-f32-dejavu-sans-fonts-2.37-7.fc32.noarch and 
> > widelands-0-0.76.build20.fc32.x86_64
> >file /usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf conflicts between 
> > attempted installs of compat-f32-dejavu-sans-fonts-2.37-7.fc32.noarch and 
> > widelands-0-0.76.build20.fc32.x86_64
>
> Since rpm can't replace the symlink, it's now trying to install the
> included files into the system fonts directory instead of in the
> widelands one.
>
> > ...Why is the 'widelands' package bundling fonts?
>
> Given that they're in an i18n directory, I assume it's trying make sure
> it has sufficient font coverage for different languages.  Also, the
> widelands special font is in there as well.  I don't see why they
> couldn't be split out though.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1806619] Non-responsive maintainer check for normunds

[bugzilla]

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

Fedora Admin XMLRPC Client  changed:

   What|Removed |Added

   Assignee|fedora...@rule.lv   |s...@techie.net



--- Comment #1 from Fedora Admin XMLRPC Client  
---
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org